This is a great idea; how would it be implemented? A new application that interfaces with bitcoin and bitmessage, or just added functionality in bitmessage that would interface with bitcoin? Obviously we can do it manually, but then it will never catch on.
I can see this being very useful in a number of cases. It also makes it harder for centralized "tainted coin" schemes to be successful, since users partaking in illegitimate activities could simply perform their transaction via privkey on bitmessage, so blockchain observer bots wouldn't even see a transaction to suspect of, say, a silk-road pot sale.
I have absolutely no idea how to create an address and make sure that the private key I am sending is for that address only. In other words, I'm a noob when it comes to doing anything that's not in the bitcoin-qt GUI. Would be nice if coin control was included in the client. But, I look forward to anything that helps me make transactions like this without cluelessly screwing around in a terminal for 2 hours.
Topic: Using Bitmessage with Bitcoin for extra privacy (Read 1937 times)
Nice idea for the rare case where you want to be extra covert. I don't think it will catch on though as a method of payment in a public setting. Loading the private key adds extra time to the transaction and one can't be sure he received payment until the private key is loaded and the bitcoins are sent away from that address.
After reading about Bitmessage last night and remembering this post on the Cryptography StackExchange by David Schwartz (now of Ripple), I thought that perhaps it could be utilized to achieve his idea. To that end I've written up a scheme on how it might be used. All credit goes to David. Criticisms welcome.
Using Bitmessage with Bitcoin for extra privacy
Bob wants to receive Bitcoin donations. He generates a new Bitmessage address and posts it on his website publicly. Bob's Bitmessage address, at a higher level, is considered to be a new type of Bitcoin receiving address. This address can be readily associated with his personal identity.
Alice wants to send some bitcoins to Bob. To do this, Alice first generates a new Bitcoin address and sends bitcoins to it. Alice then generates a new temporary Bitmessage address (it will not need to be stored after the payment has successfully completed). She uses this to send the Bitcoin private key to Bob over the Bitmessage network. This message is encrypted to Bob's Bitmessage public key, so only he can read it. Bob receives the message, is able to successfully decrypt it, and sees the Bitcoin private key contained therein.
To accept payment, Bob generates a new Bitcoin address and, using the private key sent to him by Alice, is able to send the funds to it. He could also choose to reject the payment by sending a message back to Alice's temporary Bitmessage address. Alice still has the private key and so she can still spend it into a new address at any time, even without this rejection message. After moving the funds into a new address, and after an acceptable number of confirmations, Bob has now received payment and Alice may delete the temporary Bitmessage address. These procedures could all be automated by the software.
If everybody were to use this scheme, there would be no Bitcoin addresses able to be readily associated with personal identities. When Bob wants to spend his bitcoins at Frank's store, he would be given a Bitmessage address by Frank to be used for payment. Bob himself would then generate a new temporary Bitmessage address to send Frank a Bitcoin private key. Bob doesn't reuse his public Bitmessage address when sending a payment to Frank, so Frank does not know that it is Bob who is paying him (unless he supplies his identity with a shipping address, email, etc.). If Bob were to simply reuse his public Bitmessage address, Frank could type it into a search engine and discover that it is owned by Bob.
Anybody can see Bob's public Bitmessage address because it is posted on his website, but they cannot simply use this to check how many Bitcoin donations Bob has received, or who has donated. Alice can see when the bitcoins are moved again on the blockchain to a new Bitcoin address, and assume that this means they have been spent by Bob, but she cannot readily associate the new Bitcoin address with Frank, even if Frank has publicly disclosed his one and only Bitmessage address on the Internet like Bob did. Only if Bob specifically tells Alice that he sent the bitcoins to Frank can Alice know that the new Bitcoin address is owned by Frank. Likewise, if Frank and Alice are able to compare notes, Frank can discover that Bob is the one who has paid him. Because of this fact, this scheme does not make Bitcoin untraceable and anonymous, but it may provide some extra privacy. It would help thwart some obvious discoveries possible with Bitcoin addresses presently, since more active collaboration would be needed to achieve the same thing.
Thankfully this scheme would be a convention built on top of Bitcoin and Bitmessage, and so wouldn't require any changes to either protocol. The old mechanism for receiving payment will still be possible, though ideally you wouldn't pool funds collected from both mechanisms into one wallet or it could leak your identity when they are associated together on the blockchain with multiple inputs to a single transaction. You would ideally keep them separate and ideally only spend Bitmessage bitcoins to other Bitmessage addresses. This would only be realistic, however, if it became a widespread practice.
One major downside to using this scheme is that Bitmessage addresses cannot passively receive bitcoins while you are offline. You will need to go online at some point to receive a payment to a Bitmessage address, because you will need to send the bitcoins to a new Bitcoin address that you own. In a GUI, this could be presented as a simple 'Accept bitcoins' button, which will automatically generate a new Bitcoin address and send the funds to it, using the private key contained in the message. Until this action is performed, however, the bitcoins are still technically owned by the original party, since they can (and should) keep a copy of the private key. In addition, the Bitmessage network deletes older messages, although they do get re-sent with a later timestamp if they were not acknowledged as being received. This resending process also requires the sender to go back online, however.
An extra possible upside to this scheme is that there would be no need for users to generate a new receiving address each time for extra privacy, although they can still do so if they wish. This would make managing payment addresses much easier. For sending, however, users should create a separate temporary Bitmessage address each time. In a possible GUI, Bitmessage could be abstracted away along with Bitcoin addresses. You could present only a single Bitmessage address to the user for receiving. This address, along with all of the Bitcoin addresses used behind the scenes, could be generated in a deterministic manner from a passphrase, allowing for wallet backup to be very simple.
Using Bitmessage with Bitcoin for extra privacy
Bob wants to receive Bitcoin donations. He generates a new Bitmessage address and posts it on his website publicly. Bob's Bitmessage address, at a higher level, is considered to be a new type of Bitcoin receiving address. This address can be readily associated with his personal identity.
Alice wants to send some bitcoins to Bob. To do this, Alice first generates a new Bitcoin address and sends bitcoins to it. Alice then generates a new temporary Bitmessage address (it will not need to be stored after the payment has successfully completed). She uses this to send the Bitcoin private key to Bob over the Bitmessage network. This message is encrypted to Bob's Bitmessage public key, so only he can read it. Bob receives the message, is able to successfully decrypt it, and sees the Bitcoin private key contained therein.
To accept payment, Bob generates a new Bitcoin address and, using the private key sent to him by Alice, is able to send the funds to it. He could also choose to reject the payment by sending a message back to Alice's temporary Bitmessage address. Alice still has the private key and so she can still spend it into a new address at any time, even without this rejection message. After moving the funds into a new address, and after an acceptable number of confirmations, Bob has now received payment and Alice may delete the temporary Bitmessage address. These procedures could all be automated by the software.
If everybody were to use this scheme, there would be no Bitcoin addresses able to be readily associated with personal identities. When Bob wants to spend his bitcoins at Frank's store, he would be given a Bitmessage address by Frank to be used for payment. Bob himself would then generate a new temporary Bitmessage address to send Frank a Bitcoin private key. Bob doesn't reuse his public Bitmessage address when sending a payment to Frank, so Frank does not know that it is Bob who is paying him (unless he supplies his identity with a shipping address, email, etc.). If Bob were to simply reuse his public Bitmessage address, Frank could type it into a search engine and discover that it is owned by Bob.
Anybody can see Bob's public Bitmessage address because it is posted on his website, but they cannot simply use this to check how many Bitcoin donations Bob has received, or who has donated. Alice can see when the bitcoins are moved again on the blockchain to a new Bitcoin address, and assume that this means they have been spent by Bob, but she cannot readily associate the new Bitcoin address with Frank, even if Frank has publicly disclosed his one and only Bitmessage address on the Internet like Bob did. Only if Bob specifically tells Alice that he sent the bitcoins to Frank can Alice know that the new Bitcoin address is owned by Frank. Likewise, if Frank and Alice are able to compare notes, Frank can discover that Bob is the one who has paid him. Because of this fact, this scheme does not make Bitcoin untraceable and anonymous, but it may provide some extra privacy. It would help thwart some obvious discoveries possible with Bitcoin addresses presently, since more active collaboration would be needed to achieve the same thing.
Thankfully this scheme would be a convention built on top of Bitcoin and Bitmessage, and so wouldn't require any changes to either protocol. The old mechanism for receiving payment will still be possible, though ideally you wouldn't pool funds collected from both mechanisms into one wallet or it could leak your identity when they are associated together on the blockchain with multiple inputs to a single transaction. You would ideally keep them separate and ideally only spend Bitmessage bitcoins to other Bitmessage addresses. This would only be realistic, however, if it became a widespread practice.
One major downside to using this scheme is that Bitmessage addresses cannot passively receive bitcoins while you are offline. You will need to go online at some point to receive a payment to a Bitmessage address, because you will need to send the bitcoins to a new Bitcoin address that you own. In a GUI, this could be presented as a simple 'Accept bitcoins' button, which will automatically generate a new Bitcoin address and send the funds to it, using the private key contained in the message. Until this action is performed, however, the bitcoins are still technically owned by the original party, since they can (and should) keep a copy of the private key. In addition, the Bitmessage network deletes older messages, although they do get re-sent with a later timestamp if they were not acknowledged as being received. This resending process also requires the sender to go back online, however.
An extra possible upside to this scheme is that there would be no need for users to generate a new receiving address each time for extra privacy, although they can still do so if they wish. This would make managing payment addresses much easier. For sending, however, users should create a separate temporary Bitmessage address each time. In a possible GUI, Bitmessage could be abstracted away along with Bitcoin addresses. You could present only a single Bitmessage address to the user for receiving. This address, along with all of the Bitcoin addresses used behind the scenes, could be generated in a deterministic manner from a passphrase, allowing for wallet backup to be very simple.
Jump to: