Topic: [ANN] Bitmsg - A Proof-of-Sacrifice distributed messaging layer over Bitcoin (Read 4075 times)
October 20, 2013, 09:11:56 PM
You may find this post on generating valid-looking pubkeys that hide data interesting: https://bitcointalksearch.org/topic/m.3377058
October 18, 2013, 06:56:05 PM
I have a bounty that is simalar to this on https://bitcointalk.org/index.php?topic=236742.new#new that was approved by the coins dev team.
October 18, 2013, 12:04:49 PM
Yeah, long-term data storage on the blockchain will never be a day-to-day backup solution, but there's a whole class of applications where the cost is worth it.
Sensitive data that should be preserved at all costs?
Yup.
Heck, I uploaded the very first computer program I ever wrote to the blockchain a few months ago.
There's a whole range of applicable programs that could be built on top of a data-neutral messaging layer. I've wondered about how a peer to peer marketplace for selling of goods and services could be done. One guy can (semi-)anonymously broadcast an "I've got a TV for sale for 4 BTC. Send me a message, here's my RSA public key."-style message. An application can take care of sorting through and searching available offers, building responses, reputation, etc. Reputation can be done with more proof-of-sacrifice sends. All really fascinating scenarios, really.
Yup. You'll probably find that at some point the fees per KB simply become too expensive, but that's just a practical consideration - figure out what parts of the system are best done on the blockchain, and what parts on a secondary system. For instance when someone has committed fraud and you want to destroy their reputation, the guaranteed wide audience of the Bitcoin blockchain may be worth the higher cost.
Quote
Nope, I just mean the txid:n pair, also known as an OutPoint. (from the COutPoint class in the reference client) That you don't need a full-weight client for, as you already know.
Anyway, if you're using the txid as an IV I think you've already met my criteria just fine!
Ah, right. I could have used the input_n in the hash, but the tx hash should be enough right?Anyway, if you're using the txid as an IV I think you've already met my criteria just fine!
Re-using IV's is often very bad and leads to plaintext compromise. Having said that, here we're using encryption for censorship resistance and steganography, not privacy, so the odd IV re-use isn't a disaster. Still you should avoid it, and including the input # helps. Come to think of it, including the nSequence of the first txin and the nLockTime of the whole transaction would be a good idea too as it's been proposed to alway set nLockTime to the current blockheight to discourage fee-sniping, thus really reducing the chances of accidental IV re-use. Point being, doing that in the future may be totally normal, so a transaction that does that won't stick out, and in the meantime including them in the calculation of the IV does no harm.
Well, then you don't end up with any more data space than regular pay-to-address. Are you suggesting that pay-to-address/scripthash is better at disguising messages than a 1-of-M multisig tx? If you use the 0x04 prefix on the public keys in the multisig transaction, you wouldn't be able to tell if they're real keys or message data.
Again, the point isn't to be efficient, it's to allow the creation of "stealth" data-encoding transactions whose existence can't be proved unless you have the secret key required to decode them.
It would be interesting to see what this could actually reveal. Anyone who's really interested in protecting where the message comes from could connect to tor and broadcast through blockchain.info/pushtx.
I've got Tor support in my dust-b-gone tool that you might find instructive.
October 18, 2013, 11:09:56 AM
Another thought: make Bitmsg pay at least slightly over the 0.0001BTC/KB minimum fee by default so you beat out badly designed wallet software that doesn't let you set fees. You can go a bit further and make the default based on the fee/KB such software would pay for a standard 1 txin, 2 txout transaction, thus beating out most stuff in the fee competition.
Less relevant for Bitmsg really, as the fact that the txs get mined eventually doesn't actually matter too much, but for a small data storage tool this is quite useful, and the marginal cost over the absolute minimum fees isn't much because of how you just need to beat a fixed-in-stone fee.
Less relevant for Bitmsg really, as the fact that the txs get mined eventually doesn't actually matter too much, but for a small data storage tool this is quite useful, and the marginal cost over the absolute minimum fees isn't much because of how you just need to beat a fixed-in-stone fee.
This is probably a wise move going forward: Bitmsg should definitely contribute more to miners. Thanks for the suggestion.
October 18, 2013, 11:08:35 AM
Quote
If you are interested in messaging that obfuscates metadata, you would do much better to contribute to Pond:
https://pond.imperialviolet.org/
https://pond.imperialviolet.org/
While Pond is pretty neat, I don't think it's a viable tool for a proof-of-sacrifice messaging system. It requires Tor to be secure.
Yeah, but there are reasons for that. What is your threat model, exactly? If you're worried about governments that engage in fibre taps, then using Tor+hidden services seems like a basic precaution you'd need to take even with a flood-fill protocol like yours.
Fair point - I mentioned security though security isn't a particularly motivating factor. Encryption is easy these days...
Quote
Otherwise they can watch the messages fly around and see who was first to broadcast it (bitcoin itself has the same issue, of course).
It would be interesting to see what this could actually reveal. Anyone who's really interested in protecting where the message comes from could connect to tor and broadcast through blockchain.info/pushtx. Quote
Pond has other features that seem important, like forward security.
I should read more on forward security, but it seems to me that this is something that could be added on top of any data-neutral transport layer. Quote
So I'm not sure why you say it's not viable. It seems like a well thought out solution to a very strong threat model.
I think I'm just seeing a barrier that involves combining three separate pieces of software instead of one, and the task would involve learning Pond when I'm already pretty familiar with the workings of Bitcoin. I wrote this project in only a couple of hours as a proof-of-concept...
October 18, 2013, 10:59:58 AM
Well, if messages are encrypted it would be hard for anyone contributing to the network to even know what they were transmitting. As far as they know, they are only serving to help Bitcoin. Long-term data storage is something I've thought about - it's really cool you know, you have to *pay* for storage. A 500kB file will cost you 5 BTC. How cool is that? The space is expensive, and will only get more expensive, so it's unlikely people will bloat the chain with copies of their favorite mp3s.
Yeah, long-term data storage on the blockchain will never be a day-to-day backup solution, but there's a whole class of applications where the cost is worth it.
Sensitive data that should be preserved at all costs?
How does using P2SH help? P2SH standard scripts only have that hash of the script. There's no good place to store data.
As long as P2SH^2 isn't implemented nothing actually checks that the hash is actually a hash; you can stuff whatever data you want in it. Here's an example tx doing just that: https://blockchain.info/tx/5143cf232576ae53e8991ca389334563f14ea7a7c507a3e081fbef2538c84f6e
Well, then you don't end up with any more data space than regular pay-to-address. Are you suggesting that pay-to-address/scripthash is better at disguising messages than a 1-of-M multisig tx? If you use the 0x04 prefix on the public keys in the multisig transaction, you wouldn't be able to tell if they're real keys or message data.
October 18, 2013, 10:04:40 AM
Another thought: make Bitmsg pay at least slightly over the 0.0001BTC/KB minimum fee by default so you beat out badly designed wallet software that doesn't let you set fees. You can go a bit further and make the default based on the fee/KB such software would pay for a standard 1 txin, 2 txout transaction, thus beating out most stuff in the fee competition.
Less relevant for Bitmsg really, as the fact that the txs get mined eventually doesn't actually matter too much, but for a small data storage tool this is quite useful, and the marginal cost over the absolute minimum fees isn't much because of how you just need to beat a fixed-in-stone fee.
Less relevant for Bitmsg really, as the fact that the txs get mined eventually doesn't actually matter too much, but for a small data storage tool this is quite useful, and the marginal cost over the absolute minimum fees isn't much because of how you just need to beat a fixed-in-stone fee.
October 18, 2013, 06:18:28 AM
Quote
If you are interested in messaging that obfuscates metadata, you would do much better to contribute to Pond:
https://pond.imperialviolet.org/
https://pond.imperialviolet.org/
While Pond is pretty neat, I don't think it's a viable tool for a proof-of-sacrifice messaging system. It requires Tor to be secure.
Yeah, but there are reasons for that. What is your threat model, exactly? If you're worried about governments that engage in fibre taps, then using Tor+hidden services seems like a basic precaution you'd need to take even with a flood-fill protocol like yours. Otherwise they can watch the messages fly around and see who was first to broadcast it (bitcoin itself has the same issue, of course).
Pond has other features that seem important, like forward security.
So I'm not sure why you say it's not viable. It seems like a well thought out solution to a very strong threat model.
October 18, 2013, 03:11:55 AM
Well, if messages are encrypted it would be hard for anyone contributing to the network to even know what they were transmitting. As far as they know, they are only serving to help Bitcoin. Long-term data storage is something I've thought about - it's really cool you know, you have to *pay* for storage. A 500kB file will cost you 5 BTC. How cool is that? The space is expensive, and will only get more expensive, so it's unlikely people will bloat the chain with copies of their favorite mp3s.
Yeah, long-term data storage on the blockchain will never be a day-to-day backup solution, but there's a whole class of applications where the cost is worth it.
One interesting one I came up with is for "pseudo-HD wallets": you use a master key, like a normal HD wallet, but instead of deriving a series of secondary keys with ECC magic you just encrypt a series of private keys and store them in the blockchain tagged such that SPV clients can easily find them again with bloom filters. It's a nice way to take a "bag-of-keys" wallet and upgrade it to HD wallet form, without having to throw away the original keys, yet a complete backup is still just that master key. No less secure either as compromise of the master key compromises the HD wallet completely anyway.
Quote from: retep
1) Make sure any data storage/messaging scheme is designed such that to prove any given message has a data payload you need to provide the entire message; that is if you don't have the entire message the authorities may actually be using the "data blacklist" as a way to freeze peoples legitimate Bitcoin funds, and if you do have the entire message through the "data blacklist" the blacklist itself is serving as the means to distribute the data. I think the scheme I outlined of encryption using the first txin as an IV meets this criteria.
The problem with using the amount of the first input is knowing what the amount is in the message-receiving end. Unless you're a full node, you can't connect inputs properly, which sucks if all you want to build is a lightweight message retrieval application. The current implementation does use the first input's txid as the IV, however.
Nope, I just mean the txid:n pair, also known as an OutPoint. (from the COutPoint class in the reference client) That you don't need a full-weight client for, as you already know.
Anyway, if you're using the txid as an IV I think you've already met my criteria just fine!
How does using P2SH help? P2SH standard scripts only have that hash of the script. There's no good place to store data.
As long as P2SH^2 isn't implemented nothing actually checks that the hash is actually a hash; you can stuff whatever data you want in it. Here's an example tx doing just that: https://blockchain.info/tx/5143cf232576ae53e8991ca389334563f14ea7a7c507a3e081fbef2538c84f6e
October 18, 2013, 02:46:42 AM
Sarchar: Oh, and one more thing: I outlined a scheme of mine on #bitcoin-wizards for what I call TXO commitments that if implemented makes UTXO bloat mostly a non-issue. Consensus seemed to be that the scheme worked and can be implemented, so don't feel bad about the UTXO bloat your stuff is creating; if anything make sure your code has options to also hide the data in truly undetectable pay-to-(pubkey|scripthash) outputs as well like the wikileaks data script from earlier this year did.
How does using P2SH help? P2SH standard scripts only have that hash of the script. There's no good place to store data.
October 18, 2013, 02:43:21 AM
Sarchar: Something I was thinking about yesterday is how messaging and data distribution over the blockchain is offers an interesting form of plausible deniability as well: people contributing bandwidth and storage space to the application can easily say they are simply contributing to Bitcoin itself rather than any particular secondary usage. Long-term data storage is particularly relevant here as the plausible deniability aspect negates the usual argument that authorities will just release blacklists of transactions that node operators will be encouraged to delete - by running a non-deleting node you get to A: continue to keep Bitcoin fully auditable and trustworthy(1) and B: continue to make censored data available to those who want it with the plausible deniability that they were just syncing up their full nodes/syncing their SPV wallets.
Well, if messages are encrypted it would be hard for anyone contributing to the network to even know what they were transmitting. As far as they know, they are only serving to help Bitcoin. Long-term data storage is something I've thought about - it's really cool you know, you have to *pay* for storage. A 500kB file will cost you 5 BTC. How cool is that? The space is expensive, and will only get more expensive, so it's unlikely people will bloat the chain with copies of their favorite mp3s.
Quote from: retep
1) Make sure any data storage/messaging scheme is designed such that to prove any given message has a data payload you need to provide the entire message; that is if you don't have the entire message the authorities may actually be using the "data blacklist" as a way to freeze peoples legitimate Bitcoin funds, and if you do have the entire message through the "data blacklist" the blacklist itself is serving as the means to distribute the data. I think the scheme I outlined of encryption using the first txin as an IV meets this criteria.
The problem with using the amount of the first input is knowing what the amount is in the message-receiving end. Unless you're a full node, you can't connect inputs properly, which sucks if all you want to build is a lightweight message retrieval application. The current implementation does use the first input's txid as the IV, however.
October 18, 2013, 02:38:27 AM
What is the purpose of this? It seems useless, and abusive.
Personally, I think it's a rather intellectual exercise. The fact that this can be done is worth exploring, and I don't want to be on the "abusive" side of things, which is why I encourage proper usage of Fees to the miners and am actively looking for ways to not destroy Bitcoin (For example, I'd like to see 0-output txns to be considered standard, so that Bitmsg can push all the sacrificed coins to miners).
Quote
You're not going to suddenly stop being abusive by donating 5 BTC to charity, sorry.
You're right - it's up to the Bitcoin protocol and its implementations to prevent abuse. You have to assume that there will be people out there doing intentionally bad things and the protocol has to adjust to handle these things. I'm in the market of improving Bitcoin, not abusing it.
Quote
If you are interested in messaging that obfuscates metadata, you would do much better to contribute to Pond:
https://pond.imperialviolet.org/
https://pond.imperialviolet.org/
While Pond is pretty neat, I don't think it's a viable tool for a proof-of-sacrifice messaging system. It requires Tor to be secure.
Along with MasterCoin, your blog post on PoS is kind of what inspired this. It's a toy, a proof-of-concept if you will.
October 18, 2013, 02:26:45 AM
Cool!
FWIW BitMessage has decent ECC encryption implemented for its messages; you could easily take that code and apply it to Bitmsg and get smaller messages from it.
FWIW BitMessage has decent ECC encryption implemented for its messages; you could easily take that code and apply it to Bitmsg and get smaller messages from it.
Ah, neat. I can check out their code some time. ECC would be nice in that we could then use Bitcoin pub/priv keys as the encryption keys. I'll keep it on the TODO list.
October 17, 2013, 09:20:56 AM
Sarchar: Oh, and one more thing: I outlined a scheme of mine on #bitcoin-wizards for what I call TXO commitments that if implemented makes UTXO bloat mostly a non-issue. Consensus seemed to be that the scheme worked and can be implemented, so don't feel bad about the UTXO bloat your stuff is creating; if anything make sure your code has options to also hide the data in truly undetectable pay-to-(pubkey|scripthash) outputs as well like the wikileaks data script from earlier this year did.
October 17, 2013, 09:08:24 AM
Sarchar: Something I was thinking about yesterday is how messaging and data distribution over the blockchain is offers an interesting form of plausible deniability as well: people contributing bandwidth and storage space to the application can easily say they are simply contributing to Bitcoin itself rather than any particular secondary usage. Long-term data storage is particularly relevant here as the plausible deniability aspect negates the usual argument that authorities will just release blacklists of transactions that node operators will be encouraged to delete - by running a non-deleting node you get to A: continue to keep Bitcoin fully auditable and trustworthy(1) and B: continue to make censored data available to those who want it with the plausible deniability that they were just syncing up their full nodes/syncing their SPV wallets.
1) Make sure any data storage/messaging scheme is designed such that to prove any given message has a data payload you need to provide the entire message; that is if you don't have the entire message the authorities may actually be using the "data blacklist" as a way to freeze peoples legitimate Bitcoin funds, and if you do have the entire message through the "data blacklist" the blacklist itself is serving as the means to distribute the data. I think the scheme I outlined of encryption using the first txin as an IV meets this criteria.
1) Make sure any data storage/messaging scheme is designed such that to prove any given message has a data payload you need to provide the entire message; that is if you don't have the entire message the authorities may actually be using the "data blacklist" as a way to freeze peoples legitimate Bitcoin funds, and if you do have the entire message through the "data blacklist" the blacklist itself is serving as the means to distribute the data. I think the scheme I outlined of encryption using the first txin as an IV meets this criteria.
October 17, 2013, 06:54:44 AM
using it right now...should be a early user of bitmsg..
October 17, 2013, 06:49:41 AM
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:
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).
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).
October 15, 2013, 12:16:12 PM
Cool!
FWIW BitMessage has decent ECC encryption implemented for its messages; you could easily take that code and apply it to Bitmsg and get smaller messages from it.
FWIW BitMessage has decent ECC encryption implemented for its messages; you could easily take that code and apply it to Bitmsg and get smaller messages from it.
October 14, 2013, 03:00:44 AM
I just pushed AES-128 support.
Today I've pushed support for RSA public-key encryption of messages, along with AES-256 and some other minor improvements.
October 12, 2013, 04:14:41 AM
I just pushed AES-128 support.
Jump to: