Another advantage of random access from BIP 32 vs iterated chain is
that if there is a bit-flip or corruption, you don't destroy access to
all future addresses, but only burn one utxo. Empirically not an
entirely theoretical issue.
I think the only thing i'd care about is bloating up the number o
On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev
wrote:
> Hi all,
>
> BIP32 [1] says: "In order to prevent these from depending solely on the key
> itself, we extend both private and public keys first with an extra 256 bits of
> entropy. This extension, called the chai
Leondardo,
There are a lot of sub-topics related to your questions that deserve at
least some response.
I was not involved deeply in bitcoin when BIPs 32/38/39/44/45 emerged, but
they were not without some strong differences of opinion and controversy,
some of which are reflected in challenges to
Hi Leonardo,
I can't tell you what the BIP32 author was thinking but if I put
myself in their shoes these are the reasons I might have done it this
way:
1. Use HMAC rather than normal SHA2 -- this is just best practice for
key derivation (even though I don't think it would make a difference
to se
Hi all,
BIP32 [1] says: "In order to prevent these from depending solely on the key
itself, we extend both private and public keys first with an extra 256 bits
of
entropy. This extension, called the chain code...".
My argument is that the chain code is not needed.
To support such claim, I'll show