Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QwFnw-0008LE-8x for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 15:55:48 +0000 X-ACL-Warn: Received: from mail-yx0-f175.google.com ([209.85.213.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QwFnv-0001Nb-1M for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 15:55:48 +0000 Received: by yxl11 with SMTP id 11so1198363yxl.34 for ; Wed, 24 Aug 2011 08:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.60.133 with SMTP id ws5mr4107620icb.288.1314201341358; Wed, 24 Aug 2011 08:55:41 -0700 (PDT) Received: by 10.42.244.130 with HTTP; Wed, 24 Aug 2011 08:55:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 08:55:41 -0700 Message-ID: From: Rick Wesson To: Gregory Maxwell Content-Type: multipart/alternative; boundary=bcaec51a89701d72d504ab425831 X-Spam-Score: 1.5 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QwFnv-0001Nb-1M Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:55:48 -0000 --bcaec51a89701d72d504ab425831 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 8:45 AM, Gregory Maxwell wrote= : > On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen > wrote: > > It seems to me the fastest path to very secure, very-hard-to-lose > > bitcoin wallets is multi-signature transactions. > > > > To organize this discussion: first, does everybody agree? > > It's a good tool which we should have in our tool-belt. > > Though it's a bit of when you are a hammer all problems are nails. > This issue can also be addressed by things like external private key > protectors. But someone would have to build one. > > Someone might be more inclined to build such a thing if the software > had good support for tracking public keys without private keys, and > generating unsigned transactions for export to the device for signing. > > > ByteCoin pointed to a research paper that gives a scheme for splitting > > a private key between two people, neither of which every knows the > [snip] > > So I'm assuming that is NOT the fastest way to solving the problem. > > Regardless, it might be useful to contact the authors. > > > I still think it is a good idea to enable a set of new 'standard' > > multisignature transactions, so they get relayed and included into > > blocks. I don't want to let "the perfect become the enemy of the > > good" -- does anybody disagree? > > I agree. > > > The arguments against are that if the proposed standard transactions > > are accepted, then the next step is to define a new kind of bitcoin > > address that lets coins be deposited into a multisignature-protected > > wallet. > > > > And those new as-yet-undefined bitcoin addresses will have to be 2 or > > 3 times as big as current bitcoin addresses, and will be incompatible > > with old clients. > > > > So, if we are going to have new releases that are incompatible with > > old clients why not do things right in the first place, implement or > > enable opcodes so the new bitcoin addresses can be small, and schedule > > a block chain split for N months from now. > > One way of doing this would be to have an address which hashes an > ordered concatenation of many addresses (perhaps plus a length > argument). To redeem you provide the public keys which are signing, > plus the addresses which aren't signing, and the receiver validates. > > If it can be done, then yes, I agree it would be worth forking the chain. > > This _feels_ like something which could and should be done with the > existing (but disabled opcodes). > > > It's not exclusive, however, with a long N-address address type for > multisig destinations. We could support that _now_ and defer the > 'compressed version' until after people have experience with this > usage. The only cost would be supporting this address type forever, > which isn't that bad. > > It's also important to note that incompatibility wouldn't be complete: > The only limit is that old clients couldn't send funds to escrow > addresses=97 which is an issue no matter how you encode the information. > > > -------------------------------------------------------------------------= ----- > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --bcaec51a89701d72d504ab425831 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 8:45 AM, Gregory= Maxwell <gmaxwell@gmail.com> wrote:
On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen
<gavinandre= sen@gmail.com> wrote:
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
>
> To organize this discussion: first, does everybody agree?

It's a good tool which we should have in our tool-belt.

Though it's a bit of when you are a hammer all problems are nails.
This issue can also be addressed by things like external private key
protectors. =A0But someone would have to build one.

Someone might be more inclined to build such a thing if the software
had good support for tracking public keys without private keys, and
generating unsigned transactions for export to the device for signing.

> ByteCoin pointed to a research paper that gives a scheme for splitting=
> a private key between two people, neither of which every knows the
[snip]
> So I'm assuming that is NOT the fastest way to solving the pr= oblem.

Regardless, it might be useful to contact the authors.

> I still think it is a good idea to enable a set of new 'standard&#= 39;
> multisignature transactions, so they get relayed and included into
> blocks. =A0I don't want to let "the perfect become the enemy = of the
> good" -- does anybody disagree?

I agree.

> The arguments against are that if the proposed standard transactions > are accepted, then the next step is to define a new kind of bitcoin > address that lets coins be deposited into a multisignature-protected > wallet.
>
> And those new as-yet-undefined bitcoin addresses will have to be 2 or<= br> > 3 times as big as current bitcoin addresses, and will be incompatible<= br> > with old clients.
>
> So, if we are going to have new releases that are incompatible with > old clients why not do things right in the first place, implement or > enable opcodes so the new bitcoin addresses can be small, and schedule=
> a block chain split for N months from now.

One way of doing this would be to have an address which hashes an
ordered concatenation of many addresses (perhaps plus a length
argument). To redeem you provide the public keys which are signing,
plus the addresses which aren't signing, and the receiver validates.
If it can be done, then yes, I agree it would be worth forking the chain.
This _feels_ like something which could and should be done with the
existing (but disabled opcodes).


It's not exclusive, however, with a long N-address address type for
multisig destinations. =A0We could support that _now_ and defer the
'compressed version' until after people have experience with this usage. =A0The only cost would be supporting this address type forever,
which isn't that bad.

It's also important to note that incompatibility wouldn't be comple= te:
The only limit is that old clients couldn't send funds to escrow
addresses=97 which is an issue no matter how you encode the information.

---------------------------------------------------------------------------= ---
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--bcaec51a89701d72d504ab425831--