[Bitcoin-development] BIP16/17 replacement

[Bitcoin-development] BIP16/17 replacement

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 2476 bytes --]

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 
technical.  Surely if there are objections to both suggestions, that another 
solution might be better?  The answer doesn't have to be A or B, if the 
answer C turns out to be acceptable.

That being said; I am not confident enough to start making BIPs so I offer 
this idea up for my traditional mailing-list roasting but with the hope that 
I blindly stumble toward something more acceptable to everyone.

----

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

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

hashOfClaimingScript is _not_ script.  It's just the hash of the script that 
is allowed to claim the output.  Then before scriptSig is allowed to run, it 
is hashed and compared against the hashOfClaimingScript.

unsignedParameters replaces the need for all the crazy messing around that 
OP_CHECKSIG currently does because it is specifically a block of the 
transaction that it not signed (although I would include the array size bytes 
in the signature calculation), therefore no script filtering is necessary.

The claiming script, scriptSig, can then be checked against whatever list of 
templates you like.  For pay-to-address it will probably look like:

  OP_PUSHPARAMETER {0}
  OP_PUSH { <claimant public key> }
  OP_CHECKSIGVERIFY

Handling the more complicated transactions (they're the point of all this 
after all) is pretty obvious; the unsignedParameters block can hold as many 
signatures as you like.  It also removes the need for OP_CHECKMULTISIG, since 
the script can specify the signature conditions.  e.g. a 2-of-3 script:

  OP_PUSHPARMETER {0}
  OP_PUSH { <claimant public key0> }
  OP_CHECKSIG
  OP_PUSHPARMETER {1}
  OP_PUSH { <claimant public key1> }
  OP_CHECKSIG
  OP_PUSHPARMETER {1}
  OP_PUSH { <claimant public key1> }
  OP_CHECKSIG
  OP_ADD
  OP_ADD
  OP_PUSH {1}
  OP_GREATERTHAN

(I'm sure someone cleverer than I can improve on the above)

-----

Let the flaming commence...



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] BIP16/17 replacement

[Luke-Jr]

On Tuesday, January 31, 2012 11:50:58 AM Andy Parkins wrote:
> 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
> technical.  Surely if there are objections to both suggestions, that
> another solution might be better?  The answer doesn't have to be A or B,
> if the answer C turns out to be acceptable.

I'm not aware of any remaining *tangible* objections to BIP 17 at this point 
(Gavin seems concerned over a theoretical risk-that-nobody-has-thought-of), 
but if there's a better solution, I'm perfectly fine Withdrawing BIP 17 to 
support it.

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

Both BIP 16 and 17 are backward compatible enough that people can continue to 
use the old clients with each other. An upgrade is only required to send to 
(or create/receive on) the new 3...-form addresses. That being said, it's 
quite possible to rewrite the practical implications of both BIP 16 and 17 in 
the format you seem to be suggesting. Doing so would even get rid of one of 
the major objections to BIP 16 (its inconsistency).

Re: [Bitcoin-development] BIP16/17 replacement

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1298 bytes --]

On 2012 January 31 Tuesday, Luke-Jr wrote:

> I'm not aware of any remaining *tangible* objections to BIP 17 at this
> point (Gavin seems concerned over a theoretical
> risk-that-nobody-has-thought-of), but if there's a better solution, I'm
> perfectly fine Withdrawing BIP 17 to support it.

I imagine the BIP16 supporters would say the same?  Isn't that the essence of 
the current impasse?

> Both BIP 16 and 17 are backward compatible enough that people can continue
> to use the old clients with each other. An upgrade is only required to
> send to (or create/receive on) the new 3...-form addresses. That being
> said, it's quite possible to rewrite the practical implications of both
> BIP 16 and 17 in the format you seem to be suggesting. Doing so would even
> get rid of one of the major objections to BIP 16 (its inconsistency).

My suggestion is backward compatible.  You'd only have to make version2 
transactions for version2 addresses; and the join between version1 and 
version2 is not a problem since the version1 source can be detected, and the 
handling of the version2 transaction altered as appropriate (it's only a 
matter of switching from the hash check to running the two scripts as 
normal).



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] BIP16/17 replacement

[Gregory Maxwell]

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.

Re: [Bitcoin-development] BIP16/17 replacement

[Andy Parkins]

[-- 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 --]

Re: [Bitcoin-development] BIP16/17 replacement

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 516 bytes --]

On 2012 January 31 Tuesday, Luke-Jr wrote:

> Both BIP 16 and 17 are backward compatible enough that people can continue
> to use the old clients with each other. An upgrade is only required to
> send to (or create/receive on) the new 3...-form addresses. That being

Is that true?  (I'm happy to be called wrong)

It doesn't seem like it to me.  The new transaction types will be rejected by 
old clients won't they?  They don't pass IsStandard().


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] BIP16/17 replacement

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

Op 1 feb. 2012 10:48 schreef "Andy Parkins" <andyparkins@gmail.com> het
volgende:
>
> On 2012 January 31 Tuesday, Luke-Jr wrote:
>
> > Both BIP 16 and 17 are backward compatible enough that people can
continue
> > to use the old clients with each other. An upgrade is only required to
> > send to (or create/receive on) the new 3...-form addresses. That being
>
> Is that true?  (I'm happy to be called wrong)
>
> It doesn't seem like it to me.  The new transaction types will be
rejected by
> old clients won't they?  They don't pass IsStandard().

IsStandard() is for accepting transactions into the memory pool.
Non-standard transactions are verified just fine when they are in the block
chain.

BIP16/17 both create transactions that, when interpreted as old scripts,
are valid. The only change to the protocol is that previously-valid
transactions become invalid. As long as a supermajority of miners enforce
the new rules, everyone can happily keep using their old bitcoin client.
They won't create the new transaction type, and don't accept them as
payment, but they will accept the new block chain.

If we do a breaking change to the protocol - such as adding a new
transaction type - ALL users must upgrade. Those who don't will see a fork
of the chain from before the first new-style transaction. That is not the
case now.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1586 bytes --]

Re: [Bitcoin-development] BIP16/17 replacement

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 669 bytes --]

On 2012 February 01 Wednesday, Pieter Wuille wrote:

> > old clients won't they?  They don't pass IsStandard().
> 
> IsStandard() is for accepting transactions into the memory pool.
> Non-standard transactions are verified just fine when they are in the block
> chain.

Ah.  My misunderstanding then.
 
> If we do a breaking change to the protocol - such as adding a new
> transaction type - ALL users must upgrade. Those who don't will see a fork
> of the chain from before the first new-style transaction. That is not the
> case now.

That makes a big difference.  Thanks for the correction.


Andy


-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] BIP16/17 replacement

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1611 bytes --]

On 2012 January 31 Tuesday, Andy Parkins wrote:

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

Having thought about it; I've realised that the above is simply BIP16 without 
the backward compatibility work in it.  If BIP16 renamed the scriptPubKey 
field to "hashOfClaimingScript" and no longer ran it as a script, it woudl be 
close to identical.  We'd simply define the field as

 0xa9 0x14 <hashOfClaimingScript> 0x87

Detection of this format of scriptPubKey activates "version2" processing of 
the transaction.  And similarly, a new definition of scriptSig to be two 
fields:

   unsignedInitialStackBlock
   scriptClaim

I'm sure nobody cares about my opinion; but that's actually been the moment 
of epiphany for me (and I raise it here, in case it is for someone else).  
Having previously been against BIP16, I'm now happy with BIP16 -- it's a 
progression towards the ideal... having a literal claimScriptHash field 
instead of scriptPubKey; and never running scriptPubKey.

Potentially OP_CHECKSIG could be simplified as well because the rules could 
be "anything that's not the serialized script" in scriptSig is not signed.

I can imagine one day, when the network is all BIP16 compliant, that 
scriptPubKey will no longer be allowed to run as script at all.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]