public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: bgroff@lavabit•com
To: "Gregory Maxwell" <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions)
Date: Wed, 3 Aug 2011 02:10:47 -0400 (EDT)	[thread overview]
Message-ID: <43351.137.56.163.46.1312351847.squirrel@lavabit.com> (raw)
In-Reply-To: <CAAS2fgQ-L-1K2Oi40tqnhxpnnWQHqgbd4BmqedhA3WcevYiCzg@mail.gmail.com>

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






  reply	other threads:[~2011-08-03  6:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-23 23:39 Gregory Maxwell
2011-08-03  6:10 ` bgroff [this message]
2011-08-04 20:35   ` Gregory Maxwell
2011-08-08  0:21     ` bgroff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43351.137.56.163.46.1312351847.squirrel@lavabit.com \
    --to=bgroff@lavabit$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gmaxwell@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox