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"><<a href=3D"mailto:gmaxwell@gmail.com" target= =3D"_blank">gmaxwell@gmail.com</a>></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> <<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandre= sen@gmail.com</a>> wrote:<br> > It seems to me the fastest path to very secure, very-hard-to-lose<br> > bitcoin wallets is multi-signature transactions.<br> ><br> > To organize this discussion: first, does everybody agree?<br> <br> </div>It's a good tool which we should have in our tool-belt.<br> <br> Though it'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> > ByteCoin pointed to a research paper that gives a scheme for splitting= <br> > a private key between two people, neither of which every knows the<br> </div>[snip]<br> <div>> So I'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> > I still think it is a good idea to enable a set of new 'standard&#= 39;<br> > multisignature transactions, so they get relayed and included into<br> > blocks. =A0I don't want to let "the perfect become the enemy = of the<br> > good" -- does anybody disagree?<br> <br> </div>I agree.<br> <div><br> > The arguments against are that if the proposed standard transactions<b= r> > are accepted, then the next step is to define a new kind of bitcoin<br= > > address that lets coins be deposited into a multisignature-protected<b= r> > wallet.<br> ><br> > 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.<br> ><br> > So, if we are going to have new releases that are incompatible with<br= > > old clients why not do things right in the first place, implement or<b= r> > enable opcodes so the new bitcoin addresses can be small, and schedule= <br> > 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'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's not exclusive, however, with a long N-address address type for<br> multisig destinations. =A0We could support that _now_ and defer the<br> 'compressed version' until after people have experience with this<b= r> usage. =A0The only cost would be supporting this address type forever,<br> which isn't that bad.<br> <br> It's also important to note that incompatibility wouldn't be comple= te:<br> The only limit is that old clients couldn'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'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--