fidelity.link — reputation by proof of burn

For some time, people have talked about burning bitcoin as a way to build a decentralized reputation system. These “fidelity bonds” are used to make it costly to create an identity, by associating your public key to a transaction sacrificing bitcoins (it prevents Sybil attacks). OpenBazaar, Datt, and JoinMarket are examples of decentralized services that could benefit from a fidelity bond system. Proof of burn has also been used to launch new blockchains, issuing a proportional amount of coins in the alternative chain. The best references I could find to using bitcoin for a fidelity bond system are an article by Peter Todd on fidelity bonds and Jeff Garzik’s identity protocol.

Burning for Reputation

The main issue with creating a fidelity bond is making sure that those bitcoins were actually burned or received by somebody else. I don’t like the idea of burning bitcoins forever (because of dangling unspent transaction outputs); so sacrificing them to the miners is better.

But if any transaction that pays everything to the miner is called a fidelity bond, miners can craft a transaction spending everything as miner fees, never broadcast it, and only include it in blocks it finds. Miners would be getting free (no sacrifice) fidelity bonds whenever they find a block.

To sort around this, we can use OP_CHECKLOCKTIMEVERIFY (a.k.a. OP_HODL) which was included recently into the bitcoin protocol. Fidelity bonds is one of the main use cases for it. A fidelity bond would be a transaction with an output that can only be spent after a number of blocks (so actually, OP_CSV would be a better candidate for this). With this time separation between the fidelity bond transaction and the spending of it, not even a miner can fake a fidelity bond.

I imagine that miners run some kind of analysis on transactions to see if they can trivially modify them to pay to themselves if the transaction is not protected by some sort of private key signature. Fidelity bonds would fall in this category.

So, a simple schema for provable sacrifices can be rolled out with standard transactions, by crafting one with the following characteristics:

• It has (at least) one input and two outputs.
• The first input that is a pay to public key hash scriptSig will have the signing public key associated with the fidelity bond.
• A pay to script hash output with a redeemScript that looks like this:
  <magic string> <block height> OP_CLTV OP_DROP
  The block height must be at least 2015 blocks in the future from the block the transaction is included in (~2 weeks of blocks). The OP_DROP leaves just one element in the stack.
• A zero satoshi output with an OP_RETURN revealing the redeemScript (the preimage of the P2SH address). This is a workaround needed because the redeemScript is not a standard transaction (but pay to script hash rules for standardness are more relaxed).

Now, everybody will be able to spend from this transaction as soon as <block height> is reached. Pushing a magic string makes the transaction easy to detect for miners redeeming sacrifice outputs. I sent my first fidelity bond of this kind yesterday, and it got included in the blockchain. It has a value of 193371 satoshis. It will be redeemable after 2025 blocks (I sent the transaction with some margin above 2015).

Tools for Fidelity Bonds

Last weekend I coded fidelity.link: a webpage with some tools to check how many satoshis were sacrificed in a transaction following the schema described above. It also allows you to create a fidelity bond by sending bitcoins to an address for a private key generated on your browser. I picked https://fidelity.link/, ascii encoded, as a way to get more visibility for the protocol.

I also have a machine set up to relay a transaction giving me back my money by block 401158 (running a development version of RelayStore), but anybody could steal those bits, specially the miner who finds that block. Hopefully, somebody steals them from me (that would mean people are scanning for bond transactions).

Future Work

This small protocol needs more development: maybe public directories of signed messages acknowledging a good reputation or denouncing misbehavior of identities associated with a bond, or a web of trust, more tools (like the RelayStore, a service that stores transactions covered with nLockTime and broadcasts them when they are final) and more protocols on top of this (maybe for the 21 environment?).

Also, burning may not be the best way to set up trust. This is intended to be used as a general purpose bond, with no counterparty. But you could have one fidelity bond per service, encoding your trust in a system or company at the same time you spend money on the bond. I think a small revolution in decentralized online reputation could start around this idea.

So feel free to check fidelity.link out, and please let me know of any ideas you have around it!

Thanks to Dario Sneidermanis, Patricio Palladino, Manu Araoz, Ryan X. Charles, and Dan Elitzer for reading draft versions and their contributions.