Let's Embrace BTC Trusted Timestamping

[mintymark]

Its obvious, but worth saying again. If you take a audio recording of a song you have written, or a a Video perhaps a draft of your latest film to be, and SHA256 that and follow the process above you have your proof.

Many musicians I meet still advocate the old method of posting a recording to themselves ort a lawyer in a sealed envelope so that the envelope gets post marked with a date. This seems to me to have several serious probems, easy to fake the post mark, hard to make the seal unbreakable, postmark often illegable, postmark may become illegible. In short, this is as bad as it gets and I doubt it would sustain a serious legal attack. I know musicians who have their lifes work protected in this foolish manner.

There is a real need for this, even if the people who need it do not always realise it.

Bitcoin, being a high-value thing, has the potential to be a much more permanent solution than other players.

It does not have to be in the mainstream clients, but I think it would be nice if it was.

[1714798365]

1714798365

[1714798365]

1714798365

[Murphant]

I understand the no-waste and no-transaction advantage of chronobit, but for anything that does transactions, this idea seems very simple and does not destroy coins. Also, it does not need a centralized service at all and no one even knows a commitment was made.

Just use the hash of the document as the secret key. Transfer .01 bitcoins to the corresponding public key's address and then transfer those .01 bitcoins back to you. To prove the signature, hash the document, calculate the corresponding public key, hash that, then show that appears in the chain.

It now takes two transactions, but it's free.

Also, I read this paper but I feel like it has no advantage over previous solutions other than being proven secure, did I miss something?
http://people.scs.carleton.ca/~clark/commitcoin/abstract.pdf

[AsymmetricInformation]

Thanks to everyone who responded so far.

I agree with retep's points, so no need to repeat them.

The main reason I feel that BTC Timestamping has serious potential to make a great contribution is actually this:

Is there a lot of demand for timestamping? Are people willing to pay for it?

No one seems to care about time-stamping at all— so no one is maintaining it, or bothering to build nice interfaces for it.

Indeed.  The world hasn't exactly been beating a path to my door to urge me to release my timestamper.  I made it because of posts here and chats on IRC about the topic, and promptly dropped it when I realized that I had no use for it, and neither did anyone else, so far as I could see.

Bitcoin timestamping has one huge advantage over other services; it is plainly and transparently verifiable.  Other services require trust. *

It may appear counter-intuitive, but this is actually strong evidence in favor of integrating timestamp to BTC clients. Hear me out!

I am not at all surprised that "no one is maintaining chronobit" or that people havent sought out kjj for his solution. The true utility of the timestamping service is, of course, that you can actually use it to prove the validity of a time stamp! That means that what really counts is how easy it is for the skeptical verifier to check the time stamp. It is probably the case that literally zero lawyers, let alone judges, could install chronobit onto anything, and we dont even have proof that kjj's software exists! Since the actual service that is being rendered is not to the user when he timestamps the file, but to the user when he is trying to convince skeptics that, yes, he did write that song before Jan 28th 2013, what is most important is that the verification process be VERY simple, so the stamp can be checked by skeptics in a low-cost way. An internet url, or drop down menu in Electrum, are at an acceptable level of simplicity, but even using the word "Linux" is probably already an instant zero in the simplicity category (which, again, is the most important category because this feature performs NOT on the user-level, who is likely technical, but on the skeptic-level, who may be completely nontechnical).

Here we see an additional advantage to Bitcoin, because guardtime, Surety, CertTime, etc have the potential of going out of business/stop offering the timestamp service/suffer some service disruption/become destroyed by nuclear war/etc, whereas with BTC you can rely on the timestamp to continue to work. In fact, when I looked into this, only hashing the file and emailing to yourself using ReadNotify provided anything close to an acceptable level of 'Verifiability'. All other protocols are just too hard for the skeptic to understand.

The second most important attribute of a timestamping system is that it has the maximum possible degree of non-arbitrariness. After all, why should a judge trust some crazy techno-babble coming from kjj about some esoteric thing that he wrote...even a techie would probably succumb to boredom before persuasion. Moreover, a reasonable person could suspect that kjj's software doesnt verify timestamps at all, and just says whatever kjj wants it to say, because when proving that he wrote that multimillion dollar song he will have an obvious financial interest in the outcome. (I dont want to narrow the applications here to the legal domain, but the optimal solution must work in all domains, including legal.)

Marry those two concepts, and hopefully it is clear that standardizing one unique protocol for this (specifically, the simplest protocol, which I believe to be the one I outlined in the first post) creates what is actually the greatest timestamping service in the history of mankind.

No exaggeration!

Moreover, no one addressed my "jewelry" point. People don't value gold at its current price of ~$1600 because it looks great in jewelry, but the converse is true: one of the reasons gold became the de facto medium of exchange is because even before gold got going as money it had some seed value as an un-tarnishable and beautiful material, among other things. Why not add even more seed value to BTC?

To me, the costs appear low, the benefits high.

[gmaxwell]

I know about chronobit and knew about it before I started my project - it's clever but it's not a good solution. As you know it works by getting the digest into the P2Pool share chain. The problem is the length of the chain from your share to the blockchain proper is hundreds or thousands of shares, which means a self-contained timestamp is huge - the included sample proof is 475KiB of data.

Thats only the case when a single p2pool user is running it— if all of them were you could easily make it smaller.

You also do not get any better precision. P2Pool shares do contain timestamps, but the timestamps follow the same 2 hour rule that Bitcoin proper does.

Thats _is_ better precision, it may not be better _accuracy_.  The p2pool sharechain format has been changed some 10 times now, and p2pool has great infrastructure for it, if there were a use-case for enforcing better accuracy it certainly could be done.

chain an incremental merkle tree so that paths from the chain to a block are short

A merkelized skiplist is what you want, I think.

but you certainly won't be able to convince him to tighten up the 2 hour rule. We've discussed that on the forums before, and any tighter than 2 hours means mining is dependent on centralized timesources, unacceptable.

A p2pool node gets a time estimate from its peers once per 10 seconds. You could use these to do better decenterlized offset estimation than anything available to Bitcoin.  The dynamics of p2pool are not those of Bitcoin.  P2Pool could, in fact, get SPV time from the sharechain and compute a decenteralized correction to a centeralized time source... and have it be substantially more accurate than Bitcoin's timing.

[phelix]

registering a namecoin name with your hash as value is a peace of cake....

[thezerg]

AI, I think you are right.  And its clear by your nick how important the idea of simplicity is to you.  Personally, and sorry if this pisses off the core devs, I think you should go ahead with a dirt simple document stamper right in the client.  But maybe double the tx fee, and pick a well-known amount of bitdust to transfer (it will be a hint to clients to not cache this unspent output).

Sure, some time in the future blockchain bloat, unspent Tx, and transaction volume will start to become an issue.  And guess what?  Either we will increase the scalability of bitcoin or transaction fees will rise!  But it won't be so bad if scalability is not solved.  People will simply have to compete to get their txns into the blockchain.  So bitcoin will be used for the big transactions and different alt-coin chains for pocket change txns.  At that point a more complex solution (or just a "stampcoin" fork) will make sense.  Moving this out of bitcoin (and Satoshi Dice, et. al. shifting to lite-coin :-) ) will free up capacity for other transactions.

tl;dr; Use bitcoin now to encourage scalability and shift to an alt-chain when the bitcoin TX fees grow too large.

[Atruk]

AI, I think you are right.  And its clear by your nick how important the idea of simplicity is to you.  Personally, and sorry if this pisses off the core devs, I think you should go ahead with a dirt simple document stamper right in the client.  But maybe double the tx fee, and pick a well-known amount of bitdust to transfer (it will be a hint to clients to not cache this unspent output).

Sure, some time in the future blockchain bloat, unspent Tx, and transaction volume will start to become an issue.  And guess what?  Either we will increase the scalability of bitcoin or transaction fees will rise!  But it won't be so bad if scalability is not solved.  People will simply have to compete to get their txns into the blockchain.  So bitcoin will be used for the big transactions and different alt-coin chains for pocket change txns.  At that point a more complex solution (or just a "stampcoin" fork) will make sense.  Moving this out of bitcoin (and Satoshi Dice, et. al. shifting to lite-coin :-) ) will free up capacity for other transactions.

tl;dr; Use bitcoin now to encourage scalability and shift to an alt-chain when the bitcoin TX fees grow too large.

It is entirely possible to make a fork of the Qt client that includes this feature which works on the bitcoin blockchain through means other than begging the core developers. Figure out how much this is really worth to you and then either code it yourself or commission someone else to do so. If you can develop or sponsor the creation of said document stamper in a bitcoin client that works as well and as simply as you describe, people might be more supportive of this in the mainline client.

I really like deterministic wallets. Enough people like the idea of deterministic wallets do much that they are working their way gradually into every major client. Deterministic wallets started with a single client's implementation though. Things like deterministic wallets and multisignature transactions that advance the protocol seem to strike me as more "core" than developing add ons that simply happen to use the protocol. SatoshiDice is popular and making dice game websites is popular, but I don't seem much clamoring for a menu option in the reference client that lets it auto-configure its operation to work as the back end of a dice gaming site.

registering a namecoin name with your hash as value is a peace of cake....

This. Because it has been merge mined forever, there is also a decent amount of hash power securing it. If your simple time stamping feature has this tremendous amount of value, building it into a namecoin client would let you have a safe place to play with it while potentially boosting the value of coins on that blockchain.

[AsymmetricInformation]

Thanks Zerg!

Things like deterministic wallets and multisignature transactions that advance the protocol seem to strike me as more "core" than developing add ons that simply happen to use the protocol.

I do happen to agree with this. Were this 'add on' (as I readily admit this is a non-monetary use, in fact touting that fact as 'backing' BTC via the "jewelry argument") implemented in Armory and Electrum I would call it Mission Accomplished! Electrum is probably the best candidate because downloading the block chain is high-cost to the skeptic and thus a severe hit to 'Verifiability'.

My code is in Python, but no one really needs it: this is so simple it would be less confusing to write from scratch rather than read...I will reach out to those developers (now that there is this healthy thread) to see if they are interested. I still want the core client (ie all clients), though, because these things need to be standardized in order to function as evidence!

registering a namecoin name with your hash as value is a peace of cake....

This. Because it has been merge mined forever, there is also a decent amount of hash power securing it. If your simple time stamping feature has this tremendous amount of value, building it into a namecoin client would let you have a safe place to play with it while potentially boosting the value of coins on that blockchain.

I also happen to somewhat agree with this ...and I am VERY passionate about Namecoin, and more than a little disappointed that it isn't catching the same development/media/user attention as Bitcoin (compare the windows installs, for example...writing your own .conf file!). Bitcoin, on the other hand, is both the new hotness that everyone loves, carries a MUCH lower risk that the software protocol will die from lack of interest. I think this BTC project will help cryptocurrencies in general and potentially encourage the ultimate earlier-adoption of Namecoin. Sadly, I HATE to say it, but Namecoin (as it stands) fails to meet acceptable levels of Verifiability.

[vog]

Some days ago I wrote Bitcoinproof, which aims to make trusted timestamping easily available for any bitcoin user. It generates an address for your dummy transaction, and even provides a "bitcoin:" URL. So the payment via your local bitcoin client is just one click away. It also provides an automatic check whether your data (or SHA-256 hash) has already been timestamped. Except for this external check, everything is calculated on client side, i.e. pure JavaScript.

[AsymmetricInformation]

Some days ago I wrote Bitcoinproof, which aims to make trusted timestamping easily available for any bitcoin user. It generates an address for your dummy transaction, and even provides a "bitcoin:" URL. So the payment via your local bitcoin client is just one click away. It also provides an automatic check whether your data (or SHA-256 hash) has already been timestamped. Except for this external check, everything is calculated on client side, i.e. pure JavaScript.

Pretty cool!

Personally, it has been on my to-do list to make one as an Electrum plugin.

Some questions:

1] How are you getting from the SHA256 to the bitcoin address? I outlined importing the HEX sha256 as a base58 private key, then bouncing to the resulting btc address and back to avoid destroying coins. It is absolutely essential that everyone coordinate on one easy-to-replicate method: the one easiest to understand and replicate.

2] Relatedly, you are using the method of sending a btc to the address to be destroyed forever. It doesn't seem like a big deal to me, but some people don't like that. Why not use the document SHA256 as a private key, to make it "free" (assuming no transaction fees)?

I find it interesting that, assuming fixed nonzero transaction cost this is technically cheaper (1 transaction cost instead of 2) to "SatoshiDice" the network with a non-monetary transaction (assuming one must pay a fee). I've been wondering if there isn't a way to realign those incentives in a more win-win way...I'm sure lots of other people are as well.

[vog]

1] How are you getting from the SHA256 to the bitcoin address? I outlined importing the HEX sha256 as a base58 private key, then bouncing to the resulting btc address and back to avoid destroying coins. It is absolutely essential that everyone coordinate on one easy-to-replicate method: the one easiest to understand and replicate.

This is explained in the "background" section of the Bitcoinproof website. Essentially, the given data is handled as if it was a public key, so the Bitcoin address is:

RIPEMD(SHA256(data)) + checksum

2] Relatedly, you are using the method of sending a btc to the address to be destroyed forever. It doesn't seem like a big deal to me, but some people don't like that. Why not use the document SHA256 as a private key, to make it "free" (assuming no transaction fees)?

I decided against that for the following reasons, which hopefully serve as a good base for discussion:

2a) I don't think the "burned" bitcoins are really an issue, especially such extremely tiny amounts (in fact, the smallest positive amount possible). As I wrote at the Bitcoinproof website, 100 million of these tiny transactions will cause the same damage to the currency as one unlucky guy owning 1 BTC and losing his wallet.

2b) I'm not sure if it is technically correct to generate a private key from a random SHA-256. Maybe I just have to refresh my knowledge about elliptic curve asymmetric cryprography, but I'm afraid that multiple SHA-256 sums could lead to essentially the same private key, or at least to the same public key, thus reducing the trust you can put into that kind of timestamping.

2c) The user would then have to do two transactions, one to the new bitcoin address, and one back from it. In a local client, this might be a no-brainer, but in an external service, you'd have to provide the private key via a "bitcoin:", or similar. I'm not sure if this is really supported by all bitcoin clients.

2d) Once the temporary account has been totally spent, it could be pruned. That could make trouble in the future, as you can validate your timestamp only with a non-pruning client.

I find it interesting that, assuming fixed nonzero transaction cost this is technically cheaper (1 transaction cost instead of 2) to "SatoshiDice" the network with a non-monetary transaction (assuming one must pay a fee). I've been wondering if there isn't a way to realign those incentives in a more win-win way...I'm sure lots of other people are as well.

I'm not sure if I really understand your question, but it might help if users are paying volutarily a duplicate transaction fee. Maybe it is possible to encode the proposed transaction fee into the generated "bitcoin:" link?

[luv2drnkbr]

You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

[vog]

You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

This won't prove anything. What's preventing me from creating a PDF document with exactly that contents afterwards, describing some old transaction (and back) that I did in the past?

[kjj]

You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

This won't prove anything. What's preventing me from creating a PDF document with exactly that contents afterwards, describing some old transaction (and back) that I did in the past?

Read carefully.  You are missing a couple of steps.

[vog]

You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

This won't prove anything. What's preventing me from creating a PDF document with exactly that contents afterwards, describing some old transaction (and back) that I did in the past?

Read carefully.  You are missing a couple of steps.

Sorry, my fault. He's describing how to create a private key out of the document hash, which might work indeed. Although I'm not sure. Any comments on my question?

2b) I'm not sure if it is technically correct to generate a private key from a random SHA-256. Maybe I just have to refresh my knowledge about elliptic curve asymmetric cryprography, but I'm afraid that multiple SHA-256 sums could lead to essentially the same private key, or at least to the same public key, thus reducing the trust you can put into that kind of timestamping.

However, putting the latest bitcoin block hash into the text is a waste of bits. Although it proves that you creates this portion of the document at that time (or later), the rest of the document could have been written years ago. Or maybe you just had it in your head and didn't write it down. Who knows?

So I agree that the upper bound works, but not the lower bound.

[kjj]

You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

This won't prove anything. What's preventing me from creating a PDF document with exactly that contents afterwards, describing some old transaction (and back) that I did in the past?

Read carefully.  You are missing a couple of steps.

Sorry, my fault. He's describing how to create a private key out of the document hash, which might work indeed. Although I'm not sure. Any comments on my question?

2b) I'm not sure if it is technically correct to generate a private key from a random SHA-256. Maybe I just have to refresh my knowledge about elliptic curve asymmetric cryprography, but I'm afraid that multiple SHA-256 sums could lead to essentially the same private key, or at least to the same public key, thus reducing the trust you can put into that kind of timestamping.

However, putting the latest bitcoin block hash into the text is a waste of bits. Although it proves that you creates this portion of the document at that time (or later), the rest of the document could have been written years ago. Or maybe you just had it in your head and didn't write it down. Who knows?

So I agree that the upper bound works, but not the lower bound.

Any collection of 256 bits can be a bitcoin private key.  The output from SHA-256 is perfectly suitable.  There is a miniscule chance of creating a weak key with hashing, but you can add a nonce and try again.  You should also play the lottery if that ever comes up.

The catch is, however, that you intend to publish the document at some point, so you can't use the account for storage.  You just transfer in as proof, then transfer out to keep your cash, and then you publish.

My system did almost exactly that, just with an indirection step to minimize the blockchain bloat.  I would take one or more documents, hash them, and then collect those hashes into a new document.  The new document would be hashed, and that hash would become the private key.  A transaction would be sent to the corresponding address, and then back to my wallet, and then the list would be published.  Anyone would be free to download the list of hashes once the money was safely back in a secret key.

Including a recent block hash doesn't help much.  You are quite correct that you can't prove that the rest of the document was created at a certain time, and no timestamping service can do that.  The best it can do is prove that it merely existed at some particular time.

[vog]

My system did almost exactly that, just with an indirection step to minimize the blockchain bloat.  I would take one or more documents, hash them, and then collect those hashes into a new document.  The new document would be hashed, and that hash would become the private key.  A transaction would be sent to the corresponding address, and then back to my wallet, and then the list would be published.  Anyone would be free to download the list of hashes once the money was safely back in a secret key.

I agree that it is a plausible optimization to collect the hashes of multiple people, and to timestamp only the hash of the the hash list. This will reduce the load on the bitcoin network if used by many people, but has two important downsides:

i) Now you are paying the transaction fees, not the users. And if you require a payment of the users for each timestamped hash, you have failed the original goal to reduce the number of transactions. So this makes only sense if that system works kind of donation based, i.e. every month some voluntary pays 2 to 4 BTC to keep this running for the next month.

ii) You have to be careful not to ruin the user experience with that. Otherwise you have a system that only few people will use, so you don't need that optimization in the first place. The best UX would be to save the hash lists on server side. When asked for a hash, you look it up in the lists, and check the bitcoin network for the list hash. However, this creates a strong dependency on the additional service, while the direct timestamping can be done independently with any tool. So you could also offer your users to download their list, and label it kind of "timestamp proof certificate".   But you can't offer them the download right away, just after 10 minutes or later. So you either have to send emails (which is an issue of its own), or you offer them their "certificate" when they come back later to check that their timestamp really entered the chain.

If there's really no better solution, one should better try to make Chronobit more usable.

[vog]

2b) I'm not sure if it is technically correct to generate a private key from a random SHA-256. Maybe I just have to refresh my knowledge about elliptic curve asymmetric cryprography, but I'm afraid that multiple SHA-256 sums could lead to essentially the same private key, or at least to the same public key, thus reducing the trust you can put into that kind of timestamping.

Any collection of 256 bits can be a bitcoin private key.  The output from SHA-256 is perfectly suitable.  There is a miniscule chance of creating a weak key with hashing, but you can add a nonce and try again.  You should also play the lottery if that ever comes up.

Okay, so let's assume that using the SHA-256 as private key is doable. What are the benefits? Let's compare the cost of the timestamper and the cost of the network, assuming a transaction fee of 0.0005 BTC:

Using SHA-256 as public key: The timestamper creates 1 transaction to send 0.00000001 BTC, with 0.0005 BTC fees. Total cost for the network: 1 transaction. Total cost for the user: 0.00050001 BTC.

Using SHA-256 as private key to get the money back: The timestamper creates 2 transactions: 1) send 0.00000001 BTC with 0.0005 BTC fees, 2) receive 0.00000001 BTC with 0.0005 BTC fees. Total cost for the network: 2 transactions. Total cost for the user: 0.00100000 BTC.

SHA-256 as ...	Cost for network	Cost for timestamper
public key	1.0 trans.	0.00050001 BTC
private key	2.0 trans.	0.00100000 BTC

So the private key variant to "get your money back" is almost twice as expensive - for the timestamper as well as the network. That's quite a lot of effort just to save 0.00000001 BTC from being "burned".

Okay, you could wait some time with the back-payment until you'll have another payment, so you don't need an extra transaction for that. But even then, this second transaction becomes bigger (in bytes) than necessary. Let's say it becomes 10% bigger. This would improve the situation as follows:

SHA-256 as ...	Cost for network	Cost for timestamper
public key	1.0 trans.	0.00050001 BTC
private key	1.1 trans.	0.00050000 BTC

In that case, you'd save 0.00000001 BTC but still produce a higher load on the network. That's not very social.

In summary, the amount is so small that you'll never need it back. And if you take it back nevertheless, you'll only create more load on the network. That's why I'm not convenced of that, but maybe I've overlooked something?

What are the real advantages of encoding the SHA-256 in the private key?

[melvster]

Many people, including myself, have a vision of using BTC to make an unalterable timestamp of a file.

________
Background for those unaware:
Unfakeable timestamping is easy to do with Bitcoin because you can just use a SHA256 of any file as a privatekey, import it, and then send BTC to it and back. The fact that you sent BTC to, and then from, the file's associated Bitcoin-key-and-address proves that you had access to the file at a certain time (the time of the transactions).

The low-tech, quick-and-dirty way is to:
1] SHA256 a file containing the contract/great ideas you want to take credit for later.
23e039cf88c6f2fe89415b938d62245af3f339ccf734d8d0c939422c7e4bb8b8

2] Hit up brainwallet.org
2.1] Convert Hex (hash) to Base58 using the convert tab of brainwallet.
5J65yxHPWGfNrXatL8gKwqhFJh9tAXKPmAxYHxFk8b9ACsxd9jS
2.2] Import this as a Private Key on the Generator tab of brainwallet...you will get an associated public key and Bitcoin Address.
1LHnjmyNPDmb9PopeBNrnhNTGVkVkhTGgY

3] Send some BTC to that address using your client.
4] Use brainwallet (transactions tab) to send that money back to your main wallet (the temp wallet created in 2.2 will not be secure when you release the file with all your great ideas, as anyone can hash it).

5] Wait patiently at http://blockexplorer.com/q/addressfirstseen/ for your BTC to show up in the network. Unfortunately this functionality has yet to be incorporated into open-source Abe (and I failed to replicate it myself).
http://blockexplorer.com/q/addressfirstseen/1LHnjmyNPDmb9PopeBNrnhNTGVkVkhTGgY
2013-01-28 05:30:09
________
Previous discussion of this:
https://bitcointalk.org/index.php?topic=52715.20
https://www.strongcoin.com/en/blog/using_the_blockchain_as_a_trusted_timestamping_service
Goblin invented a version of this, but I could not get it to work (sorry!): https://github.com/goblin/chronobit
Someone wrote a paper about this and related ideas: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&cad=rja&ved=0CC8QFjAAOAo&url=http%3A%2F%2Feprint.iacr.org%2F2011%2F677.pdf&ei=OwIGUcqoCarD0AHDy4D4Bg&usg=AFQjCNE53BUwzCopGFXB9lX7F4tOYEpyzw&bvm=bv.41524429,d.dmQ
________


Personally, I envision this as something that would actually make a great core feature. Much in the way that gold is used in industry/jewelry (in addition to being a store of value and medium of exchange) Bitcoins can be used to timestamp files in an unalterable way for ~free (and used for sending international transfers for ~free, unfreezable assets, brain-storage, etc), in addition to being a store of value and medium of exchange.

Personally, I envision a drop down selection in the client GUI (for example **File > Timestamp File**) that just asks you for the path of the file. Easy to use, mainstream for everyone! Likely also a **File > Get File Time** to verify that a file was stamped. Obviously for this to happen there would need to be widespread community support.

Having millions of copies of proof of existance/ownership is way cooler than jewelry! Am I wrong? There are other minor benefits, like responding to people who say that "Bitcoins are inherently worthless / not 'backed' by anything" and helping to explain the sheer quantity of BTC addresses (at minimum 1 per possible MS Word document you could ever create) to people who worry about collisions or make similar arguments.

Your thoughts?

Note: I tried to code all of this myself but I ran into two snags, replicating /addressfirstseen/ and getting a ecdsa public key from a given private key (where is brainwallet.org getting 'G' to do the multiplication???). Im sure the core developers could do the whole thing in like 15 minutes if they wanted to, though, even if it needs to rely on blockexplorer.com's /addressfirstseen/  for now.

Neat idea but could you not do something like this on github, or can you fool timestamps in github.  In any case it should get indexed by search engines and archive.org

I see two issues with this
- Extra overhead to maintain extra generated outputs
- You introduce more incentive to attack the block chain

I'd suggest waiting until the block chain is more mature and robust to let this go more mainstream, but if you do it as a one-off, be nice and add a decent tx fee, to compensate for the processing current and future, that you'll add.  I dont think it belongs in the default client at this point.

Regarding gold as jewelery, that was more that gold was the mythological metal of many religions, and the solar metal, rather than, it being multi purpose.  Leaders often wore the gold circle to indicate being close to god and the solar power.  So I am unsure there is a like for like comparison here.

[socrates1024]

The true utility of the timestamping service is, of course, that you can actually use it to prove the validity of a time stamp! That means that what really counts is how easy it is for the skeptical verifier to check the time stamp. It is probably the case that literally zero lawyers, let alone judges, could install chronobit onto anything, and we dont even have proof that kjj's software exists!

So, lets talk about a different application for timestamping. If we have to rely on vague "judgments" conducted by humans, we'll never get a good definition of "validity". Instead we should define the judgment itself as an algorithm. Then to give this teeth, we should have a scenario where someone can claim an actual prize of Bitcoins if they're able to produce valid evidence of timestamped data. Ideally this validation scheme would be encode in a Bitcoin (or altcoin) script, so that the entire judgment and disbursement is carried out automatically/decentralized/trustlessly.

Is there anything that fits this framework? The obvious cases like protecting patents and copyrighted material at least require some additional judgment of 'similarity' or something so you'd still have to rely on some kind of fuzzy human argument. If we can't think of anything that fits this framework, then it's evidence that there's little use for timestamping beyond the sort of services that contribute legal defense of the timestamp as part of the deal.