rich1.0npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeghttps://nostr.ae/npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqegnjumphttps://nostr.ae📅 Original date posted:2021-02-12 📝 Original message:On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > What Blockchain Commons (and the Airgapped Wallet Community) call a policy > map would be > > ``` > wsh(sortedmulti(1,,,)) > ``` > > A PBKDF of that as would be unique for all 2 of 3 segwig transactions. > With the addition of the addition of the Policy Map creators optional note, > it would be truly unique. The Policy Map and/or PBKDF are small and could > easily added to existing APIs. > > So for legacy hardware, we can use existing 48' subtree, but 3' as the > format for this form (2' is segwit), then the desktop can just ask for the > /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token. > More sophisticated Airgapped apps you can send > "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and > optionally allow it return something different in a full keyset (i.e. > "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting > app, knowing that it is different from the PBKDF can know what to do if it > needs to what to ask for in the future. > Thanks Christopher, very interesting ideas... A couple of thoughts: 1/ Generating the path index using the policy is clever. However, I think it has 2 problems. Number #1 is with the above scheme now you have a hard dependency on (policy map + note) - losing (policy map + note) means that you will lose access to PBKDF', and hence the funds permanently. At least with the current soluttions, you can look up what the most common derivation paths and indices are to recover funds in the worst case. 2/ Number #2 is that this wouldn't necessarily prevent XPUB reuse. It seems like the above scheme depends on (a) the Coordinator keeping track accurately of all the existing PBKDF-ed indices and (b) the Signer truthfully gives the XPUB at the path that the Coordinator asks for. In reality, neither of these conditions can be guaranteed. For example, the Signer could lie about the XPUB at /48'/0'/0'/3'/PBKDF' when it just keeps reusing the XPUB at /48'/0'/0'/2' 3/ Preventing XPUB reuse is an interesting problem, but IMHO it is beyond the scope of the current proposal. Maybe worth a separate BIP? Best, Hugo On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > I think the key issue here is avoiding xpub key reuse in multisig. Not > only in the future with Schnorr, but we need it today! > > Current common practice by hardware wallets is the 48'/0'/0'/2' derivation > for segwit multsig ( e.g. > [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b > ) is the only one used for ALL multisigs offered by that hardware wallet. > > As Pieter said, leveraging a HD path parameters can help, but we need a > better, less reusable path for the index. > > I personally suggest a simpler solution, which is to create an index using > a PBKDF of the Account Policy (a descriptor with all xpubs and keys > removed), plus optional notes. (BTW, I think double sha256 or HMAC is > overkill). > > Example: for the reference bit descriptor that might result in: > > ``` > > wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*)) > ``` > > What Blockchain Commons (and the Airgapped Wallet Community) call a policy > map would be > > ``` > wsh(sortedmulti(1,,,)) > ``` > > A PBKDF of that as would be unique for all 2 of 3 segwig transactions. > With the addition of the addition of the Policy Map creators optional note, > it would be truly unique. The Policy Map and/or PBKDF are small and could > easily added to existing APIs. > > So for legacy hardware, we can use existing 48' subtree, but 3' as the > format for this form (2' is segwit), then the desktop can just ask for the > /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token. > More sophisticated Airgapped apps you can send > "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and > optionally allow it return something different in a full keyset (i.e. > "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting > app, knowing that it is different from the PBKDF can know what to do if it > needs to what to ask for in the future. > > The other advantage of this technique is that the cosigner app can know > what policy it is participating in, before the descriptor is completed. It > may decide it doesn't want to participate in some funky 4:9 with a weird > script, and not return an xpub at all. > > Long term I think a commitment scheme should be used, so that you don't > reveal what xpub you offered until all the parties xpubs are shared, but as > Pieter said, we can do that at the same time we do the musig. But we need > to prevent xpub reuse NOW, and I think my proposal easy and could the job. > > -- Christopher Allen, Blockchain Commons > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210212/bfb1f588/attachment.html>