Topic: Let's Embrace BTC Trusted Timestamping - page 2. (Read 7600 times)

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


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'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?

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

Lots of demand, which is why guardtime, Surety 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, (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.

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.

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.

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