Idea: selling files with bitcoin

[boukeversteegh]

The following mechanism would allow people to sell files for Bitcoin, without requiring trust.

- a seller encrypts a file with the public key of a bitcoin address he owns
- a buyer downloads the file from the seller, but cannot open the file yet
- the buyer makes a payment to the seller's address
- for the seller to ever spend his payment, he needs to publish his public key
- using the public key, the buyer can decrypt the file

Use case:
- trading files online
- unfortunately, also ransomware

Advantages:
- the seller cannot access the payment without allowing the buyer to access the file
- the buyer has some assurance that his payment will not be wasted

Disadvantages:
- this mechanism doesn't let the parties agree on a price before the transaction is made. it is up to the seller whether to accept the payment, after the fact.
- the seller could refuse the payment, then the buyer lost his money and still cannot access the file
- if the encrypted file was hosted publicly, anyone else could also decrypt it, once the seller claims his payment

Possible improvements:
- use nLockTime to ensure that the seller takes the payment (transfers it to another address), or that the buyer will get his money back.

Do you think this is possible, or did I miss something important?

[Muhammed Zakir]

To decrypt a file encrypted with a public key, you need private key associated with it.

How can we assure seller actually share the private key with buyer after getting payment? nLockTime won't work here but with OP_CHECKLOCKTIMEVERIFY^[1] because nLockTime transaction can be invalidated by using those inputs in other transactions.

[1] https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

[amaclin]

To decrypt a file encrypted with a public key, you need private key associated with it.

ECDSA used in bitcoin is signing/verifying algorithm. It can not be used for encryption/decryption at all

[Muhammed Zakir]

To decrypt a file encrypted with a public key, you need private key associated with it.

ECDSA used in bitcoin is signing/verifying algorithm. It can not be used for encryption/decryption at all

If you know public key, then yes, you can encrypt/decrypt messages.

-snip-

As for the encryption aspect... I don't see why the ECDSA signature keys can't be used as encryption keys.  The BTC ECDSA is based on a NIST-blessed elliptic curve (secp256k1), and you have a public-key-point and private-key on that curve.  If it's secure for signing, it will be at least very secure for encryption. 

Despite being a mathematician and studied cryptography before, I'm not a black-hat kind of guy.  I know that this will be very secure, but I don't know if there's maybe weaknesses in using a recommende ECDSA curve for encryption.  I just know it's possible to use it, and the security of the signature process implies a high degree of security in the encryption process.

-Eto

Elliptic Curve DSA and Elliptic Curve encryption are almost as closely related to one another as signing and encryption in RSA. 

   RSA Signing and Decryption:        both are exponentiation mod N with the private key
   RSA Verification and Encryption:   both are exponentiation mod N with the public key

In ECDSA and ECIES, the key-pair relationship is similar, but instead of simple exponentiation mod N, you're applying a different mathematical equation for all four operations (signing, verification, encrypting, decrypting).  The only real difference is that NIST has blessed different elliptic curves for ECDSA and ECIES.  That doesn't meant that the secp256k1 curve can't be used for encryption, it just means that people smarter than us have decided that different curves should be used for cryptography and signing. 

Unfortunately, in my graduate cryptography class, we didn't dive into elliptic curves far enough for me to know what kinds of vulnerabilities there are with naive elliptic curve selection, but there was also no reason why security of the two would be different on the same curve.  I would say that the security of ECDSA keys on the secp256k1 curve will provide sufficient security for encryption as well.  I wouldn't guard nuclear launch codes with it, but I would venture that your 256-bit key will give you at least 128-bits of security.

A more-likely explanation is that the security is actually identical between the two.  But it's standard practice in cryptographic protocols/implementations to use different keys for signing and encryption.  Perhaps this is why NIST chose two different curves:  so that if you decide to use NIST curves, you can't pick the same key for both, even if you wanted to.

But as has been said before:  you don't have the person's public key until they either give it to you, or you see a transaction signed with it.  Having their BTC address is not enough.

-Eto

Additional links:

• https://bitcointalk.org/index.php?topic=196378.0
• https://bitcointalk.org/index.php?topic=145098

[boukeversteegh]

To decrypt a file encrypted with a public key, you need private key associated with it.

[1] https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

Ah, yes of course, but I was actually thinking about symmetric encryption. The public key would be used for both encrypting it, and decrypting. In that case, it would work and the seller MUST publish the encryption key to spend the money, since it is his public key, which is published upon signing the transaction.

[Muhammed Zakir]

Ah, yes of course, but I was actually thinking about symmetric encryption. The public key would be used for both encrypting it, and decrypting. In that case, it would work and the seller MUST publish the encryption key to spend the money, since it is his public key, which is published upon signing the transaction.

Actually, buyer should give the public key to seller to encrypt it. But in this way, either buyer or seller need to send first. So what is to be done to avoid middleman?

[boukeversteegh]

the whole point of my proposal is that it avoids a middle man..

to say again:

- the seller encrypts the file symmetrically with his public key
- the buyer sends bitcoin to the associated bitcoin address
- the seller must publish the public key of the address to spend the payment

no middle are necessary

however, another issue with it is that the buyer has no guarantee that the file was actually encrypted with the address'es pubkey

[belcher]

The idea sounds a lot like darkleaks

https://medium.com/@ZozanCudi/darkleaks-information-blackmarket-1ee5ac28c892
https://github.com/darkwallet/darkleaks

There's a lot of hype and PR there, but it's a good idea nonetheless. OP_CTLV is needed to fix crucial incentive problems though.

Looks like development has stopped in the very early stages so don't be disheartened that someone else came up with the idea already.

[boukeversteegh]

The idea sounds a lot like darkleaks

https://medium.com/@ZozanCudi/darkleaks-information-blackmarket-1ee5ac28c892
https://github.com/darkwallet/darkleaks

There's a lot of hype and PR there, but it's a good idea nonetheless. Looks like development has stopped so don't be disheartened that someone else came up with the idea already.

Pretty awesome, the basic mechanism is the same. Thanks for pointing out this project. Now I know someone is working on this, my mind is at ease

[Muhammed Zakir]

the whole point of my proposal is that it avoids a middle man..

to say again:

- the seller encrypts the file symmetrically with his public key
- the buyer sends bitcoin to the associated bitcoin address
- the seller must publish the public key of the address to spend the payment

no middle are necessary

however, another issue with it is that the buyer has no guarantee that the file was actually encrypted with the address'es pubkey

Wait a minute... so if the file is encrypted with seller's public key, how can buyer decrypt it? Am I missing something?

[belcher]

Now I know someone is working on this

Yeah... about that...

https://github.com/darkwallet/darkleaks/commits/master

[achow101]

the whole point of my proposal is that it avoids a middle man..

to say again:

- the seller encrypts the file symmetrically with his public key
- the buyer sends bitcoin to the associated bitcoin address
- the seller must publish the public key of the address to spend the payment

no middle are necessary

however, another issue with it is that the buyer has no guarantee that the file was actually encrypted with the address'es pubkey

Wait a minute... so if the file is encrypted with seller's public key, how can buyer decrypt it? Am I missing something?

It uses symmetric encryption which is "normal" encryption. It only needs one key, which can be the public key in this case.

[hexafraction]

Wait a minute... so if the file is encrypted with seller's public key, how can buyer decrypt it? Am I missing something?

The encryption itself is symmetric, for example AES. When the address is created, and the file encrypted, the owner of the file knows the private key for that address, the public key for same address, and the HASH160 of that public key. The HASH160 (and hash160 only) is published, and in Base58check encoding it becomes the address to which the buyer must pay. The file is encrypted with AES with the public key as the AES symmetric key, and the encrypted file is published openly.

In order for the seller to use the coins that they received for the file, they must create a transaction. This transaction will make the public key to that address available (since it wasn't before, only a hash was). In this manner, the seller can't do anything with the payment without releasing the file/data.

The issue I'm seeing here, however, is how to verify that the file contents are not bogus. A seller giving the key to a nonsense/dummy file is no better than a seller not giving the file to begin with in the old scheme.

[MrHighlands]

After reading through the OP it seems that you are looking this in a manner that seems to be over complicated and bothersome for the average consumer of said 'file'.

There is a much simpler approach to this.

A trusted website where a producer of a 'file' can upload said 'file' to the website. This file is then sold via the website, the buyer get's the link to the purchase page from the seller. Once on this page he clicks "buy now" (or something to that effect) a unique bitcoin address is generated and the buyer is asked to transfer the asking price for the 'file' to this address, after a certain number of confirmations the file is released and the buy can download said 'file'.

The seller can have automatic withdrawals set up so that once a product has been bought and confirmed through the website. The BTC that was sent is then forwarded to the seller minus whatever commission the site is charging for providing this service.

The file contents would also be verified by the operators of the website and there is a review system so that buyers can review the file they have bought.

[achow101]

After reading through the OP it seems that you are looking this in a manner that seems to be over complicated and bothersome for the average consumer of said 'file'.

There is a much simpler approach to this.

A trusted website where a producer of a 'file' can upload said 'file' to the website. This file is then sold via the website, the buyer get's the link to the purchase page from the seller. Once on this page he clicks "buy now" (or something to that effect) a unique bitcoin address is generated and the buyer is asked to transfer the asking price for the 'file' to this address, after a certain number of confirmations the file is released and the buy can download said 'file'.

The seller can have automatic withdrawals set up so that once a product has been bought and confirmed through the website. The BTC that was sent is then forwarded to the seller minus whatever commission the site is charging for providing this service.

The file contents would also be verified by the operators of the website and there is a review system so that buyers can review the file they have bought.

There are already sites that do this, but what the OP is doing is going for a trustless approach. Your suggestion (also widely used) requires trusting a third party. They have to trust that that third party doesn't read the contents of the files, and for the third party to release the file to the buyer and to release the funds to the seller. The trustless system suggested here is to remove that middleman who is also collecting commission. It allows the buyer and seller to buy and sell files while also giving an incentive to not scam.

[hexafraction]

There are already sites that do this, but what the OP is doing is going for a trustless approach. Your suggestion (also widely used) requires trusting a third party. They have to trust that that third party doesn't read the contents of the files, and for the third party to release the file to the buyer and to release the funds to the seller. The trustless system suggested here is to remove that middleman who is also collecting commission. It allows the buyer and seller to buy and sell files while also giving an incentive to not scam.

There's no incentive not to scam. Say that someone is looking for, say, a program to do foo. I can upload a file of roughly the same size as one would expect from such a program, but fill it with random data, malware, zeros, or any bogus data. This scheme does not protect one from such a scenario, even if a hash of the correct plaintext was known in advance to both parties, since the txn provides no provisions for checking said hash.