📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
> On 04/23/2014 09:00 PM, Tier Nolan wrote:
> > The point is to have a single system that is compatible over a large
> > number of systems.
>
> There is such system and it is called BIP32.
>
> On the other hand, in BIP64 we try to put a set of restrictions and
> rules on top of BIP32. There will always be some special usecases where
> BIP64 is not a good fit and there's no reason why you cannot use BIP32
> in a different manner using a different "purpose" field.
>
> Examples: Electrum does not want to use accounts and they start to use
> scheme m/65'/change/address (where change = 0 or 1). Or Andreas
> Schildbach wants to have refunds chain so he uses m/66'/chain/address
> (where chain = 0, 1 or 2).
>
> We wanted to find one good solution that fits all, but unfortunately it
> turned out everyone wants something a little bit different.
Why do clients need to use the features in BIP 64? If Electrum doesn't want to
use accounts, then it can just use account 0 for everything. Refund chains are
definitely a third case that should be added to the external and
internal/change address division... and a wallet not implementing refund
addresses would simply not use that chain.
Luke
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 15:17:55
in reply to nevent1q…tnwl
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsPublished at
2023-06-07 15:17:55Event JSON
{
"id": "356a7ec1541098f3af6fc9d298e48106a2f2e9251dcb3c45cc856efce80ef7e5",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686151075,
"kind": 1,
"tags": [
[
"e",
"3d6a81230db6ab232d8356d3ea7e609f18aff1b8f11502ea70755e81b0de88f9",
"",
"root"
],
[
"e",
"c074fb38a6cb2f23f886c77898487bbd117a470c63db8b38c48e544a16f52a1c",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2014-04-23\n📝 Original message:On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:\n\u003e On 04/23/2014 09:00 PM, Tier Nolan wrote:\n\u003e \u003e The point is to have a single system that is compatible over a large\n\u003e \u003e number of systems.\n\u003e \n\u003e There is such system and it is called BIP32.\n\u003e \n\u003e On the other hand, in BIP64 we try to put a set of restrictions and\n\u003e rules on top of BIP32. There will always be some special usecases where\n\u003e BIP64 is not a good fit and there's no reason why you cannot use BIP32\n\u003e in a different manner using a different \"purpose\" field.\n\u003e \n\u003e Examples: Electrum does not want to use accounts and they start to use\n\u003e scheme m/65'/change/address (where change = 0 or 1). Or Andreas\n\u003e Schildbach wants to have refunds chain so he uses m/66'/chain/address\n\u003e (where chain = 0, 1 or 2).\n\u003e \n\u003e We wanted to find one good solution that fits all, but unfortunately it\n\u003e turned out everyone wants something a little bit different.\n\nWhy do clients need to use the features in BIP 64? If Electrum doesn't want to \nuse accounts, then it can just use account 0 for everything. Refund chains are \ndefinitely a third case that should be added to the external and \ninternal/change address division... and a wallet not implementing refund \naddresses would simply not use that chain.\n\nLuke",
"sig": "e3c133ca8b743dad714651d2276fda5ecf98951b6dc018726cd44b6d1d50fb03a6bc1017d7d35e05b7b24612cb41b6b605416ac873e45f2d486af0c160b52edc"
}