keybase / keybase-issues

A single repo for managing publicly recognized issues with the keybase client, installer, and website.
902 stars 37 forks source link

Use OP_RETURN to store merkle root in bitcoin blockchain #1104

Open walling opened 10 years ago

walling commented 10 years ago

Instead of sending to a bitcoin address, which adds to the set of unspent outputs (UXTO), you should use OP_RETURN. More info: https://en.bitcoin.it/wiki/Script#Provably_Unspendable.2FPrunable_Outputs

Many bitcoin clients index the UXTO set and if used to store data in an automatic way, the set increases faster. A better way is to use OP_RETURN and let those transactions be pruned from the set. The OP_RETURN can be followed by arbitrary data and you can store the merkle root. It is the same principles the Proof of Existence site is using.

chris-belcher commented 8 years ago

Some more information for why keybase should be modified to use OP_RETURN.

The UTXO set must be held by every bitcoin node, it is used to validate every transaction. Bloating the UTXO set by creating unspendable transaction outputs like keybase does can be seen as an abuse of the commons, akin to air pollution. Every bitcoin node has to store these small outputs forever.

Bloating the UTXO set means it will become harder than it should be to run a bitcoin node. Keybase could work for 5 or 10 years but if not enough of a variety of people run bitcoin nodes the network will stop being decentralized and all the trustlessness that keybase relies on will be gone.

OP_RETURN is not difficult to use, an example transaction is here https://blockchain.info/tx/58c378ff4fd2445faff4eda85105e1dd39cd2476dec055030c9b206ca5a671df?show_adv=true Keybase would just load all the transactions to some address e.g. 1HUCBSJeHnkhzrVKVjaVmWg2QtZS1mdfaz and parse their OP_RETURN output to get the merkle tree root. Many in the bitcoin community and IRC channel would likely be willing to advise you how to do this because we don't want the bitcoin commons to be abused.

bitcoinfees commented 8 years ago

Discovered this post while searching for the reason why Keybase isn't using OP_RETURN; just chiming in to voice my agreement.

Also, I noticed that the transaction uses a output of 547 satoshis. This is the dust limit, assuming a minrelaytxfee of 1000 sats/kB - the previous default Bitcoin Core setting.

The default has recently changed, however, to 5000 sats/kB, which gives a new dust limit of 547*5. Many nodes have been increasing their minrelaytxfee, due to higher transaction volumes on the network. Keybase may find, therefore, that it becomes harder for their transactions to get timely confirmations.

With OP_RETURN, you won't run into this dust problem.