I don't quite understand your NACK.
The following are measures you say we should take as best practices, which I
believe are all implemented:
>A) We should accept that users must to backup their multisig account maps
>(descriptor with only xpubs) along with their cosigner key material to be able
>to recover funds.
BSMS requires that the descriptor persist in storage and be able to be
displayed when requested by the user. It is already industry standard that the
same apply to cosigner key material. Backing up both is good practice. (My BIP
for a new key hierarchy enforces this as well
(https://github.com/bitcoin/bips/pull/1089))
>B) Cosigner wallets and transaction coordinator services should not share the
>master xpub
Again, check out my updated hierarchy for multisignature wallets, which
enforces this and works very well with BSMS.
>C) In many current wallets, the master xpub fingerprint is required
I am confused by this - the descriptor language standardizes the master xpub
fingerprint in the key origin information?
>E) Transaction coordinators should send the cosigner "policy"
There is no cosigner "policy" in this standard, but the same checks are
implemented (N unique key records, key is included in descriptor, plus valid
MAC, valid signatures, valid checksum, etc).
>F) Transaction coordinators should also send the final "account map" to all
>the cosigner wallets
This is done
Robert Spigler
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, April 12, 2021 2:45 PM, Christopher Allen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Though I am ACK on that we need to solve the problem of xpub privacy and
> reuse, I'm NACK on this solution. It is currently too complex and doesn't
> really solve the problem.
>
> I believe that the ultimate solution will be some form of multi-round
> cryptographic commitment scheme, and as musig threshold signatures with
> Taproot/Schnoor also require multi-round scheme, we should start thinking now
> about how maybe we can leverage that work to address this problem as well.
> However, I'm not a cryptographer and don't have a specific solution in this
> area to offer.
>
> In the meantime, there are some possible measures we can take as new best
> practices. This is not a formal list, and I'm open to other suggestions, but
> each are currently relatively easy and are functional with some existing
> wallets that CAN support state. Let us get it right with stateful wallets,
> then we can return back to better best practices for stateless wallets like
> Trezor, Ledger, etc.
>
> A) We should accept that users must to backup their multisig account maps
> (descriptor with only xpubs) along with their cosigner key material to be
> able to recover funds. In the Airgap Community we make this very easy with a
> simple UR code that works efficiently as a QR. I personally keep multiple
> copies of this account map in multiple locations, as it is less of a risk
> (mostly privacy) if one of the locations is compromised.
>
> B) Cosigner wallets and transaction coordinator services should not share the
> master xpub, only the derived co-signer xpubs required for that specific
> account. Currently too many libraries, wallets and coordinators only function
> if they get the master xpub — these should be updated to not require them.
>
> C) In many current wallets, the master xpub fingerprint is required — that
> master fingerprint is also a privacy risk and should not be used. For
> instance, the current practice of offering what the Airgap Community calls a
> `crypto-hdkey` [604b93f2/48'/1'/0'/2'] with the master fingerprint root,
> could instead be to only offer a single parent fingerprint [f93749a7/2'] from
> that grandparent master key. Thus different fingerprints can be offered for
> each account, and only the signer knows the actual master fingerprint and its
> children.
>
> D) Given C, when creating a new multisig account, a transaction coordinator
> may request a specific master fingerprint and/or a fixed 48' derivation xpub
> from a cosigner wallet, but these are only hints. If it gets back a different
> fingerprint or derivation, it should accept it. In the case of the Airgap
> Community's specifications, in our "crypto-request" we actually specifically
> allow for wildcard requests which makes this easy and explicit. Yes, only
> stateful signers can know to return an xpub something other than the
> fingerprint and m/48'/1'/0'/2' default, but a transaction coordinator should
> accept it if it receives it.
>
> E) Transaction coordinators should send the cosigner "policy" (basically the
> multisign descriptor without any keys in it) along with any request to derive
> a new xpub for that new account. Stateful wallets can use this policy to know
> later if they are asked to sign a PSBT that does not match this policy.
>
> F) Transaction coordinators should also send the final "account map" to all
> the cosigner wallets as a best practice as well. This would replace the
> temporary "policy" in D. If a PSBT request to sign using a key doesn't match
> the original account map, the cosigner wallet can reject it.
>
> These best practices don't solve the problem with stateless wallets like
> Trezor, but they are possible now with the new generation of multisig
> hardware and software wallets, such as Foundation Devices, CoboVault,
> Sparrow, Bluwallet and my Gordian reference wallet tools. We have available
> NOW working interoperable specifications, reference code, and example apps
> that support these best practices, and some are already supported by multiple
> wallets in the Airgapped Wallet Community hosted by Blockchain Commons at
> https://github.com/blockchainCommons/airgapped-Wallet-Community.
>
> I've put a copy of this rough proposal in our Airgapped Wallet Community
> discussion area if you have suggestions or alternative best practices.
>
> [Initial proposal for best practice to avoid XPUB reuse in multisig account
> creation](https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/53)
>
> -- Christopher Allen, Blockchain Commons
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
