* [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions)
@ 2011-07-23 23:39 Gregory Maxwell
2011-08-03 6:10 ` bgroff
0 siblings, 1 reply; 4+ messages in thread
From: Gregory Maxwell @ 2011-07-23 23:39 UTC (permalink / raw)
To: Bitcoin Development
Pull 349 (https://github.com/bitcoin/bitcoin/pull/349)
implements a pretty nice implementation of multiple signature escrowed
transactions. Especially with clearcoin gone I think that this is
something we ought to have sooner rather than later.
I've tested it on a private network and it appears to work pretty well.
It probably needs more testing and discussion before it is actually
added to the client, but one challenge is that because it requires a
new transaction type it won't be deployable until _after_ an updated
isStandard is widely used in the network.
So I think that makes a good argument for separating out the
IsStandard part of the patch and getting it out in 0.4.
Unfortunately, the patch exposes an issue with multisig validation: If
I understand it correctly, the problem is that due to redundancy in
the script length coding opcodes it's possible to code a script
multiple ways. The signature validation code creates new template
scripts in order to evaluate signatures for one output, and the code
in bitcoin is not careful to code the new script the same way the
original one was coded, causing the signature validation to fail when
something used OP_PUSHDATA when a direct length could have been used.
Pull 349 (https://github.com/bitcoin/bitcoin/pull/349) contains one
candidate fix for this: Excluding the length opcodes from the
comparison.
This fix carries a risk of creating differences in how nodes validate
transactions leading to lasting forks. (e.g. Old clients will reject a
block which new clients would have accepted). I do also wonder about
strange effects arising from multiple valid TXN which are identical in
meaning but have different hashes, but I guess thats already possible
in a number of different ways.
Another way of fixing this would be to just define that OP_PUSHDATA*
_cannot_ be used to push the smaller lengths which could be more
efficiently encoded with the direct length opcodes. I think this
would have the benefit of being consistent with the current behavior
and carry no severe split risk.
Yet way of fixing it would be to change out the templating code works
to make sure it codes the template the same way the original was
coded. This seems tricky to implement to me, tricky to validate, but
it would potentially be beneficial if this same class of problem
exists for things other than the length coding.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions)
2011-07-23 23:39 [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions) Gregory Maxwell
@ 2011-08-03 6:10 ` bgroff
2011-08-04 20:35 ` Gregory Maxwell
0 siblings, 1 reply; 4+ messages in thread
From: bgroff @ 2011-08-03 6:10 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
Gregory Maxwell wrote:
> Pull 349 (https://github.com/bitcoin/bitcoin/pull/349)
> implements a pretty nice implementation of multiple signature escrowed
> transactions. Especially with clearcoin gone I think that this is
> something we ought to have sooner rather than later.
>
> I've tested it on a private network and it appears to work pretty well.
Thank you! (I think you mean 319 here)
> It probably needs more testing and discussion before it is actually
> added to the client, but one challenge is that because it requires a
> new transaction type it won't be deployable until _after_ an updated
> isStandard is widely used in the network.
With Eligius mining !IsStandard transactions and probably other pools open
to the idea, I am hopeful that we can quickly get 30%+ of mining power to
upgrade, which means that we could still mine these in a reasonable time
frame (under 1 hour).
...
> Unfortunately, the patch exposes an issue with multisig validation: If
> I understand it correctly, the problem is that due to redundancy in
> the script length coding opcodes it's possible to code a script
> multiple ways. The signature validation code creates new template
> scripts in order to evaluate signatures for one output, and the code
> in bitcoin is not careful to code the new script the same way the
> original one was coded, causing the signature validation to fail when
> something used OP_PUSHDATA when a direct length could have been used.
>
I'm not sure I see the problem here. CScript.operator<< currently inserts
values into scripts using the shortest possible sequence. As long as code
continues to conform to this convention, scripts generated by it will
verify correctly.
If new code is written that generates one of the longer sequences, it will
generate transactions that will not pass block validation since the
signature won't verify. So such code will be useless and we can refrain
from writing it?
--
Bobby Groff
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions)
2011-08-03 6:10 ` bgroff
@ 2011-08-04 20:35 ` Gregory Maxwell
2011-08-08 0:21 ` bgroff
0 siblings, 1 reply; 4+ messages in thread
From: Gregory Maxwell @ 2011-08-04 20:35 UTC (permalink / raw)
To: bgroff; +Cc: Bitcoin Development
On Wed, Aug 3, 2011 at 2:10 AM, <bgroff@lavabit•com> wrote:
> Thank you! (I think you mean 319 here)
Correct.
> With Eligius mining !IsStandard transactions and probably other pools open
> to the idea, I am hopeful that we can quickly get 30%+ of mining power to
> upgrade, which means that we could still mine these in a reasonable time
> frame (under 1 hour).
It's not just a matter of mining power, it's also a question of
propagation. Matt and I tried to perform a non-standard transaction
weeks ago and weren't able to get in mined after many hours. (we
eventually double spent the input with a normal transaction in order
to make it go away, interestingly one point about non-propagating txn
is that they're extra vulnerable to double spending by a standard txn,
as the non-standard one won't preclude the propagation of the standard
one)
From discussion on IRC it seemed clear enough that the current focus
on maturity/bugfixes is probably going to delay your full patch, but
the IsStandard part is uncontroversial and could go in quickly.
Based on that I think it would be very useful to split 319 into two
pull requests: one which does the IsStandard change, and one which
adds the full escrow feature set. This way when the escrow patch does
enter the mainline client it will be meet up with a network which is
happy to handle its transactions.
(and people who are eager to use escrow can use modified clients on
the main network before that point in time)
> I'm not sure I see the problem here. CScript.operator<< currently inserts
> values into scripts using the shortest possible sequence.
Ah for some reason I thought your current code did not always produce
the shortest sequence.
If so, I see no reason to block on the other pull.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions)
2011-08-04 20:35 ` Gregory Maxwell
@ 2011-08-08 0:21 ` bgroff
0 siblings, 0 replies; 4+ messages in thread
From: bgroff @ 2011-08-08 0:21 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
> On Wed, Aug 3, 2011 at 2:10 AM, <bgroff@lavabit•com> wrote:
>> Thank you! Â (I think you mean 319 here)
>
> Correct.
>
>> With Eligius mining !IsStandard transactions and probably other pools
>> open
>> to the idea, I am hopeful that we can quickly get 30%+ of mining power
>> to
>> upgrade, which means that we could still mine these in a reasonable time
>> frame (under 1 hour).
>
> It's not just a matter of mining power, it's also a question of
> propagation. Matt and I tried to perform a non-standard transaction
> weeks ago and weren't able to get in mined after many hours. (we
> eventually double spent the input with a normal transaction in order
> to make it go away, interestingly one point about non-propagating txn
> is that they're extra vulnerable to double spending by a standard txn,
> as the non-standard one won't preclude the propagation of the standard
> one)
Right, the user would have to connect directly to miners accepting
non-standard transactions.
> From discussion on IRC it seemed clear enough that the current focus
> on maturity/bugfixes is probably going to delay your full patch, but
> the IsStandard part is uncontroversial and could go in quickly.
With the latest high profile security breaches, I am hoping that the whole
things can be pulled relatively soon. Building secure deposit systems
will improve trust in the ecosystem.
I've included a significant amount of unit tests to "pay" for the
additional feature, and I can add more if needed.
--
Bobby Groff
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-08-08 0:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-23 23:39 [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions) Gregory Maxwell
2011-08-03 6:10 ` bgroff
2011-08-04 20:35 ` Gregory Maxwell
2011-08-08 0:21 ` bgroff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox