Bitcoin Forum
March 19, 2024, 03:30:12 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Using bitcoin for trusted timestamping?  (Read 7944 times)
sebastian (OP)
Full Member
***
Offline Offline

Activity: 129
Merit: 118


View Profile
November 23, 2011, 10:02:38 PM
 #1

What about using bitcoin for trusted timestamping?

Found out this: https://en.bitcoin.it/wiki/Mini_private_key_format

Apparently, anything can be used as private key (like SHA("haha") as private key, and then a public key can be generated out of this).

Then, if I take a document, lets say a legal document, some important server logs, bookkeeping records in a company, or anything else that needs a trusted timestamp. Then I take SHA() of the document.
Then I use the result of SHA() as private key (appending zeroes if its too short, and truncating if too long), generate a adress and publickey out of this, transfer X number of BTC (high enough to avoid any transaction fees), to this adress.

Then I use the SHA() private key to transfer the funds back.

After this, I publish the timestamped document along with a link to blockexplorer to verify it.


Now I have created a record in the blockchain, that, anyone having access to the document in question, can check the timestamp in this way:
SHA() of the document in question. Then create public key out of this private key, then make a adress out of this. Check with blockchain which are the *earliest* entry of this adress. The timestamp of that entry is the timestamp of the document in question.

Since the address is empty since we transferred the funds back, theres no funds to be able to withdraw from someone that has the document in question and can generate the private key.


How accurate is bitcoin timestamps and how can they be manipulated?
(either by the one timestamping the document, in effort to defraud someone with a future/history marked document, or some external adversary in order to gain any fraud convience, like manipulating timestamp so a important document seems to be issued after a identy theft credit block is ordered on a specific social security number in order to invalidate the document?)
1710819012
Hero Member
*
Offline Offline

Posts: 1710819012

View Profile Personal Message (Offline)

Ignore
1710819012
Reply with quote  #2

1710819012
Report to moderator
1710819012
Hero Member
*
Offline Offline

Posts: 1710819012

View Profile Personal Message (Offline)

Ignore
1710819012
Reply with quote  #2

1710819012
Report to moderator
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710819012
Hero Member
*
Offline Offline

Posts: 1710819012

View Profile Personal Message (Offline)

Ignore
1710819012
Reply with quote  #2

1710819012
Report to moderator
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5138
Merit: 12565


View Profile
November 23, 2011, 10:30:37 PM
 #2

It's much easier than that:
There's a very easy way to do this without any program:

First, SHA-1 the data you want to timestamp (or RIPEMD-160, or SHA-256 and truncate to 160 bits). Then use this to turn it into an address:

http://blockexplorer.com/q/hashtoaddress/putHashHere

Then, send any amount of BTC to the returned address. (If you modify Bitcoin, it's actually possible to create a transaction that sends 0 BTC to an address, which would also work. Then you don't have to destroy BTC.)

Finally, you can see the timestamp here:

http://blockexplorer.com/q/addressfirstseen/timestampAddress

How accurate is bitcoin timestamps and how can they be manipulated?

You need more than around 50% of the network's computational power in order to get the timestamp off by more than a few hours.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
sebastian (OP)
Full Member
***
Offline Offline

Activity: 129
Merit: 118


View Profile
November 23, 2011, 10:47:46 PM
 #3

But what about transaction fees? If we send 0BTC into a adress, it would never make it into a block unless a miner is honoring non-fee'd low transactions.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5138
Merit: 12565


View Profile
November 23, 2011, 10:57:43 PM
 #4

But what about transaction fees? If we send 0BTC into a adress, it would never make it into a block unless a miner is honoring non-fee'd low transactions.

You can put a fee on a transaction with a 0BTC output.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736
Merit: 1006

Let's talk governance, lipstick, and pigs.


View Profile
November 23, 2011, 11:22:55 PM
 #5

This could even become an automated 'notary' service. I'm sure this has been discussed before.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
sebastian (OP)
Full Member
***
Offline Offline

Activity: 129
Merit: 118


View Profile
November 24, 2011, 12:27:38 AM
 #6

cbeast: Exactly what im talking about.
This could be even included as a patch to the original client, since no changes in protocol is needed (you don't even need to disable IsStandard check), simply a button/menu alternative "Let bitcoin network notarize any document", and you get a large textbox to paste anything you want to notarize.

When a block gets confirmed, we have a time window of 10 minutes, where the notarized document will appear.

Combine this with a "real" notarizing service like: http://www.timemarker.org/en/ and you get second precision in the service.

The "timemarker.org" service then makes second precision, but timemarker.org would not be as trustworty as you think since they don't have many users, so even if you dont cheat, a verifyer can say that you cheat and you cannot prove you don't cheat.
You then combine this with a 0BTC transaction on bitcoin, and get both very high security, since bitcoin is really hard to cheat, but also get second precision for the timestamp.

What you could do, is simply timestamping (0BTC:ing) the hash of timemarker.org signature including the timestamp data, using the timestamp from timemarker.org as transaction timestamp, and including both in your data that was timestamped.
Bimmerhead
Legendary
*
Offline Offline

Activity: 1291
Merit: 1000


View Profile
November 24, 2011, 01:41:32 AM
 #7

Apparently there is quite a bit of leeway in the timestamp:

https://bitcointalk.org/index.php?topic=48782.msg581628#msg581628
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 503


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 30, 2011, 01:29:54 AM
 #8

This is genius and deserves a bump.

zellfaze
Full Member
***
Offline Offline

Activity: 141
Merit: 101


Security Enthusiast


View Profile WWW
November 30, 2011, 04:50:45 AM
 #9

I agree.  Without reading the post that Bimmerhead linked to, I think I remember there being a few hours leeway in the timestamp.  I'll have to check to be sure.  Surely though it isn't enough leeway to change the day the document was signed on.

EDIT:
Read the linked to post, it seems that there is 2 hours leeway.  So as long as you only need to be accurate within a few hours, you are alright.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 503


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 30, 2011, 10:05:42 AM
 #10

For the record, you don't actually need to send ฿0. You can send ฿100, and then retrieve it later. Of course, don't release your document to the public before retrieving your money.

Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
November 30, 2011, 03:39:38 PM
 #11

This is genius and deserves a bump.
To be "genius" it needs to be both good and novel. This application (using the block chain to prove that a piece of information existed at a given point in time) is good but well-known.

Also it can be done much simpler than in the OP. Since you don't need to be able to actually redeem any sent coins, you can skip the private key completely and simply include the document hash as an address.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
November 30, 2011, 04:01:26 PM
 #12

For the record, you don't actually need to send ฿0. You can send ฿100, and then retrieve it later. Of course, don't release your document to the public before retrieving your money.

How?  The address is non-existent.  You are sending BTC to an address which is simply a hash of the document.  There is no corresponding private key. Any funds sent there are irrecoverable.
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 503


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 30, 2011, 04:20:34 PM
 #13

For the record, you don't actually need to send ฿0. You can send ฿100, and then retrieve it later. Of course, don't release your document to the public before retrieving your money.

How?  The address is non-existent.  You are sending BTC to an address which is simply a hash of the document.  There is no corresponding private key. Any funds sent there are irrecoverable.
I was assuming the hash was used as a private key. The address can then be generated from the private key. When you release the document to the world, others can verify that it hashes to a private key which encodes the address.
Your way is better.

Note: You probably don't want to send ฿0 to it, because then it might get pruned when blockchain pruning is implemented.

To be "genius" it needs to be both good and novel. This application (using the block chain to prove that a piece of information existed at a given point in time) is good but well-known.
Yes, I've been told so since. I wasn't aware of this concept, but I guess it makes sense. (Putting an advertisement in a newspaper with a hash, or something similar.)

zellfaze
Full Member
***
Offline Offline

Activity: 141
Merit: 101


Security Enthusiast


View Profile WWW
November 30, 2011, 04:41:07 PM
 #14

I forgot about the concept of Block chain pruning.  You are right, it might be best to send something to it.

Although, I don't think that a transaction with 0 outputs and a fee would be pruned.  Then the fee would be lost.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
November 30, 2011, 04:46:50 PM
 #15

I forgot about the concept of Block chain pruning.  You are right, it might be best to send something to it.

Although, I don't think that a transaction with 0 outputs and a fee would be pruned.  Then the fee would be lost.

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.
zellfaze
Full Member
***
Offline Offline

Activity: 141
Merit: 101


Security Enthusiast


View Profile WWW
November 30, 2011, 04:52:17 PM
 #16

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.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
November 30, 2011, 05:02:14 PM
 #17

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.

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.
zellfaze
Full Member
***
Offline Offline

Activity: 141
Merit: 101


Security Enthusiast


View Profile WWW
November 30, 2011, 05:39:47 PM
 #18

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.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
dogisland
Sr. Member
****
Offline Offline

Activity: 262
Merit: 250



View Profile
November 30, 2011, 06:42:21 PM
 #19

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
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5138
Merit: 12565


View Profile
November 30, 2011, 07:38:40 PM
 #20

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!