From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd39B-00016m-7W for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:47:57 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.172 as permitted sender) client-ip=209.85.217.172; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f172.google.com; Received: from mail-lb0-f172.google.com ([209.85.217.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd397-0001DR-DH for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:47:57 +0000 Received: by mail-lb0-f172.google.com with SMTP id c11so1203710lbj.17 for ; Wed, 23 Apr 2014 12:47:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.201.1 with SMTP id jw1mr2712974lbc.47.1398282466653; Wed, 23 Apr 2014 12:47:46 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 12:47:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 12:47:46 -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: 1Wd397-0001DR-DH 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 19:47:57 -0000 On Wed, Apr 23, 2014 at 12:19 PM, Mike Hearn wrote: > That's the definition of a Finney attack, right? A finney attack is where you attempt to mine a block with a transaction paying you, and as soon as you are successful you quickly make a transaction spending that coin to someone else, then release the block after they've taken an irreversible action. If everything is automated it should have something like a 99% success rate, though it has a cost of some small increase in the number of orphan blocks you experience. > I mean, I hope that's the definition of a Finney attack, given that I coi= ned > the term :) You might have coined the term, but I don't think the attack you're describing is the attack Hal described: https://bitcointalk.org/index.php?topic=3D3441.msg48384#msg48384 What you're talking about is just disagreement about the content of the memory pool, but we have no consensus mechanism there (the blockchain _is_ the consensus mechanism). Mempools are sometimes inconsistent all on their own, without any attacker being involved. > These sorts of proposals are all just ways of saying block chains kind of > suck and we should go back to using trusted third parties. I think thats an unsophisticated view. Consider this protocol. I take some of my funds and assign them to a 2 of 2 multisig with myself and Oscar. I do not announce this transaction until I get Oscar to sign a timelocked anyonecanpay refund to send the coin back to me (say in 3 months). Oscar gives me my refund and I announce the transaction. Later I can make instant payments with oscar signing up until the refund time comes clue to anyone who trusts Oscar to never double spend. For the receiver this is purely additive with regular blockchain security: in that even with Oscar's help I cannot double spend except where I would have been successful absent Oscar. On the sender side, Oscar cannot up and steal my funds and he can't try to extort me (except by creating a delay up to the refund time). Oscar himself can be implemented as a majority M parties to further increase confidence, though if you're talking about using this for low value retail transactions=E2=80=94 the fact that any cheating by oscar is cryptographically provable (just show them the double signatures) maybe be strong enough alone. (Though there is a multitude of other proposals to provide more evidence of Oscar's honesty). There are also ways to blind Oscar so he can't reliably identify which transactions are ones he signed for. I don't think this is at all a "return to trusted third parties"=E2=80=94 t= hat it's a shrug and an admission of defeat. Its a very narrowly scoped trust, filling in precisely where large scale decentralized consensus is fundamentally weak... the result is something which combines advantages from both classes and is stronger than either trust or blockchains alone. (I'm also not trying to say that an implementation of this is _simple_ by any means, working out all the details is hard.) By contrast, I think proposals which overly depend on colluding miners to behave in very specific ways are themselves just a way of saying block chains suck unless we turn the miners themselves into a trusted third party. I'm much more in favor of adding a little bit of mastercard to transactions where mastercard is really what people want, than turning mining=E2=80=94 and thus bitcoin itself=E2=80=94 into ma= stercard, especially since miners=E2=80=94 self selecting as they are=E2=80=94 are a = pretty poor set of parties to act as trusted agents. :) >> Doubly so because a 'nasty' party with non-trivial hash-power can >> doublespend their own transactions > If a miner is vertically integrated and defrauding merchants themselves, > with no service component, pretty quickly people would talk to each other= , > notice this pattern and stop trading with them, making their coins rather > useless. Also if their real identity is ever revealed they could be liabl= e > and there'd be a lot of people wanting to sue them. We have an existence proof that it isn't so=E2=80=94 you can say that it wasn't consistent enough, but what is? There wasn't any major doubt that they were actually doing it. They're the largest identifiable pool as we speak. I think, instead, that strong zero-conf security isn't a part of what many people think of when they think of Bitcoin's characteristics. Zero conf is risky, and I think for a lot of people thats okay. If it isn't there are ways to improve it that don't involve asking miners to participate in a majority vote to take away funds from people.