Closed ChristopherA closed 4 years ago
tennis left loud despair fit expire air fade myth whisper abuse divorce
fall desk enemy major public walk tree garment discover shift iron hip
best bubble jewel great skirt spend warfare donate zebra human erosion purity
[fe23bc9a/48h/1h/0h/2h]tpubDEzBBGMH87CU5rCdo7gSaByN6SVvJW7c4WDkMuC6mKS8bcqpaVD3FCoiAEefcGhC4TwRCtACZnmnTZbPUk4cbx6dsLnHG8CyG8jz2Gr6j2z
[e120e47b/48h/1h/0h/2h]tpubDEvTHKHDhi8rQyogJNsnoNsbF8hMefbAzXFCT8CuJiZtxeZM7vUHcH65qpsp7teB2hJPQMKpLV9QcEJkNy3fvnvR6zckoN1E3fFywzfmcBA
[f0578536/48h/1h/0h/2h]tpubDE5GYE61m5mx2WrgtFe1kSAeAHT5Npoy5C2TpQTQGLTQkRkmsWMoA5PSP5XAkt4DBLgKY386iyGDjJKT5fVrRgShJ5CSEdd66UUc4icA8rw
Key_123&wsh(sortedmulti(2,[fe23bc9a/48h/1h/0h/2h]tpubDEzBBGMH87CU5rCdo7gSaByN6SVvJW7c4WDkMuC6mKS8bcqpaVD3FCoiAEefcGhC4TwRCtACZnmnTZbPUk4cbx6dsLnHG8CyG8jz2Gr6j2z,[e120e47b/48h/1h/0h/2h]tpubDEvTHKHDhi8rQyogJNsnoNsbF8hMefbAzXFCT8CuJiZtxeZM7vUHcH65qpsp7teB2hJPQMKpLV9QcEJkNy3fvnvR6zckoN1E3fFywzfmcBA,[f0578536/48h/1h/0h/2h]tpubDE5GYE61m5mx2WrgtFe1kSAeAHT5Npoy5C2TpQTQGLTQkRkmsWMoA5PSP5XAkt4DBLgKY386iyGDjJKT5fVrRgShJ5CSEdd66UUc4icA8rw))
Using proprietary fields we specify "wallet fingerprint" and derivation path in a single field per scope
We remove all unnecessary fields and keep only signatures.
cHNidP8BAKcCAAAAAmtf+aCJOAZFLjqssQE/KTqu5zFXyv0kXnq7d1UnVUT+AAAAAAD/////hfIx+psgPuEl8lxVLepxcyRzk3IUFx8Veij/7faI23EAAAAAAP////8CQA0DAAAAAAAXqRT+NhaqwDNNeHZhDsae0yoC4s1JVYecSgAAAAAAACIAINKANkka2RBh3JEdPhUb7o7llU4gvIL3q4KR6KuTVgRvAAAAAAAiAgPExwk5ZZXRFmLJ4U4KvGNAONt7GWveEVZkav+u6JaCsUgwRQIhAJN9QwEJomhYkOFmJLCZJys06fl+1xv9r9o22aELhC2/AiBy9p/tVCxaQLVpYKSZxDDPHzMQIeVgnsWKUWSM2xljsQEAIgICLq8QU+I/jFu7VgWC4th3VRUB41rdTpsOn4GX32wawdRIMEUCIQDquLm5LtR4fWIhQ/aI2miY1OCGigQ6iF+r70h6BMD54QIgTXP0LSVFo0QwgSVbTNeYQZDyJhAAKyrGP+C9sJXyzgcBAAAA
Thanks. We'll puzzle through the differences between our approach and your approach and get back to you!
-- Christopher Allen
Ok, there was a comment that disappeared... 48h derivation path is something weird... It is not standartized, but commonly used by Electrum wallet, Trezor, Ledger and ColdCard. 48h/0h/0h/2h is used for native segwit, /1h for nested segwit. I don't like this derivation though... But it is adopted in the industry.
Is this documented anywhere? I've never seen a 48' path before.
I found a mention of 48' path on this useful site https://walletsrecovery.org but I'm surprised I never heard of it before. Best I found elsewhere in https://wiki.trezor.io/Standard_derivation_paths is that Copay did this first, but the only comment in the Copay wallet description (https://github.com/bitpay/copay#wallet-export-format) was:
Since version 1.5, Copay uses the root m/48' for hardware multisignature wallets. This was coordinated with Ledger and Trezor teams. While the derivation path format is still similar to BIP44, the root was in order to indicate that these wallets are not discoverable by scanning addresses for funds. Address generation for multisignature wallets requires the other copayers extended public keys.
My best guess that the the idea here is that by using 48' for multisig paths, you'll never need to check a single signature balance from that key, and you'l never reuse a derived key both for a single-signature wallet and a multisig wallet. Is that your best guess too?
Not quite how I'd do it (I had a weird idea about using a hash of the wallet descriptor without your key in it so the derivation would be a different for each key holder and never conflict with another derivation) but I guess it is easier and works.
What do you use to test compatibility against for 48' multisigs?
-- Christopher Allen
What do you use to test compatibility against for 48' multisigs?
I didn't quite understand the question... I use Specter in multisig with ColdCard, Ledger and Trezor... I also checked that Electrum is generating the same addresses as my setup if I load seeds there.
My best guess that the the idea here is that by using 48' for multisig paths, you'll never need to check a single signature balance from that key, and you'l never reuse a derived key both for a single-signature wallet and a multisig wallet. Is that your best guess too?
I think so. Second index is for coin type, third can be used as a multisig "account" index (like an id of multisig setup you use, makes sense to bump if you are involved in many multisig setups), last one is for address type. As "account" number is not the last one you don't share it with your cosigners (child index in shareble xpub shows script type, not account number), so some privacy is also preserved.
Second index is for coin type, third can be used as a multisig "account" index (like an id of multisig setup you use, makes sense to bump if you are involved in many multisig setups), last one is for address type. As "account" number is not the last one you don't share it with your cosigners (child index in shareble xpub shows script type, not account number), so some privacy is also preserved.
I'd love to get this properly documented and shared someplace. Either as a SLIP or BIP. I'd also be glad to host it in the Blockchain Commons along with QR standards, etc. in the meantime.
It is a small document but increasingly important.
-- Christopher Allen
@stepansnigirev Apologies I deleted my comment as I think I had made some false assumptions. I will just get Specter up and running and then ask questions ;)
Currently my only question is why the "wallet import QR" from above does not seem to be HD? Meaning it has no range and if I import it into my node that wallet will only be able to derive one multi-sig address?
@ChristopherA would be nice to have such place. Blockchain Commons looks like a good fit :)
@Fonta1n3 because it's not quite a bitcoin core descriptor. If we would use pure bitcoin core descriptors I would need to duplicate it twice for internal /1/ and receiving /0/ addresses. So we decided to use a single one without derivation paths and derive addresses from all xpubs with /0/ for receiving and /1/ for change. It's not a very elegant solution, but reduces the size of the QR code by the factor of 2. Suggestions are very welcome :)
Ok, there was a comment that disappeared... 48h derivation path is something weird... It is not standartized, but commonly used by Electrum wallet, Trezor, Ledger and ColdCard. 48h/0h/0h/2h is used for native segwit, /1h for nested segwit. I don't like this derivation though... But it is adopted in the industry.
Just to make sure I am understanding the standard here: m/48h/1h/0h/2h/1/0 represents a testnet bech32 change address? m/48h/0h/0h/2h/0/0 represents a mainnet bech32 primary address?
@ChristopherA would be nice to have such place. Blockchain Commons looks like a good fit :)
@Fonta1n3 because it's not quite a bitcoin core descriptor. If we would use pure bitcoin core descriptors I would need to duplicate it twice for internal /1/ and receiving /0/ addresses. So we decided to use a single one without derivation paths and derive addresses from all xpubs with /0/ for receiving and /1/ for change. It's not a very elegant solution, but reduces the size of the QR code by the factor of 2. Suggestions are very welcome :)
Ok so I can go ahead and convert it HD on my end, understood.
yes, from what I saw in Electrum I also didn't find any proper documentation on the topic, so it's my guess based on the assumption that Electrum does it properly :)
I've started taking some notes about m/48', with the goal of creating some BIP quality specification documentation about this.
Currently it is in HackMD:
https://hackmd.io/@ChristopherA/B1jW4ghOU
I'll connect this to a Blockchain Commons github repo soon.
I think this ultimately should be a BIP or at least a SLIP, but if you've got any good names for what these interim wallet related specification documents should be called, let me know?? WIP for both Wallet Improvement Proposal and also jokingly Work in Progress?
-- Christopher Allen
@stepansnigirev @ChristopherA
Woohoo, I got it working, amazing.
Next FN2 update will allow you to:
Very cool!
I’ve searched out a bit and it seems like there was supposed to be a BIP48
about that, but it was never proposed. The only mention I found of it (besides in Bitpay codebase) was here: https://github.com/bitcoin/bips/pull/436#issuecomment-245744956
Seems like @matiu from Copay (which were indeed the ones to first use m/48
) was working on such BIP48
a few years ago. I'm wondering what happened to that BIP eventually...
@ChristopherA I think it would make a lot of sense to make that into a BIP, I'm just wondering if there is an existing version of such BIP hiding somewhere (as it is discussed as a BIP for example in Bitpay code), or if it was never actually written.
@stepansnigirev
If I wanted to pass Specter a PSBT to sign what format does it accept?
If I wanted to pass Specter a PSBT to sign what format does it accept?
Base64 encoded psbt should work for both. Specter-Desktop scans the QR code and sends it to Bitcoin Core with the initial one to combine and finalize. Specter-DIY understands standard PSBT and signs whatever it can, the only restriction is that we don't allow mixed inputs - you can't have inputs from multisig and single-sig wallets in the same transaction, and Specter-DIY should have the wallet imported for currently selected network in order to check the change address (we need cosigner's xpubs to check change)
You can drop here your qr code and recovery phrase and I can try signing it :)
@ChristopherA
AFAIK m/45h
is still used for legacy multisig (BIP-45), but this bip is missing many features we have in standard bips 44, 49 and 84 - no coin type, no account number.
But nobody uses legacy transactions anymore, right? =)
I summon @justinmoon here for multisig-48h-derivation discussion! Justin, you should know something about that as well.
If I wanted to pass Specter a PSBT to sign what format does it accept?
Base64 encoded psbt should work for both. Specter-Desktop scans the QR code and sends it to Bitcoin Core with the initial one to combine and finalize. Specter-DIY understands standard PSBT and signs whatever it can, the only restriction is that we don't allow mixed inputs - you can't have inputs from multisig and single-sig wallets in the same transaction, and Specter-DIY should have the wallet imported for currently selected network in order to check the change address (we need cosigner's xpubs to check change)
You can drop here your qr code and recovery phrase and I can try signing it :)
This is created from the QR's you sent all in this thread and was signed with key 2 (fall desk...), it includes all the data so is not small...
:)
meh... that's a big one... I failed to scan it both with Specter and with my phone. That's exactly the reason I remove all data except partial signatures from the QR code.
meh... that's a big one... I failed to scan it both with Specter and with my phone. That's exactly the reason I remove all data except partial signatures from the QR code.
Will have to take that approach for exporting, good idea. If you want to paste it here is the text:
cHNidP8BAIkCAAAAAYXyMfqbID7hJfJcVS3qcXMkc5NyFBcfFXoo/+32iNtxAAAAAAD9////AmYrAAAAAAAAIgAgns5gPRjFvRXAwTtF6biQyUVgnGckx8V8LQ0IFwph7zbJ+AAAAAAAACIAICOQBlQCio1gu9yzwjCkMcgNls1Hbs4lxdD4TTTORq3OAAAAAAABASv4JAEAAAAAACIAIFa5x7zWLtecrqXrrkE8c5bQaIEAqYkwhJVWkOnrf/cVIgIDeoaLzd5m9WFqwioRb4djzbENrZLD8+4S3FuqvGX1F7pHMEQCIFViQFhcF0RNcPIBFSP7RLuRR8j5qQo7sYGaa62ga0ZVAiBX53KEfKJNemwX14I+riq8udA657a1n7GrLkgWdZetDwEBBWlSIQIiJctmsrXzdJ+OtzogNIKbcz9wzXjjrQ5KHd22mUDcmSECLq8QU+I/jFu7VgWC4th3VRUB41rdTpsOn4GX32wawdQhA3qGi83eZvVhasIqEW+HY82xDa2Sw/PuEtxbqrxl9Re6U64iBgIiJctmsrXzdJ+OtzogNIKbcz9wzXjjrQ5KHd22mUDcmRzwV4U2MAAAgAEAAIAAAACAAgAAgAAAAAACAAAAIgYCLq8QU+I/jFu7VgWC4th3VRUB41rdTpsOn4GX32wawdQc/iO8mjAAAIABAACAAAAAgAIAAIAAAAAAAgAAACIGA3qGi83eZvVhasIqEW+HY82xDa2Sw/PuEtxbqrxl9Re6HOEg5HswAACAAQAAgAAAAIACAACAAAAAAAIAAAAAAQFpUiEDGwHoHjaYhrIq5TboA9dEGoFZDmNGR3hX7oQ1HEya4+chA8e5XyKmetuKuUA+6+9ZqYyRem0bxZ168i09DlfJ+jOtIQPl5+Bj/X4XvaAIxoOyD1sKrZvgs/jtuVzWSzD6S0TYrVOuIgIDGwHoHjaYhrIq5TboA9dEGoFZDmNGR3hX7oQ1HEya4+cc/iO8mjAAAIABAACAAAAAgAIAAIAAAAAABQAAACICA8e5XyKmetuKuUA+6+9ZqYyRem0bxZ168i09DlfJ+jOtHPBXhTYwAACAAQAAgAAAAIACAACAAAAAAAUAAAAiAgPl5+Bj/X4XvaAIxoOyD1sKrZvgs/jtuVzWSzD6S0TYrRzhIOR7MAAAgAEAAIAAAACAAgAAgAAAAAAFAAAAAAEBaVIhAhrY+PHzNn+l9rid/84O9H9kqz5AlJTyTqgcz1PXkEhyIQPAtVuBn+R4n5x1zKj/Ku7VKk5RXuFEsnbYiBtQUswPwCED9USfwqK/fvpRANmSMa1FvwDQG72cu965QBjHc8j+3VtTriICAhrY+PHzNn+l9rid/84O9H9kqz5AlJTyTqgcz1PXkEhyHP4jvJowAACAAQAAgAAAAIACAACAAQAAAAUAAAAiAgPAtVuBn+R4n5x1zKj/Ku7VKk5RXuFEsnbYiBtQUswPwBzwV4U2MAAAgAEAAIAAAACAAgAAgAEAAAAFAAAAIgID9USfwqK/fvpRANmSMa1FvwDQG72cu965QBjHc8j+3Vsc4SDkezAAAIABAACAAAAAgAIAAIABAAAABQAAAAA=
Is this issue still relevant? I'm lacking the skills to judge that. It changed topic a bit from the test-vector to the documentation. I'm not skilled enough to judge here.
Is this issue still relevant? I'm lacking the skills to judge that. It changed topic a bit from the test-vector to the documentation. I'm not skilled enough to judge here.
I don’t think so! We got the wallet export/import working great.
Can we get some Testnet vectors for a 2 of three multisig PSBT with one signature that your use in a QR and provide us with the bip39 for the second signature, so that we can test FullyNoded2 against it?
Thanks!
cc/ @fonta1n3
— Christopher Allen