Pull 748 pay to script hash

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.

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

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.

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

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.