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.
Topic: Let's Embrace BTC Trusted Timestamping - page 3. (Read 7600 times)
I suspect you built your system in significantly less time than I did mine. 
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.
I suspect you built your system in significantly less time than I did mine.
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.
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 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
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.
I've written such a web service. It is pretty easy to do it right.
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.
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.
Agreed.
I've written such a web service. It is pretty easy to do it right.
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.
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.
I've written such a web service. It is pretty easy to do it right.
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.
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.
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.
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.
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.
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.
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.
________
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.
Jump to: