Why Nostr? What is Njump?
2023-06-07 15:18:04
in reply to

Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-24 📝 Original message:On Thu, Apr 24, 2014 at ...

📅 Original date posted:2014-04-24
📝 Original message:On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
>>> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
>>> use accounts, [...]
>>
>> To clarify:
>> Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.

It doesn't appear to me that reoccurring payments, receive accounts,
multisig addresses, etc can be used with this proposal, but instead
you must use a different purpose code and another BIP and are not
compatible with the draft here.

Am I misunderstanding it? Will Electrum be limiting itself in this
way? I'd consider it a unfortunate loss of functionality if wallets
couldn't implement reoccurring payment chains without making users
generate entirely different wallets (which they couldn't share funds
across) since addresses for recurring payments was one of the main
motivations in BIP32.
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet