Nostr notes by

📅 Original date posted:2016-08-16 📝 Original message:Hello ...

2023-06-07T19:52:48+02:00

In reply to nevent1q…w0nl
_________________________

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

📅 Original date posted:2016-05-14 📝 Original message:Am ...

2023-06-07T19:50:42+02:00

In reply to nevent1q…h9sj
_________________________

📅 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

📅 Original date posted:2016-04-20 📝 Original message:Hello ...

2023-06-07T19:50:09+02:00

In reply to nevent1q…6u9a
_________________________

📅 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