Make coins redeemable from stamped address

[ghost]

The general principal of stamping a hash of some data into the blockchain is fine, except it causes bitcoins to be sent to unredeemable addresses.

One could achieve the same result by using the hash of the data to create a private key (just like a brain wallet). You can then send coins to the bitcoin address of the private key, and be able to redeem the coins afterwards.

privateKey = brainwallet(hash(data))
address = get_address_from(privateKey)

Remember now have a minimum dust level which could rise later, bitcoin price is skyrocketing so this becomes expensive, and now we reduce the fee to 2 x miners fee which is more likely to go down over time.

[ghost]

Reference implementations:

Python

https://github.com/willwharton/pybrainwallet/blob/master/brainwallet.py or https://github.com/jgilmour/brainwallet-check/blob/master/brainwallet-check.py

Javascript

https://github.com/brainwallet/brainwallet.github.com/blob/master/js/brainwallet.js or https://github.com/pointbiz/bitaddress.org/blob/master/src/ninja.brainwallet.js

[shesek]

Heh, I was just replying to an email on this exact same subject!

The email reply is relevant here as well, so I'll just copy the conversation here:

Hi,

your current timestamping seems to "destroy" bitcoins for each stamp by sending them to addresses which have no private key.

This can be avoided by creating deterministic addresses (see, for example, [1]): Given a hash XXX which want to timestamp, a deterministic address Y is created by initializing a pseudo-RNG with XXX, and the bitcoins are sent to Y. For the next timestamp, the coins in Y can be re-used.

Of course, somebody can steal the coins if he knows your hash XXX. You should thus transfer the coins back to your walled immediatly, and publish XXX only after they are save.

Cheers Eph

[1] http://brainwallet.org/

Hey Ephrim,

Thanks for contacting me!

Yes, I am aware of the problems caused by destroying coins (its even mentioned on the homepage along with some reasoning for why I chose that anyway, under "Doesn't it destroy the Bitcoins used to pay to that address?"), and there's also the issue of Bitcoin 0.8.2 not relaying transactions with small outputs (also mentioned on the website, under "Update:").

I am planning on replacing this method with another one, but I got caught up with another Bitcoin-related project I'm working on and haven't had much time to work on that. Its also a bit problematic because the alternative methods aren't as straight-forward - with the current one, it just requires generating an address and paying to it. Alternative methods requires multiple transactions, and are harder for the average user to use, so I'm trying to think of a convenient way to do that.

There's another method that I'm planning to use, which would make stealing coins impossible - you can generate an 2-of-2 multisig address, with one of the keys being a regular key, and the second one based on the hash being timestamped (BTW, you don't need an pseudo-RNG, you can just use the hash itself as the private key). That way, the hash would still be included in the block, but it'll require an extra key to transfer the funds back.

As I said, its a bit more complex than the current implementation - the user would have two import two private keys to his wallet, create the multisig address, pay to it, than transfer the coins back. And even the simpler method that you suggested would require importing a new private key and broadcasting two transactions.

I do hope to find some time for that when I release the current project I'm working on, but it might take awhile until I get around to that.

Cheers, Nadav

I'll leave this issue open to track the progress of this.

[ghost]

FYI I opened a ticket in his tracker yesterday :) also... :)

[ghost]

I would like to comment on the issue of "stealing coins". It's false. You create the hash(data) and get a public and private keypair. At the time of sending money to the hash, you do not reveal the data so there is no way for someone to get the funds. In fact, you dont have to redeem the money until you do reveal the data. But in practice you should redeem the money immediately (after 1 confirm) so you don't forget about it/lose the key. And this is something an online wallet could do automatically actually.

[shesek]

At the time of sending money to the hash, you do not reveal the data so there is no way for someone to get the funds.

This is true for cases where the data is private at the time of transaction, but there are cases where its not. For example, when timestamping a contract that two parties signed or when the data was shared with someone prior to timestamping it.

I do agree that in the common case the data would be private, but it isn't necessarily so.

[maciej-trebacz]

Hi,

It is possible to create an output with data only, which doesn't destroy Bitcoins. Please investigate this feature added recently to Bitcoin: https://github.com/bitcoin/bitcoin/pull/2738

[ghost]

@M4v3R but isn't that prunable data? How would you prove it once pruned from the blockchain?

[maciej-trebacz]

It is, but not all clients prune the data, only reference clients. You can still find the output data on most online blockchain databases like BTCLook, Blockchain.info or Blockexplorer. The advantage is that these don't bloat the network, while achieving the same goal.

[ghost]

I suppose that is an option because eventually wholly spent outputs also get pruned if I am not mistaken (correct me if I am wrong).

[ghost]

Also would the TxOut be clearly visible in block explorers/wallet software like Qt?

[maciej-trebacz]

Reference client probably won't show them, though I'm not sure about that. It could be easily added by any developer though.

When you spend an output, it gets removed from the UTXO (unspent tx outputs) database, which is the most important thing every Bitcoin client keeps and what we don't want to be bloated. The above OP_RETURN outputs doesn't get added to this database in the first place. I'm not sure about pruning the spent outputs from the blocks/transactions database. It probably depends on your "txindex" setting in bitcoin.conf.

[ghost]

@M4v3R Seems to make verification a lot more obscure than having the bitcoin address be derived from the hash of the data (via private key). But it's still an interesting option.

So it seems like we have 3 ways now to embed data that do not destroy any bitcoin. Pretty interesting.