📅 Original date posted:2018-05-30
📝 Original message:On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The idea to add birthdate and gap limit sounds very good and addresses lots
> of problems users are facing.
>
> However, adding birthday to keys breaks two basic properties
>
> - Visually Comparing two keys to find if they are same (Important)
Can you explain exactly what you mean there? I can think of to
plausible meanings (that two valid keys could differ by only a single
symbol, which wouldn't be true due to the checksum and could be made
even stronger if we thought that would be useful or I think you could
also be complaining that the same "key material" could be encoded two
ways which I think is both harmless and unavoidable for anything
versioned).
> - Different wallet software could set different birthday/gap limit. creating
> different xpub/xprv for the same set of mathematically derived individual
> keys. This removes the decoupling between key and wallet metadata
Personally, I think it's a mistake to believe that any key format can
really make private keying material strongly compatible between
wallets. At best you can hope for a mostly compatible kind of recovery
handling.
But the lookahead amount may be pretty integral to the design of the
software, so signaling it may not mean the other side can obey the
signal... but that wouldn't make the signal completely useless.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 18:12:31
in reply to nevent1q…nud6
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:12:31Event JSON
{
"id": "4b39e175fcf6770b22061c0de37d47195b2bd7913edd5983cad268e3f1604603",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686161551,
"kind": 1,
"tags": [
[
"e",
"7999fd619e15dea42ea86f407f30a83888b254a55644cb5d1a6e12c335c1e13a",
"",
"root"
],
[
"e",
"e1ed23cfae9e0d9562177aae2727bc1871dcd36bb58439ed50906340bc3488e4",
"",
"reply"
],
[
"p",
"73b22eae19475ecafd3ad7608b5964dd8c693ff3c22755e534ff815332ed7dde"
]
],
"content": "📅 Original date posted:2018-05-30\n📝 Original message:On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e The idea to add birthdate and gap limit sounds very good and addresses lots\n\u003e of problems users are facing.\n\u003e\n\u003e However, adding birthday to keys breaks two basic properties\n\u003e\n\u003e - Visually Comparing two keys to find if they are same (Important)\n\nCan you explain exactly what you mean there? I can think of to\nplausible meanings (that two valid keys could differ by only a single\nsymbol, which wouldn't be true due to the checksum and could be made\neven stronger if we thought that would be useful or I think you could\nalso be complaining that the same \"key material\" could be encoded two\nways which I think is both harmless and unavoidable for anything\nversioned).\n\n\u003e - Different wallet software could set different birthday/gap limit. creating\n\u003e different xpub/xprv for the same set of mathematically derived individual\n\u003e keys. This removes the decoupling between key and wallet metadata\n\nPersonally, I think it's a mistake to believe that any key format can\nreally make private keying material strongly compatible between\nwallets. At best you can hope for a mostly compatible kind of recovery\nhandling.\n\nBut the lookahead amount may be pretty integral to the design of the\nsoftware, so signaling it may not mean the other side can obey the\nsignal... but that wouldn't make the signal completely useless.",
"sig": "a4ae32ac592039acc0ad3ae4812239392d92c114842cb5b92da865804e67dc00e6cb6b48a97aa15fcb7913c6551f58c338a3994eb2cc6e82bd47036ee6736d77"
}