bgroff at lavabit.com [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-03 🗒️ Summary of this message: Bitcoin ...

📅 Original date posted:2011-08-03
🗒️ Summary of this message: Bitcoin developer Gregory Maxwell has proposed a new implementation of multiple signature escrowed transactions, which he believes should be added to the client sooner rather than later. The patch, which is still in testing, requires a new transaction type and will need more discussion before it is added to the client. However, Maxwell is hopeful that 30% of mining power will upgrade to the new transaction type in a reasonable timeframe. The patch has exposed an issue with multisig validation, but Maxwell believes this can be resolved by ensuring code conforms to the shortest possible sequence.
📝 Original message: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