Jeremy Spilman [ARCHIVE] on Nostr: 📅 Original date posted:2013-06-19 📝 Original message:Hi Alan, > “BIP 32 does ...
📅 Original date posted:2013-06-19
📝 Original message:Hi Alan,
> “BIP 32 does not prescribe a way to use multiple chains like you described
> with the convenient type-2 derivation (though we could create a variant
> that does)”
What do you think is missing from BIP32 for this? A wallet creates a
child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
and then generally expects transactions to come in starting at /0 and
incrementing monotonically.
Also, I'm not sure I follow your point about the 128kB hardware wallet --
it's a signing device, so assuming it's even validating output amounts, at
worst it cares about the number of inputs to the outputs being spent, but in
many cases you're just handing it a sighash and the BIP32 "path"
(/1/54/27/0) to generate the right private key for signing. The hardware
wallet is not actually listening on the P2P network and detecting payments,
so it's unaffected by dedicating child-nodes to each contact.
Consider the benefits of gaining critical mass of support for a technique
which [I think] can be used in all cases, and increases security and privacy
for everyone. I think there are huge benefits to leaving the age of 'single
address generation' behind us...
Thanks,
--Jeremy
Published at
2023-06-07 15:03:35Event JSON
{
"id": "4fe7956678a3b530b36d8e2ce5ffa8f818b1b0ea036778fc79e67907fd0eddf3",
"pubkey": "7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3",
"created_at": 1686150215,
"kind": 1,
"tags": [
[
"e",
"60c63b2d935c09c2d6c618c7776de45a3225391d6d5c2bbb728d2b54da18fc56",
"",
"root"
],
[
"e",
"bf3987391abc18a52fb1297efb336211a2c6739099aaa2c3618c01982f14ddd9",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2013-06-19\n📝 Original message:Hi Alan,\n\n\u003e “BIP 32 does not prescribe a way to use multiple chains like you described \n\u003e with the convenient type-2 derivation (though we could create a variant \n\u003e that does)”\n\nWhat do you think is missing from BIP32 for this? A wallet creates a \nchild-node using the public / type-2 CDF, hands out the PubKey/ChainCode, \nand then generally expects transactions to come in starting at /0 and \nincrementing monotonically.\n\nAlso, I'm not sure I follow your point about the 128kB hardware wallet -- \nit's a signing device, so assuming it's even validating output amounts, at \nworst it cares about the number of inputs to the outputs being spent, but in \nmany cases you're just handing it a sighash and the BIP32 \"path\" \n(/1/54/27/0) to generate the right private key for signing. The hardware \nwallet is not actually listening on the P2P network and detecting payments, \nso it's unaffected by dedicating child-nodes to each contact.\n\nConsider the benefits of gaining critical mass of support for a technique \nwhich [I think] can be used in all cases, and increases security and privacy \nfor everyone. I think there are huge benefits to leaving the age of 'single \naddress generation' behind us...\n\nThanks,\n--Jeremy",
"sig": "c4ba2ba788a8200bb513576c3d94493ccf34725c64bfb9121c0dfdd2b29528c06b5d0a91afe5e5f28d757bc7d44282e2e6328b0776f041cf50a05d9e3bbdbd68"
}