1

Ok, I know that blockchain is public knowledge. But, than, there are experiments like zcash which encrypt sender receiver and amount information and they still work.

I'm considering whether p2p blockchain arbitration service is possible. For example, you want to exchange ETH for BTC. A blockchain generates 2 addresses, one of which is for BTC, other is for ETH. Once both addresses are funded, funds of both are forwarded to the recipients. To do this via blockchain, there should be a secure way to store and use private keys on blockchain.

Is this completely impossible, or are there any indications that one could do something like that?

  • 1
    Yes. There are examples of people attaching binary files into the blockchain. If you encrypt the private keys, then you can store them on the blockchain. If you use public key cryptography, encrypt it with someone's public key and only they can decrypt it. If you use symmetric key encryption, encrypt it with a password then tell someone the password. All of this is not recommended however. – Chloe Mar 17 '17 at 0:32
1

There is no encryption involved anywhere in a blockchain. There are no keys to encrypt with, as every node has the same information as all others. Cryptography is involved, but for signing/proving. Not for encrypting.

Even in the zcash case, encryption is not involved. All wallets do is prove to the rest of the network that they had the funds they're spending. The only difference compared to Bitcoin is that it reveals less information in doing so, and as a result, the proofs are much more complex.

blockchains don't generate private keys - that doesn't make sense, as the chain can be seen by everyone.

Wallets do have private keys. They're never shared with anyone. They hand out the corresponding public keys in order to be paid, and use the private key to later prove to others they own certain coins.

The example you're describing with an exchange occurring between two chains is possible using a technique called cross-chain atomic swap. It relies on a hashlocked​ transaction where the first wallet that moves its money out on one chain reveals a random value that hashes to a value that is known ahead of time. The other party then uses this preimage to unlock funds on the other side.

1

Someone proposed something similar, posting encrypted files on IPFS network (public like say the Ethereum blockchain) and then sending keys to the participants to decrypt.

The founder Juan Bennet highlighted the following quote:

'Naive example: encrypt the file with some secret, and share the secret with the people who have "read permission"'

https://github.com/ipfs/ipfs/issues/86

What you really need is a decentralised capability system.

https://github.com/autocontracts/permissioned-blocks/blob/master/whitepaper.md

(Disclaimer, this is a white paper I wrote)

-1

It is not recommended to send a private asymmetric key as a blockchain transaction (which is a communication channel) in this manner.

There is a good paper on key exchanges here:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.6107&rep=rep1&type=pdf

In this paper the author makes also makes it clear that sending a private key over a channel is not good design:

"When a key is sent in a message, only the public key is used, to be explicit... None of the protocols studied in this paper ever send a secret key over the wire"

https://dominictarr.github.io/secret-handshake-paper/shs.pdf

Public keys are designed for sending over a channel. Not the private key. Encryption can be broken by brute force. Once someone has the private key they can decrypt everything that was encrypted with that key.

  • 1
    Thanks for contributing but this answer doesn't provide enough detail to be useful – Highly Irregular Oct 15 '17 at 21:58
  • 1
    I have updated my comment with some links. – Michael Smolenski Oct 16 '17 at 7:54
  • This answer would be better if you explained that the blockchain is being used as a channel, and therefore the sources you cite are relevant. This is difficult for a casual observer to pick up on, which is probably why you've been downvoted. – Jestin Oct 16 '17 at 21:40
  • Thanks @Jestin. Yeah I was down voted before I put the links in explaining what I was meaning. First comment was "It is not recommended to send encrypted private keys over a channel" - without a reason. Up vote if you think the answer is better now :-) – Michael Smolenski Oct 17 '17 at 14:44
  • The connection that is hard for people to make is blockchain data == channel. It's a connection I think you've assumed people make, but I doubt they all do. A sentence explaining this would help, especially since the term "channel" in this forum is more often used to mean "payment channel". – Jestin Oct 17 '17 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.