Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ucb11-00029K-Dg for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 12:41:07 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of lavabit.com designates 72.249.41.33 as permitted sender) client-ip=72.249.41.33; envelope-from=calebdelisle@lavabit.com; helo=karen.lavabit.com; Received: from karen.lavabit.com ([72.249.41.33]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Ucb10-00012c-FZ for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 12:41:07 +0000 Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id 1B71F11BB42 for ; Wed, 15 May 2013 07:41:01 -0500 (CDT) Received: from 192.168.1.3 (c-174-62-136-247.hsd1.ct.comcast.net [174.62.136.247]) by lavabit.com with ESMTP id 2GX5UH3U90NE for ; Wed, 15 May 2013 07:41:01 -0500 Message-ID: <5193825B.20909@lavabit.com> Date: Wed, 15 May 2013 08:40:59 -0400 From: Caleb James DeLisle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20130514115151.GA21600@netbook.cypherspace.org> <20130514140902.GA22447@netbook.cypherspace.org> <20130515102509.GA3401@netbook.cypherspace.org> <20130515111906.GA26020@savin> <20130515114956.GA5863@netbook.cypherspace.org> In-Reply-To: <20130515114956.GA5863@netbook.cypherspace.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 2.1 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [72.249.41.33 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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 X-Headers-End: 1Ucb10-00012c-FZ 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: Wed, 15 May 2013 12:41:07 -0000 I can't see this working, if 51% of the mining power doesn't like your coins, when you create the commitment they will reject it. If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap & ransom is effective. Suffice to say after the first >= $10mn kidnapping-for-bitcoin heist, governments will be forced to decide how they view the system. It will likely fall somewhere between "arrest/question anyone identified holding tainted coins" to something nonsensical and reactionary like "blocking" bitcoin as Iran does TOR. Thanks, Caleb On 05/15/2013 07:49 AM, Adam Back wrote: > On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote: >> Protocols aren't set in stone - any attacker that controls enough >> hashing power to pose a 51% attack can simply demand that you use a >> Bitcoin client modified [to facilitate evaluation of his policy] > > Protocol voting is a vote per user policy preference, not a CPU vote, which > is the point. Current bitcoin protocol is vulnerable to hard to prove > arbitrary policies being imposable by a quorum of > 50% miners. The blind > commitment proposal fixes that, so even an 99% quorum cant easily impose > policies, which leaves the weaker protocol vote attack as the remaining > avenue of attack. That is a significant qualitative improvement. > > The feasibility of protocol voting attacks is an open question, but you > might want to consider the seeming unstoppability of p2p protocols for a > hint. > > Adam > > ------------------------------------------------------------------------------ > 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 >