đź“… Original date posted:2017-09-07
đź“ť Original message:On 07/09/17 18:47, Jonas Schnelli wrote:
> But not sure if it’s worth to save ~two bytes for that.
I think it's not worth complicating the field just to save two bytes.
But if we agree (for privacy reasons) that resolution of this field
should be reduced to week-level (as suggested by Jonas) or month-level
(as sugested by Peter), we could use just 16 bits for this.
TBH I think TREZOR will provide hardcoded constant for this field
(1.1.2014 for all its P2PKH xpubs and 1.8.2017 for all its
P2WPKH-in-P2SH xpubs). So no privacy is lost in this case, but if we
want to ENFORCE this on BIP level, we should decrease the resolution.
> 2.
> Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths.
I think this is exactly what Thomas meant by "wallet developers are
going to use dirtier tricks" in his email, that's why I specifically
tried to avoid this. I see no good reason to do this, unless we want to
save some bytes and I don't think we are in need of doing this.
> 3.
> Would adding a version bit make sense to allow future extensions?
I think changing the human-readable part is the way to go. That way the
wallet can immediately say if it understands the format or not, without
parsing the binary data contents. Version bits were introduced in older
standards, because there was no such thing as human-readable prefix.
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/1bdc5fe7/attachment.sig>;
Pavol Rusnak [ARCHIVE] /
npub1wc…3hnuq
2023-06-07 18:05:33
in reply to nevent1q…42hk
Author Public Key
npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuqPublished at
2023-06-07 18:05:33Event JSON
{
"id": "c36e6d49e36a7bc23469895bc1e86b91080817c63e40d039f38b047639d5e28b",
"pubkey": "7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63",
"created_at": 1686161133,
"kind": 1,
"tags": [
[
"e",
"8b6c82e376bdda93cb2f70dd4782d9cc9d7453907841b893f7135515b4f67b4c",
"",
"root"
],
[
"e",
"c58b68bc530aea9612cc203531a26776a9e6788241f4442ad1d2ae704f491202",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2017-09-07\n📝 Original message:On 07/09/17 18:47, Jonas Schnelli wrote:\n\u003e But not sure if it’s worth to save ~two bytes for that.\n\nI think it's not worth complicating the field just to save two bytes.\n\nBut if we agree (for privacy reasons) that resolution of this field\nshould be reduced to week-level (as suggested by Jonas) or month-level\n(as sugested by Peter), we could use just 16 bits for this.\n\nTBH I think TREZOR will provide hardcoded constant for this field\n(1.1.2014 for all its P2PKH xpubs and 1.8.2017 for all its\nP2WPKH-in-P2SH xpubs). So no privacy is lost in this case, but if we\nwant to ENFORCE this on BIP level, we should decrease the resolution.\n\n\u003e 2.\n\u003e Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths.\n\nI think this is exactly what Thomas meant by \"wallet developers are\ngoing to use dirtier tricks\" in his email, that's why I specifically\ntried to avoid this. I see no good reason to do this, unless we want to\nsave some bytes and I don't think we are in need of doing this.\n\n\u003e 3.\n\u003e Would adding a version bit make sense to allow future extensions?\n\nI think changing the human-readable part is the way to go. That way the\nwallet can immediately say if it understands the format or not, without\nparsing the binary data contents. Version bits were introduced in older\nstandards, because there was no such thing as human-readable prefix.\n\n-- \nBest Regards / S pozdravom,\n\nPavol \"stick\" Rusnak\nCTO, SatoshiLabs\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/1bdc5fe7/attachment.sig\u003e",
"sig": "7ed1f643b955a4c014900308cbe5f9ac635acf809541f89497f6abd62d11a0a8ffc5d1329f718c7c548f2841e20c1330dd96f6b66dae4fc11355989e8dbaf89f"
}