đź“… Original date posted:2014-04-25
đź“ť Original message:On Fri, Apr 25, 2014 at 7:53 AM, Jim <jim618 at fastmail.co.uk> wrote:
> Oh dear.
>
> For reasons that are perfectly reasonable we are close to losing any chance of intra-client HD compatibility for BIP32 wallets.
>
> In the next 12 months there will probably be collectively millions of users of our new wallets. I don't want them to suffer from vendor lockin.
>
> Can we not agree on a lowest common denominator that we agree to support ?
> An "HD Basic" if you like.
> For entry level users we can keep things simple and any "HD Basic" bitcoin will be fully interoperable.
>
> Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it.
>
> I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice.
I don't believe that wallet interoperability at this level is possible
in general except as an explicit compatibility feature. I also don't
believe that it is a huge loss that it is so.
The structure of the derivation defines and constrains functionality.
You cannot be structure compatible unless you have the same features
and behavior with respect to key management. To that extent that
wallets have the same features, I agree its better if they are
compatible— but unless they are dead software they likely won't keep
the same features for long.
Even if their key management were compatible there are many other
things that go into making a wallet portable between systems; the
handling of private keys is just one part: a complete wallet will
have other (again, functionality specific) metadata.
I agree that it would be it would be possible to support a
compatibility mode where a wallet has just a subset of features which
works when loaded into different systems, but I'm somewhat doubtful
that it would be widely used. The decision to use that mode comes at
the wrong time— when you start, not when you need the features you
chose to disable or when you want to switch programs. But the obvious
thing to do there is to just specify that a linear chain with no
further branching is that mode: then that will be the same mode you
use when someone gives you a master public key and asks you to use it
for reoccurring changes— so at least the software will get used.
Compatibility for something like a recovery tool is another matter,
and BIP32 probably defines enough there that with a bit of extra data
about how the real wallet worked that recovery can be successful.
Calling it "vendor lock in" sounds overblown to me. If someone wants
to change wallets they can transfer the funds— manual handling of
private keys is seldom advisable, and as is they're going to lose
their metadata in any case. No one expects to switch banks and to
keep their account records at the new bank. And while less than
perfect, the price of heavily constraining functionality in order to
get another result is just too high.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:20:05
in reply to nevent1q…6kuu
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:20:05Event JSON
{
"id": "d47bb6f02657ff41c5c7ddba250acc4996546add00a98e8609d3af65fdf590a5",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151205,
"kind": 1,
"tags": [
[
"e",
"692eac5a75f05a182335e76c9b1e0f6eb679dd54e3d43b36d140b5454edcc477",
"",
"root"
],
[
"e",
"2bc491d3e7aba1ac4581a5a0065fc0644d582f3bc76ef070f0d73c307890512c",
"",
"reply"
],
[
"p",
"e9799fb8f78387b0c1fd27d4d15afa550d214db447d801dae134d0d1703271ec"
]
],
"content": "📅 Original date posted:2014-04-25\n📝 Original message:On Fri, Apr 25, 2014 at 7:53 AM, Jim \u003cjim618 at fastmail.co.uk\u003e wrote:\n\u003e Oh dear.\n\u003e\n\u003e For reasons that are perfectly reasonable we are close to losing any chance of intra-client HD compatibility for BIP32 wallets.\n\u003e\n\u003e In the next 12 months there will probably be collectively millions of users of our new wallets. I don't want them to suffer from vendor lockin.\n\u003e\n\u003e Can we not agree on a lowest common denominator that we agree to support ?\n\u003e An \"HD Basic\" if you like.\n\u003e For entry level users we can keep things simple and any \"HD Basic\" bitcoin will be fully interoperable.\n\u003e\n\u003e Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it.\n\u003e\n\u003e I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice.\n\nI don't believe that wallet interoperability at this level is possible\nin general except as an explicit compatibility feature. I also don't\nbelieve that it is a huge loss that it is so.\n\nThe structure of the derivation defines and constrains functionality.\nYou cannot be structure compatible unless you have the same features\nand behavior with respect to key management. To that extent that\nwallets have the same features, I agree its better if they are\ncompatible— but unless they are dead software they likely won't keep\nthe same features for long.\n\nEven if their key management were compatible there are many other\nthings that go into making a wallet portable between systems; the\nhandling of private keys is just one part: a complete wallet will\nhave other (again, functionality specific) metadata.\n\nI agree that it would be it would be possible to support a\ncompatibility mode where a wallet has just a subset of features which\nworks when loaded into different systems, but I'm somewhat doubtful\nthat it would be widely used. The decision to use that mode comes at\nthe wrong time— when you start, not when you need the features you\nchose to disable or when you want to switch programs. But the obvious\nthing to do there is to just specify that a linear chain with no\nfurther branching is that mode: then that will be the same mode you\nuse when someone gives you a master public key and asks you to use it\nfor reoccurring changes— so at least the software will get used.\n\nCompatibility for something like a recovery tool is another matter,\nand BIP32 probably defines enough there that with a bit of extra data\nabout how the real wallet worked that recovery can be successful.\n\nCalling it \"vendor lock in\" sounds overblown to me. If someone wants\nto change wallets they can transfer the funds— manual handling of\nprivate keys is seldom advisable, and as is they're going to lose\ntheir metadata in any case. No one expects to switch banks and to\nkeep their account records at the new bank. And while less than\nperfect, the price of heavily constraining functionality in order to\nget another result is just too high.",
"sig": "0137d31158f57cfea4baa8fa3c011a17b48d919dcc952cec325a0e7439c00dd1cbbac525b217e58972a3d691a5f4d8761a4a4e6e1828d6fc76de49ed3017e67d"
}