Re: How to verify the did:key document is authorized by the private key holder ... JWS?

On Thu, Mar 18, 2021 at 8:01 PM Wayne Chang <wyc@fastmail.fm> wrote:

> There is a privacy disadvantage for this in did-doge though...you are
> effectively outing your doge address as DID-capable if you do decide to
> create on-chain updates, but the privacy is better than did-btcr if you
> decide to not to update the DID document. did-btcr, while requiring an
> initiation transaction, is better for privacy in the sense that its update
> transactions can be created so they're though to distinguish from normal
> btc transactions, which could be hidden enough in the herd privacy of the
> bitcoin blockchain, but possibly still vulnerable to statistical discovery
> attacks.
>

I'm hoping with the next version of BTCR that we can keep the privacy
without fully exposing on-chain data. For instance, we really should
support P2WPSH (pay to witness public script hash) which doesn't reveal the
public key on chain.

Each of these new approaches could replace the current BTCR 0.1 legacy-only
transaction based approach with a more modern UTXO-focused approach. The
solution space include kind of sign-to-contract commitment scheme (
https://www.reddit.com/r/Bitcoin/comments/d3lffo/technical_paytocontract_and_signtocontract/)
maybe along with some delegation tricks (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018615.html)
for key rotation, or BIP322 proof-of-control of a UTXO (
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki), or
possibly a single-use-seals (
https://github.com/rgb-org/spec/blob/develop/01-OpenSeals.md) for did
document state changes.

There are some challenges in choosing between these for the future of BTCR.
For instance, BIP322 means you have to implement an entire bitcoin script
engine. Another challenge is we are all moving toward taproot, which means
Schnorr signatures, which will make many things easier, but is unlikely to
be deployed in less than 18 month.

-- Christopher Allen