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 1UcnqM-0002qc-5R for bitcoin-development@lists.sourceforge.net; Thu, 16 May 2013 02:22:58 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.45 as permitted sender) client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f45.google.com; Received: from mail-oa0-f45.google.com ([209.85.219.45]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UcnqK-0001js-Sc for bitcoin-development@lists.sourceforge.net; Thu, 16 May 2013 02:22:57 +0000 Received: by mail-oa0-f45.google.com with SMTP id j6so3134743oag.18 for ; Wed, 15 May 2013 19:22:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.240.136 with SMTP id wa8mr19191607obc.2.1368670971434; Wed, 15 May 2013 19:22:51 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.162.230 with HTTP; Wed, 15 May 2013 19:22:51 -0700 (PDT) In-Reply-To: References: <20130514115151.GA21600@netbook.cypherspace.org> <20130514140902.GA22447@netbook.cypherspace.org> <20130515102509.GA3401@netbook.cypherspace.org> <20130515111906.GA26020@savin> <20130515114956.GA5863@netbook.cypherspace.org> <5193825B.20909@lavabit.com> <20130515162129.GB6156@netbook.cypherspace.org> <20130515234030.GA17920@netbook.cypherspace.org> Date: Wed, 15 May 2013 19:22:51 -0700 X-Google-Sender-Auth: WycmANa9buLooiy1X2aW9WejvU4 Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e01634f0e1121a404dccc8b45 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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 X-Headers-End: 1UcnqK-0001js-Sc Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) 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: Thu, 16 May 2013 02:22:58 -0000 --089e01634f0e1121a404dccc8b45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Conceptually it sounds a lot like ZeroCoin (not in implementation)? I'm not really convinced miner cartels that try to exclude transactions are likely to be a big deal, but such schemes could I suppose be kept in a back pocket in case one day I'm proven wrong. On Wed, May 15, 2013 at 6:39 PM, Gregory Maxwell wrote= : > On Wed, May 15, 2013 at 6:24 PM, Gavin wrote: > > Busy with pre-conference stuff, not following details of this > conversation... > > > > ... but it sounds a lot like the "guy fawkes" protocol Zooko was > thinking about a year or so ago. > > Sort of, but in a guy fawkes signature you use the commitment to hide > the preimage that proves you had authority to spend a coin. Adam > proposes you do this in order to hide _which coin you're spending_. > > This has obvious anti-DOS complications, but Adam deftly dodged my > initial attempts to shoot him down on these grounds by pointing out > that you could mix blinded and blinded inputs and have priority and > transaction fees come from only the unblinded ones. > > Effectively, it means that so long as you could convince the network > to let you spend some coins, you could also spend other ones along for > the ride and the network wouldn't know which ones those were until it > was too late for it to pretend it never saw them. > > I think there are all kinds of weird economic implications to this=E2=80= =94 a > blinded payment would seem to have a different utility level to an > unblinded one: you can't use it for fees=E2=80=94 except you can unblind = it at > any time. And the discontinuousness ("two types of inputs") and that > it would enable mining gibberish (though perhaps not data storage, if > you see my preimage solution to that) seems awkward and I think I have > to spend some time internalizing it before I can really think through > the implications. > > > -------------------------------------------------------------------------= ----- > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --089e01634f0e1121a404dccc8b45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Conceptually it sounds a lot like ZeroCoin (not in impleme= ntation)?

I'm not really convinced miner cartels tha= t try to exclude transactions are likely to be a big deal, but such schemes= could I suppose be kept in a back pocket in case one day I'm proven wr= ong.


On Wed,= May 15, 2013 at 6:39 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
On Wed, May 15, 2013 at 6:= 24 PM, Gavin <gavinandresen@g= mail.com> wrote:
> Busy with pre-conference stuff, not following details of this conversa= tion...
>
> ... but it sounds a lot like the "guy fawkes" protocol Zooko= was thinking about a year or so ago.

Sort of, but in a guy fawkes signature you use the commitment to hide=
the preimage that proves you had authority to spend a coin. =C2=A0 Adam
proposes you do this in order to hide _which coin you're spending_.

This has obvious anti-DOS complications, but Adam deftly dodged my
initial attempts to shoot him down on these grounds by pointing out
that you could mix blinded and blinded inputs and have priority and
transaction fees come from only the unblinded ones.

Effectively, =C2=A0it means that so long as you could convince the network<= br> to let you spend some coins, you could also spend other ones along for
the ride and the network wouldn't know which ones those were until it was too late for it to pretend it never saw them.

I think there are all kinds of weird economic implications to this=E2=80=94= a
blinded payment would seem to have a different utility level to an
unblinded one: you can't use it for fees=E2=80=94 except you can unblin= d it at
any time. =C2=A0And the discontinuousness =C2=A0("two types of inputs&= quot;) and that
it would enable mining gibberish (though perhaps not data storage, if
you see my preimage solution to that) seems awkward and I think I have
to spend some time internalizing it before I can really think through
the implications.

---------------------------------------------------------------------------= ---
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial.
http://p.s= f.net/sfu/alienvault_d2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--089e01634f0e1121a404dccc8b45--