📅 Original date posted:2012-02-01
📝 Original message:On 2012 January 31 Tuesday, Gregory Maxwell wrote:
> I think you've been deceived by people who have some interest in
> promoting this as some sort of big controversy, or perhaps just
> confused by the general level of noise.
Well that's good that there is no real problem.
> It does not, in fact— Yes, it requires a client update to make use of
> the new functionality, but old nodes will happily continue to validate
> things. It's hard to express how critical this is distinctly.
> Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that
> things were done right, the validate them for themselves.
>
> A breaking change of the kind you suggest is not something that would
> be considered lightly, and this is certainly not justified for this.
To be brutally honest; I don't see how the BIP16/17 changes are any less
"breaking" than what I proposed (I'm not trying to push mine; forget it, the
last thing bitcoin needs is another proposal if there is no real argument).
I will agree the changes are smaller for BIP16, since the transactions are
left as they are.
If BIP16/BIP17 were being honest they would too increase the version number
of the transaction structure. The new transaction type is not supported by
the old client... that's a break. My argument would be that once you're
going to break the old clients anyway, go the whole hog and fix some other
stuff as well.
> If we ever were to scrap the system, I think we very much would do
> something like what you describe here... and as much has been
> documented:
>
> https://en.bitcoin.it/wiki/Hardfork_Wishlist
> (see "Elimination of output scripts")
I'm glad I wasn't talking rubbish then.
> But, to be clear, this stuff is pretty much fantasy. I'm doubtful that
> it will ever happen, doubtful that we can get the kind of development
Me too. Which is a shame; as it means we're locked into quite a fair number
of earlier decisions that will now never be changed.
> resources required to pull off a true breaking change in a way that
> people would actually trust upgrading to— at least not before a time
> that the system is simply too big to make that kind of change.
Again: I don't see how BIP16/17 aren't "breaking" as well; but perhaps I'm
just not familiar enough with the conventions. As far as I understand; no
pre-BIP16 miner is going to allow BIP16 into the blockchain because it's not
going to pass the IsStandard() test.
I'd repeat: the reasonable thing to do is to increase the version number of
the transaction structure to indicate that they are being processed
differently from old transactions.
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/20120201/1fd55c20/attachment.sig>;
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 03:02:35
in reply to nevent1q…fvvn
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 03:02:35Event JSON
{
"id": "d4fbe1e88f948c67415bb8b7904a5ecfc30fb4b1843d59b83e36c9c9035c2084",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686106955,
"kind": 1,
"tags": [
[
"e",
"c92e2a87aa2d3c7365eadb419b42aac76742888a43a9dd185e4a98ca6fda909f",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2012-02-01\n📝 Original message:On 2012 January 31 Tuesday, Gregory Maxwell wrote:\n\n\u003e I think you've been deceived by people who have some interest in\n\u003e promoting this as some sort of big controversy, or perhaps just\n\u003e confused by the general level of noise.\n\nWell that's good that there is no real problem.\n\n\u003e It does not, in fact— Yes, it requires a client update to make use of\n\u003e the new functionality, but old nodes will happily continue to validate\n\u003e things. It's hard to express how critical this is distinctly.\n\u003e Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that\n\u003e things were done right, the validate them for themselves.\n\u003e \n\u003e A breaking change of the kind you suggest is not something that would\n\u003e be considered lightly, and this is certainly not justified for this.\n\nTo be brutally honest; I don't see how the BIP16/17 changes are any less \n\"breaking\" than what I proposed (I'm not trying to push mine; forget it, the \nlast thing bitcoin needs is another proposal if there is no real argument). \nI will agree the changes are smaller for BIP16, since the transactions are \nleft as they are.\n\nIf BIP16/BIP17 were being honest they would too increase the version number \nof the transaction structure. The new transaction type is not supported by \nthe old client... that's a break. My argument would be that once you're \ngoing to break the old clients anyway, go the whole hog and fix some other \nstuff as well.\n\n\u003e If we ever were to scrap the system, I think we very much would do\n\u003e something like what you describe here... and as much has been\n\u003e documented:\n\u003e \n\u003e https://en.bitcoin.it/wiki/Hardfork_Wishlist\n\u003e (see \"Elimination of output scripts\")\n\nI'm glad I wasn't talking rubbish then.\n \n\u003e But, to be clear, this stuff is pretty much fantasy. I'm doubtful that\n\u003e it will ever happen, doubtful that we can get the kind of development\n\nMe too. Which is a shame; as it means we're locked into quite a fair number \nof earlier decisions that will now never be changed.\n\n\u003e resources required to pull off a true breaking change in a way that\n\u003e people would actually trust upgrading to— at least not before a time\n\u003e that the system is simply too big to make that kind of change.\n\nAgain: I don't see how BIP16/17 aren't \"breaking\" as well; but perhaps I'm \njust not familiar enough with the conventions. As far as I understand; no \npre-BIP16 miner is going to allow BIP16 into the blockchain because it's not \ngoing to pass the IsStandard() test.\n\nI'd repeat: the reasonable thing to do is to increase the version number of \nthe transaction structure to indicate that they are being processed \ndifferently from old transactions.\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/20120201/1fd55c20/attachment.sig\u003e",
"sig": "29c403d61df1f401b6302f66681832423befc37207848d7818ae54192d1d16d14f47bba9dca0096801f9f4a6670a9dcfe7af2e1989c2f96874a2971cb2762035"
}