Topic: Let's Embrace BTC Trusted Timestamping (Read 7600 times)

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.

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.

brilliant

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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?

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.

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.

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.

Read carefully.  You are missing a couple of steps.

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?