UTXO and Blockchain Bloat

[ChristopherA]

I know that @lukejr and others will complain that DIDs have the potential to bloat the blockchain and UTXO mempool, as each DID:BTCR will have to have at least one unspent output.

For know I propose that we acknowledge this objection and keep it on our issue list. We will recommend P2WPKH over P2PKH so that witness data and op_return data can easily by purged by nodes who do not wish to retain all the data. If at some point we can address the UTXO bloat issue (say with @petertodd pay-to-contract approach?) we will do so. In addition, we will be clear in our various materials that DID:BTCR is not intended to scale to all the world's citizens, but is instead is for self-soveright identities with high security and pseudo-anonymity requirements.

In the meantime, we are not the only ones using op_return, so in the spirit of "Perfection is the Enemy of the Good" we will support P2PKH and op_returns that point to DDOs.

[ChristopherA]

As @sipa said in #2 (comment)

Please don't abuse the UTXO set as key revocation storage :(

What I said in my reply to @sipa's comment was:

@sipa, @petertodd had some ideas about how we can minimize that in the future.
 I'm not sure it will go to zero, but much reduced. He hasn't published his technique
 yet but I presume it will also be similar to one he is working on for #opentimestamps
 For now we are trying to get a prototypes functioning, but your concern is valid and
 been noted for some time (it is issue #4 in this repo for instance :-) )

What we say in the main README.md is:

"Some aspects of the BTCR method will not be practical if inappropriately scaled — for
instance, there is a transaction cost to update keys and DDO object, potential UTXO
inflation (i.e. one additional unspent output for every BTCR-based identity), and even if
segwit isn't used it could cause blockchain bloat. However, identities using the BTCR
method can be a strong as Bitcoin itself -- currently securing billions of dollars of digital
value."

Can we improve on our message in the README.md and elswhere?

[rxgrant]

It's easy to imagine a sidechain that manages DID update access for many identities at the cost of a single Bitcoin UTXO, along with reliance on an external data store to retrieve the actual keys.

Part of our messaging could take the experimental nature of this blockchain integration into account.

[petertodd]

@rxgrant Remember that such a sidechain has a censorship risk; you'd at least want a backup method of revocation via publishing in another medium, such as Bitcoin itself.

[kimdhamilton]

This issue was moved to WebOfTrustInfo/rwot5-boston#17