Show HN: btproof - trusted timestamping on the Bitcoin blockchain
btproof.com
btproof.com
Some miners don't like such 'dust' (abandoned micro amounts) living eternally in their shared datastructure. Their displeasure means it's possible some future pruning-rules would discard these from the well-replicated eternally 'live' set of recorded values. Still, there might be enough 'orthodox' non-discarding operators, or historic archives, that such blockchain deletionism wouldn't harm the usefulness of these timestamps.
For greater efficiency you could batch together multiple timestamp requests into a hash tree, and just insert the root into the blockchain – giving each individual document submitted a 'ticket' of the other hashes that can be combined with theirs to anchor their hash in the blockchain. (They'd then have to retain that for full proof-of-existence in the future.)
If you're willing to rely on full historic archives of the blockchain, rather than 'live' balances, for future verification, you can avoid destroying balances (and creating 'dust'), at the expense of a bit more state, delay and transaction fees. You mix the (root/document) hash with some salt, to create a real private key. Send any amount to the corresponding public key. Then, empty that balance to another address. Finally, reveal the salt and (root/document) hash to the world/your-users. They can then use the historic record (but not live balances) to show that their hash existed at the time of the fill/empty transactions... but no BTC is permanently abandoned.
The block header contains the merkle hash tree of all the transactions, meaning that the transactions, in their exact original form, are required by any client that wants to verify the proof of work and validity of blocks.
> or greater efficiency you could batch together multiple timestamp requests into a hash tree, and just insert the root into the blockchain
Yeah, I thought about that. If I'll be getting a lot of orders, I'll probably start doing that.
> you can avoid destroying balances (and creating 'dust'), at the expense of a bit more state, delay and transaction fees. You mix the (root/document) hash with some salt, to create a real private key...
I originally mentioned that option in the website, but commented it out [1]. Although my reasoning there about future pruning rules isn't quite right (as I wrote above), I still think the amount is too tiny for it to make a difference. As I wrote in the website, destroying coins like that to create 1 billion timestamps is equal to 10 BTC being lost due to someone losing his private keys.
[1] https://github.com/shesek/btproof/blob/master/views/index.ja...
If it's just 1 satoshi for $3 you might be fine (if PayPal doesn't notice), but don't even think of doing that with a more reasonable ratio, since you'll get raped by people cashing out stolen paypal or credit cards using it.
In general, I don't see why you are putting the hash in the address, rather than putting it in a comment in the transaction script, and sending BitCoin back to yourself (or perhaps doing a 0-ouput fee-only transaction, but not sure if that's accepted by clients).
0.000000001 to <hash of document>
N - 0.0000000001 - <fee> to owner's wallet #2
<fee> to miner
So the $3 doesn't buy you any bitcoins, since the address that is the hash of the document isn't a valid bitcoin address since it wasn't generated from a public/private key that is known.The user can input whatever address they want, so technically they could use it to buy Bitcoins, but still - the amount is really tiny and insignificant, and it'll be highly non profitable ($3 for bitcoins worth ~$0.0000013).
However, due to the changes in the way bitcoin-qt 0.8.2 handles dust outputs, I will probably need to change it to a different method in the future. For now, there are still a lot of miners that accepts those transactions.
A timestamping/notary is one use. Namecoin (mutable key/value store), Bitmessage (transient messaging) are others.
I expect we'll see a lot more. It's interesting to think about how you could combine various properties of different p2p systems like Bitcoin, BitTorrent, etc.
Not saying they necessarily will, but if the US outlaws Bitcoin at any point, then it will be extremely easy for them (or anyone; hypothetical anti-Bitcoin couch-vigilantes perhaps) to see the IP addresses of American users of the network, and then serve warrants and take action against them.
Same if Tor ever gets outlawed; Tor relays in the US can be identified and taken down with ease.
Also it would be rather ironic for the US gov to outlaw Tor, given that they help fund it's development.
As long as Tor or similar systems are available other p2p networks can be used over it (you could even imagine networks that operate as hidden services)
Interesting talk on how governments have tried to shut down Tor: http://www.youtube.com/watch?v=DX46Qv_b7F4
So far the centralised bits of the bitcoin ecosystem (in particular the exchanges) look a lot more fragile than the network itself.
Also, if they want to play bitcoin whack-a-mole, I think they have to outlaw tor as well ;)
If a network is totally closed off, with a single point of entry, one would first have to take down or infiltrate that single point. For example, if a hypothetical illicit VPN was created, hosted by a large server in Serbia, criminals in the US could tunnel their traffic through chains of proxies, with this VPN server at the end of the chain. US law enforcement would have quite a bit of trouble seeing the internals of this network, at least without significant social engineering and investigation.
If a network is freely joinable and is a "panopticon" (everyone can see everyone else), investigation into the network can be done by anyone anywhere, with ease. What IP addresses are connected, how much data and what kind of data nodes are sending, etc.
In general I agree though. The Bitcoin network and protocol is strong and well-designed, and assuming major governments do not ever outlaw the use of the Bitcoin protocol itself (and they probably won't), it should remain strong for a long time. Bitcoin exchanges are definitely the weakest link.
Personally, I would just include the hash in a comment of a payment to myself (or any payment at all), which is easily done with the current bitcoin client. The signature can easily be viewed on blockchain.info and you can use any hash that you like. Finding it would be harder though, but should not be difficult if I know any of the sending, receiving address or transaction id.
So if you want to create a PoW agreement scheme, you have to create a system of incentives, that is create a currency out of it. Which Bitcoin does. But currency is a secondary part. Primary part is agreement.
1. Use SHA256 of your document as a private key.
2. Send some money (e.g. 0.01 BTC) to the address created from that private key.
3. Wait till it is well confirmed and "old enough" (to avoid paying antispam fee).
4. Send that money back to your private address.
5. Reveal your SHA256 to the world.
Yours is infinitely cooler tho
The switch to first to file might render this moot, though, since it seems that inventions that are never made public can be "stolen" by someone else filing a patent at a later date (corrections welcome).
I am looking for a way to prove that web content existed -- building a cryptographically verifiable "Internet Archive" knock-off; timestamping is a key part of this.