Is this possible?

[Inca]

Is it possible to natively place a small amount of data in the bitcoin blockchain such that it can be hidden until a transaction with another party completes to a specified amount?

 

[cypherdoc]

Not currently that I've heard of.

A link would help.

 

[theZerg]

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

 

[frankenmint]

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?

 

[cypherdoc]

Now someone pays into the bitcoin address (which, to review, is the SHA256 of the public key not the public key).

to be precise, it's the ripemd160(sha256(pubkey)) or hash160 of the pubkey.

 

[Inca]

Excellent thoughts guys, especially thezerg. I just refamiliarised myself with the bitcoin.org dev page and you are quite right cypher it is a 160 bit double hash of the pubkey.

I think I will have a play with some python this weekend..

 

[Inca]

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?

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.

 

[theZerg]

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.

 

[cypherdoc]

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.

 

[cypherdoc]

how about using BIP38 password protected privkeys for your use case?

 

[Inca]

Still thinking about how to go about it!

 

[cypherdoc]

@Inca

tell us exactly what you want to do!

 

[Peter R]

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.

 

[Inca]

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!

 

[jacksonmr]

@Inca

please post your findings, this sounds like it has potential for simple transactions on the blockchain. I'm curious!

 

[Stereotype]

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.

 

[Dlam9090]

** Swift Fox Coder: Your Trusted Partner in Digital Security**

After losing access to my cryptocurrency wallet, I felt completely lost. That’s when I discovered Swift Fox Coder, and it changed everything for me. Their experienced team delivered tailored solutions that not only helped recover my assets but also strengthened my online security.

The crypto recovery process was thorough and transparent, with frequent updates that kept me in the loop. I was impressed by their dedication to confidentiality, and even after the recovery, their 24/7 support was available to address any remaining questions.

Thanks to Swift Fox Coder, I not only regained my assets but also gained essential insights into digital security. I highly recommend their services to anyone experiencing similar challenges.

**Services Provided:**
- Social Media & Account Recovery
- Data Recovery & Modification
- Credit Score Enhancement
- Phone Location Services
- Hacking and Tracking
- School Grade Adjustments
- Cryptocurrency Recovery, and more!

**Reach Out Today!**
For more information: https://rb.gy/2kix6z
Email: swiftfoxcoder@gmail.com
Telegram: Techfox99