Dear Pavol,
Thank you for your valuable perspective on the subject.
I fully appreciate the original design intentions of BIP39 and the importance
of maintaining interoperability and simplicity.
However, I'd like to share some thoughts in light of the concerns you've raised.
Regarding the
On Wed, Dec 27, 2023 at 8:06 PM Nagaev Boris wrote:
>
> On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev
> wrote:
> > As a result, there are incentives structure distorted and critical
> > inefficiencies/vulnerabilities (e.g. misallocation of block space,
> > blockspace value
On Sat, 13 Jan 2024 at 10:53, Leslie <0300dbd...@protonmail.com> wrote:
> Developments like aezeed[1] or Electrum V2[2] also demonstrate that the
> standard BIP39 entropy might not always suffice for specific applications,
> leading to alternative standards being developed.
> This reality
Dear Pavol,
>It is a very unrealistic that any kind of seed standard with extra metadata
>will cover all possible future usecases.
>Therefore new standards will always keep emerging.
>
Indeed, this proposal does not aim to cover *all* usecases, but rather to
provide a backward-compatible way to
Hi Leslie, hi list!
BIP39 author here. Not having version was a design decision, not accidental
omission.
When designing BIP39 we were striving for maximum interoperability. There
are thousands of BIP39 applications and all of them have 100% interoperable
way how to share entropy using a single