public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [Bitcoin-development] BIP16/17 replacement 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.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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