Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2012-02-01 📝 Original message:On 2012 January 31 ...
📅 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>;
📝 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>;