From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y9atE-0007VB-HF for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 14:50:16 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.176 as permitted sender) client-ip=209.85.223.176; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f176.google.com; Received: from mail-ie0-f176.google.com ([209.85.223.176]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y9atC-0007yN-M8 for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 14:50:16 +0000 Received: by mail-ie0-f176.google.com with SMTP id tr6so15341132ieb.7 for ; Fri, 09 Jan 2015 06:50:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.178.143 with SMTP id cy15mr2818449igc.8.1420815009373; Fri, 09 Jan 2015 06:50:09 -0800 (PST) Received: by 10.107.16.30 with HTTP; Fri, 9 Jan 2015 06:50:09 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Jan 2015 14:50:09 +0000 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 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 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Y9atC-0007yN-M8 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY 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: Fri, 09 Jan 2015 14:50:16 -0000 On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn wrote: > Additionally, there is a school of thought that says Bitcoin must work even > if lots of miners are malicious and willing to break arbitrary things in > order to try and get more money. I don't think Bitcoin can really be a This being unsafe doesn't require "a lot" though, if 1% of the hashpower is naughty, an attacker will have a 1% success rate. Naughty can also just mean broken in various ways, like mining while somewhat partitioned (didn't hear the update) potentially due to a DOS attack, or because of some garbage collection policy made it forget the transaction to conserve resources. An unkind user can simply run software that automatically attempts (by sending naughty miners an earlier conflict right before the locktime expires). "Use Blue Rewards wallet for 2% cash back for all the Bitcoin purchases you make online!" :P Of course, all the miners who don't play along will very much see how much income they're missing. > so clients can enforce that all versions have the same fee attached Sadly, they cannot. This is why I specifically mentioned child pays for parent. In any case, sometimes a 1% fault rate is acceptable. But generally for cases that they are, even weaker constructs (e.g. no payment channel at all, just accept an IOU) are also often acceptable, and cannot be modulated in their success by resource starvation attacks on the network. We have objective proof of substantial miners behaving maliciously, that much isn't a speculative concern. The school of thought view is a bit too black and white. My perspective is that absolute soundness is best (rules which cannot be broken at all), followed by cryptographic soundness (rules that breaking requires P=NP, theft of a secret, or insane luck), followed by economic soundness (rules that cannot be profitably broken), followed by honesty soundness (rules that hold when the participants follow the rules and aren't faulty). We should try to move up that stack as far towards absolutely soundness as possible; and be increasingly cautious about compromises as we move down it espeically because the last two are unstable and difficult to reason about because they strongly import the vulgarities of humanity into the security model. If we could make the whole system absolutely sound or cryptographically sound, I would think we should (and would) even if it implied other compromises. But we can't and so users of Bitcoin must navigate this risk stack. One thing that I think you miss in this argument is that one man's integrity is another man's malice. The history of security and privacy is filled with instances where someone's trust was violated because there someone was, rightly or wrongly, convinced that Some Reason was Good Enough to justify it. Because of this a risk analysis has to import the clarity of judgement, morality, coerceability, personal values, etc. of everyone in the trust chain; and many of these things are unknowable; this greatly increases the costs of transacting, and the efforts to mitigate those costs (and the failures to remove the harms) result in an unequitable enviroment where some people get unjust rewards and unequal access to justice. The gain from cryptographic tools is being able to make some level of stronger assurances which cut out most of that trust, they're predictable, 'cheap' on a marginal basis, and fair in a fundamental sense (in theory everyone has equal access to math). So, while I could even buy the argument that miners will never believe themselves to be "actually malicious", history shows that people's ability to convince themselves of the justification of something is basically unbounded, even outright thieves often believe they're owed their spoils-- and there are a lot of ways to misbehave in Bitcoin that stop short of theft. And so, where we cannot have cryptographic security enforce the rules, we-- those who use and depend on Bitcoin-- _generally_ ought to behave in ways that cannot be harmed by a failure to follow the rules so that we don't _invite_ failures to follow the rules and thereby create an institution of it. Of course, all things equal I don't want to choose for other people what tools they can use and what risks they take. But in the case of relaying locked transactions this isn't an otherwise neutral choice: A straight forward "relay and store any locked spend" policy has unbounded space and communications complexity. It's not clear to me that if any real degree of "you can take your risks, it'll probably work, but maybe not" can be supported without a very large resource cost to the network, and without creating incentives to DOS attack the network (e.g. to make it forget previous spends). It may be that there is some set of constraints that actually do make it workable and don't create the incentives though... meaning that it may _merely_ be unsafe for people who choose to use it. If so, then it might be reasonable but we also cannot ignore the incentives it creates in a wider ecosystem and what their ultimate conclusion might be. E.g. If you put a bounty for miners to behave 'wrong' in a way the system cannot prevent, some will. Is the next step to try to say that only "good" miners can mine? If so, how many more steps until every transaction is being tested against a set of system external goodness criteria? In that state, is Bitcoin any better than a very computationally and bandwidth inefficient version of Paypal? Slipper slope arguments can be a bit slippery. I don't have any clear answers. I do know that ignoring the risks we know about isn't a good path.