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

Censorship of OP_RETURN Transactions #3

Closed
ChristopherA opened this issue Jun 30, 2017 · 2 comments
Closed

Censorship of OP_RETURN Transactions #3

ChristopherA opened this issue Jun 30, 2017 · 2 comments
Assignees

Comments

@ChristopherA
Copy link
Member

It has been raised by @petertodd and others that using an op_return to encode the pointer to the DDO could hurt censorship resistance, as minors could identify those transactions that are DID related and not include them.

Instead, they recommend encoding it into the script of a P2SH transaction as some form of pay-to-contract. However, I still don't have a proposal from @petertodd on the best way to do this (he wants a similar capability to prevent censorship of open timestamps transactions). Another concern about the pay-to-contract approach is that it may mean two transactions to do a DDO update. An advantage is that it may support P2SH multisig DDOs.

For the first prototypes of the DID:BTCR method, I suggest we stick to P2PKH and P2WPKH transactions and we can support more censorship resistant methods later.

@petertodd
Copy link

@apoelstra Submitted a pull-req to python-opentimestamps for pay-to-contract-hash that I'll be implementing sometime in august: opentimestamps/python-opentimestamps#14

For now I'd just stick with op-return, but assume something else will be added in the future. You can easily disambiguate this stuff by pre-committing to which method will be used in the same way you commit to the txout to be spent.

@kimdhamilton
Copy link
Collaborator

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

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

No branches or pull requests

3 participants