[Bitcoin-development] Pull 748 pay to script hash

[Bitcoin-development] Pull 748 pay to script hash

[Amir Taaki]

https://github.com/bitcoin/bitcoin/pull/748/files

I'm reading a diff of a now defunct OP_EVAL proposal with the current pay to script hash one.

It might be better for code review if the old pull is reverted and then this one re-requested. That will make it easier to see the real changes.

Re: [Bitcoin-development] Pull 748 pay to script hash

[Gavin Andresen]

> It might be better for code review if the old pull is reverted and then this one re-requested. That will make it easier
> to see the real changes.

I count the 1 major merge then 8 commits to fix bugs or tweak
things...  I just tried reverting them and stopped when I got scared
I'll accidentally revert a fix we do want to keep.

Instead, I updated my gavinandresen/master github branch to the state
of the tree just before the OP_EVAL merge, so for code review purposes
you can look at:

https://github.com/gavinandresen/bitcoin-git/compare/master...pay_to_script_hash

There are unrelated 0.6 pulls in those changes, too, but it should be
pretty obvious what is what.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Pull 748 pay to script hash

[Amir Taaki]

OK, here is one thing:

what is the purpose behind counting the number of sig ops after you have executed the script in ConnectInputs?
Seems like it would be too late then.



----- Original Message -----
From: Gavin Andresen <gavinandresen@gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Sent: Saturday, January 7, 2012 10:48 PM
Subject: Re: [Bitcoin-development] Pull 748 pay to script hash

> It might be better for code review if the old pull is reverted and then this one re-requested. That will make it easier
> to see the real changes.

I count the 1 major merge then 8 commits to fix bugs or tweak
things...  I just tried reverting them and stopped when I got scared
I'll accidentally revert a fix we do want to keep.

Instead, I updated my gavinandresen/master github branch to the state
of the tree just before the OP_EVAL merge, so for code review purposes
you can look at:

https://github.com/gavinandresen/bitcoin-git/compare/master...pay_to_script_hash

There are unrelated 0.6 pulls in those changes, too, but it should be
pretty obvious what is what.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Pull 748 pay to script hash

[Gavin Andresen]

> what is the purpose behind counting the number of sig ops after you have executed the script in ConnectInputs?
> Seems like it would be too late then.

The purpose is to comply with the "a block shall not contain more than
MAX_BLOCK_SIGOPS (20,000)" rule, under both the old way of counting
(look at the scriptPubKeys and count CHECKMULTISIGs as 20 sigops no
matter what) and the new way (look at both scriptPubKeys and
pay-to-script-hash scripts in the scriptSig, but count CHECKMULTISIGS
preceded by OP_1/2/3/... as 1/2/3 operations).

RE: too late:

Excellent point. I'll refactor ConnectInputs further, and do something like:

FetchInputs()
AreInputsStandard() <-- reject from memory pool if nonstanard
ComputeSigOps()
ComputeFees() <-- reject if too little fees per byte / sigop
ConnectInputs()

Pieter's compressed-public-keys patch (which was just pulled)
interacts with pay-to-script-hash to make ECDSA denial-of-service
attempts less expensive; I think we need to think hard again about
transaction fees before releasing 0.6, and maybe tweak the fee policy
so denial-of-service attacks using compressed public keys and 1-of-3
CHECKMULTISIG transactions is expensive enough to deter would-be
attackers.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Pull 748 pay to script hash

[Pieter Wuille]

On Sat, Jan 07, 2012 at 08:12:35PM -0500, Gavin Andresen wrote:
> Pieter's compressed-public-keys patch (which was just pulled)

Uhm, was it? I just added some unit tests though.

> interacts with pay-to-script-hash to make ECDSA denial-of-service
> attempts less expensive; I think we need to think hard again about
> transaction fees before releasing 0.6, and maybe tweak the fee policy
> so denial-of-service attacks using compressed public keys and 1-of-3
> CHECKMULTISIG transactions is expensive enough to deter would-be
> attackers.

Very true; compressed public keys are 32 bytes smaller (so more keys
fit in a script), and are about 5% more CPU intensive to verify.

-- 
Pieter