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 <rick.wesson@iidf.org>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAAS2fgS+YLf3hP+VbMiQAZ8S7fNrno1g6pi33825MFWiTg7=4A@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
	<CAAS2fgS+YLf3hP+VbMiQAZ8S7fNrno1g6pi33825MFWiTg7=4A@mail.gmail.com>
Date: Wed, 24 Aug 2011 08:55:41 -0700
Message-ID: <CAJ1JLtuukHSPOamKFbexjRMC=Gs2pt=hbgbhthM7-eG9YQoBcg@mail.gmail.com>
From: Rick Wesson <rick@support-intelligence.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <gmaxwell@gmail.com> wrote=
:

> On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen
> <gavinandresen@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.  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

<br><br><div class=3D"gmail_quote">On Wed, Aug 24, 2011 at 8:45 AM, Gregory=
 Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=
=3D"_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div>On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen<br>
&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandre=
sen@gmail.com</a>&gt; wrote:<br>
&gt; It seems to me the fastest path to very secure, very-hard-to-lose<br>
&gt; bitcoin wallets is multi-signature transactions.<br>
&gt;<br>
&gt; To organize this discussion: first, does everybody agree?<br>
<br>
</div>It&#39;s a good tool which we should have in our tool-belt.<br>
<br>
Though it&#39;s a bit of when you are a hammer all problems are nails.<br>
This issue can also be addressed by things like external private key<br>
protectors. =A0But someone would have to build one.<br>
<br>
Someone might be more inclined to build such a thing if the software<br>
had good support for tracking public keys without private keys, and<br>
generating unsigned transactions for export to the device for signing.<br>
<div><br>
&gt; ByteCoin pointed to a research paper that gives a scheme for splitting=
<br>
&gt; a private key between two people, neither of which every knows the<br>
</div>[snip]<br>
<div>&gt; So I&#39;m assuming that is NOT the fastest way to solving the pr=
oblem.<br>
<br>
</div>Regardless, it might be useful to contact the authors.<br>
<div><br>
&gt; I still think it is a good idea to enable a set of new &#39;standard&#=
39;<br>
&gt; multisignature transactions, so they get relayed and included into<br>
&gt; blocks. =A0I don&#39;t want to let &quot;the perfect become the enemy =
of the<br>
&gt; good&quot; -- does anybody disagree?<br>
<br>
</div>I agree.<br>
<div><br>
&gt; The arguments against are that if the proposed standard transactions<b=
r>
&gt; are accepted, then the next step is to define a new kind of bitcoin<br=
>
&gt; address that lets coins be deposited into a multisignature-protected<b=
r>
&gt; wallet.<br>
&gt;<br>
&gt; And those new as-yet-undefined bitcoin addresses will have to be 2 or<=
br>
&gt; 3 times as big as current bitcoin addresses, and will be incompatible<=
br>
&gt; with old clients.<br>
&gt;<br>
&gt; So, if we are going to have new releases that are incompatible with<br=
>
&gt; old clients why not do things right in the first place, implement or<b=
r>
&gt; enable opcodes so the new bitcoin addresses can be small, and schedule=
<br>
&gt; a block chain split for N months from now.<br>
<br>
</div>One way of doing this would be to have an address which hashes an<br>
ordered concatenation of many addresses (perhaps plus a length<br>
argument). To redeem you provide the public keys which are signing,<br>
plus the addresses which aren&#39;t signing, and the receiver validates.<br=
>
<br>
If it can be done, then yes, I agree it would be worth forking the chain.<b=
r>
<br>
This _feels_ like something which could and should be done with the<br>
existing (but disabled opcodes).<br>
<br>
<br>
It&#39;s not exclusive, however, with a long N-address address type for<br>
multisig destinations. =A0We could support that _now_ and defer the<br>
&#39;compressed version&#39; until after people have experience with this<b=
r>
usage. =A0The only cost would be supporting this address type forever,<br>
which isn&#39;t that bad.<br>
<br>
It&#39;s also important to note that incompatibility wouldn&#39;t be comple=
te:<br>
The only limit is that old clients couldn&#39;t send funds to escrow<br>
addresses=97 which is an issue no matter how you encode the information.<br=
>
<div><div></div><div><br>
---------------------------------------------------------------------------=
---<br>
EMC VNX: the world&#39;s simplest storage, starting under $10K<br>
The only unified storage solution that offers unified management<br>
Up to 160% more powerful than alternatives and 25% more efficient.<br>
Guaranteed. <a href=3D"http://p.sf.net/sfu/emc-vnx-dev2dev" target=3D"_blan=
k">http://p.sf.net/sfu/emc-vnx-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br>

--bcaec51a89701d72d504ab425831--