š
Original date posted:2017-09-06
š Original message:> In addition, consensus might be more difficult to reach on that
Let's move forward with the simplest solution that solves the problem and
achieves consensus! Version bytes {x,y,z} fits the bill.
On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 05.09.2017 21:00, Kabuto Samourai wrote:
> >
> > The Electrum approach is nice but may not go far enough, as xpub and zpub
> > both list "P2PKH or P2SH." Why not expand the number of version prefixes
> to
> > eliminate the ambiguity?
> >
>
> I agree that this would make sense if we had done it from the start.
> However, fixing that now might be difficult.
>
> My "xyz" proposal extends the current format in a way that is very easy
> to deploy, because existing software will require minimal changes.
> However, if we eliminate the p2sh ambiguity now, wallets will need to
> add extra safeguards, in order to prevent scenarios that are currently
> allowed, and they will need to handle legacy xpub/xprv differently than
> ypub and zpub. This would take much more time to deploy.
>
> In addition, consensus might be more difficult to reach on that; I guess
> not all developers will not agree that removing that ambiguity is
> useful. Since there is an infinity of possible P2SH scripts, it will
> never be possible to remove ambiguity from a master key associated to a
> P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
> strong.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/57f3bc91/attachment.html>;
Kabuto Samourai [ARCHIVE] /
npub1f3ā¦px7uy
2023-06-07 18:05:23
in reply to nevent1qā¦f4mh
Author Public Key
npub1f3xpeyllrkdy9250q8n8dpn8tnh7v5y8n735szj8qegx7z62lleqzpx7uyPublished at
2023-06-07 18:05:23Event JSON
{
"id": "36dd77ecb229fcffb097471911e1febd360f49929ca64d59c46e7fa7fd6da212",
"pubkey": "4c4c1c93ff1d9a42aa8f01e67686675cefe650879fa3480a4706506f0b4afff2",
"created_at": 1686161123,
"kind": 1,
"tags": [
[
"e",
"a923bf1bc525f39bcc8b2d79f1a19c60437c6f409ee33c9b06b9485d2e732c67",
"",
"root"
],
[
"e",
"8a9621baabd9906c75c8f4aa6f76e96d3961b812322f8d37ffc8e2ad409ca572",
"",
"reply"
],
[
"p",
"7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05"
]
],
"content": "š
Original date posted:2017-09-06\nš Original message:\u003e In addition, consensus might be more difficult to reach on that\n\nLet's move forward with the simplest solution that solves the problem and\nachieves consensus! Version bytes {x,y,z} fits the bill.\n\nOn Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e On 05.09.2017 21:00, Kabuto Samourai wrote:\n\u003e \u003e\n\u003e \u003e The Electrum approach is nice but may not go far enough, as xpub and zpub\n\u003e \u003e both list \"P2PKH or P2SH.\" Why not expand the number of version prefixes\n\u003e to\n\u003e \u003e eliminate the ambiguity?\n\u003e \u003e\n\u003e\n\u003e I agree that this would make sense if we had done it from the start.\n\u003e However, fixing that now might be difficult.\n\u003e\n\u003e My \"xyz\" proposal extends the current format in a way that is very easy\n\u003e to deploy, because existing software will require minimal changes.\n\u003e However, if we eliminate the p2sh ambiguity now, wallets will need to\n\u003e add extra safeguards, in order to prevent scenarios that are currently\n\u003e allowed, and they will need to handle legacy xpub/xprv differently than\n\u003e ypub and zpub. This would take much more time to deploy.\n\u003e\n\u003e In addition, consensus might be more difficult to reach on that; I guess\n\u003e not all developers will not agree that removing that ambiguity is\n\u003e useful. Since there is an infinity of possible P2SH scripts, it will\n\u003e never be possible to remove ambiguity from a master key associated to a\n\u003e P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as\n\u003e strong.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\n\n\n-- \n-Kabuto\n\nPGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/57f3bc91/attachment.html\u003e",
"sig": "61cda61e4086c9b679f05d936ff3ed286e0a781ea8b3aead6392d4f30a790926b94a80fd229950ce555fed6303ac98a049bd8b96e032bab9eb068e8c83fee998"
}