Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd3iL-0003Y3-54 for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:24:17 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.178 as permitted sender) client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f178.google.com; Received: from mail-lb0-f178.google.com ([209.85.217.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd3iK-0004VN-5X for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:24:17 +0000 Received: by mail-lb0-f178.google.com with SMTP id s7so1229384lbd.37 for ; Wed, 23 Apr 2014 13:24:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.7.8 with SMTP id f8mr3201055laa.39.1398284649575; Wed, 23 Apr 2014 13:24:09 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 13:24:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 13:24:09 -0700 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1Wd3iK-0004VN-5X 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:24:17 -0000 On Wed, Apr 23, 2014 at 12:59 PM, Mike Hearn wrote: >> What you're talking about is just disagreement about the content of >> the memory pool > That's the same thing. Whilst you're mining your double spend tx, it's in > your mempool but you don't broadcast it as per normal. Then when you find > the block you broadcast it to override everyone elses mempool. So yours a= nd > theirs were inconsistent. The difference is when you transact. In the attack Hal described you transact with your victim only after finding a block but before announcing it. > don't know if they inform you when they found a block (probably not), so = you > have to do the purchase and then hope BitUndo finds the next block. 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. You then hope your selected miner finds the next block and 'undoes' the transaction you gave the rest of the network. > This just brings us back to square one. Who are these parties and what if= I > pay them to be corrupt? What if they offer to be corrupt as a service? > > Let's say I succeed in finding some parties who are incorruptible no matt= er > how large of a percentage I offer them. At this point, why bother with > miners at all? Why pay for double spend protection twice, once to a group= of > Oscar's who are trustworthy and once to a group of miners who are not? > > The point of the broadcast network and mining is so there can be lots of > Oscar's and I don't have to know who they are or sign up with them or put > any effort into evaluating their reputation. But it isn't at all the same thing. Miners select themselves based on controlling hash-power. You can distrust a miner all you like but all your distrust does not prevent him from participating in the consensus, potentially to your detriment. Moreover, the set of miners has to be the same for everyone or otherwise the network doesn't converge. There are miners I _know_ to be scoundrels, but there is nothing I can do about it. 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. If they behave in an untrustworthy way you can instantly stop honoring them because the bad action is provable beyond any doubt and never trust them again (unlike mempool consistency)... and you can do this even if everyone else is too foolish to do so for some reason. The trustworthness of oscars needs only be limited and is different in kind from the kind of 'trust' we need over the history=E2=80=94 they arbitrating over the ordering of some subset of transactions right at the tip of the chain, and only those transaction of people who have specifically chosen to use them, of lower value transactions where you need instant settlement. Why pay twice? Because you're actually getting a different part of your security from each, and the result is additive. There is no such thing as an uncorruptable party, invoking that is a useless strawman. Instead we can consider how difficult the corruption is and what can happen if they're corrupted and hope to balance the risks and the controls for those risks. Any self-selectingness as anonymity (in the not-previously-enumerated sense) of mining is important for censorship security but it's terrible for other things like getting reliable mempool behavior. > But as you point out, cheating my GHash.io did not result in any obvious > negative consequence to them, despite that preventing double spending is > their sole task. Why would Oscar be different to GHash.io? Because you can choose to stop trusting an oscar while you=E2=80=94 individually=E2=80=94 can't choose anything about ghash.io. To stop GHash.= io we would have to take away their hardware or change the Bitcoin protocol to make their hardware useless, and in the latter case we'd _all_ have to agree to do this not just some (perhaps quite large) subset of us who doesn't want to trust them, and even though it is quite apparent what they did there is still some room to claim doubt. > Trying to solve the problem of dishonest miners is effectively trying to > solve the "automatically find trusted third parties" problem at scale. Mining is universal=E2=80=94 everyone must use the same miners, trust seldo= m is seldom universal and shouldn't be. The trust we have in mining is exceptionally limited, I think any effort to increase it is doomed to fail=E2=80=94 both because trust heavy systems stink, because mining is a b= ad fit for trust, and because increasing the requirements create other exposures and vulnerabilities.