> 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
> 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