Is this possible?
- Thread starter Inca
- Start date
How about you encrypt something using a bitcoin public key as the encryption key. Now someone pays into the bitcoin address (which, to review, is the SHA256 of the public key not the public key). Now you eventually "accept" the money paid by creating a txn to send it somewhere else. That txn reveals the bitcoin public key which can therefore be used to decrypt the data.
So its sort of like an escrow without recourse... if the "seller" never accepts then the data remains hidden and the money is unusable.
You could maybe add multisig and nLockTime into the mix to allow the buyer to get his money back if the seller doesn't choose to buy after a time.
EDIT: you could XOR or append a shared secret into the public key to create the encryption key to keep the data hidden from everyone else
So its sort of like an escrow without recourse... if the "seller" never accepts then the data remains hidden and the money is unusable.
You could maybe add multisig and nLockTime into the mix to allow the buyer to get his money back if the seller doesn't choose to buy after a time.
EDIT: you could XOR or append a shared secret into the public key to create the encryption key to keep the data hidden from everyone else
frankenmint
New Member
what kind of data? From what I recall the op_return allows you to store about 80 Bytes. if you could encrypt your data somehow with a signed message from the payor (you would have to have a copy of this in advance to use to encrypt the message) then you should be able to do what you're asking. Though your situation only seems to make sense if you're someplace such as a hostile country where your data is being monitored - why not just use pgp?
- Aug 28, 2015
- 517
- 1,679
I want to pass info to a buyer from a seller in a trustless way, where the server does not know the contents of the info because it is encrypted by a key, but also only the buyer who paid a btc transaction can securely decrypt the info. Ideally the server should just hold the encrypted info which is assumed to be public and vulnerable.
The info could just be a key.
Last edited:
Is the idea here that you have a file uploaded beforehand, and then want to sell access to that data multiple times?
Some issues, ideas:
1. Keep the data private to only that buyer
Seller encrypts the document's decrypt key with the public key of one of the outputs the buyer used to transfer BTC to purchase the document, and adds this information into the transaction (via OP_RETURN?) that "accepts" the money (moves it from the nLockTime addess to one controlled solely by the seller). Buyer sees this txn, decrypts the data key, and uses that to decrypt the data.
OFC, the seller could just take the money without putting the document's decrypt key in OP_RETURN... but he could also just fill the document with garbage so the buyer must presume some good faith on the part of the seller.
2. a buyer can't verify beforehand that the data is real.
One solution to this issue is to break the data into chunks and the buyer could buy a chunk, verify it, and then buy another. Ofc, this requires that the data be both incrementally valuable and verifiable in portions.
You would need to protect both against the data being junk, and against the seller cheating on the last txn (not providing the decrypt key). The way to do this would be to break the document into rising and falling power of 2 chunks. For example, the document could be broken into chunks of size:
1,2,4,8,16,8,4,2,1
payment for each chunk would be proportional to the size of the chunk/total document size.
3. The buyer could give his decryption key to others.
You could require the buyer to put bitcoin in an address corresponding to the decryption key. Anyone who is given the decryption key could steal the buyer's coins... the server monitors this address and pulls the document when the coins disappear.
Ofc the buyer could just download and decrypt the document and then send it to whoever he wants. So
this idea only works if what you are selling is the bandwidth (the access), or if the "document" is actually rapidly changing data whose value diminishes rapidly.
Some issues, ideas:
1. Keep the data private to only that buyer
Seller encrypts the document's decrypt key with the public key of one of the outputs the buyer used to transfer BTC to purchase the document, and adds this information into the transaction (via OP_RETURN?) that "accepts" the money (moves it from the nLockTime addess to one controlled solely by the seller). Buyer sees this txn, decrypts the data key, and uses that to decrypt the data.
OFC, the seller could just take the money without putting the document's decrypt key in OP_RETURN... but he could also just fill the document with garbage so the buyer must presume some good faith on the part of the seller.
2. a buyer can't verify beforehand that the data is real.
One solution to this issue is to break the data into chunks and the buyer could buy a chunk, verify it, and then buy another. Ofc, this requires that the data be both incrementally valuable and verifiable in portions.
You would need to protect both against the data being junk, and against the seller cheating on the last txn (not providing the decrypt key). The way to do this would be to break the document into rising and falling power of 2 chunks. For example, the document could be broken into chunks of size:
1,2,4,8,16,8,4,2,1
payment for each chunk would be proportional to the size of the chunk/total document size.
3. The buyer could give his decryption key to others.
You could require the buyer to put bitcoin in an address corresponding to the decryption key. Anyone who is given the decryption key could steal the buyer's coins... the server monitors this address and pulls the document when the coins disappear.
Ofc the buyer could just download and decrypt the document and then send it to whoever he wants. So
this idea only works if what you are selling is the bandwidth (the access), or if the "document" is actually rapidly changing data whose value diminishes rapidly.
i find this interesting. after looking around a bit, i found this blog post by Ken Schirrer who's done some interesting work on the blockchain. i never understood exactly how some sorts of data got embedded before and he explains it pretty well here:
http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html
The data is stored in the blockchain by encoding hex values into the addresses. Below is an excerpt of one of the transactions storing the Mandela information. In this transaction, tiny amounts of bitcoins are being sent to fake addresses such as 15gHNr4TCKmhHDEG31L2XFNvpnEcnPSQvd. This address is stored in the blockchain as hex 334E656C736F6E2D4D616E64656C612E6A70673F. If you convert those hex bytes to Unicode, you get the string 3Nelson-Mandela.jpg?, representing the image filename. Similarly, the following addresses encode the data for the image. Thus, text, images, and other content can be stored in Bitcoin by using the right fake addresses.
http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html
The data is stored in the blockchain by encoding hex values into the addresses. Below is an excerpt of one of the transactions storing the Mandela information. In this transaction, tiny amounts of bitcoins are being sent to fake addresses such as 15gHNr4TCKmhHDEG31L2XFNvpnEcnPSQvd. This address is stored in the blockchain as hex 334E656C736F6E2D4D616E64656C612E6A70673F. If you convert those hex bytes to Unicode, you get the string 3Nelson-Mandela.jpg?, representing the image filename. Similarly, the following addresses encode the data for the image. Thus, text, images, and other content can be stored in Bitcoin by using the right fake addresses.
I think theZerg's suggestion would work. For testing, just XOR your secret with the pubkey (like he said). When you make the transaction, the pubkey is exposed and the secret can be decrypted.
- Aug 28, 2015
- 517
- 1,679
Aim is to trustlessly transfer a digital asset from buyer to seller. Idea is to encrypt the file using the blockchain, accept payment and release the file decrypted or with key to buyer entirely using bitcoin chain for security.
Buyer and seller never communicate directly. Server should ideally never see the file decrypted or need to store private keys which could be exposed.
My problem is that the server will need to hold and generate private keys (well at least one newly created ECDSA keypair) during this process (unless the seller can provide this) and if which compromised could be used to decrypt the file. There is some trust that the server is secure.
I'll have a play this weekend. Just a fun project!
Buyer and seller never communicate directly. Server should ideally never see the file decrypted or need to store private keys which could be exposed.
My problem is that the server will need to hold and generate private keys (well at least one newly created ECDSA keypair) during this process (unless the seller can provide this) and if which compromised could be used to decrypt the file. There is some trust that the server is secure.
I'll have a play this weekend. Just a fun project!
Stereotype
New Member
- Aug 28, 2015
- 17
- 7
I invited jl777 (James) to comment. He has done alot of this kind of coding for NXT. I believe he can cross-over to Bitcoin, with this issue.