Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UTXO and Blockchain Bloat #17

Open
kimdhamilton opened this issue Jul 15, 2017 · 3 comments
Open

UTXO and Blockchain Bloat #17

kimdhamilton opened this issue Jul 15, 2017 · 3 comments
Assignees
Labels

Comments

@kimdhamilton
Copy link
Contributor

From @ChristopherA on June 30, 2017 6:57

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.

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#4

@kimdhamilton
Copy link
Contributor Author

From @ChristopherA on July 8, 2017 3:23

As @sipa said in WebOfTrustInfo/btcr-hackathon-2017#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?

@kimdhamilton
Copy link
Contributor Author

From @rxgrant on July 10, 2017 10:11

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.

@kimdhamilton
Copy link
Contributor Author

From @petertodd on July 12, 2017 21:30

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants