From: Andy Parkins <andyparkins@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP16/17 replacement
Date: Wed, 1 Feb 2012 09:46:31 +0000 [thread overview]
Message-ID: <201202010946.37807.andyparkins@gmail.com> (raw)
In-Reply-To: <CAAS2fgTvvDT+acJQfwAGpVNeA2PAQ7wip9xXc-__V2oz-=Kk6Q@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 2743 bytes --]
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@gmail•com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-02-01 9:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 16:50 Andy Parkins
2012-01-31 16:58 ` Luke-Jr
2012-01-31 17:11 ` Andy Parkins
2012-02-01 9:48 ` Andy Parkins
2012-02-01 10:02 ` Pieter Wuille
2012-02-01 10:25 ` Andy Parkins
2012-01-31 17:45 ` Gregory Maxwell
2012-02-01 9:46 ` Andy Parkins [this message]
2012-02-01 14:14 ` Andy Parkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201202010946.37807.andyparkins@gmail.com \
--to=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox