Re: [Bitcoin-development] BIP16/17 replacement

[Gregory Maxwell <gmaxwell@gmail.com>]

On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> Hello,
>
> Gulp.  Am a little nervous about wading into this swamp.  However, it seems
> to me that the debate has veered into the personal and away from the

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.

The differences between BIP16/BIP17 are technically obscure, everyone
who is well versed in the issue (with the potential exception of
Luke). There is broad consensus among the involved technically minded
parties over just about all of it.

Luke has been maintaining an opinion tracker page:
https://en.bitcoin.it/wiki/P2SH_Votes

reflecting the views of core developers and people who've been
technically involved enough to have an informed opinion.

> Surely if there are objections to both suggestions, that another
> solution might be better?

There is always a different color that the shed could be painted.
Expecting absolute consensus on the _best_ way forward is an
unreasonable standard, especially if you're going to invite the
opinions of many people.

Depending on how you count we have considered a good two dozen options
in this space—  Starting with the OP_CAT key combinations many months
back, and including many variants of the current ideas. The BIPs only
represent the "final" surviving ideas.

In particular, BIP16 was the isolated consensus path forward that came
out of the discussions about the concerns that BIP12 was too
computationally powerful— I don't think I can identify any particular
person as the author of the BIP16 idea.  At the the time BIP16 became
a BIP only Luke was actively objecting to it.

Though his hard work and tireless (...unstoppable dogmatic) promotion
he's managed to build a workable alternative, and it now has some
support other than himself.  This, however, doesn't constitute a
material schism.

> this idea up for my traditional mailing-list roasting but with the hope that

As always, asbestos underwear is required.

> If the change is going to be a big one anyway and will require a client
> upgrade why not...

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.

>  - Increase the version number in transactions to make a new transaction
>   structure
>  - Dump the "scriptPubKey" field completely.  Everything will be pay-to-
>   script-hash in version2 transactions
>  - Replace it with "hashOfClaimingScript"
>  - Add an "unsignedParameters" array.

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")

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
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.