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 1QwLvD-0005e7-NM for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 22:27:43 +0000 X-ACL-Warn: Received: from mail-iy0-f171.google.com ([209.85.210.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QwLvC-0003zU-O6 for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 22:27:43 +0000 Received: by mail-iy0-f171.google.com with SMTP id 13so3042842iyf.30 for ; Wed, 24 Aug 2011 15:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.251.214 with SMTP id mt22mr11284091ibb.9.1314224862608; Wed, 24 Aug 2011 15:27:42 -0700 (PDT) Sender: mith@jrbobdobbs.org Received: by 10.42.167.10 with HTTP; Wed, 24 Aug 2011 15:27:42 -0700 (PDT) Received: by 10.42.167.10 with HTTP; Wed, 24 Aug 2011 15:27:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 17:27:42 -0500 X-Google-Sender-Auth: wbNbFJW1wsQVHJFv0naUF60LE6I Message-ID: From: Douglas Huff To: Gregory Maxwell Content-Type: multipart/alternative; boundary=0015175cab96173be304ab47d247 X-Spam-Score: 1.0 (+) 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 X-Headers-End: 1QwLvC-0003zU-O6 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 22:27:43 -0000 --0015175cab96173be304ab47d247 Content-Type: text/plain; charset=ISO-8859-1 On Aug 24, 2011 3:29 PM, "Gregory Maxwell" wrote: > > On Wed, Aug 24, 2011 at 3:05 PM, Christian Decker > wrote: > > 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. > > This works fine for ECC. But it requires that the composite key > signer has simultaneous access to all the key-parts, so it doesn't > solve the "my PC has malware" problem. I don't think anything simple enough to actually be used by people in general does. Same concept as what I proposed earlier before nanotube gave me the context for Gavin's intent on irc. Now that I'm understanding the use case I really think the best way to go about this initially is like you said earlier. Provide methods to export/import unsigned txns, provide methods to run the GUI in a way that can track your own addresses with only pubkeys available to the client, provide methods to sign and import/export/broadcast signed txns. With these tools offline wallets become feasible. Combined with wallet crypto I think this is really the best that can be done to protect users from themselves in a way that isn't too complicated for them to actually use. --0015175cab96173be304ab47d247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 24, 2011 3:29 PM, "Gregory Maxwell" <gmaxwell@gmail.com> wrote:
>
> On Wed, Aug 24, 2011 at 3:05 PM, Christian Decker
> <decker.christian@gma= il.com> wrote:
> > we could add an rsa-like scheme which allows m-out-of-n signature= s. It works
> > by distributing shares of the key which are points on a curve hav= ing 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= .
>
> This works fine for ECC. =A0But it requires that the composite key
> signer has simultaneous access to all the key-parts, so it doesn't=
> solve the "my PC has malware" problem.

I don't think anything simple enough to actually be used by people = in general does. Same concept as what I proposed earlier before nanotube ga= ve me the context for Gavin's intent on irc.

Now that I'm understanding the use case I really think the best way = to go about this initially is like you said earlier.

Provide methods to export/import unsigned txns, provide methods to run t= he GUI in a way that can track your own addresses with only pubkeys availab= le to the client, provide methods to sign and import/export/broadcast signe= d txns.

With these tools offline wallets become feasible. Combined with wallet c= rypto I think this is really the best that can be done to protect users fro= m themselves in a way that isn't too complicated for them to actually u= se.

--0015175cab96173be304ab47d247--