<unnamed>

Public Key

npub1tue9u2scw5pe77vn4fz0464zz0387gm0zwy2zjhqg2yap36zhj2s4dca6f

Profile Code

nprofile1qqs97vj79gv82qul0xf65386a23p8cnlydh38z9pftsy9zwscapte9gpzpmhxue69uhkummnw3ezuamfdejs9sukvt

Publishing to

nostr.wine

Last Notes

2023-06-07 18:30:45 UTC

- reply

📅 Original date posted:2021-03-18
📝 Original message:Hello Robert,
you wrote:
> 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.
No a BIP39/BIP44 wallet can recover all BIP44 accounts using just the seed
words. Read the section account recovery closely to see how it's done. No
public keys or derivation paths needed, as the derivation path can just be
enumerated and for single signature wallets you don't need external public
keys. Similarly a BIP39/BIP44/BIP49/BIP84 can recover all these accounts
using just the seed words and for example the Trezor Suite does this. Most
hardware wallets currently rely on this feature, as they don't store any
additional information like output descriptors (which would be possible,
but would make regular backups necessary). Of course, autodiscover doesn't
work for multisig wallets, unless you would store some output descriptor in
an OP_RETURN on the blockchain.
It's okay to make a new standard that requires regular backups, but you
should at least keep in mind that this complicates some use cases.
Jochen
On Tue, 16 Mar 2021 at 13:19, Robert Spigler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
>
>
> _______________________________________________
> 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/20210318/78c59965/attachment.html>

2023-06-07 17:53:04 UTC

- reply

📅 Original date posted:2016-08-24
📝 Original message:On 24.08.2016 16:18, Jonas Schnelli via bitcoin-dev wrote:
>
> Another thing that I think could be a BIP misdesign:
>
> BIP44 Gap Limits
> From the BIP:
>
> ----------
> "Address gap limit is currently set to 20. If the software hits 20
> unused addresses in a row, it expects there are no used addresses beyond
> this point and stops searching the address chain."
> ----------
>
> * Does that mean, we do a transaction rescan back to the genesis block
> for every 20 addresses?
As I understand it, you can scan sequentially starting with the genesis
block (or with a block at around the time when BIP44 was written). Then
if you find a new transaction, which requires to generate new addresses,
you generate them and scan further from that point on. This way you can
scan in a single pass if the scanning process calls you back when it
finds a transaction and allows you to change the set of addresses on the
fly.
Jochen

2023-06-07 17:52:48 UTC

- reply

📅 Original date posted:2016-08-16
📝 Original message:Hello Jonas,
thanks for your efforts of writing the draft for the standard.
First, this only describes detached signing. A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware. Do you plan to have this in a separate
standard or should this also be included here? Basically one needs one
operation: get xpub for an HD path.
From a first read over the specification I found the following points
missing, that a fully checking hardware wallet needs to know:
- the amount spent by each input (necessary for segwit).
- the full serialized input transactions (without witness informations)
to prove that the amount really matches (this is not necessary for segwit)
- the position of the change output and its HD Path (to verify that it
really is a change output).
- For multisig change addresses, there are more extensive checks
necessary: All inputs must be multisig addresses signed with public
keys derived from the same set of xpubs as the change address and use
the same "m of n" scheme. So for multisig inputs and multisig change
address the standard should allow to give the parent xpubs of the other
public keys and their derivation paths.
It is also a bit ambiguous what the "inputscript" is especially for p2sh
transactions. Is this always the scriptPubKey of the transaction output
that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
there are three scripts
witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig: <0 <32-byte-hash>>
(0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
(0xA914{20-byte-hash}87)
(quoted from BIP-141).
In principle one could put witness and scriptSig (with "OP_FALSE" in
places of the signatures) in the raw transaction and make inputscript
always the scriptPubKey of the corresponding output. Then one also
doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
nested in bip16 p2sh" transactions.
Regards,
Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/37adb191/attachment.sig>

2023-06-07 17:50:42 UTC

- reply

📅 Original date posted:2016-05-14
📝 Original message:Am 14.05.2016 um 10:16 schrieb Jonas Schnelli via bitcoin-dev:
>
> Importing a bip32 wallet (bip44 or not) is still an expert job IMO.
> Also importing can lead to bad security practice (especially without a
> sweep).
One important use case is importing xpubs for watch-only accounts. This
is necessary for hardware wallets and there are other valid use cases
for this.
>
> Users will send around xpriv or import an seed over a compromised
> computer to a cold storage, etc.
>
> I don't think users want to import private keys.
> They probably want to import the transaction history and send all funds
> covered by that seed to a new wallet.
>
Yes, in general it is not a good idea to import private keys and many
wallets don't even have an option to give out the xprv (except
indirectly via the backup mechanism). But even when sweeping a
bip-44+segwit wallet you need to know where the segwit addresses are.
Jochen

2023-06-07 17:50:09 UTC

- reply

📅 Original date posted:2016-04-20
📝 Original message:Hello Bitcoin Developers,
I would like to make a proposal to update BIP-32 in a small way.
TL;DR: BIP-32 is hard to use right (due to its requirement to skip
addresses). This proposal suggests a modification such that the
difficulty can be encapsulated in the library.
#MOTIVATION:
The current BIP-32 specifies that if for some node in the hierarchy
the computed hash I_L is larger or equal to the prime or 0, then the
node is invalid and should be skipped in the BIP-32 tree. This has
several unfortunate consequences:
- All callers of CKDpriv or CKDpub have to check for errors and handle
them appropriately. This shifts the burden to the application
developer instead of being able to handle it in the BIP-32 library.
- It is not clear what to do if an intermediate node is
missing. E.g. for the default wallet layout, if m/i_H/0 is missing
should m/i_H/1 be used for external chain and m/i_H/2 for internal
chain? This would make the wallet handling much more difficult.
- It gets even worse with standards like BIP-44. If m/44' is missing
should we use m/45' instead? If m/44'/0' is missing should we use
m/44'/1' instead, using the same addresses as for testnet?
One could also restart with a different seed in this case, but this
wouldn't work if one later wants to support another BIP-43 proposal
and still keep the same wallet.
I think the first point alone is reason enough to change this. I am
not aware of a BIP-32 application that handles errors like this
correctly in all cases. It is also very hard to test, since it is
infeasible to brute-force a BIP-32 key and a path where the node does
not exists.
This problem can be avoided by repeating the hashing with slightly
different input data until a valid private key is found. This would
be in the same spirit as RFC-6979. This way, the library will always
return a valid node for all paths. Of course, in the case where the
node is valid according to the current standard the behavior should be
unchanged.
I think the backward compatibility issues are minimal. The chance
that this affects anyone is less than 10^-30. Even if it happens, it
would only create some additional addresses (that are not seen if the
user downgrades). The main reason for suggesting a change is that we
want a similar method for different curves where a collision is much
more likely.
#QUESTIONS:
What is the procedure to update the BIP? Is it still possible to
change the existing BIP-32 even though it is marked as final? Or
should I make a new BIP for this that obsoletes BIP-32?
What algorithm is preferred? (bike-shedding) My suggestion:
---
Change the last step of the private -> private derivation functions to:
. In case parse(I_L) >= n or k_i = 0, the procedure is repeated
at step 2 with
I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i))
---
I think this suggestion is simple to implement (a bit harder to unit
test) and the string to hash with HMAC-SHA512 always has the same
length. I use I_R, since I_L is obviously not very random if I_L >= n.
There is a minimal chance that it will lead to an infinite loop if I_R
is the same in two consecutive iterations, but that has only a chance
of 1 in 2^512 (if the algorithm is used for different curves that make
I_L >= n more likely, the chance is still less than 1 in 2^256). In
theory, this loop can be avoided by incrementing i in every iteration,
but this would make an implementation error in the "hard to test" path
of the program more likely.
The other derivation functions should be updated in a similar matter.
Also the derivation of the root node from the seed should be updated
in a similar matter to avoid invalid seeds.
If you followed until here, thanks for reading this long posting.
Jochen