📅 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>;
Hugo Nguyen [ARCHIVE] /
npub1jq…5jqeg
2023-06-07 20:28:35
in reply to nevent1q…c3xu
Author Public Key
npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqegPublished at
2023-06-07 20:28:35Event JSON
{
"id": "a18a30b6311ad2b2753f0fbd4fe958238225eedd6ec3277f0f763e19e407f7da",
"pubkey": "900d0aa57c9ef670488e2c0efb871d265d6926e13726d517e503044f1806ab78",
"created_at": 1686162515,
"kind": 1,
"tags": [
[
"e",
"86ad6c37ed92954d8359f9dbcd43bb8becf51e4b072d4e707f08909fe0306de5",
"",
"root"
],
[
"e",
"b3392e7fc629a890dd7cb12336f3091d62f92586d5705e8c98f0c528d23b74b0",
"",
"reply"
],
[
"p",
"2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d"
]
],
"content": "📅 Original date posted:2021-02-12\n📝 Original message:On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e What Blockchain Commons (and the Airgapped Wallet Community) call a policy\n\u003e map would be\n\u003e\n\u003e ```\n\u003e wsh(sortedmulti(1,,,))\n\u003e ```\n\u003e\n\u003e A PBKDF of that as would be unique for all 2 of 3 segwig transactions.\n\u003e With the addition of the addition of the Policy Map creators optional note,\n\u003e it would be truly unique. The Policy Map and/or PBKDF are small and could\n\u003e easily added to existing APIs.\n\u003e\n\u003e So for legacy hardware, we can use existing 48' subtree, but 3' as the\n\u003e format for this form (2' is segwit), then the desktop can just ask for the\n\u003e /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.\n\u003e More sophisticated Airgapped apps you can send\n\u003e \"wsh(sortedmulti(1,,,))\"+label and let the cosigner app do the PBKDF, and\n\u003e optionally allow it return something different in a full keyset (i.e.\n\u003e \"[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…\", and then the requesting\n\u003e app, knowing that it is different from the PBKDF can know what to do if it\n\u003e needs to what to ask for in the future.\n\u003e\n\nThanks Christopher, very interesting ideas... A couple of thoughts:\n1/ Generating the path index using the policy is clever. However, I think\nit has 2 problems. Number #1 is with the above scheme now you have a hard\ndependency on (policy map + note) - losing (policy map + note) means that\nyou will lose access to PBKDF', and hence the funds permanently. At least\nwith the current soluttions, you can look up what the most common\nderivation paths and indices are to recover funds in the worst case.\n2/ Number #2 is that this wouldn't necessarily prevent XPUB reuse. It seems\nlike the above scheme depends on (a) the Coordinator keeping track\naccurately of all the existing PBKDF-ed indices and (b) the Signer\ntruthfully gives the XPUB at the path that the Coordinator asks for. In\nreality, neither of these conditions can be guaranteed. For example, the\nSigner could lie about the XPUB at /48'/0'/0'/3'/PBKDF' when it just keeps\nreusing the XPUB at /48'/0'/0'/2'\n3/ Preventing XPUB reuse is an interesting problem, but IMHO it is beyond\nthe scope of the current proposal. Maybe worth a separate BIP?\n\nBest,\nHugo\n\n\n\nOn Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I think the key issue here is avoiding xpub key reuse in multisig. Not\n\u003e only in the future with Schnorr, but we need it today!\n\u003e\n\u003e Current common practice by hardware wallets is the 48'/0'/0'/2' derivation\n\u003e for segwit multsig ( e.g.\n\u003e [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b\n\u003e ) is the only one used for ALL multisigs offered by that hardware wallet.\n\u003e\n\u003e As Pieter said, leveraging a HD path parameters can help, but we need a\n\u003e better, less reusable path for the index.\n\u003e\n\u003e I personally suggest a simpler solution, which is to create an index using\n\u003e a PBKDF of the Account Policy (a descriptor with all xpubs and keys\n\u003e removed), plus optional notes. (BTW, I think double sha256 or HMAC is\n\u003e overkill).\n\u003e\n\u003e Example: for the reference bit descriptor that might result in:\n\u003e\n\u003e ```\n\u003e\n\u003e wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))\n\u003e ```\n\u003e\n\u003e What Blockchain Commons (and the Airgapped Wallet Community) call a policy\n\u003e map would be\n\u003e\n\u003e ```\n\u003e wsh(sortedmulti(1,,,))\n\u003e ```\n\u003e\n\u003e A PBKDF of that as would be unique for all 2 of 3 segwig transactions.\n\u003e With the addition of the addition of the Policy Map creators optional note,\n\u003e it would be truly unique. The Policy Map and/or PBKDF are small and could\n\u003e easily added to existing APIs.\n\u003e\n\u003e So for legacy hardware, we can use existing 48' subtree, but 3' as the\n\u003e format for this form (2' is segwit), then the desktop can just ask for the\n\u003e /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.\n\u003e More sophisticated Airgapped apps you can send\n\u003e \"wsh(sortedmulti(1,,,))\"+label and let the cosigner app do the PBKDF, and\n\u003e optionally allow it return something different in a full keyset (i.e.\n\u003e \"[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…\", and then the requesting\n\u003e app, knowing that it is different from the PBKDF can know what to do if it\n\u003e needs to what to ask for in the future.\n\u003e\n\u003e The other advantage of this technique is that the cosigner app can know\n\u003e what policy it is participating in, before the descriptor is completed. It\n\u003e may decide it doesn't want to participate in some funky 4:9 with a weird\n\u003e script, and not return an xpub at all.\n\u003e\n\u003e Long term I think a commitment scheme should be used, so that you don't\n\u003e reveal what xpub you offered until all the parties xpubs are shared, but as\n\u003e Pieter said, we can do that at the same time we do the musig. But we need\n\u003e to prevent xpub reuse NOW, and I think my proposal easy and could the job.\n\u003e\n\u003e -- Christopher Allen, Blockchain Commons\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210212/bfb1f588/attachment.html\u003e",
"sig": "7b54cccb1a1e1476ddebfdccd0d454dd9bf0077290156c2f542367a78aae9b016a0047a37984034eb81b51e5c0522af524cd2b2a6a6ad3b584fffe1f029c943f"
}