Bitcoin Forum

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.

I would prefer to have a separate app which is designed specifically for this purpose. Having it rely on blockexplorer wouldn't be too bad imo.

we had some very similar ideas and came up with these  prototype implementation for both android  (end-user) and python (server) - they work independently.
we also use sha256(file) as the private key, but for now we don't send the money back.

https://github.com/bitcoinaustria/bitnotar

because of the workings of intents, you can use this tool in basically any Android app that supports sharing of content. (text, pictures, videos) it utilizes a generic bitcoin URI intent to send the funds, so you can use bitcoin wallet for android, bitcoinspinner and possibly others in the future.

i think this would be a great addition to dashcam software, for on-the-fly video notarisation if properly extended.

Maybe the "sending back" is actually a not so good idea. Will tx with all outputs spent not be pruned from the blockchain at some time in future?

Just make the amount small enough to not matter.

Then again, if my suspicion is correct and tx will get pruned, and also the private key will be public, people can cover evidence just by collecting the last Satoshis that prove the existence of the evidence...

Generally it's a neat idea but IMHO Bitcoin should not be overloaded with lots of services that are unrelated to payment. We will have a lot of work scaling the payment alone, if Bitcoin catches on.

I think having this option in wallets would mostly confuse people. It's an obscure concept that has limited utility. Standalone apps are the way to go. If you want to really push this, please make sure OP_FALSE is a standard script type so such outputs can be pruned in future.

Agreed.  This isn't something that should be in the reference client, nor widely deployed at all.  The correct way to do this is either with one of the zero-bloat merged mining systems, or with a web service that can collect a batch of hashes to reduce the blockchain load to one transaction per day, or hour, or block or whatever, and can respend the proof transaction to prevent UTXO pollution.

I've written such a web service.  It is pretty easy to do it right.

Agreed.


Oh yeah? Where is it? I wrote one too, but haven't promoted it because I want to see if I can get a version going that has a P2P layer of co-operating nodes doing the actual timestamping tx. (coinbase or not) Currently mine only supports a single timestamping server, although it's easy to extend it to multiple redundant servers if the servers have co-operating sysadmins.

If there is demand for this stuff, please let us know and we can get a better solution than polluting the blockchain, and especially creating a bunch of unspent transaction outputs. This won't take much time either; I've already done nearly all the work myself. You have to remember that the total number of unspent outputs will be a really big issue in the future, because while not every validating node needs a full copy of the blockchain, every validating node does need a full copy of the unspent outputs. In addition any solution that needs a transaction per timestamp is also going to be paying fees - prohibitive for the dash-cam example above - while the non-blockchain-bloating solutions will be free to use.

Hidden on my webserver, of course.  I tested the interface and the automation (by running the cron jobs by hand) and made sure it worked.  I just ran out of steam thinking about the next steps (security review, polish, release).  The bitcoin parts of it really are easy; anyone can write one.  Maybe I'll even finish mine some day.

Mine derives a pubkey using the hash of the list of hashes as the privkey and spends all collected fees to that address, then spends it back to a real wallet before publishing the final list.  Zero UTXO pollution, maximum of 2 transactions per block, usually MUCH less.  There was a minimum fee for the notary service with a long service window, and people could pay extra to hurry it along.  The holding time was calculated based on the fees collected and the ages of the documents, so that even a single document with the minimum fee would trigger it after 24 hours.

Mine is a much more generalized system. The core is a generalized mechanism that takes digests and applies operations to them to produce other digests. Provided the series of operations is one-way, you know that any mechanism that has timestamped the resulting digest, implies every other digest in the chain is also timestamped. To support structures like merkle trees there is code that operates on directed-acyclic-graphs of these operations, and further more code to maintain various merkle tree structures efficiently. It's generalized enough that the whole blockchain can be represented within the system, as well as alt-chains and a whole bunch of other stuff. The actual timestamping mechanism is then called a "notary method" and Bitcoin is just one of many possible ones.

The Bitcoin-specific stuff I have implemented uses multi-sig transactions. For each timestamp I create a transaction spending an input, usually an earlier timestamp, with a scriptPubKey consisting of a bare 1-of-2 CHECKMULTISIG. One of the pubkeys is a real 33-byte compressed pubkey, and the other is just the digest to be timestamped. Thus per digest you just need a single transaction about 200 bytes in size, and again the output is spent and thus prunable. Equally you can use coinbase transactions, and because of the flexibility the client software doesn't care. Each timestamp also includes the merkle path all the way up to the block header itself, so you verify a timestamp you just check that the block header hash is a valid block; this can be done efficiently without the full block chain by SPV clients. You also don't need to implement any ECDSA crypto operations to create or validate these timestamps; just easy SHA256 hashing. An example tx is a467025de01a7707b0f0e3f7bd9ffb94a2eeb02eede115e0dfe4590361655e02 (http://blockchain.info/tx/a467025de01a7707b0f0e3f7bd9ffb94a2eeb02eede115e0dfe4590361655e02)

The service I setup just takes submitted digests and builds a merkle tree of them every 10 minutes (currently) and submits the top digest. The intermediate nodes in the tree are saved temporarily for clients to retrieve them once they confirm; I could also email back the timestamps. With the generality you could also use trusted-signature-based stuff like RFC3161 or PGP signing in parallel to Bitcoin to get better timestamp resolution.

I suspect you built your system in significantly less time than I did mine.  :P

Not counting the time I spent writing encoders and decoders, and learning the raw transaction API, I'd say less than three hours.  But mine was intended to be a minimum-effort system that does nothing more than prove that some hash X existed prior to some block Y.

I started working on mine last June, and went through three designs before I settled on a core structure that I liked. I also was thinking I might be able to write it up as a masters thesis. ("it" as in a complete system including actual applications, good UI's, etc. more of a masters in UI design than cryptography really)

But it still has the "O(n)" problem in that once released people will start running their own servers - n of them - rather than using efficient centralized ones. I was hoping to design a workable, DDoS resistant way of creating a P2P co-operative network for building up the merkle tree that actually gets timestamped, preferably in a coinbase tx, but I haven't figured that part out yet.

Still, as I said above, if people are actually doing blockchain bloating timestamping already, maybe I should just release what I have... I don't mean to offend apetersson, but your bitnotar app really worries me.

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

There are already free, centralized services that will timestamp arbitrary hashes for you. Besides the risk that they might go away (which you could mitigate by getting timstamps from several of them), is there any real advantage to using the blockchain?

If I can already get timestamps for free, why would I bother to pay a transaction fee to get a blockchain timestamp?

I'm often wrong, so feel free to ignore me, but blockchain timestamping seems to me like one of those gee-whiz ideas that appeals to us techies but isn't "enough better" than existing solutions to be interesting to non-techies.

.... another random thought:  I wouldn't be surprised if you could get tricky with nonces to get any https-enabled web server to act as a free timestamping service, too...

Timestamping in a scalable way (zero cost) has already been implemented:  https://github.com/goblin/chronobit

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

I'm thinking this might be one of those applications that would be perfect for a merge mined altchain. If the desired feature is timestamping, it shouldn't matter that timecoins aren't worth anything.

Lots of demand, which is why guardtime (http://www.guardtime.com/), Surety (http://www.surety.com/) and a bunch of other services exist. On the other hand, I'd argue that what those people are selling isn't timestamping, it's lawyers. Specifically the legal frameworks to convince juries and judges in court cases that the timestamps were valid. The actual mechanism is secondary. The clients are specific, regulated markets such as digital evidence, medical trials etc. Note how services not targetting those markets, like CertTime (http://www.certtime.com/), (graphics designers, now closed) haven't done so well.


Yup, CA's supporting RFC3161 or Authenticode are common.


Frankly trust is a big one. RFC3161 and Authenticode are pure "signature-only" timestamps that trust the issuer %100; they don't even have hash-chain-based logging to reduce fraud. (guardtime does this, but it's expensive) Scalability is also a problem: they need n units of server capacity for n timestamps, and the secure hardware running the servers is expensive; all the CA-run servers heavily rate-limit and will ban you if you try to use them in an automated way. This means isn't a free way to timestamp, say, log files as they come in, git revision id's, or say archive.org's webcrawler. Scalability is actually a big part of why I wrote OpenTimestamps: even without the blockchain it'd make timestamping with centralized servers much more usable.


You can say that for timestamping in general... What a timestamp does security-wise is tricky to understand and use to make something else secure. It's precisely why I thought I could make a masters out of the subject, and a masters that I could actually do at the industrial design department at the art school I got my degree at.


There is a lot of truth to that statement: look at how few RFC3161 implementations there are in the open source world and how there isn't a single package in the Ubuntu or Debian repositories related to timestamping at all. Having said that I think this is because all the existing solutions come from the commercial world of regulated industries and require central services that must be trusted %100 - anathema to open-source philosophy, and more practically, difficult to use because of the need to keep track of revocation lists and other on-going maintenance.

As for chronobit, like Gavin said about ease of use, why would you use something that requires dedicated mining hardware running for a few hours to make a single timestamp when you could bloat the txout set instead? It's bloody inconvenient, and on top of that the resulting timestamps are huge because they depend on P2Pool's linear block chain. (note that without a link to the Bitcoin blockchain the P2Pool timestamp is worthless, and additionally P2Pool follows Bitcoin's 2 hour rule so your resolution isn't any better) It's the same problem with coinbase timestamping: if you implemented it on just Eligius - as Luke graciously offered - it'll easily take a day or two before your timestamp gets into the blockchain. Even just having to wait up to an hour (what I've written) is problematic enough because you really need a server-side mechanism to later send the completed timestamp or the client, or maintain something like a 1s resolution calendar database for later retrieval by the client. (this is how guardtime works)

Ultimately the big thing you're up against is whatever solution you come up with has to be less expensive, in fees and in whatever else the user wants, than the fee to create a transaction. I also suspect that if we do nothing people will gradually find useful things to do with blockchain timestamping, and there's no guarantee the application that does find traction does it right. The dash-cam example above is a good, and scary, example as dash-cam's are really popular in some parts of the world.


The obvious way to do it - a pure chain with timestamps - is unlikely to work because you probably won't be able to get enough hash power to trust it by itself. Now the shares that make it to the Bitcoin blockchain directly can be trusted but you're back to the "takes a few hours" problem. That said an alt-chain might be part of a protocol to do P2P co-operative timestamping.

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. *

I might dust it off and polish it up some day as an amusement.  And maybe it'll even be useful some day.  Bitcoin is, after all, teaching all of us to live with trust-free money.  Perhaps some day, we'll have a good use for trust-free timestamping.

* Amusingly enough, this trust is already abused in real life timestamping systems.  Most courts will accept postmark dates as fact, but all serious offices have postage machines that print their own dates, so they are super easy to fake.  The good news is that the post office will scribble out your date and put their own on your mail if they notice something like that happening.  And not much pisses off a judge quite like a lawyer disregarding his duty as an officer of the court.

Note how the need for trust makes existing timestamping useless for anything anonymous, or even just that some large entity doesn't like; Satoshidice timestamped their secrets on the blockchain for a reason.

Check out chronobit.  The merged mining system allows arbitrary numbers of alt-chains to ride along with no additional cost to the bitcoin chain, beyond the first one.  Chronobit uses that system to create provable timestamps.  Oh, and it uses the p2pool sharechain to give (relatively) high precision, and to allow timestamping to anyone that can generate a p2pool share.

chronobit is really nifty.  If I had learned about it before making my timestamper instead of after, I probably never would have started.

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.

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. Of course you could try counting the number of shares and multiplying by the average share time, but that doesn't work either as there isn't any way to know if the share chain ending in a Bitcoin block is actually a real p2pool share chain because old shares in the chain are discarded, and it's impractical to store every share ever made. It might be possible to convince forrest to make the p2pool chain an incremental merkle tree so that paths from the chain to a block are short, 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.

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.

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.


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

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:


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.

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

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.

A merkelized skiplist is what you want, I think.

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.

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

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.


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.

Thanks Zerg!


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!


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.

Some days ago I wrote Bitcoinproof (http://vog.github.io/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.

This is explained in the "background" section of the Bitcoinproof website (http://vog.github.io/bitcoinproof/). Essentially, the given data is handled as if it was a public key, so the Bitcoin address is:

RIPEMD(SHA256(data)) + checksum


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 (http://vog.github.io/bitcoinproof/), 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'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?

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?


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.

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.

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?

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.

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.

The main idea is not to protect copyrighted work or proof that a idea existed in Before, since you only proof that your work existed at time T, but you cannot proof that anyone other work similiar to your work DID NOT exist at T-x. For that, we would need every work to be timestamped, which would require a law change that states that copyright or patent is invalid without a certified timestamp.

Rather, its to securely proof that data was unchanged at a specific Point of time.


Examples where timestamping can be very useful:
Corporate bookkeeping: For example here in sweden, Bookkeeping requires a software that MUST be closed-source, to be able to proof that data was unchanged at a specific Point of time. If we instead cryptographically proof it, it cant be changed without detection.

Physical contracts: It can be good to have certified time on contracts to proof that the contract was established for example Before a ID-card was revoked/barred/expired. Because if the ID-card was revoked/barred/expired at the Point of establishment, the contract can be invalid per the law. Certifying a contract can be done by for example scanning it, timestamping it and then saving the image file as proof, while still keeping the original.
Signing at "Sign with name and date" is not enough in some cases, contracts can be back-signed (by the issuer by prefilling the date, to be able to establish the contract knowing that the ID-card is stolen) or future-signed (by the signer, to be able to protest the contract after barring the ID-card as stolen). If the issuer timestamp the received signed contract, there will be clear proof that the signer future-signed it, and the signer can easly protest a back-signed contract that lacks a timestamp if all other contracts by the issuer bear a timestamp.

Digital contracts: Here the same thing - but with revoking or expiration of private keys that is the key Point here.

Something about Txout that I dont understand. But I am now convinced it should just be Ripmd160(Sha256(*)) and no go through the trouble of importing a key.

Somehow it is possible to send 0 BTC that cant be pruned.


You dont really believe any of that, do you? What earthly system is practical under this requirement? If it is understood that this service exists, people would reasonably ask "why did you not BTC timestamp this?"

There's two other options that I can see for timestamping into the blockchain, both of which don't burn any coins, and are only one transaction:

Use the amounts sent as the hash: BitcoinTimestamp (https://github.com/fireduck64/BitcoinTimestamp) does this, and is the utility that SatoshiDice used to set their timestamp. Break the hash to be timestamped into 2-byte chunks (0-65,535 in decimal), and translate those into satoshis (max of 0.00065535 BTC cost). Create a multi-send transaction that has outputs that put the hash pieces in order. The BitcoinTimestamp utility uses 16 separate addresses, but I don't think there's any reason why this multi-send couldn't just send all the outputs back to the sending address. Or you could send to one other of your addresses to keep the coins. Zero coins get burned in the process, though the downside is a rather bloated transaction that splits out a chunk of BTC into several "dust" outputs.

Use the Script of a transaction: Currently the Transaction with a message (https://en.bitcoin.it/wiki/Script#Transaction_with_a_message) isn't a standard message type, so you'd need a non-standard-friendly miner to get it into a block. However, with 520 bytes available as a single raw value in a Script (that can then be OP_DROP-ped), that's plenty of space for a 256-bit hash (32 bytes). If we could add that sort of transaction Script to the list of "is standard" scripts, associating a separate hash with a transaction is one of several things that could be done with it. It would make the transaction bigger by 32 bytes (or however large the "message" part of the transaction is), however.

I was going to post a new thread about using the bitcoin protocol and a way to tie a unique work of (digital) art with it to create a new type of copyright office on a global level, but I feel like maybe this thread is going there already.


I am an artist. Putting up a music track or a photo online is pretty much instant, but I have to send my recording to the Copyright office, http://www.copyright.gov/prereg/help.html#help15. Things are getting faster compared to sending my music for $35 per recording 20 years ago on a cassette via the post office. Obviously France has their laws, so does Germany and so forth.

This is a very naive question but since the protocol found a way to create a unique digital entity, why not use it to attach a unique ID to the name of an artist with all the Data he would love to provide with his creation, but being verified as being posted by him on the bitcoin protocol by all the see on a block chain like site anytime, years from now?
The same concept of transferring the rights to another person could be coded too with a contract built in. The bitcoin could release the right to make the artist creations automatically public domain 15, 20 years after his death, or whatever the artist's will was before his passing. a concept like Creative common could use the protocol too and adopt their open way using a solid foundation that goes across nations and many levels of copyright laws.

I believe pure digital arts should have value as much as a Picasso. Of course a Picasso is unique. Could not this be solve with the bitcoin protocol too? Sure some may make a copy of the art, but only the owner could prove to anyone with his public key he owns the full right of say art to be displayed in a museum for example. The museum could have a contract with the artist to  have his digital art displayed exclusively for a set of weeks or months. Right now this could be a music installation, images or tomorrow it could be some full high resolution holograms.

The other reason I believe this to be VERY important is a way to have the bitcoin protocol to be impossible to be vilified ONLY for its anonymous nature as being cash online. I am sure many thought of using the protocol as a new way to copyright their works before I did, but this concept could accelerate the adoption of the bitcoin protocol and make it legit even faster, beyond being simply "digital cash"

Anyway, should I still post all of this to a new thread?

Thank you for reading.

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

It hashes your data to an address you can destroy some btm on.  Might want to do a first round hash offline so that the server does not see your data. Genius simple.

With namecoin you could link hashes to a name. Hash data to a namecoin address (like in the post above) and link it with your name.

Ok so namecoin's "structure" would be more suitable for my copyright concept than the bitcoin protocol then?

I was more in favor using bitcoin after watching this video from Mike Hearn http://youtu.be/mD4L7xDNCmA

The protocol seems very powerful to evolve into the ultimate digital stamping tool for whatever files using the web. Now that ASICs will be online, could it be that other transaction other than money would be processed faster like contracts/copyright issues, sorting through TB of data to find out who owns what contracts, etc? I could imagine a company building ASICs just for the purpose of managing a sub network of everything not related to the currency part.

Bitcoin's fundamental tenant is on anonymity; "attach an ID to an artist" is against the grain of that. You could force it to work, but you may want to try looking at PGP/GPG instead, which is based on giving a unique individual a unique identifier, and then they can sign/encrypt things proving to be themselves.

Bitcoin addresses can be used in this way somewhat, especially since you can now sign a message in such a way that it proves that you own a particular Bitcoin address. So, if you create a new bitcoin address, use one of the discussed ways to create a transaction that's effectively a hash of a digital asset you created, using the new address as destination, you can then create a message and sign it with that address saying "Transaction [ID] is a hash of digital asset [MySong] that I created." Make sure that signed message is public and won't be lost in time. Now you've proven that "MySong" existed at a certain time (due to the timestamp), and is related to a given Bitcoin address, and whoever is able to sign a message from that address is in possession of the private key of that address, and therefore the owner of "MySong". In your will, you can give the private key to whoever the new owner should be, to pass along ownership. This is close to what you're describing, but effectively the bitcoin address "owns" the asset, not an individual person (which may or may not be what you want).


No, transactions will not happen faster; read up on the "difficulty" bar set into the network. Blocks will be generated every 10 minutes. If the hashing power of the miners on the network goes up (e.g. ASICs become available), the difficulty goes up too, so it still takes 10 minutes.

Here's an idea

1. Take a SHA256 of your document

2. Put it into http://brainwallet.org/ passphrase field

3. Send some BTC there

Bingo!  Now the existence of that file is timestamped forever in the block chain and all block chain explorers.

Question is how high should the tx fee be?  You are inviting an attack on bitcoin by parties that may not wish this file to be timestamped.  Although it will probably survive in google and other mirrors.

brilliant :)

Oops ... I see what yours does now ... I was originally confused by the timestamp field and thought you filled it in.  I see it is read only now, everything makes sense.

Altcoins could also input hashes of their blocks in the bitcoin blockchain to provide proof of the chronological order of the blocks generated in their chain that can't be tampered through a reorganization of the alt-chain, caused, for example, by a >50% attack.

A small limitation to this is bitcoin's 10 minute block time being longer than some of the bitcoin-alts' block times. If bitcoin moved to a 1 minute block time, then it would be useful as a timestamp server in almost all situations for the existing bitcoin-alts.