{"type":"rich","version":"1.0","author_name":"npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058y","author_url":"https://nostr.ae/npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058y","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-12\n📝 Original message:Hard no to this idea:\n\nOn Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:\n...\n\u003e /48'/0'/0'/3'/PBKDF(complex string)'\n\nAs someone who has helped people find UTXO at key paths they didn't\nknow/want, this is a terrible idea. Key derivation paths should be\nsmall, sequential integers, so they can be searched in reasonable time.\n\nOf course when things are working it doesn't matter, but the stakes\ncan be very high when they stop working.\n\nThis is true for multisig and single signer.\n\n---\nPeter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10\n\nOn Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen wrote:\n\u003e I think the key issue here is avoiding xpub key reuse in multisig. Not only\n\u003e 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 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. With\n\u003e the addition of the addition of the Policy Map creators optional note, it\n\u003e 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\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210212/cce516d7/attachment-0001.sig\u003e"}