5 ms·

Show HN: btproof - trusted timestamping on the Bitcoin blockchain

75 points by nadaviv 13y ago

nadaviv 13y ago
Hey, I'm the author. I'd love to hear your feedback.
- randall 13y ago
  Have you ever had to use this yourself? Or was this more a technical exercise?
  - nadaviv 13y ago
    More of a technical exercise, but I could see it coming handy in the future.
    - chewxy 13y ago
      How coincident. Not 5 mins ago I was reimplementing trusted timestamping for a document to be opened 3 months in the future. Yours is infinitely cooler tho
- mikeash 13y ago
  How would this compare to posting the hash in a public and frequently backed up way such that the date would be generally established by archives? For example, you could take out a classified ad with the hash in a newspaper, or post to Usenet so Google Groups archives it, or even submit it as a story to HN. (Or do all of the above and more at once.) Obviously, those aren't as technically sweet, but they seem workable. I'd be interested in knowing if there are more subtle tradeoffs involved.
  - nwh 13y ago
    The Bitcoin blockchain will presumably be around for the foreseeable future, and can't under any circumstance be modified by anyone. That's the main reason you'd want proof there.
- deleted 13y ago
  [deleted]
- drcross 13y ago
  While I applaud novel uses of technology I am a bit uneasy using the bitcoin blockchain for the purpose of something other than transferring financial value. Couldn't you create a new blockchain with the sole purpose you had in mind? I'm sure you considered this, was the widely distribute aspect of the existing bitcoin blockchain the only thing that prevented you from using your own?
  - oleganza 13y ago
    I feel opposite. Bitcoin is a proof-of-work scheme to come to an agreement on certain information. Due to the costs of work, any kind of PoW scheme will be used as commodity and traded. Also, people will tend to allocate all their "mining" resources towards most valuable protocol. Which will lead to a single most powerful blockchain while others will be in very tiny minority. 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.
- oleganza 13y ago
  I would suggest this to avoid losing coins. 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.
- labawi 13y ago
  Correct me if I am wrong, but I would argue that creating these addresses with tiny leftover cash amounts creates more of a burden on bitcoin nodes than normal transactions. Every bitcoin node that verifies transactions must at all times be aware of the current balance of all accounts (more precisely all nonredeemed transaction, I think) and hence each of these signatures will necessarily live on all verifying nodes for as long as those coins are considered valid. Pruning strategies are being developed, but they do not prune accounts of balances, they only remove old transactions, so these balances cannot be removed, unless a satoshi stealing strategy is approved which would be a very significant incompatible change. 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.
gojomo 13y ago
Nice work; I'm glad this exists. (There have been a few others... see for example the [bitnotar] project.) 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.
- nadaviv 13y ago
  > Theirdispleasure means it's possible some future pruning-rules would discard these from the well-replicated eternally 'live' set of recorded values. 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.jade#L78 https://github.com/shesek/btproof/blob/master/views/index.ja...
wayu 13y ago
Are you really letting people pay with PayPal to send BitCoins to an arbitrary address? 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).
- nadaviv 13y ago
  It is technically possible to add arbitrary data to a transaction with OP_DROP, but it isn't widely supported enough, and most tools for exploring the blockchain won't display it in a convenient manner. 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.
- fryguy 13y ago
  My understanding is that, for $3 the author creates a transaction from some wallet of N bitcoins under the author's control, that has a distribution of: 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.
  - nadaviv 13y ago
    You understand it exactly correctly. Also, I'm sending those transactions with 0.01 BTC (~$1.3) in fees, which is roughly half the $3 payment (after credit card processing fees). 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).
    - 13y ago
tocomment 13y ago
How does yours compare to this one http://vog.github.io/bitcoinproof/ http://vog.github.io/bitcoinproof/
tlrobinson 13y ago
One of the most exciting things about bitcoin is the innovation it has sparked in trustless p2p applications. Currencies are just the beginning. 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.
- meowface 13y ago
  The one disadvantage of such P2P networks is if law enforcement ever cracks down on it. 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.
  - xyzzy123 13y ago
    Is what you are discussing not simply a disadvantage of networks though? While it would be possible to whack-a-mole P2P users, it's still a lot more work than taking down a centralised system. 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 ;)
    - meowface 13y ago
      Part of the disadvantage is that any user of a P2P network can instantly join the network, and then immediately "rat out" any other peer he comes across. 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.
nitrogen 13y ago
I've thought a lot about cryptographically verifiable timestamps as an alternative to and defense against patents, as I'm sure others have as well. I'm glad that you and others are looking at P2P solutions to this problem. The big challenge would be getting expert witnesses to testify in court that the timestamps are valid, or otherwise convincing the court to accept them. 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).
j_s 13y ago
What are the advantages of using this for timestamps rather than the SSL CA timestamp servers? http://en.wikipedia.org/wiki/Trusted_timestamping http://en.wikipedia.org/wiki/Trusted_timestamping 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.

75 points by nadaviv 13y ago

nadaviv 13y ago

Hey, I'm the author. I'd love to hear your feedback.

randall 13y ago
Have you ever had to use this yourself? Or was this more a technical exercise?
- nadaviv 13y ago
  More of a technical exercise, but I could see it coming handy in the future.
  - chewxy 13y ago
    How coincident. Not 5 mins ago I was reimplementing trusted timestamping for a document to be opened 3 months in the future. Yours is infinitely cooler tho
mikeash 13y ago
How would this compare to posting the hash in a public and frequently backed up way such that the date would be generally established by archives? For example, you could take out a classified ad with the hash in a newspaper, or post to Usenet so Google Groups archives it, or even submit it as a story to HN. (Or do all of the above and more at once.) Obviously, those aren't as technically sweet, but they seem workable. I'd be interested in knowing if there are more subtle tradeoffs involved.
- nwh 13y ago
  The Bitcoin blockchain will presumably be around for the foreseeable future, and can't under any circumstance be modified by anyone. That's the main reason you'd want proof there.
deleted 13y ago
[deleted]
drcross 13y ago
While I applaud novel uses of technology I am a bit uneasy using the bitcoin blockchain for the purpose of something other than transferring financial value. Couldn't you create a new blockchain with the sole purpose you had in mind? I'm sure you considered this, was the widely distribute aspect of the existing bitcoin blockchain the only thing that prevented you from using your own?
- oleganza 13y ago
  I feel opposite. Bitcoin is a proof-of-work scheme to come to an agreement on certain information. Due to the costs of work, any kind of PoW scheme will be used as commodity and traded. Also, people will tend to allocate all their "mining" resources towards most valuable protocol. Which will lead to a single most powerful blockchain while others will be in very tiny minority. 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.
oleganza 13y ago
I would suggest this to avoid losing coins. 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.
labawi 13y ago
Correct me if I am wrong, but I would argue that creating these addresses with tiny leftover cash amounts creates more of a burden on bitcoin nodes than normal transactions. Every bitcoin node that verifies transactions must at all times be aware of the current balance of all accounts (more precisely all nonredeemed transaction, I think) and hence each of these signatures will necessarily live on all verifying nodes for as long as those coins are considered valid. Pruning strategies are being developed, but they do not prune accounts of balances, they only remove old transactions, so these balances cannot be removed, unless a satoshi stealing strategy is approved which would be a very significant incompatible change. 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.

gojomo 13y ago

Nice work; I'm glad this exists. (There have been a few others... see for example the [bitnotar] project.) 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.

nadaviv 13y ago
> Theirdispleasure means it's possible some future pruning-rules would discard these from the well-replicated eternally 'live' set of recorded values. 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.jade#L78 https://github.com/shesek/btproof/blob/master/views/index.ja...

wayu 13y ago

Are you really letting people pay with PayPal to send BitCoins to an arbitrary address? 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).

nadaviv 13y ago
It is technically possible to add arbitrary data to a transaction with OP_DROP, but it isn't widely supported enough, and most tools for exploring the blockchain won't display it in a convenient manner. 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.
fryguy 13y ago
My understanding is that, for $3 the author creates a transaction from some wallet of N bitcoins under the author's control, that has a distribution of: 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.
- nadaviv 13y ago
  You understand it exactly correctly. Also, I'm sending those transactions with 0.01 BTC (~$1.3) in fees, which is roughly half the $3 payment (after credit card processing fees). 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).
  - 13y ago

tocomment 13y ago

How does yours compare to this one http://vog.github.io/bitcoinproof/ http://vog.github.io/bitcoinproof/

tlrobinson 13y ago

One of the most exciting things about bitcoin is the innovation it has sparked in trustless p2p applications. Currencies are just the beginning. 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.

meowface 13y ago
The one disadvantage of such P2P networks is if law enforcement ever cracks down on it. 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.
- xyzzy123 13y ago
  Is what you are discussing not simply a disadvantage of networks though? While it would be possible to whack-a-mole P2P users, it's still a lot more work than taking down a centralised system. 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 ;)
  - meowface 13y ago
    Part of the disadvantage is that any user of a P2P network can instantly join the network, and then immediately "rat out" any other peer he comes across. 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.

nitrogen 13y ago

I've thought a lot about cryptographically verifiable timestamps as an alternative to and defense against patents, as I'm sure others have as well. I'm glad that you and others are looking at P2P solutions to this problem. The big challenge would be getting expert witnesses to testify in court that the timestamps are valid, or otherwise convincing the court to accept them. 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).

j_s 13y ago

What are the advantages of using this for timestamps rather than the SSL CA timestamp servers? http://en.wikipedia.org/wiki/Trusted_timestamping http://en.wikipedia.org/wiki/Trusted_timestamping 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.