Topic: Using bitcoin for trusted timestamping? (Read 7985 times)

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.

Good point!

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

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

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.

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.

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.

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.

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

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.

That is less hacky than a tx?

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.

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

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.

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.

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

I found a web service that does SHA2 for files and I've taken the liberty of writing this up as a blog post.

https://strongcoin.com/blog/using_the_blockchain_as_a_trusted_timestamping_service

Ah.  I thought after we sent the coins to the address, we would send them back to ourselves.  You are suggesting that we keep the coins there.  That makes things much different.

Also thank you for your explanation of the pruning process.  That makes sense.

Not exactly.

Without blockchain pruning we keep all transactions so they can be traced back to the origination.

With blockchain pruning we remove transactions where the addresses involved in the transaction have no value (0 BTC) and where the subsequent transactions are "deep enough" in the block chain.  Yeah I know I explained that badly.  Maybe an example would help.

Say 10 BTC gets transfered like this*
Coinbase origination -> Address A -> Address B -> Address C -> Address D.

*This is simplified obviously there would be multiple branches and change address and fees but the concept doesn't change.

Currently we ensure no double spend by tracing transactions back from D to C to B to A to block origination but that is obviously costly in terms of disk space and will be continually increasing in cost.  

With pruning lets say the transaciton transfering coins from B to C is behind a checkpoint (hardcoded hash in the client) and over 400 blocks deep in the block chain.  The value of address C is now "secure" even without looking at subsequent transactions.

To reverse that transaction would require building a chain 400 blocks longer than the valid chain AND somehow updating majority of clients to a version of the client without the hard coded checkpoint.  We can feel confident this won't happen so we can consider output of the B->C transaction to be canonical.

So we prune them the prior portion of the his sequence.

We keep
 Address C -> Address D.

We remove
Address A -> Address B
&
Address B -> Address C

Key point:
No we can only prune a transaction if
a) the address no longer has any value (otherwise coins would be lost)
b) the output of the transaction has been involved in another subsequent input (address C in the example)
c) the transaction in condition b is behind a checkpoint or deep enough in the block chain (preferably both).

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.

A non zero BTC transaction which never has a subsequent transaction can never be pruned.  Yes this means the the fnal transaction of "lost coins" and coins sent to nowhere will always be part of the block chain.  Normally that is a limitation of pruning but here we can use that fact to ensure the transaction is never pruned.

Wouldn't the same apply to sending a non-zero amount then?  Or am I misunderstanding how Block Chain Pruning is planned to work.  I thought that we need all the transactions leading up to a particular transaction to make sure there wasn't a double spend.  Therefore, we would need to keep the transaction that had the fee attached so that there is a record of how the miner got those particular Bitcoins.

It wouldn't.  Once the fee has been transferred to a third address and that address is buried deep enough into the block chain it can be pruned.

The best would be to send a non-zero amount.