* [Bitcoin-development] Pull 748 pay to script hash
@ 2012-01-07 17:21 Amir Taaki
2012-01-07 22:48 ` Gavin Andresen
0 siblings, 1 reply; 5+ messages in thread
From: Amir Taaki @ 2012-01-07 17:21 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Pull 748 pay to script hash
2012-01-07 17:21 [Bitcoin-development] Pull 748 pay to script hash Amir Taaki
@ 2012-01-07 22:48 ` Gavin Andresen
2012-01-07 23:11 ` Amir Taaki
0 siblings, 1 reply; 5+ messages in thread
From: Gavin Andresen @ 2012-01-07 22:48 UTC (permalink / raw)
To: Amir Taaki; +Cc: Bitcoin Dev
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Pull 748 pay to script hash
2012-01-07 22:48 ` Gavin Andresen
@ 2012-01-07 23:11 ` Amir Taaki
2012-01-08 1:12 ` Gavin Andresen
0 siblings, 1 reply; 5+ messages in thread
From: Amir Taaki @ 2012-01-07 23:11 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Pull 748 pay to script hash
2012-01-07 23:11 ` Amir Taaki
@ 2012-01-08 1:12 ` Gavin Andresen
2012-01-08 16:12 ` Pieter Wuille
0 siblings, 1 reply; 5+ messages in thread
From: Gavin Andresen @ 2012-01-08 1:12 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Pull 748 pay to script hash
2012-01-08 1:12 ` Gavin Andresen
@ 2012-01-08 16:12 ` Pieter Wuille
0 siblings, 0 replies; 5+ messages in thread
From: Pieter Wuille @ 2012-01-08 16:12 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-08 16:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-07 17:21 [Bitcoin-development] Pull 748 pay to script hash Amir Taaki
2012-01-07 22:48 ` Gavin Andresen
2012-01-07 23:11 ` Amir Taaki
2012-01-08 1:12 ` Gavin Andresen
2012-01-08 16:12 ` Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox