Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QwIlq-0003Jp-Hj for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 19:05:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.42 as permitted sender) client-ip=209.85.210.42; envelope-from=decker.christian@gmail.com; helo=mail-pz0-f42.google.com; Received: from mail-pz0-f42.google.com ([209.85.210.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QwIlp-0006DP-FY for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 19:05:50 +0000 Received: by pzk37 with SMTP id 37so1152328pzk.1 for ; Wed, 24 Aug 2011 12:05:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.217.3 with SMTP id p3mr2713488wfg.166.1314212743448; Wed, 24 Aug 2011 12:05:43 -0700 (PDT) Received: by 10.68.54.163 with HTTP; Wed, 24 Aug 2011 12:05:42 -0700 (PDT) Received: by 10.68.54.163 with HTTP; Wed, 24 Aug 2011 12:05:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 21:05:42 +0200 Message-ID: From: Christian Decker To: Gavin Andresen Content-Type: multipart/alternative; boundary=000e0cd22f68bb8a7804ab44ff76 X-Spam-Score: 0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QwIlp-0006DP-FY 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 19:05:50 -0000 --000e0cd22f68bb8a7804ab44ff76 Content-Type: text/plain; charset=ISO-8859-1 Sorry for keeping this short but I'm in holiday and reading/writing on my phone is a pain. On Aug 24, 2011 4:12 PM, "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 great way for companies to secure their assets. > > ByteCoin pointed to a research paper that gives a scheme for splitting > a private key between two people, neither of which every knows the > full key, but, together, both can DSA-sign transactions. That's very > cool, but it involves high-end cutting-edge crypto like zero-knowledge > proofs that I know very little about (are implementations available? > are they patented? have they been thoroughly vetted/tested? etc). > So I'm assuming that is NOT the fastest way to solving the problem. > > If anybody has some open-source, patent-free, thoroughly-tested code > that already does DSA-key-splitting, speak up please. Since. we have the possibility o add other signature schemes to the protocol we could add an rsa-like scheme which allows m-out-of-n signatures. It works by distributing shares of the key which are points on a curve having the actual key as 0-value. It does not require special length for the key so if ecdsa allows something similar there need not be anything changed. > > I've been trying to get consensus on low-level 'standard' transactions > for transactions that must be signed by 2 or 3 keys; current draft > proposal is here: > https://gist.github.com/39158239e36f6af69d6f > and discussion on the forums here: > https://bitcointalk.org/index.php?topic=38928.0 > ... and there is a pull request that is relevant here: > https://github.com/bitcoin/bitcoin/pull/319 > > > 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? Would be a first step. > > 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. > > My biggest worry is we'll say "Sure, it'll only take a couple days to > agree on how to do it right" and six months from now there is still no > consensus on exactly which digest function should be used, or whether > or not there should be a new opcode for arbitrary boolean expressions > involving keypairs. And people's wallets continue to get lost or > stolen. > > Just wanted to point you in that alternative direction as it would possibly keep backward compatibility and allow multisignature. Regards, Chris > > -- > -- > Gavin Andresen > > ------------------------------------------------------------------------------ > 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 --000e0cd22f68bb8a7804ab44ff76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sorry for keeping this short but I'm in holiday and reading/writing = on my phone is a pain.

On Aug 24, 2011 4:12 PM, "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 great way for companies to secure their assets.

>
> ByteCoin pointed to a research paper that gives a scheme for splitting=
> a private key between two people, neither of which every knows the
> full key, but, together, both can DSA-sign transactions. =A0That's= very
> cool, but it involves high-end cutting-edge crypto like zero-knowledge=
> proofs that I know very little about (are implementations available? > are they patented? =A0have they been thoroughly vetted/tested? =A0etc)= .
> So I'm assuming that is NOT the fastest way to solving the problem= .
>
> If anybody has some open-source, patent-free, thoroughly-tested code > that already does DSA-key-splitting, speak up please.
Since. we have the possibility o add other signature schemes to the protoco= l we could add an rsa-like scheme which allows m-out-of-n signatures. It wo= rks by distributing shares of the key which are points on a curve having th= e actual key as 0-value. It does not require special length for the key so = if ecdsa allows something similar there need not be anything changed.
>
> I've been trying to get consensus on low-level 'standard' = transactions
> for transactions that must be signed by 2 or 3 keys; current draft
> proposal is here:
> =A0https://gi= st.github.com/39158239e36f6af69d6f
> and discussion on the forums here:
> =A0https= ://bitcointalk.org/index.php?topic=3D38928.0
> ... and there is a pull request that is relevant here:
> =A0https://git= hub.com/bitcoin/bitcoin/pull/319
>
>
> 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?

Would be a first step.
>
> 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.
>
> My biggest worry is we'll say "Sure, it'll only take a co= uple days to
> agree on how to do it right" and six months from now there is sti= ll no
> consensus on exactly which digest function should be used, or whether<= br> > or not there should be a new opcode for arbitrary boolean expressions<= br> > involving keypairs. =A0And people's wallets continue to get lost o= r
> stolen.
>
>

Just wanted to point you in that alternative direction as it would possi= bly keep backward compatibility and allow multisignature.

Regards,
Chris
>
> --
> --
> Gavin Andresen
>
> ----------------------------------------------------------------------= --------
> 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.s= f.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development=

--000e0cd22f68bb8a7804ab44ff76--