Jochen Hoenicke [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-09 13:00:34

- reply

📅 Original date posted:2020-07-15
📝 Original message:
On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Mr. Lee,
>
> > Sorry. Re-sending with correction to CC bitcoin-dev
> >
> > I am sorry if this was already brought up in previous threads. If I know
> > lightning network correctly then HTLC is used to enforce settlements on
> > blockchain if there is a dispute. Could a person lose money if their HTLC
> > does not get confirmed in the timeframe or if an older HTLC gets
> > confirmed first? I see different ways this could happen.
> >
> > One, if the blockchain is very saturated with other transactions. The
> > reason we need lightning network is why it might have troubles with
> > settlements?
>
> This could happen, but the entire exercise is to move transactions off the
> blockchain, precisely to lower this risk.
>
> Otherwise, transfers onchain will take a long time.
> In practice, a long time to settle a payment will invalidate many
> real-world economic exchanges anyway (consider paying for food at a
> restaurant --- if your payments take days to settle, the food has gotten
> stale before the restaurant receives payment and releases your food).
> Thus, if an onchain transfer takes a long time to settle, there is already
> risk of economic loss present.
>
> By moving activity offchain, we reduce pressure onchain and improve
> settlement speeds on both offchain and onchain, reducing risk of economic
> loss due to delay.
>
>
> > Two, competition from a different conflicting HTLC. A newer
> > HTLC might not get confirmed before an older HTL.
>
> I cannot make sense of this.
>
> You cannot create conflicting HTLCs.
>
Correct. Removing or Creating an HTLC is something that both channel
partners need to agree on. They may create multiple pending HTLCs as long
as there are enough funds, but creating conflicting HTLCs is not possible.
> >
> > I found out about a recent attack technique that sounds like it might be
> > similar called "flood and loot".
>
> Roughly, my understanding of Flood and Loot is to make a lot of
> uneconomically tiny HTLCs going through a target victim forwarding node.
> You make circular routes going from your own node back to yourself.
> Then you refuse to actually claim the HTLCs sent back to yourself.
>
No, the way I understand it is that an attacker, say Malleroy, routes a lot
of medium sized HTLC payments from his node to his node via a victim node,
say Alice's, and possibly other nodes.
Then Malleroy *accepts* the payments by publishing the hash on the
receiving end, so he gets all the sent funds on his receiving channel.
Malleroy's receiving node behaves completely honestly, and nobody can prove
that it belongs to the attacker.
Finally when Alice claims her HTLC by presenting the hash, Malleroy just
ignores the claim. Now Alice, the victim, is forced to close the channel
to prevent the HTLC to timeout. If Malleroy does it with multiple victims
at exactly the same time, they will all compete with each other. The
victims cannot increase the fee for the HTLC claiming transaction, because
they are the ones who force-closed the channel. CPFP doesn't work, because
their ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can
claim the still pending HTLCs using an RBF transaction.
So it is Alice who has to force close, which puts her at a big disadvantage.
Malleroy will have to pay the lightning fees, but they are negligible. The
fee for the on-chain force-close transaction (with the HTLC outputs) is
paid by whoever opened the channel. AFAIK the fee for the HTLC resolving
transactions is paid by whoever claims the HTLC. In this scenario it is
paid from Alice's money. If Malleroy opened the channel, he risks losing
some funds to on-chain fees. On the other hand the one who pays the fee
controls the fee. He could negotiate a very low fee (say a cent per HTLC),
when the network is idle and then wait for a natural congestion before
starting the attack, giving him a low risk with high success probability.
Every HTLC he can claim after timeout is profit.
Regards,
Jochen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200715/ed01a6cf/attachment.html>

2023-06-07 18:30:45

- 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 18:25:55

- reply

📅 Original date posted:2020-07-15
📝 Original message:On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Mr. Lee,
>
> > Sorry. Re-sending with correction to CC bitcoin-dev
> >
> > I am sorry if this was already brought up in previous threads. If I know
> > lightning network correctly then HTLC is used to enforce settlements on
> > blockchain if there is a dispute. Could a person lose money if their HTLC
> > does not get confirmed in the timeframe or if an older HTLC gets
> > confirmed first? I see different ways this could happen.
> >
> > One, if the blockchain is very saturated with other transactions. The
> > reason we need lightning network is why it might have troubles with
> > settlements?
>
> This could happen, but the entire exercise is to move transactions off the
> blockchain, precisely to lower this risk.
>
> Otherwise, transfers onchain will take a long time.
> In practice, a long time to settle a payment will invalidate many
> real-world economic exchanges anyway (consider paying for food at a
> restaurant --- if your payments take days to settle, the food has gotten
> stale before the restaurant receives payment and releases your food).
> Thus, if an onchain transfer takes a long time to settle, there is already
> risk of economic loss present.
>
> By moving activity offchain, we reduce pressure onchain and improve
> settlement speeds on both offchain and onchain, reducing risk of economic
> loss due to delay.
>
>
> > Two, competition from a different conflicting HTLC. A newer
> > HTLC might not get confirmed before an older HTL.
>
> I cannot make sense of this.
>
> You cannot create conflicting HTLCs.
>
Correct. Removing or Creating an HTLC is something that both channel
partners need to agree on. They may create multiple pending HTLCs as long
as there are enough funds, but creating conflicting HTLCs is not possible.
> >
> > I found out about a recent attack technique that sounds like it might be
> > similar called "flood and loot".
>
> Roughly, my understanding of Flood and Loot is to make a lot of
> uneconomically tiny HTLCs going through a target victim forwarding node.
> You make circular routes going from your own node back to yourself.
> Then you refuse to actually claim the HTLCs sent back to yourself.
>
No, the way I understand it is that an attacker, say Malleroy, routes a lot
of medium sized HTLC payments from his node to his node via a victim node,
say Alice's, and possibly other nodes.
Then Malleroy *accepts* the payments by publishing the hash on the
receiving end, so he gets all the sent funds on his receiving channel.
Malleroy's receiving node behaves completely honestly, and nobody can prove
that it belongs to the attacker.
Finally when Alice claims her HTLC by presenting the hash, Malleroy just
ignores the claim. Now Alice, the victim, is forced to close the channel
to prevent the HTLC to timeout. If Malleroy does it with multiple victims
at exactly the same time, they will all compete with each other. The
victims cannot increase the fee for the HTLC claiming transaction, because
they are the ones who force-closed the channel. CPFP doesn't work, because
their ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can
claim the still pending HTLCs using an RBF transaction.
So it is Alice who has to force close, which puts her at a big disadvantage.
Malleroy will have to pay the lightning fees, but they are negligible. The
fee for the on-chain force-close transaction (with the HTLC outputs) is
paid by whoever opened the channel. AFAIK the fee for the HTLC resolving
transactions is paid by whoever claims the HTLC. In this scenario it is
paid from Alice's money. If Malleroy opened the channel, he risks losing
some funds to on-chain fees. On the other hand the one who pays the fee
controls the fee. He could negotiate a very low fee (say a cent per HTLC),
when the network is idle and then wait for a natural congestion before
starting the attack, giving him a low risk with high success probability.
Every HTLC he can claim after timeout is profit.
Regards,
Jochen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200715/ed01a6cf/attachment.html>

2023-06-07 18:04:51

- reply

📅 Original date posted:2017-08-21
📝 Original message:On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote:
> To fix this I consulted with andytoshi and got something we think works
> for both cases:
>
> 1) When a signing device receives a partially signed transaction, all
> inputs must come with a ownership proof:
> - For the input at address A, a signature over H(A || x) using the key
> for A. 'x' is some private fixed key that only the signing device
> knows(most likely some privkey along some unique bip32 path).
> - For each input ownership proof, the HW wallet validates each signature
> over the hashed message, then attempts to "decode" the hash by applying
> its own 'x'. If the hash doesn't match, it cannot be its own input.
> - Sign for every input that is yours
Interesting, basically a proof of non-ownership :), a proof that the
hardware wallet doesn't own the address.
But shouldn't x be public, so that the device can verify the signature?
Can you expand on this, what is exactly signed with which key and how is
it checked?
One also has to make sure that it's not possible to reuse signatures as
ownership proof that were made for a different purpose.
Jochen

2023-06-07 17:53:04

- 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

- 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:52:02

- reply

📅 Original date posted:2016-07-27
📝 Original message:Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
schrieb am Di., 26. Juli 2016 um 22:10 Uhr:
> Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
> personally consider "not enough" to protect a serious amount of funds.
>
>
But what are the alternatives? Put an expensive processor and a decent
amount of memory in every hardware wallet to support scrypt? Use a million
iterations and just wait 10 minutes after entering you passphrase? Or
compute the secret key on your online computer instead?
Also, how many iterations are secure? A million? Then just add two random
lower-case letters to the end of your passphrase and you have a better
protection with 2048 iterations. If you want to be able to use your
passphrase with cheap hardware and be protected against a high-end computer
with multiple GPUs that is almost a mllion times faster, then you have to
choose a good passphrase. Or just make sure nobody steals your seed; it is
not a brainwallet that is only protected by the passphrase after all.
Regards,
Jochen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160727/6744055a/attachment.html>

2023-06-07 17:51:03

- reply

📅 Original date posted:2016-06-15
📝 Original message:Hello Daniel,
Am 14.06.2016 um 17:41 schrieb Daniel Weigl via bitcoin-dev:
> Hi List,
>
> Following up to the discussion last month ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html ), ive prepared a proposal for a BIP here:
>
> https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
>
>
> Any comments on it? Does anyone working on a BIP44 compliant wallet implement something different?
> If there are no objection, id also like to request a number for it.
thank you for going forward with this. Should we keep the discussion on
the list, or should we make it on github?
I think we should already consider not only P2WPKH over P2SH addresses
but also "native" P2WPKH addresses. Instead of having one BIP for these
two kinds of segwit addresses and forcing the user to have several
different accounts for each BIP, the idea would be that every fully
BIP?? compatible wallet must support both of them. Since P2WPKH is
simpler than P2WPKH over P2SH, this is IMHO reasonable to require.
I would go with the suggestion from Aaron Voisine to use different chain
id's to distinguish between different address types. E.g., 0,1 for
P2WPKH over P2SH and 2,3 for native P2WPKH. I see no reason why a
wallet would want to use P2WPKH over P2SH for change addresses instead
of native P2WPKH, though.
Jochen

2023-06-07 17:50:45

- reply

📅 Original date posted:2016-05-14
📝 Original message:Am 13.05.2016 um 15:16 schrieb Daniel Weigl via bitcoin-dev:
>
> With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses.
> I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.
>
The discussion so far shows that starting a new BIP is a very good idea.
Otherwise everyone would do it slightly different.
With P2(W)SH you mean P2WPKH embedded in P2SH, right? P2WSH is
completely different and used for example for multisig.
> In my opinion there are two(?) different options:
To summarize, option 1 means one account that supports both non-segwit
and segwit addresses. With option 2 you have one p2pkh-only account and
one segwit-only account, which are completely separated.
I personally would vote for option 1. Scanning twice the addresses can
be avoided with Aaron's trick. The second disadvantage remains:
> -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
A non-segwit wallet would ignore all segwit outputs, which means that
the balance it shows is smaller (and it doesn't show transactions that
spend from previous segwit outputs). I don't see that this can lead to
losing money except maybe when sweeping the account with a p2pkh-only
wallet and then throwing the xprv away.
Of course, you can also do option 2 and let it appear to the user as if
it was only one account, but what is the advantage over option 1 in that
case? Also you need two xpubs to watch this joined account.
Jochen

2023-06-07 17:50:42

- 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:10

- reply

📅 Original date posted:2016-04-22
📝 Original message:Am 21.04.2016 um 17:28 schrieb Eric Lombrozo:
> In practice the probability of this case triggering is on the order of
> 2^-128 or something astronomically tiny. I've been using BIP32 for a few
> years already as have many others...I don't think we've ever had to
> handle this case. Justifiably, many app developers feel like the
> additional complexity of properly handling this case is not worth the
> effort.
>
> Having said that, if the handling of this case is simple to implement
> and easy to isolate in the program flow, I am in favor of doing
> something along the lines of what you propose.
>
Yes, the idea is to handle the problem in the library so that app
developers don't have to handle the case of missing addresses or just
ignore the problem. It also doesn't add much complexity to the library
as the current implementations already test for invalid keys. The
library would then just retry instead of returning an error (that most
app developers would then ignore).
Jochen

2023-06-07 17:50:09

- 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