Bitcoin Forum
December 05, 2016, 02:39:43 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Using bitcoin for trusted timestamping?  (Read 6960 times)
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
November 30, 2011, 07:41:44 PM
 #21

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.
1480905583
Hero Member
*
Offline Offline

Posts: 1480905583

View Profile Personal Message (Offline)

Ignore
1480905583
Reply with quote  #2

1480905583
Report to moderator
1480905583
Hero Member
*
Offline Offline

Posts: 1480905583

View Profile Personal Message (Offline)

Ignore
1480905583
Reply with quote  #2

1480905583
Report to moderator
1480905583
Hero Member
*
Offline Offline

Posts: 1480905583

View Profile Personal Message (Offline)

Ignore
1480905583
Reply with quote  #2

1480905583
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480905583
Hero Member
*
Offline Offline

Posts: 1480905583

View Profile Personal Message (Offline)

Ignore
1480905583
Reply with quote  #2

1480905583
Report to moderator
sebastian
Member
**
Offline Offline

Activity: 119


View Profile
December 04, 2011, 07:30:41 PM
 #22

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
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
December 05, 2011, 02:28:58 AM
 #23

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

Activity: 38


View Profile
April 09, 2012, 10:22:05 AM
 #24

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
April 09, 2012, 02:55:09 PM
 #25

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

Activity: 38


View Profile
April 10, 2012, 12:24:21 AM
 #26

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

Activity: 38


View Profile
April 18, 2012, 01:03:46 PM
 #27

TADA! https://github.com/goblin/chronobit
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2016



View Profile
April 18, 2012, 01:37:23 PM
 #28

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
Newbie
*
Offline Offline

Activity: 14


View Profile
April 09, 2013, 06:02:50 AM
 #29

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
Legendary
*
expert
Offline Offline

Activity: 1064


View Profile
April 09, 2013, 10:13:19 AM
 #30

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

Activity: 1036


View Profile
April 09, 2013, 10:14:35 AM
 #31

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
sebastian
Member
**
Offline Offline

Activity: 119


View Profile
April 09, 2013, 12:07:14 PM
 #32


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
Legendary
*
expert
Offline Offline

Activity: 1064


View Profile
April 09, 2013, 12:28:24 PM
 #33


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

Activity: 190


View Profile
April 10, 2013, 07:04:16 AM
 #34

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.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!