Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WjiUd-0004zd-EL for bitcoin-development@lists.sourceforge.net; Mon, 12 May 2014 05:09:39 +0000 X-ACL-Warn: Received: from mail-pa0-f50.google.com ([209.85.220.50]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WjiUc-0001zF-6T for bitcoin-development@lists.sourceforge.net; Mon, 12 May 2014 05:09:39 +0000 Received: by mail-pa0-f50.google.com with SMTP id fb1so7646953pad.9 for ; Sun, 11 May 2014 22:09:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KNfNxv8aUslnMOgmdhZUMlT8vsMkwNBh+q1IV9y7Pqs=; b=KzewNOehNmDqc3kuDNLMBfEDav7gxFkaF4132FqVngMNKmGCpd8v6fPKRDASXqvBBC gFuiIR5ieyg61EKPFnjV2nGBhnVI9Oqyd/d0ifbFYNmn7nM/X2KEbJoB3E96PQXPq7Ur VTHydt7ZlNM6LUnJ5AM0HipzRf3BmA9lJhwSJgY4rVdJHItcNAIDvOay3vzUhVlRG3Uo XsaY3bzPJf9hMwaav68CLt4FGiFNXe2yd5BkP2e/nuM2Wojd6FPHsoMZ1Go+sWuf8/cT 8rXxJXuulZSNimcGeYSxJ1yFXCt1FaeVEQGXuQwG9AfPb8r6u4ye45yeC0CJWPGFuul6 dGPQ== X-Gm-Message-State: ALoCoQkpQksDmHIkdpDCU+KunTx4chV/Imi1yPgfF6uVbNPWOrnlnHBVs9xkxNHa7OHQLhJsTZNs X-Received: by 10.66.230.193 with SMTP id ta1mr50819792pac.29.1399869668134; Sun, 11 May 2014 21:41:08 -0700 (PDT) Received: from [192.168.1.89] (99-6-44-248.lightspeed.sntcca.sbcglobal.net. [99.6.44.248]) by mx.google.com with ESMTPSA id jd5sm20395752pbb.18.2014.05.11.21.41.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 May 2014 21:41:07 -0700 (PDT) Message-ID: <537050E0.2040008@thinlink.com> Date: Sun, 11 May 2014 21:41:04 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <536589CC.8080005@thinlink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 1WjiUc-0001zF-6T Subject: Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk 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: Mon, 12 May 2014 05:09:39 -0000 Christophe Biocca wrote: > The problem is that since the rule > isn't enforceable, no miner will wait before mining on the longest > chain (which is the rational move), and you're back to where we are > now. Back up to the miner who decided to include a "seasoned" double-spend in his block. Let's say he saw it 21 seconds after he saw an earlier spend, and included it, despite the rule. The expected cost of including the respend is any revenue loss from doing so: (total miner revenue of block)*(fraction of hashpower following the rule). So today, if only 1% of hashpower follows the rule (ie a near total failure of consensus implementation), he still loses at least .25 BTC. .25 BTC is about 1000x the typical "double-spend premium" I'm seeing right now. Wouldn't the greedy-rational miner just decide to include the earlier spend instead?