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.
> 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.
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.)
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.
Comments
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.
> 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...
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