Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd3v4-0008Dh-TZ for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:37:26 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.53 as permitted sender) client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f53.google.com; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd3v3-0002wH-VL for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:37:26 +0000 Received: by mail-oa0-f53.google.com with SMTP id j17so1615780oag.40 for ; Wed, 23 Apr 2014 13:37:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.132.236 with SMTP id ox12mr2366237oeb.81.1398285440691; Wed, 23 Apr 2014 13:37:20 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 13:37:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 22:37:20 +0200 X-Google-Sender-Auth: eFBmy1ncFLtufT-q9MwAzMbCPCM Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b41cd28fcb77104f7bbb251 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: 1Wd3v3-0002wH-VL Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks 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, 23 Apr 2014 20:37:27 -0000 --047d7b41cd28fcb77104f7bbb251 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell wrote: > Right, this works in the Bitcoin network today absent any collusion by > the miners. You give one miner a transaction and you give every other > node you can reach another transaction. > Yes, but that can be fixed with double spend alerts. > Someone you ask to not double spend is an entirely separate matter. > They aren't self-selecting: you select who you trust to not make > double spends and there is no need for this trust to be globally > consistent. > No? It's not just your decision that matters, the receiver also has to trust them. They're like a dispute mediator in this regard. You can pick whoever you want, but that doesn't matter if the receiver doesn't recognise them or trust them. You have to find an overlap to make an instant trade. In practice if people have to think about this, evaluate brands etc then you'd get a very small number of parties because the value of global agreement is so high. Then it becomes hard to remove ones that have a lot of momentum. The censorship resistance of the block chain doesn't matter if your double spending partners refuse to help you spend your money (because they're being coerced). The censorship can just happen at a different place. > To stop GHash.io we would have to take away their hardware or change the > Bitcoin > protocol to make their hardware useless > ..... or, have a majority decide to zero out their coinbase rewards for blocks that double spent against dice sites. That wouldn't undo the double spend, but you can't do that with the multisig scheme either. All you can do is punish the corrupted party post-hoc, either by not using them again, or by "unpaying" them for the service they did not provide. --047d7b41cd28fcb77104f7bbb251 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell@gmail.com>= wrote:
Right, this works in the Bit= coin network today absent any collusion by
the miners. You give one miner a transaction and you give every other
node you can reach another transaction.

Yes, but that can be fixed with double spend alerts.
=C2=A0
Someone you ask to not double spend is an entirely separate= matter.
They aren't self-selecting: you select who you trust to not make
double spends and there is no need for this trust to be globally
consistent.

No? It's not just your = decision that matters, the receiver also has to trust them. They're lik= e a dispute mediator in this regard. You can pick whoever you want, but tha= t doesn't matter if the receiver doesn't recognise them or trust th= em. You have to find an overlap to make an instant trade.

In practice if people have to think about this, evaluat= e brands etc then you'd get a very small number of parties because the = value of global agreement is so high. Then it becomes hard to remove ones t= hat have a lot of momentum.

The censorship resistance of the block chain doesn'= t matter if your double spending partners refuse to help you spend your mon= ey (because they're being coerced). The censorship can just happen at a= different place.
=C2=A0
To stop GHash.io=C2=A0we wo= uld have to take away their hardware or change the Bitcoin
protocol to make their hardware useless
=C2=A0
..... or, have a majority decide to zero out their coinbase rewards for = blocks that double spent against dice sites. That wouldn't undo the dou= ble spend, but you can't do that with the multisig scheme either. All y= ou can do is punish the corrupted party post-hoc, either by not using them = again, or by "unpaying" them for the service they did not provide= .

--047d7b41cd28fcb77104f7bbb251--