You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
From @ChristopherA on June 30, 2017 6:51
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.
Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#3
The text was updated successfully, but these errors were encountered: