Using bitcoin for trusted timestamping?

[DeathAndTaxes]

Thus a zero BTC transaction even w/ a fee could be pruned.  When the fee gets transfered to another address and that transaction is deep enough the 0 BTC transaction is eligible for pruning.

0-value outputs can be spent (uselessly), so these outputs can't be pruned. The fee never has anything to do with pruning.

Interesting.  Good point. 

So as long as the address is to "nowhere" (no known private key) then the transaction can't be pruned because there will never be a subsequent transaction using that output as an input.

[1715030776]

1715030776

[1715030776]

1715030776

[1715030776]

1715030776

[1715030776]

1715030776

[sebastian]

Isnt the 2 hour "leeway" only for which times a node will *accept* a transaction?
For verifying a timestamp, a bogus timestamp would be very visible, even if its accepted.

For what I have understand, the node that makes a block (mine), affixes *his* system time to the block before working on it, and since it takes 10 minutes to work on it, the timestamp will be 10 minutes behind, and so on.

So each block then have a timestamp that is about 10 minutes apart.
So if we have this:

block1: 12:00:00

block2: 12:10:00

block3: 12:20:00


a transaction appearing in block2 could then the verifyer assume that the transaction was done on some time between 12:00 to 12:10. If the node who did block2 is bogus (eg emitting false timestamp for his blocks), you could use the blocks after and before this to verify how much bogus the node who did block2 is.

[ByteCoin]

0-value outputs can be spent (uselessly)

You have a habit of identifying these interesting and useful corner cases Theymos!

One can then store 256bits in the "random" k value of this signature for every transaction spending those 0 coins back to itself! Anyone can read this information with a suitable patch to the client or some freestanding software.

ByteCoin

[goblin]

I'm kinda working on this at the moment.

Rather than using a hacky transaction, I'll use p2pool and store the merkle tree of hashes that need to be timestamped in the coinbase of p2pool's shares. Later when p2pool finds a bitcoin block, you'll be able to track down your hash from the block's hash, through a chain of p2pool's share hashes, down to your coinbase.

The proof of timestamp will be quite a long file as it'll have to reference a few hundred or thousand hashes, but I hope to work with forrestv to minimize that into a neater tree.

[DeathAndTaxes]

I'm kinda working on this at the moment.

Rather than using a hacky transaction, I'll use p2pool and store the merkle tree of hashes that need to be timestamped in the coinbase of p2pool's shares. Later when p2pool finds a bitcoin block, you'll be able to track down your hash from the block's hash, through a chain of p2pool's share hashes, down to your coinbase.

The proof of timestamp will be quite a long file as it'll have to reference a few hundred or thousand hashes, but I hope to work with forrestv to minimize that into a neater tree.

That is less hacky than a tx?

[goblin]

That is less hacky than a tx?

Yeah, kinda. Cause it doesn't bloat the bitcoin blockchain and stuff. No extra data apart from what's being put there by p2pool already. No dodgy transactions.

[goblin]

TADA! https://github.com/goblin/chronobit

[gmaxwell]

That is less hacky than a tx?

It's enormously less hacky.   It doesn't waste coins, it doesn't increase the size of the blockchain ... not by one byte... even if it were committing to trillions of documents per minute.   So it can actually scale to be widely used, if it did so it wouldn't risk breaking bitcoin in the process.

[vog]

Although the "Chronobit" approach might be a bit nicer to the transaction history, I doubt it will ever gain traction. It lacks a good user interface and requires you to become part of a mining pool. So on the one side, it's optimized for billions of users, but this optimization makes it so cumbersome that almost nobody will use it. Kind of paradox.

I decided to go the other way around, using the extremely simple "make a dummy address from your data" approach, burning 0.00000001 BTC (or 0 BTC if your bitcoin client allows it), and make that available to everyone:

http://vog.github.io/bitcoinproof/

Bitcoinproof is meant to be very user friendly, and works "one-click" with any bitcoin client that understands "bitcoin:" URLs. I doubt that the timestamping need of the people is so huge that it will become a problem for the bitcoin network.

[Peter Todd]

You should make it possible to timestamp short strings as well. For instance it's inconvenient to timestamp git revision id's with your website because they are 160bit sha1 hashes, and thus your "SHA-256" field won't accept them for being too short.

[TierNolan]

Speaking of block pruning.  Is the intention that the pruned info would actually be thrown away?  Effectively, as some point in the future, the info about some of the block chain would be lost?

I had assumed that pruning was a RAM saving system, where you don't store pruned transactions outputs in RAM.

[sebastian]

retep: You can always pad the git ID with 24 zeroes to get it 256bit:

Here is the gitID of Webconverger 18.0 padded with 24 zeroes:
57437d19b849af2622850a27f6e065afeede54dc000000000000000000000000

[Peter Todd]

retep: You can always pad the git ID with 24 zeroes to get it 256bit:

Here is the gitID of Webconverger 18.0 padded with 24 zeroes:
57437d19b849af2622850a27f6e065afeede54dc000000000000000000000000

Good point!

Actually, how about 160bit hashes are put in the address directly then?

[Stardust]

Actually, how about 160bit hashes are put in the address directly then?

I always said that's the best idea; both blockexplorer.com, blockchain.info, and bitcoin bash tools can be used to convert 160bit hashes to bitcoin addresses and vice versa.