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 1WdHjd-0006BI-IO for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 11:22:33 +0000 Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdHjb-00025H-80 for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 11:22:33 +0000 Received: by mail-la0-f43.google.com with SMTP id c6so1890877lan.16 for ; Thu, 24 Apr 2014 04:22:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ItUysMc5MydtJjwAYtiq7BrEydpvrf86WihYTDnV2Is=; b=eHozHLEvUrW7um9Clax2vW3bSpoeI4WV7lWdW11HmGa6fse3w74yuv90njZnn40u2K hgITRxv8b3oPCDvoSH3rVxbfm1C9E7/UqAQpGfm6gcr7KSuBezhBU/YVCXYVEOCduo8H aKEKVpt+F5AstYwF5KdCNkFS6JvAGzb1jLk8uh8QunNOuqr10VjoSf2dOC2IlkbcSGGG Xe1JJpBWTp+XiQh0yR773aLrT8qzjRxvQNPmIsaqjUd5Sp36hMRFwDUtBL/8s7a2GeD4 qcVGjKWPFgFiG4RSU5ini/XWrgWc0FWCBl/4ptvY7t/AeOaM0swXQIM1Kz4ps2qg9h7e zLpQ== X-Gm-Message-State: ALoCoQlLhVKhMxbenPmkIBviBnowIIYIc0+XpPsautHGft+/FhRGe90Ns05xwcjsD8CRH9WahRkd MIME-Version: 1.0 X-Received: by 10.152.44.234 with SMTP id h10mr41750lam.68.1398338544517; Thu, 24 Apr 2014 04:22:24 -0700 (PDT) Received: by 10.112.185.4 with HTTP; Thu, 24 Apr 2014 04:22:24 -0700 (PDT) X-Originating-IP: [85.59.56.59] In-Reply-To: References: Date: Thu, 24 Apr 2014 13:22:24 +0200 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Mike Hearn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WdHjb-00025H-80 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: Thu, 24 Apr 2014 11:22:33 -0000 On 4/23/14, Mike Hearn wrote: >> I guess word "honest" might have different meanings, that can be a sourc= e >> of confusing. >> 1. Honest -- not trying to destroy bitcoin >> 2. Honest -- following rules which are not required by the protocol >> > > I'm using it in the same sense Satoshi used it. Honest miners work to > prevent double spends. That's the entire justification for their existenc= e. I thought the mechanism they used to prevent double-spends was proof of wor= k. Therefore dishonest miners where only those who mine on top of a block which is not the longest valid chain they've seen. To distinguish this definition from your own "honest miners are those who decide on double-spends by mining the transaction they saw first" definition I propose to give another new name to the later, instead of changing the definition of the former. So inside the group of honest miners we have some that decide on transactions based on reception times and others that simply maximize their revenue while respecting the protocol rules. I suggest "stupid miners" and "smart miners" respectively as more clear terms for what we're talking about here. > Miners that are deliberately trying to double spend are worse than useles= s. I completely disagree. Miner's proof of work makes transactions irreversible. Even if zero confirmation transactions weren't possible in a replace-by-fee environment, that's very useful. Even if you always had to wait for transactions to be confirmed with some irreversible proof of work (as described in Satoshi's whitepaper), it doesn't follow that "automatically resolves the Bitcoin experiment as a failure". I don't understand how can you conclude that. But in fact 0 conf txs are possible *precisely* using replace-by-fee, as described in the " 0 confirmation txs using replace-by-fee and game theory" thread. So that conclusion is definitely wrong. On your concrete proposal, it seems to me that you're trying to prevent double-spending without relying on proof of work, which I think it impossible in the context of a truly p2p system. I don't think your current proposal is secure and I fear that at best you will end up with an "invite only" transaction processing network like Ripple.com has with their consensus algorithm and Unique Node Lists: that's not really p2p. --=20 Jorge Tim=F3n http://freico.in/