Nostr notes by

📅 Original date posted:2021-04-10 📝 Original message:Hi ...

2023-06-08T00:51:19+02:00

In reply to nevent1q…qwd3
_________________________

📅 Original date posted:2021-04-10
📝 Original message:Hi Sjors,

Thanks for your comments.

>Chicken-egg problem

I agree with Hugo's detailed response here.

>Losing multisig setup context (in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.)

Devices need to persist the descriptor, if they currently can't, they don't comply with this standard and they can't be used securely for multisig. There's no reasons the master seed and descriptor both can't be backed up outside of each device. I can't see a scenario where it would be possible to recover only the seed. (I don't know yet how Core will decide how to best backup this info, seeing as BIP39 was rejected).

>BIP48

I agree with Hugo that BIP48 is redundant with descriptors, please see https://github.com/bitcoin/bips/pull/1089 for a proposed updated hierarchy for multisignature wallets.

>An encryption convention for the descriptor data

I understand this concern. Like you mentioned previously, I too often set up multisignature wallets for clients where they are actually owned by the single party. A concern is that while the backup location owners cannot spend (due to the M-of-N restriction), they can view the wallet balance/history. As Hugo mentioned, you can apply any encryption you want after the setup, so a solution may be to use Shamir Secret Sharing (Blockchain Commons has done a lot of work on that here: https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/37#discussioncomment-287993)

>Plain text vs binary

I too favor plain text

Robert Spigler
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, April 9, 2021 11:33 AM, Sjors Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Thanks for the detailed response. Just 1 thing I needed to clarify:
>
>>> To the list of concerns at the top of the BIP, I would add one: losing multisig setup context. E.g. in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.
>>
>> Good point.
>>
>>> If you still have all devices and know (or guess) the threshold then BIP48 and sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 1 device then without the metadata your coins are lost. In a future with musig(?) and miniscript increasingly the setup data is just as critical as the seeds.
>>
>> How so? Each signer device should ideally have a copy of the multisig configuration. If you lose 1 device in a 2-of-3, you can still spend from the wallet? Unless I'm missing something here.
>
> I was thinking about a scenario where all devices are destroyed. All you have left are the mnemonics. But indeed if at least one of your devices is still intact AND it has the configuration, you're also good.
>
> But there are plenty of devices out there that can't do this. Those devices can still be useful, even if they can't fully check everything.
>
> Sjors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210410/83ab6a0b/attachment.html>;

📅 Original date posted:2021-04-12 📝 Original message:I ...

2023-06-07T20:31:19+02:00

In reply to nevent1q…qlhn
_________________________

📅 Original date posted:2021-04-12
📝 Original message: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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210412/bf6756eb/attachment-0001.html>;

📅 Original date posted:2021-04-10 📝 Original message:Hi ...

2023-06-07T20:31:15+02:00

In reply to nevent1q…7p27
_________________________

📅 Original date posted:2021-04-10
📝 Original message:Hi Sjors,

Thanks for your comments.

>Chicken-egg problem

I agree with Hugo's detailed response here.

>Losing multisig setup context (in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.)

Devices need to persist the descriptor, if they currently can't, they don't comply with this standard and they can't be used securely for multisig. There's no reasons the master seed and descriptor both can't be backed up outside of each device. I can't see a scenario where it would be possible to recover only the seed. (I don't know yet how Core will decide how to best backup this info, seeing as BIP39 was rejected).

>BIP48

I agree with Hugo that BIP48 is redundant with descriptors, please see https://github.com/bitcoin/bips/pull/1089 for a proposed updated hierarchy for multisignature wallets.

>An encryption convention for the descriptor data

I understand this concern. Like you mentioned previously, I too often set up multisignature wallets for clients where they are actually owned by the single party. A concern is that while the backup location owners cannot spend (due to the M-of-N restriction), they can view the wallet balance/history. As Hugo mentioned, you can apply any encryption you want after the setup, so a solution may be to use Shamir Secret Sharing (Blockchain Commons has done a lot of work on that here: https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/37#discussioncomment-287993)

>Plain text vs binary

I too favor plain text

Robert Spigler
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, April 9, 2021 11:33 AM, Sjors Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Thanks for the detailed response. Just 1 thing I needed to clarify:
>
>>> To the list of concerns at the top of the BIP, I would add one: losing multisig setup context. E.g. in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.
>>
>> Good point.
>>
>>> If you still have all devices and know (or guess) the threshold then BIP48 and sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 1 device then without the metadata your coins are lost. In a future with musig(?) and miniscript increasingly the setup data is just as critical as the seeds.
>>
>> How so? Each signer device should ideally have a copy of the multisig configuration. If you lose 1 device in a 2-of-3, you can still spend from the wallet? Unless I'm missing something here.
>
> I was thinking about a scenario where all devices are destroyed. All you have left are the mnemonics. But indeed if at least one of your devices is still intact AND it has the configuration, you're also good.
>
> But there are plenty of devices out there that can't do this. Those devices can still be useful, even if they can't fully check everything.
>
> Sjors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210410/83ab6a0b/attachment.html>;

📅 Original date posted:2021-04-04 📝 Original ...

2023-06-07T20:31:08+02:00

In reply to nevent1q…k8rc
_________________________

📅 Original date posted:2021-04-04
📝 Original message:I'd like to pre-register a comment that I don't think signet should be a consideration for MTP vs height, since taproot is already activated on signet, and there's no indication that ST will be used in the future (we should continue our search for the ideal activation method)

Robert Spigler

Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, April 4, 2021 5:31 AM, Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> So the only thing that seemed clear, using height as per bip8, it's not clear anymore.
> And, as usual, we're not talking about activation in general but about taproot activation, segwit activation...
>
> I won't make it to the meeting because I don't think I have much more to contribute that I haven't said already beyond perhaps: sigh.
> My arguments will probably ignored again, so it doesn't matter.
>
> On Sun, Apr 4, 2021, 06:39 Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> We'll be having another meeting this Tuesday, as per https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html. If you can't make it feel free to leave a comment on any agenda item below, or if you think there are other things to be discussed.
>>
>> Agenda:
>>
>> 1. AJ's update to MTP time.
>>
>> Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated it substantially.
>>
>> The PR is now purely MTP based, and the state machine has been simplified. This approach is intended to be compatible with a mandatory signaling period (via a LAST_CHANCE change) and makes it easier to deploy ST on signets (irrelevant for Taproot, because it is already active on all signets).
>>
>> 2. Selecting between MTP and Height
>>
>> In the previous meeting, there was no substantial publicly discussed benefit to using MTPs over height. Since agenda item 1, there is now a tangible benefit to using MTP.
>>
>> The changes AJ promulgated for MTP neutralizes the argument, mostly, that MTP was easier to review. As such, the main conversation in this agenda item is around the pros/cons of height or MTP and determining if we can reach consensus on either approach.
>>
>> 3. Timeline Discussion
>> In all hope, we will reach consensus around item 2. Should that occur, we can use this time to discuss a final selection on parameters, mindful of Core's process.
>>
>> If the meeting doesn't reach rough consensus around item 2, it seems that we may fall short on the proposed schedule from last time. In this section, we can discuss realities around scheduling.
>>
>> Best,
>>
>> Jeremy
>>
>> --
>> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
>> _______________________________________________
>> 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/20210404/ae136571/attachment.html>;

📅 Original date posted:2021-03-14 📝 Original message:No, ...

2023-06-07T20:30:44+02:00

In reply to nevent1q…unpq
_________________________

📅 Original date posted:2021-03-14
📝 Original message:No, wallets don't and shouldn't have to check all script types on recovery. Descriptor Wallets solve all of this.

To back up a multisignature wallet, each cosigner stores their xprv (how you do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor. This is done, for example, in Yeti. To recover, simply combine `M` private keys, and check the script designated in 1 of the descriptor copies.

For single signature wallets, it is the same, except only one signature is needed. Store xprv and descriptor.

It is not fair nor accurate to say that currently, in order to recover, wallets need "just the seed words". They also need all public keys, and derivation paths.

Descriptors (and this BIP), is a much cleaner way to handle wallet creation and backup, by separating the two layers (keys and scripts) and getting rid of redundant information.

Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 11:13 AM, SomberNight <somber.night at protonmail.com> wrote:

> See some replies inline. (quoted text from BIP draft)
>
> > Date: Sun, 14 Mar 2021 01:51:15 +0000
> > From: Robert Spigler RobertSpigler at protonmail.ch
> > Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for Deterministic Wallets.
>
> > There are many issues with the current standards. As background, BIP 44/49/84 specifies:
> > `m / purpose' / coin_type' / account' / change / address_index`
> > where the BIP43 `purpose'` path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script derivations are made redundant with descriptors
>
> > We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script or signature type
>
> You say that keys and scripts should not be mixed in the same layer, and imply that this was solely done due to these standards predating output script descriptors. Even if this was the case, it is not the only reason for doing it. BIP44/49/84 mixing scripts and keys in the same layer makes recovery from seed/mnemonic much easier.
> Note the significant overlap between the authors of BIP39 and BIP44. I am fairly certain BIP44 was designed with recovering from a BIP39 seed (and no additional information backed up) in mind. Note the "Account discovery" section of BIP44.
> (Electrum seeds go even further, as such seeds contain a version number that encodes both the script type and the key derivation path to use.)
>
> > We define the following 5 levels in the BIP32 path:
> > `m / purpose' / coin_type' / account' / change / address_index`
>
> > [Account]
> > It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
> > For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the `account'` level. Before creating it's own single signature wallet, the `account'` level must again be incremented.
>
> Imagine a user who has a BIP39 (or similar) seed. Even today, recovering most non-singlesig scripts from that is obviously infeasible. However, all singlesig scripts at least can be discovered if the keys are using the suggested derivation paths.
> By trying to create a standard that mixes discoverable and non-discoverable scripts in the same derivation scheme and incrementing a single index, you are turning all scripts into being non-discoverable.
> Note that even if a user only used singlesig scripts and followed this proposal, during recovery from seed the wallet would have to check all script types for all account indices (which is only ever going to get more expensive as new script types come).
> The workaround and I imagine your suggested solution is clearly to backup both seed words and output script descriptors; and to keep appending new output script descriptors to existing backups when the account index is incremented. While much less user-friendly than backing up just a seed, it is more generic and extendable.
>
> My point is simply that your proposal is making a tradeoff here. The tradeoff itself seems easy to miss on first read of the text, so I just wanted to explicitly point it out for the record.
>
> ghost43 / SomberNight

📅 Original date posted:2021-03-13 📝 Original message:Hello, ...

2023-06-07T20:30:44+02:00

In reply to nevent1q…59fj
_________________________

📅 Original date posted:2021-03-13
📝 Original message:Hello,

I am working on a draft BIP for a signature and script independent hierarchy for deterministic wallets.

I believe with the implementation of descriptor wallets, the typical use case of of a BIP43 `purpose’` level per script type is redundant. The differentiation of separate BIPs for multisignature derivation paths, with BIP45 and “BIP” 48, is also redundant – with path levels such as `cosigner_index` and `script_type`. Descriptors can set the order of the public keys with `multi` or have them sorted lexicographically with `sortedmulti`.

I don’t believe we should be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys.

The BIP defines the following 5 levels in the BIP32 path:

m / purpose' / coin_type' / account' / change / address_index

It is crucial that the `account’` level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes. For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the `account’` level. Before creating it's own single signature wallet, the `account’` level must again be incremented. This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, and inbetween the same wallet types.

For full details, please see the BIP here: https://github.com/Rspigler/bips-1/blob/Sane_Mulitisg_deriv/Modern%20Derivation%20Standard.mediawiki

Please see the PR here: https://github.com/Rspigler/bips-1/pull/1

Looking forward to comments.

Thank you,

Robert Spigler

Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210314/1cdda930/attachment.html>;