Show HN: btproof - trusted timestamping on the Bitcoin blockchain(btproof.com)
btproof.com
Show HN: btproof - trusted timestamping on the Bitcoin blockchain
https://www.btproof.com/
7 comments
> 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.ja...
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...
I think you are better off working with Peter Todd, a bitcoin developer working on opentimestamps (github.com/opentimestamps), rather than inventing your own thing. He's already got Merkle tree hashing, and injects data into the Bitcoin blockchain using the standard merged-mining protocol, meaning it doesn't increase the chain size at all (beyond the hit that's already being taken to allowed merged mining of things like Namecoin.)
Clickable link for visibility, convenience, GoogleBot, and posterity: http://github.com/opentimestamps (Bitcoin-based timestamps)
Look into some of the pruning development discussions that are happening, if you haven't already [0]. I believe it's a question of when, not if. Probably, only a few nodes will end up needing to keep the full merkle tree, that others can then use to bootstrap. But then, a few full, original nodes are all your service really needs, too.
0. http://thread.gmane.org/gmane.comp.bitcoin.devel/2065
0. http://thread.gmane.org/gmane.comp.bitcoin.devel/2065
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).
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).
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
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).
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).
It's a nice touch that such a large percentage of the Paypal price goes to the miners.
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.
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.
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.
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.
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.
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.
I don't see these systems themselves being outlawed in the US and it will be a dark day if they are. I'm not a lawyer, but I imagine their use falls under the 1st Amendment. Even if they're used for illegal purposes they're not inherently illegal.
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
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
I agree, it's highly unlikely it could or would be outlawed. Was just thinking hypothetically.
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 ;)
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 ;)
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.
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.
Hey, I'm the author. I'd love to hear your feedback.
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.
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.
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.
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.
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?
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.
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.
[deleted]
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.
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.
Have you ever had to use this yourself? Or was this more a technical exercise?
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).
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).
What are the advantages of using this for timestamps rather than the SSL CA timestamp servers? 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.
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.
How does yours compare to this one http://vog.github.io/bitcoinproof/
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.