š
Original date posted:2012-01-31
š Original message:On 2012 January 31 Tuesday, Luke-Jr wrote:
> I'm not aware of any remaining *tangible* objections to BIP 17 at this
> point (Gavin seems concerned over a theoretical
> risk-that-nobody-has-thought-of), but if there's a better solution, I'm
> perfectly fine Withdrawing BIP 17 to support it.
I imagine the BIP16 supporters would say the same? Isn't that the essence of
the current impasse?
> Both BIP 16 and 17 are backward compatible enough that people can continue
> to use the old clients with each other. An upgrade is only required to
> send to (or create/receive on) the new 3...-form addresses. That being
> said, it's quite possible to rewrite the practical implications of both
> BIP 16 and 17 in the format you seem to be suggesting. Doing so would even
> get rid of one of the major objections to BIP 16 (its inconsistency).
My suggestion is backward compatible. You'd only have to make version2
transactions for version2 addresses; and the join between version1 and
version2 is not a problem since the version1 source can be detected, and the
handling of the version2 transaction altered as appropriate (it's only a
matter of switching from the hash check to running the two scripts as
normal).
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/0908135b/attachment.sig>;
Andy Parkins [ARCHIVE] /
npub1nxā¦7wjrv
2023-06-07 03:02:26
in reply to nevent1qā¦s8qf
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 03:02:26Event JSON
{
"id": "1f36426db095796445a8e1c58f5c4f904ce6e11c99b5536dd1d363eb611fac16",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686106946,
"kind": 1,
"tags": [
[
"e",
"22b31c7914344e2558f61c1ca11e9ce319306fcef8c5a07a7de90e59af569931",
"",
"root"
],
[
"e",
"f9ac959ace19b243217a5c6b7e23f5bf129901c50b0a3e572f3da63e31af2ba1",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "š
Original date posted:2012-01-31\nš Original message:On 2012 January 31 Tuesday, Luke-Jr wrote:\n\n\u003e I'm not aware of any remaining *tangible* objections to BIP 17 at this\n\u003e point (Gavin seems concerned over a theoretical\n\u003e risk-that-nobody-has-thought-of), but if there's a better solution, I'm\n\u003e perfectly fine Withdrawing BIP 17 to support it.\n\nI imagine the BIP16 supporters would say the same? Isn't that the essence of \nthe current impasse?\n\n\u003e Both BIP 16 and 17 are backward compatible enough that people can continue\n\u003e to use the old clients with each other. An upgrade is only required to\n\u003e send to (or create/receive on) the new 3...-form addresses. That being\n\u003e said, it's quite possible to rewrite the practical implications of both\n\u003e BIP 16 and 17 in the format you seem to be suggesting. Doing so would even\n\u003e get rid of one of the major objections to BIP 16 (its inconsistency).\n\nMy suggestion is backward compatible. You'd only have to make version2 \ntransactions for version2 addresses; and the join between version1 and \nversion2 is not a problem since the version1 source can be detected, and the \nhandling of the version2 transaction altered as appropriate (it's only a \nmatter of switching from the hash check to running the two scripts as \nnormal).\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part.\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/0908135b/attachment.sig\u003e",
"sig": "f7e84a673c7298b224ce4a85657178a866a4190520ee6bd5ca85d1ad0d27d07d75f1bcd583c0f25a78f145d928a78a0a479ca880d0f4cec099086ebeeff7c841"
}