Robert Spigler [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-08-23 to 2021-04-20
💬 Posted a total of 11 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-08 00:51:19

- reply

📅 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>

2023-06-08 00:51:09

- reply

📅 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>

2023-06-07 20:31:15

- reply

2023-06-07 20:30:51

- reply

📅 Original date posted:2021-03-15
📝 Original message:I agree with Matt.
The naked pubkey is required for some of the benefits being implemented (snicker coinjoins).
Even with pubkey hashes, bitcoin could still be stolen because the pubkey is published on spend. Regardless, QC needs to be fixed later on (decades), and shouldn't be a reason to NACK taproot.
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 15, 2021 6:05 PM, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been many threads on this before, I'm not sure anything new has been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
>
> > I do not personally see this as a reason to NACK Taproot, but it has become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware of
> > it and can make their own judgements.
>
> Note that this is most definitelynot news to this list, eg, Anthony brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse corpse.
>
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause" while a
> > full quantum-safe fix is developed, and then resume transacting. With Taproot
> > as-is, it could very well become an unrecoverable situation if QC go online
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause" can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > Also, what I didn't know myself until today, is that we do not actually gain
> > anything from this: the features proposed to make use of the raw keys being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at worst, it
> > would create an incentive for more people to use their own full node, which
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is materially reduced by avoiding the hash indirection.
>
> > Despite this, I still don't think it's a reason to NACK Taproot: it should be
> > fairly trivial to add a hash on top in an additional softfork and fix this.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at least nine years and still haven't solved it.
> Worse, there's a lot of old coins that are unlikely to move any time soon that are exposed whether we like it or not.
>
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've seen
> > far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of supply rather quickly (presumably over the course
> of a few days, at maximum), instead of a slow process with significant upfront real-world cost in the form of electricity.
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:30:46

- reply

📅 Original date posted:2021-03-18
📝 Original message:(IMO), where this proposal really excels, is mutlisig. And if you check my commits, it actually originally was for multisig only, and I extended it for multisig and single sig wallets.
ghost43 and Jochen Hoenicke brought up important issues with this proposed BIP re: single sig wallets, so I will be reverting this back for multisig derivations. I believe that should cover all concerns.
Please view the updated BIP here: https://github.com/Rspigler/bips-1/blob/Sane_Mulitisg_deriv/Modern%20Hierarchy%20for%20Deterministic%20Multisignature%20Wallets.mediawiki
And the updated PR here: https://github.com/Rspigler/bips-1/pull/1
Thank you,
Robert
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, March 18, 2021 4:44 PM, Robert Spigler via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> I (Robert Spigler) will respond in a next post.
>
> Thanks for your comments!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210318/eb5bd6d3/attachment.html>

2023-06-07 20:30:45

- reply

📅 Original date posted:2021-03-18
📝 Original message:Please keep comments in the ML. That way it can be archived, seen be anyone interested in the proposal, and have as much review and improvements as necessary/possible. The ML isn't taproot activation discussion only :)
For summary:
David Harding commented to Craig's post:
[Replying off list as I'm not sure this is an important point and the
list is already noisy these days.]
On Wed, Mar 17, 2021 at 09:26:50AM +0200, Craig Raw via bitcoin-dev wrote:
> I think it's important to note that [not encoding the script type in
> the derivation path] shifts more burden of wallet backup onto the
> user, who now has an additional item (the output descriptor) to backup
> correctly.
I don't think that's correct. Most wallets today that allow you to
restore with just a seed by deriving the keys for that seed in the BIP32
paths the wallet supports (i.e, including the purpose field) and then
scanning for outputs paying addresses derived from those keys.
If you try entering your seed into a different wallet (or one that's not
maintaining backwards compatibility with earlier versions of itself), it
won't necessarily support the same addresses you used earlier and so may
not work even if it fully supports BIP44 in principle. You'll need to
use different software and may need to tell that software the addresses
and paths your previous software used.
Under this proposed standard, I don't think any of that changes. If you
try to restore a seed into the same wallet that created it, it can scan
for the address types it supports. A different or
backwards-incompatible wallet may not work and you may need to find
software that can handle your old address type and specific path
information, which descriptors (and miniscript) makes easier.
The way I see it, there's not really a change to the information the
user needs to record for the normal case (seed phrase + name of software
used) or the unusual case (seed phrase + address types + paths).
Where I think this new proposal excels is in handling multisigs, where
the user needs to record the other signers' keys anyway. In those
cases, the fairly small overhead of descriptors compared to a minimalist
encoding is worth descriptor's benefits of providing an error detection
code and BIP32 fingerprints/paths that allow key location.
> 2. Use a standard set of derivation paths that encode the script type,
> ensuring that even if users do not back this up, they can check against a
> handful of common derivations and recover the funds.
I think the scanning work in this case is the same whether you use
descriptors or not.
- Under the current BIP44-style paths, a wallet that supports P2PKH and
P2WPKH with a single account and a gap limit of 50 needs to scan:
pkh([deadbeef/44'/0'/0'/0/0])
pkh([deadbeef/44'/0'/0'/0/1])
pkh([deadbeef/44'/0'/0'/0/...])
pkh([deadbeef/44'/0'/0'/0/49])
wpkh([deadbeef/84'/0'/0'/0/0])
wpkh([deadbeef/84'/0'/0'/0/1])
wpkh([deadbeef/84'/0'/0'/0/...])
wpkh([deadbeef/84'/0'/0'/0/49])
- Under the proposed standard, a wallet that suports P2PKH and P2WPKH
with a single account and a gap limit of 50 needs to scan:
pkh([deadbeef/XY'/0'/0'/0/0])
pkh([deadbeef/XY'/0'/0'/0/1])
pkh([deadbeef/XY'/0'/0'/0/...])
pkh([deadbeef/XY'/0'/0'/0/49])
wpkh([deadbeef/XY'/0'/0'/0/0])
wpkh([deadbeef/XY'/0'/0'/0/1])
wpkh([deadbeef/XY'/0'/0'/0/...])
wpkh([deadbeef/XY'/0'/0'/0/49])
It's essentially the same amount of work in either case. (It's
technically less work under the new standard as you only need to derive
the set of keys once---but since the actual scanning process typically
takes many orders of magnitude longer than key derivation, this doesn't
matter.)
There is a one-time cost of transaction, where wallets that previously
supported BIP44-style purposes and switch to the new proposal need to
scan both sets of paths. That can be avoided if the new paths are only
implemented for new address types (e.g. wallet previously supported
P2PKH with 44', P2WPKH with 84', but now the wallet adds P2TR support
with XY').
-Dave
***********
To which ghost43 replied:
Hi Dave,
>> 2. Use a standard set of derivation paths that encode the script type,
>> ensuring that even if users do not back this up, they can check against a
>> handful of common derivations and recover the funds.
>
> I think the scanning work in this case is the same whether you use
> descriptors or not.
>
> - Under the current BIP44-style paths, a wallet that supports P2PKH and
> P2WPKH with a single account and a gap limit of 50 needs to scan:
>
> pkh([deadbeef/44'/0'/0'/0/0])
> pkh([deadbeef/44'/0'/0'/0/...])
> pkh([deadbeef/44'/0'/0'/0/49])
>
> wpkh([deadbeef/84'/0'/0'/0/0])
> wpkh([deadbeef/84'/0'/0'/0/...])
> wpkh([deadbeef/84'/0'/0'/0/49])
>
> - Under the proposed standard, a wallet that suports P2PKH and P2WPKH
> with a single account and a gap limit of 50 needs to scan:
>
> pkh([deadbeef/XY'/0'/0'/0/0])
> pkh([deadbeef/XY'/0'/0'/0/1])
> pkh([deadbeef/XY'/0'/0'/0/...])
> pkh([deadbeef/XY'/0'/0'/0/49])
>
> wpkh([deadbeef/XY'/0'/0'/0/0])
> wpkh([deadbeef/XY'/0'/0'/0/1])
> wpkh([deadbeef/XY'/0'/0'/0/...])
> wpkh([deadbeef/XY'/0'/0'/0/49])
That is not how I understand the BIP draft. I think the text specifically
mentions avoiding key reuse between different scripts (by increasing the
account index); unlike your example list which reuses keys between pkh and
wpkh.
From the draft BIP's text [0]:
> 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. This prevents key reuse - across single signature and
> multisignature wallets, across ECDSA and Schnorr signatures, and inbetween
> the same wallet types.
It is good not to reuse keys. However this raises a new issue, which is what
I was alluding to in my previous email: when restoring from seed the wallet
will have to try all scripts for all account indices. Continuing your example,
it could be that account 0 is pkh and account 1 is wpkh or it could be the
other way around. Or the user might have created two wpkh accounts -- after all,
BIP44 allows that, and this new BIP is trying to be even more generic so why not?
> It's essentially the same amount of work in either case.
No, it is more work; and it will be even more in the future as new script types
come. It is the same amount of work only in the best case if the user backed up
descriptors; it is a lot more if they did not.
ghost43
*****************
David replied back:
On Wed, Mar 17, 2021 at 11:29:26PM +0000, SomberNight wrote:
> That is not how I understand the BIP draft. I think the text specifically
> mentions avoiding key reuse between different scripts (by increasing the
> account index); unlike your example list which reuses keys between pkh and
> wpkh.
There's no actual reuse there. Let's say the Foo Wallet v1 used P2PKH
and v2 defaulted to P2WPKH (but still allowed spending from P2PKH).
User Alice started with v1, so Foo Wallet gave her addresses,
pkh([a11ce000/XY'/0'/0'/0/0])
pkh([a11ce000/XY'/0'/0'/0/1])
pkh([a11ce000/XY'/0'/0'/0/...])
When she upgraded to v2, it gave her the following new addresses (note
the antepenultimate path level (the account level) is incremented):
wpkh([a11ce000/XY'/0'/1'/0/0])
wpkh([a11ce000/XY'/0'/1'/0/1])
wpkh([a11ce000/XY'/0'/1'/0/...])
Now we consider Bob who started with the v2 version of the wallet that
defaulted to P2WPKH. His addresses are:
wpkh([b0bb10c5/XY'/0'/0'/0/0])
wpkh([b0bb10c5/XY'/0'/0'/0/1])
wpkh([b0bb10c5/XY'/0'/0'/0/...])
This means that, when Alice restores from backup, the wallet looks
through the zeroeth account to see if it finds any P2PKH outputs; when it
does, it also checks the first account to see if there are any P2WPKH
outputs. When Bob restores from backup, it scans for P2PKH, doesn't find
any, scans fro P2WPH and finds them.
> It is good not to reuse keys. However this raises a new issue, which is what
> I was alluding to in my previous email: when restoring from seed the wallet
> will have to try all scripts for all account indices. Continuing your example,
> it could be that account 0 is pkh and account 1 is wpkh or it could be the
> other way around. Or the user might have created two wpkh accounts -- after all,
> BIP44 allows that, and this new BIP is trying to be even more generic so why not?
So to make sure I understand your corncern, following the example abole
there is an edge case there where Alice creates a v1 wallet, hands out
a P2PKH address that doesn't get used, and then upgrades to v2 and
starts using P2WPKH addresses. Is that your concern?
I agree, that's a problem. I'll have to think about that (and maybe Robert
already has).
-Dave
******************
ghost43 clarifies concerns:
Consider Carol, who creates 5 pkh accounts, then creates 1 wpkh account, then 1 wpkh-sh account, then 2 more wpkh (9 accounts overall).
If Carol is using BIP44/49/84, she will then have used:
- BIP44 account indices 0-4 inclusive,
- BIP49 account index 0,
- BIP84 account indices 0-2
If using new BIP XY, she will then have used:
- BIPXY account indices 0-4 for p2pkh
- BIPXY account index 5 for p2wpkh
- BIPXY account index 6 for p2wpkh-p2sh
- BIPXY account indices 7-8 for p2wpkh
The issue is that when restoring, with BIPXY, the wallet software will have to try all script types for all account indices: if it does not find an account, it might stop there, and miss all subsequent accounts too.
If using BIP44/49/84, when restoring, the wallet will scan:
- for p2pkh, BIP44, indices 0-5, stopping at 5 as it has not been used: scanned 5 accounts worth of addresses (+1 extra address for account idx 5)
- for p2wpkh-p2sh, BIP49, indices 0 and 1, stopping at 1 as it has not been used: scanned 1 account worth of addresses (+1 extra address for account idx 1)
- for p2wpkh, BIP84, indices 0-3, stopping at idx 3 as it has not been used: scanned 3 accoutns worth of addresses (+1 extra address for account idx 3)
All together the wallet needs to scan ~9 accounts worth of addresses which matches the 9 accounts the user actually created.
If using new BIP XY, when restoring, the wallet will scan:
- address index 0, hmmm wonder what script type the user might have used here, let's try p2wpkh as that is the cool thing today... --- ends up trying all script types (in worst case) until it finds p2pkh
- address index 1, hmmm surely the user used the new script type by then? tries all script types in worst case again
- ...
All together the wallet might end up scanning 9 * n (maybe three for now; but what about p2pk; or p2tr?) accounts worth of addresses.
ghost43
***********
ghost43 clarifies further:
> If using new BIP XY, she will then have used:
> - BIPXY account indices 0-4 for p2pkh
> - BIPXY account index 5 for p2wpkh
> - BIPXY account index 6 for p2wpkh-p2sh
> - BIPXY account indices 7-8 for p2wpkh
> The issue is that when restoring, with BIPXY, the wallet software will have to try all script types for all account indices: if it does not find an account, it might stop there, and miss all subsequent accounts too.
In fact note that if an older wallet does not support p2wpkh; only p2pkh and p2wpkh-p2sh, it only find accounts 0-4, and miss account 6.
This is a regression compared to BIP44/49.
**********
David Replies:
On Thu, Mar 18, 2021 at 12:22:48AM +0000, SomberNight wrote:
> > If using new BIP XY, she will then have used:
> > - BIPXY account indices 0-4 for p2pkh
> > - BIPXY account index 5 for p2wpkh
> > - BIPXY account index 6 for p2wpkh-p2sh
> > - BIPXY account indices 7-8 for p2wpkh
>
> > The issue is that when restoring, with BIPXY, the wallet software will have to try all script types for all account indices: if it does not find an account, it might stop there, and miss all subsequent accounts too.
>
> In fact note that if an older wallet does not support p2wpkh; only p2pkh and p2wpkh-p2sh, it only find accounts 0-4, and miss account 6.
> This is a regression compared to BIP44/49.
Agreed. The risk that older wallet software will reuse keys because it's
unaware of what a newer version of itself is doing negates my whole
premise of being able to use seeds without explicit descriptors.
Thank you for your insight and for arguing with me!
-Dave
*******
Craig response:
Great explanation SomberNight.
A pity now this isn't on-list, would like to share it in future!
Craig
*********
I (Robert Spigler) will respond in a next post.
Thanks for your comments!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210318/4d7ef947/attachment-0001.html>

2023-06-07 20:30:44

- reply

📅 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>

2023-06-07 20:30:44

- reply

📅 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

2023-06-07 20:26:37

- reply

📅 Original date posted:2020-08-23
📝 Original message:Hello All,
In the past, discussions around how to securely store/use/setup PSBT's have been decided as out of scope for BIP 174 - "it is not a specification of how hardware wallets should behave, it is a description of a data structure and the abstract workflow around it"
For example, Nicolas Dorier had many concerns around a year ago during the global xpub field discussions, and Electrum Wallet devs and Sjors Provoost have had various discussions on how to coordinate multisig wallets and represent cosigners securely (1. what do cosigners need: xfp, derivation prefix, xpub, script type; 2. needs to be forward thinking: work with Musig, Lightning, Taproot, Native Descriptor Wallets, etc; 3. how do we authenticate across devices, ensure PSBT's haven't been changed en route, defend against change attacks, etc - Bob McElrath had some interesting ideas on these).
Jonathan Underwood's PSBT_GLOBAL_XPUB_SIGNATURE addition to BIP174 helps with some of these, but it is not a finalized BIP yet, and while the global xpub field is, it is not pulled into Core yet.
What do people think of the idea of expanding or creating a new, more descriptive BIP on how to securely use PSBT's?
IMO, especially since Core has been merging more PR's on the work around offline/multisig use, this has become more important.
Last time I discussed this, Glenn Willen and Luke Dashjr thought this was a good idea, with Luke offering a Bitcoin Wiki page for the short term, but that was a few months ago and I thought I would open this idea to the general community.
-Robert Spigler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200823/41254548/attachment.html>