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.
Published at
2023-06-07 15:18:04Event JSON
{
"id": "44a516060911aa87e0e34dc8408069e5076953f15561c401d1bf1ba0339dd540",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151084,
"kind": 1,
"tags": [
[
"e",
"3d6a81230db6ab232d8356d3ea7e609f18aff1b8f11502ea70755e81b0de88f9",
"",
"root"
],
[
"e",
"2b70f36cad0a710ae182551364bd6711bd7dd8f6d9d05e7d74bb4f755555aef7",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-04-24\n📝 Original message:On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin \u003cthomasv1 at gmx.de\u003e wrote:\n\u003e\u003e\u003e Why do clients need to use the features in BIP 64? If Electrum doesn't want to\n\u003e\u003e\u003e use accounts, [...]\n\u003e\u003e\n\u003e\u003e To clarify:\n\u003e\u003e Electrum plans to have bip32 accounts; Multibit will not, afaik.\n\u003e\n\u003e To clarify:\n\u003e BIP64 has a much stricter definition for accounts than BIP32.\n\u003e\n\u003e In BIP32, it is not well specified what accounts are used for. They\n\u003e can be used for \"subwallets\", \"receive accounts\" (as in bitcoind's\n\u003e account feature), \"recurring payments\", part of a chain used as\n\u003e multisig addresses, ... determined individually for each index.\n\u003e\n\u003e In BIP64, they are strictly used for subwallets, and can't be used by\n\u003e anything else.\n\nIt doesn't appear to me that reoccurring payments, receive accounts,\nmultisig addresses, etc can be used with this proposal, but instead\nyou must use a different purpose code and another BIP and are not\ncompatible with the draft here.\n\nAm I misunderstanding it? Will Electrum be limiting itself in this\nway? I'd consider it a unfortunate loss of functionality if wallets\ncouldn't implement reoccurring payment chains without making users\ngenerate entirely different wallets (which they couldn't share funds\nacross) since addresses for recurring payments was one of the main\nmotivations in BIP32.",
"sig": "83b4c05d74049e75b520573bbdd696ba11c6b789254e21e15b304bfd18da141280fc020e417fa6d8a5ecc2247a05a6f125bec1054e1a75117839495ff87a1ea1"
}