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; 
MIME-Version: 1.0
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
Date: Wed, 24 Aug 2011 21:05:42 +0200
Message-ID: <CALxbBHXAcRse9YE-evKNmDut684vjkUMHkbx+8E+aTNT5wMg5A@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=000e0cd22f68bb8a7804ab44ff76
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
 schedule a blockchain split?
Precedence: list

--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" <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.  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

<p>Sorry for keeping this short but I&#39;m in holiday and reading/writing =
on my phone is a pain.</p>
<p>On Aug 24, 2011 4:12 PM, &quot;Gavin Andresen&quot; &lt;<a href=3D"mailt=
o:gavinandresen@gmail.com">gavinandresen@gmail.com</a>&gt; wrote:<br>
&gt;<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>
It&#39;s a great way for companies to secure their assets.</p>
<p>&gt;<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>
&gt; full key, but, together, both can DSA-sign transactions. =A0That&#39;s=
 very<br>
&gt; cool, but it involves high-end cutting-edge crypto like zero-knowledge=
<br>
&gt; proofs that I know very little about (are implementations available?<b=
r>
&gt; are they patented? =A0have they been thoroughly vetted/tested? =A0etc)=
.<br>
&gt; So I&#39;m assuming that is NOT the fastest way to solving the problem=
.<br>
&gt;<br>
&gt; If anybody has some open-source, patent-free, thoroughly-tested code<b=
r>
&gt; that already does DSA-key-splitting, speak up please.<br>
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.<br>

&gt;<br>
&gt; I&#39;ve been trying to get consensus on low-level &#39;standard&#39; =
transactions<br>
&gt; for transactions that must be signed by 2 or 3 keys; current draft<br>
&gt; proposal is here:<br>
&gt; =A0<a href=3D"https://gist.github.com/39158239e36f6af69d6f">https://gi=
st.github.com/39158239e36f6af69d6f</a><br>
&gt; and discussion on the forums here:<br>
&gt; =A0<a href=3D"https://bitcointalk.org/index.php?topic=3D38928.0">https=
://bitcointalk.org/index.php?topic=3D38928.0</a><br>
&gt; ... and there is a pull request that is relevant here:<br>
&gt; =A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/319">https://git=
hub.com/bitcoin/bitcoin/pull/319</a><br>
&gt;<br>
&gt;<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?</p>
<p>Would be a first step. <br>
&gt;<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>
&gt;<br>
&gt; My biggest worry is we&#39;ll say &quot;Sure, it&#39;ll only take a co=
uple days to<br>
&gt; agree on how to do it right&quot; and six months from now there is sti=
ll no<br>
&gt; consensus on exactly which digest function should be used, or whether<=
br>
&gt; or not there should be a new opcode for arbitrary boolean expressions<=
br>
&gt; involving keypairs. =A0And people&#39;s wallets continue to get lost o=
r<br>
&gt; stolen.<br>
&gt;<br>
&gt;</p>
<p>Just wanted to point you in that alternative direction as it would possi=
bly keep backward compatibility and allow multisignature.</p>
<p>Regards,<br>
Chris<br>
&gt;<br>
&gt; --<br>
&gt; --<br>
&gt; Gavin Andresen<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; EMC VNX: the world&#39;s simplest storage, starting under $10K<br>
&gt; The only unified storage solution that offers unified management<br>
&gt; Up to 160% more powerful than alternatives and 25% more efficient.<br>
&gt; Guaranteed. <a href=3D"http://p.sf.net/sfu/emc-vnx-dev2dev">http://p.s=
f.net/sfu/emc-vnx-dev2dev</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>=
<br>
</p>

--000e0cd22f68bb8a7804ab44ff76--