Taylor Gerring [ARCHIVE] on Nostr: 📅 Original date posted:2013-12-20 📝 Original message:I’m inclined to agree, ...
đź“… Original date posted:2013-12-20
📝 Original message:I’m inclined to agree, as this was discussed on multiple occasions and seems to fix a lot of the address re-use problems. With hot topics like “coin validation”, I think it’s important to highlight the privacy that generating fresh addresses from public extended keys grants us.
Also thinking about implications regarding non-merchant use of Payment Protocol, encouraging the exchange of extended public keys instead of a single address could be a boon for Payment Protocol to actually be useful for users. Initially, the idea was that the merchant would generate a new address from an extended key and include that in the Payment Request. How do we handle pushing the extended public key down to the wallet itself? Do we just shoehorn the exchange of keys into the Payment Protocol itself via a special tag or would this require more substantive change? Services could develop to facilitate the exchange (acting as a sort of “PP gateway”) or wallet software might be able to directly communicate, perhaps by exchanging PGP-encrypted files in Payment Protocol format via Bluetooth, AirDrop, email, BitMessage, or whatever future communications channel comes into being.
Thanks again to Peter for putting together a consolidated list of topics!
Taylor
On Dec 19, 2013, at 2:40 PM, caedes <caedes at sindominio.net> wrote:
> I feel it's missing mention of using (or not) *extended public keys*
> from bip 32 to share multiple addresses in one go, so regular payments
> can be done without asking for further addresses. Also since whoever has
> the extended key can generate public keys this might help P2SH where the
> public key is also needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131220/f86849b3/attachment.html>
Published at
2023-06-07 15:10:55Event JSON
{
"id": "532eded188fac7181199d3858e75c8db1062047df8cfcbdc696b72567aad8c6d",
"pubkey": "cf0c36d3cbefb87dda6e830ae3e537314270c42aa31124b0838c6619e712088e",
"created_at": 1686150655,
"kind": 1,
"tags": [
[
"e",
"514301cc9f5ddc25df3b828aa9333770c3d0836a61c6b4a37a507b4ca1f9b3ce",
"",
"root"
],
[
"e",
"2f2ee849cd90c9ae5d1624da8df623f52ecb3c1d4ef7f1b421b15a32b91688cb",
"",
"reply"
],
[
"p",
"50ece7cbb2dc316af1cd5da0d62e0e1fec40f20919242c8fbedd53702fba95db"
]
],
"content": "📅 Original date posted:2013-12-20\n📝 Original message:I’m inclined to agree, as this was discussed on multiple occasions and seems to fix a lot of the address re-use problems. With hot topics like “coin validation”, I think it’s important to highlight the privacy that generating fresh addresses from public extended keys grants us.\n\nAlso thinking about implications regarding non-merchant use of Payment Protocol, encouraging the exchange of extended public keys instead of a single address could be a boon for Payment Protocol to actually be useful for users. Initially, the idea was that the merchant would generate a new address from an extended key and include that in the Payment Request. How do we handle pushing the extended public key down to the wallet itself? Do we just shoehorn the exchange of keys into the Payment Protocol itself via a special tag or would this require more substantive change? Services could develop to facilitate the exchange (acting as a sort of “PP gateway”) or wallet software might be able to directly communicate, perhaps by exchanging PGP-encrypted files in Payment Protocol format via Bluetooth, AirDrop, email, BitMessage, or whatever future communications channel comes into being. \n\nThanks again to Peter for putting together a consolidated list of topics!\n\nTaylor\n\n\n\nOn Dec 19, 2013, at 2:40 PM, caedes \u003ccaedes at sindominio.net\u003e wrote:\n\n\u003e I feel it's missing mention of using (or not) *extended public keys*\n\u003e from bip 32 to share multiple addresses in one go, so regular payments\n\u003e can be done without asking for further addresses. Also since whoever has\n\u003e the extended key can generate public keys this might help P2SH where the\n\u003e public key is also needed.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131220/f86849b3/attachment.html\u003e",
"sig": "71a99c37e5fbf5ae9476f76e3652ff90c62d543a55d4803dba819f047f6a9c4bd13da1b8eff405bd896ac636ccd3531d1410e023e508ecaf6535bf14f231db0d"
}