Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 [ANN] Bitmsg - A Proof-of-Sacrifice distributed messaging layer over Bitcoin October 09, 2013, 04:19:06 PM

Last edit: October 15, 2013, 01:52:04 PM by Sarchar #1



I want to announce a simple utility to do something that I think is quite interesting: to encrypt and send messages using the Bitcoin network and the blockchain.



I know a lot of people are going to find this very controversial because I'm using the blockchain to do something for which it wasn't originally intended. However, I do believe the blockchain is a neutral store of data and something like this is eventual and also serves to affirm the reliability of the blockchain. I believe in the blockchain!



That being said, I'm willing to donate 5 BTC to a charity or interesting code bounty or any otherwise charitable clause. See the bounty below for details.



The idea behind Bitmsg is to encode data into Bitcoin public keys such that only the intended recipient(s) can decode and read the message. It works on a very similar idea to MasterCoin, in fact, except we use multiple M-of-N multisig transactions. In many ways, this strategy can be an effective replacement for Bitmessage (where Bitmessage relies on PoW algorithms, Bitmsg is a sacrifice-based system).



Bitmsg messages, like all Bitcoin transactions, are produced without PoW, so it could allow for faster conversation than Bitmessage. In fact, communication is as fast as it takes for a transaction to flood-fill the network.



Unfortunately, the current strategy involves throwing away a Satoshi to each of the encoded addresses, something I'd like to eventually improve upon (I'd rather the Satoshis go to the miners). If the Bitcoin reference client allowed for relaying zero-satoshi outputs, we could instead send the dust to the miners as a better proof of sacrifice system. It also means that every message that gets published gets stored in the Blockchain forever, perhaps that would be quite bad for anonymity.



The current implementation supports RC4, AES-128 and AES-256 (all symmetric key) encryption and also supports multiple-recipient RSA (of any key size). It also supports sending public messages where no encryption key is required.



As for the bounty, I would thoroughly appreciate anyone who can start work on a PyQt4 UI. To the person that writes that code (and it works, and I accept the pull request) I'll donate 5 BTC to a charity of your choice. I reserve the right to request a different charity but I doubt I'd have any need to do that. I'll sign a message using the source Bitcoin address as confirmation and proof.



The github repository is



And as a friendly reminder:

USE AT YOUR OWN RISK. THIS IS PREMATURE SOFTWARE. DO NOT USE WITH ADDRESSES THAT CONTAIN MORE THAN YOU'RE WILLING TO LOSE .

Hi everyone,I want to announce a simple utility to do something that I think is quite interesting: to encrypt and send messages using the Bitcoin network and the blockchain.I know a lot of people are going to find this very controversial because I'm using the blockchain to do something for which it wasn't originally intended. However, I do believe the blockchain is a neutral store of data and something like this is eventual and also serves to affirm the reliability of the blockchain. I believe in the blockchain!That being said, I'm willing to donate 5 BTC to a charity or interesting code bounty or any otherwise charitable clause. See the bounty below for details.The idea behind Bitmsg is to encode data into Bitcoin public keys such that only the intended recipient(s) can decode and read the message. It works on a very similar idea to MasterCoin, in fact, except we use multiple M-of-N multisig transactions. In many ways, this strategy can be an effective replacement for Bitmessage (where Bitmessage relies on PoW algorithms, Bitmsg is a sacrifice-based system).Bitmsg messages, like all Bitcoin transactions, are produced without PoW, so it could allow for faster conversation than Bitmessage. In fact, communication is as fast as it takes for a transaction to flood-fill the network.Unfortunately, the current strategy involves throwing away a Satoshi to each of the encoded addresses, something I'd like to eventually improve upon (I'd rather the Satoshis go to the miners). If the Bitcoin reference client allowed for relaying zero-satoshi outputs, we could instead send the dust to the miners as a better proof of sacrifice system. It also means that every message that gets published gets stored in the Blockchain forever, perhaps that would be quite bad for anonymity.The current implementation supports RC4, AES-128 and AES-256 (all symmetric key) encryption and also supports multiple-recipient RSA (of any key size). It also supports sending public messages where no encryption key is required.As for the bounty, I would thoroughly appreciate anyone who can start work on a PyQt4 UI. To the person that writes that code (and it works, and I accept the pull request) I'll donate 5 BTC to a charity of your choice. I reserve the right to request a different charity but I doubt I'd have any need to do that. I'll sign a message using the source Bitcoin address as confirmation and proof.The github repository is here . It contains a small list of TODO items. If anyone has suggestions for a better name, I'm all ears:)And as a friendly reminder:

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANN] Bitmsg - A simple utility to send and receive encrypted Bitcoin messages October 10, 2013, 07:55:42 AM #6 Quote from: retep on October 09, 2013, 10:49:13 PM Up to 3 pubkeys, but a pubkey can be any data from 33 to 120 bytes long. (what's actually in the data isn't checked at all)



The main advantage of CHECKMULTISIG is that one of the pubkeys can be real, and your own, which lets you still spend that output and recover the bitcoins sent to it.



All right. I pushed a change that will use multisig transactions (1-of-n, where n can be 1, 2 or 3). Right now, the outputs are still unspendable.



Question though: where can I find information on 120-byte long public keys? Browsing through bitcoind source code seems to indicate only 33 and 65 byte keys are acceptable.

All right. I pushed a change that will use multisig transactions (1-of-n, where n can be 1, 2 or 3). Right now, the outputs are still unspendable.Question though: where can I find information on 120-byte long public keys? Browsing through bitcoind source code seems to indicate only 33 and 65 byte keys are acceptable.

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANN] Bitmsg - A simple utility to send and receive encrypted Bitcoin messages October 10, 2013, 10:03:45 AM #8 Quote from: retep on October 10, 2013, 09:10:39 AM Look at the IsStandard() function in script.cpp - a pubkey in the standard transaction testing code is defined there. c49b3c445c89d832289de0fd3b0281efdcce418333dacd028061e8de9f0a6f10 is an example of 2x 120 byte PUSHDATA'S, and one actual 33 byte pubkey. 72590fcf0d8021bad77826c5008eaca3541f81d212d55bb7c02ec6a4bf584404 is another example, with 3x 120 byte pushdatas, although it's not spendable.



Well, I'll be damned. The relevant code is in script.cpp Solver():



Code: // Template matching opcodes:

if (opcode2 == OP_PUBKEYS)

{

while (vch1.size() >= 33 && vch1.size() <= 120)

{



I had thought that the code was checking to make sure the pubkeys are actual ecdsa keys (i.e., of length 33 or 64 and starts with 0x02, 0x03, or 0x04).



Quote Are you aware of the dust limit?



Yes and no. I'm aware that it exists, that it's part of what determines relaying and standard transactions, however, it doesn't seem to be preventing any of my transactions from confirming.

Well, I'll be damned. The relevant code is in script.cpp Solver():I had thought that the code was checking to make sure the pubkeys are actual ecdsa keys (i.e., of length 33 or 64 and starts with 0x02, 0x03, or 0x04).Yes and no. I'm aware that it exists, that it's part of what determines relaying and standard transactions, however, it doesn't seem to be preventing any of my transactions from confirming.

Peter Todd



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: [ANN] Bitmsg - A simple utility to send and receive encrypted Bitcoin messages October 10, 2013, 10:28:45 AM #9 Quote from: Sarchar on October 10, 2013, 10:03:45 AM



Code: // Template matching opcodes:

if (opcode2 == OP_PUBKEYS)

{

while (vch1.size() >= 33 && vch1.size() <= 120)

{



I had thought that the code was checking to make sure the pubkeys are actual ecdsa keys (i.e., of length 33 or 64 and starts with 0x02, 0x03, or 0x04).

Well, I'll be damned. The relevant code is in script.cpp Solver():I had thought that the code was checking to make sure the pubkeys are actual ecdsa keys (i.e., of length 33 or 64 and starts with 0x02, 0x03, or 0x04).

Yup, I thought that was a bit of a WTF when I found it too.



FWIW while code may be added in the future to make sure things that are supposed to be pubkeys start with the right bytes, it's unlikely to go further than that; you might want to make your program drop the first byte of any pubkey-like thing that's either 33 or 65 bytes for forward compatibility in the future.



Another trick is to use the low-order-bits of the txout value to signal which PUSHDATA's in the txout script are or are not part of the message being embedded. If you do this, it's best to encrypt those bits as well for the sake of censorship resistance.



Of course, people will bitch at you before long for putting crap in the blockchain, but from a technical point of view there's nothing that can be done to stop that entirely, just make it more expensive. (which as you say is a good thing from a spam point of view)



Quote from: Sarchar on October 10, 2013, 10:03:45 AM Quote Are you aware of the dust limit?



Yes and no. I'm aware that it exists, that it's part of what determines relaying and standard transactions, however, it doesn't seem to be preventing any of my transactions from confirming.

Yes and no. I'm aware that it exists, that it's part of what determines relaying and standard transactions, however, it doesn't seem to be preventing any of my transactions from confirming.

You sure about that? I thought you said they were single satoshi outputs - that's definitely under the dust limit. You using an up-to-date client? Yup, I thought that was a bit of a WTF when I found it too.FWIW while code may be added in the future to make sure things that are supposed to be pubkeys start with the right bytes, it's unlikely to go further than that; you might want to make your program drop the first byte of any pubkey-like thing that's either 33 orbytes for forward compatibility in the future.Another trick is to use the low-order-bits of the txout value to signal which PUSHDATA's in the txout script are or are not part of the message being embedded. If you do this, it's best to encrypt those bits as well for the sake of censorship resistance.Of course, people will bitch at you before long for putting crap in the blockchain, but from a technical point of view there's nothing that can be done to stop that entirely, just make it more expensive. (which as you say is a good thing from a spam point of view)You sure about that? I thought you said they were single satoshi outputs - that's definitely under the dust limit. You using an up-to-date client? BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANN] Bitmsg - A simple utility to send and receive encrypted Bitcoin messages October 10, 2013, 12:55:02 PM #10 Quote from: retep 33 or 65 bytes

Oops, typo. Pushed code that uses the full 120 byte pubkey space for data.



Quote from: retep on October 10, 2013, 10:28:45 AM Another trick is to use the low-order-bits of the txout value to signal which PUSHDATA's in the txout script are or are not part of the message being embedded. If you do this, it's best to encrypt those bits as well for the sake of censorship resistance.

Maybe I'm not motivated enough to do this, as I'm not sure what it gets me other than a bit more obscurity. If the message itself is already encrypted, I'm not sure how shuffling around the bits with funky magic adds anything to security.



Quote Of course, people will bitch at you before long for putting crap in the blockchain, but from a technical point of view there's nothing that can be done to stop that entirely, just make it more expensive. (which as you say is a good thing from a spam point of view)



Naturally, and I expect them to. In some regards, these "bloat" mechanisms for the chain serve only to reinforce the stability of Bitcoin.



Quote Quote from: Sarchar on October 10, 2013, 10:03:45 AM Quote Are you aware of the dust limit?



Yes and no. I'm aware that it exists, that it's part of what determines relaying and standard transactions, however, it doesn't seem to be preventing any of my transactions from confirming.

Yes and no. I'm aware that it exists, that it's part of what determines relaying and standard transactions, however, it doesn't seem to be preventing any of my transactions from confirming.

You sure about that? I thought you said they were single satoshi outputs - that's definitely under the dust limit. You using an up-to-date client?

You sure about that? I thought you said they were single satoshi outputs - that's definitely under the dust limit. You using an up-to-date client?

Yeah, the tx 5da82ef18664968630fe14440caaa4882d00141fb74e054c941866b985fd008e was indeed one that was confirmed with dust outputs. Perhaps it's still standard because of the one non-dust output?

Oops, typo. Pushed code that uses the full 120 byte pubkey space for data.Maybe I'm not motivated enough to do this, as I'm not sure what it gets me other than a bit more obscurity. If the message itself is already encrypted, I'm not sure how shuffling around the bits with funky magic adds anything to security.Naturally, and I expect them to. In some regards, these "bloat" mechanisms for the chain serve only to reinforce the stability of Bitcoin.Yeah, the tx 5da82ef18664968630fe14440caaa4882d00141fb74e054c941866b985fd008e was indeed one that was confirmed with dust outputs. Perhaps it's still standard because of the one non-dust output?

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANN] Bitmsg - A simple utility to send and receive encrypted Bitcoin messages October 12, 2013, 06:38:25 AM #12 Quote from: retep on October 10, 2013, 02:30:35 PM Means you can add a "full-stealth" mode in the future easily where unless you have the decryption key you won't even be able to know if the message is there at all. (the low-order bits let you easily have txouts that are not related to the message for instance)



That would be an interesting thing to have. I think a message could easily be hidden in the pubkeys by actually using 65-bytes pubkey, and nobody would know whether it's a message or actually from a key. However, using such small outputs makes it look suspicious. The multisig output could be the change output (using 1-of-m multisig) if one of the three keys is actually the one belonging to the sender.



Quote

Speaking of, I noticed that you aren't using an initialization vector with your encryption scheme; you really need this. Yes, RC4 doesn't support one natively, but RC4 is awful - use AES instead. (AES128 is fine) A nice trick for this stuff is to take the IV from the first transaction input, specifically H(txid + n), which means you don't need to waste any space on it. You also want to be using something other than electronic codebook mode.

I'll add this to my todo list. I think you're right and it should be done. AES128 would be nice too.





Quote Well one reason people dislike this stuff is some have this idea that blockchain space will somehow magically have enough supply for all "reasonable" financial transactions to the extent that users won't need to think about fees; applications that make use of blockchain space for any other reason compete with financial transactions and push up the price for them. Sure fee competition is "stable", but it still makes some marginal uses of Bitcoin too expensive.

Wouldn't it be in the interest of miners to see the fees go up? I guess it's also against their interest to have to process and store lots of data..



Quote The question then is how many applications out there need the unique capabilities of data storage, data distribution, timestamping, censorship resistance and proof-of-publication that the blockchain provides, and how much are those users willing to pay? I think efforts like your's are a necessary evil, because we need to understand this stuff before Bitcoin becomes large enough that we can't change it.

Thanks! And I agree. I'm glad that the first person responding to this project is approaching it with a very objective viewpoint:)



Quote Ah, I just realized how you're using blockchain.info to send transactions - they don't care about the dust limit, so your transactions still manage to get to one of the miners that ignores it. Nice trick.



But that confuses me - I thought the dust change made recently affected relaying mostly. Regardless of where I push to (I could actually just push to the network manually), nodes on the network should stop relaying a "dust" transaction. And actually right now, blocks aren't processed for messages. As long as the tx floodfills the network, the message can be received; as far as functionality goes, it actually doesn't matter if the tx ever gets confirmed.

That would be an interesting thing to have. I think a message could easily be hidden in the pubkeys by actually using 65-bytes pubkey, and nobody would know whether it's a message or actually from a key. However, using such small outputs makes it look suspicious. The multisig output could be the change output (using 1-of-m multisig) if one of the three keys is actually the one belonging to the sender.I'll add this to my todo list. I think you're right and it should be done. AES128 would be nice too.Wouldn't it be in the interest of miners to see the fees go up? I guess it's also against their interest to have to process and store lots of data..Thanks! And I agree. I'm glad that the first person responding to this project is approaching it with a very objective viewpoint:)But that confuses me - I thought the dust change made recently affected relaying mostly. Regardless of where I push to (I could actually just push to the network manually), nodes on the network should stop relaying a "dust" transaction. And actually right now, blocks aren't processed for messages. As long as the tx floodfills the network, the message can be received; as far as functionality goes, it actually doesn't matter if the tx ever gets confirmed.

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANN] Bitmsg - A Proof-of-Sacrifice distributed messaging layer over Bitcoin October 17, 2013, 11:49:41 AM #16



If you are interested in messaging that obfuscates metadata, you would do much better to contribute to Pond:



https://pond.imperialviolet.org/



It provides forward secure messaging using Tor to frustrate traffic analysis, and a bunch of clever crypto tricks to kill metadata collection as well (even if you can find the servers). What is the purpose of this? It seems useless, and abusive. You're not going to suddenly stop being abusive by donating 5 BTC to charity, sorry.If you are interested in messaging that obfuscates metadata, you would do much better to contribute to Pond:It provides forward secure messaging using Tor to frustrate traffic analysis, and a bunch of clever crypto tricks to kill metadata collection as well (even if you can find the servers).