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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xbazz-0001vv-Qk for bitcoin-development@lists.sourceforge.net; Tue, 07 Oct 2014 20:04:43 +0000 X-ACL-Warn: Received: from p3plsmtpa12-08.prod.phx3.secureserver.net ([68.178.252.237]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Xbazy-0004tF-Rk for bitcoin-development@lists.sourceforge.net; Tue, 07 Oct 2014 20:04:43 +0000 Received: from [192.168.0.23] ([201.231.95.129]) by p3plsmtpa12-08.prod.phx3.secureserver.net with id 0L4b1p0022nUpUh01L4cYe; Tue, 07 Oct 2014 13:04:37 -0700 Message-ID: <54344751.708@certimix.com> Date: Tue, 07 Oct 2014 17:04:33 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 CC: bitcoin-development References: <543438E4.8080501@certimix.com> <54343948.1030400@certimix.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [68.178.252.237 listed in list.dnswl.org] 1.2 MISSING_HEADERS Missing To: header X-Headers-End: 1Xbazy-0004tF-Rk Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) 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: Tue, 07 Oct 2014 20:04:44 -0000 On 07/10/2014 04:16 p.m., Gregory Maxwell wrote: > Then I spend the output of the fraudulent spend nlocked > one block higher, and spend the output of that one again, nlocked one > block higher, and so on... each step paying fees. Yes, you're right. I didn't consider that case. But the problem is that this is not automatic. Currently there is a clear division between miners how will not take the kickback (irrrational) and miners who will (rational). If somebody modifies the bitcoind to make this choice automatic, then DECOR+ is the only solution I know about to avoid people doing anonymous double-spends (with chained kickbacks, as you mention). The "locktime on normal transactions" you proposed does not solve the problem, just diminishes it in a constant value (which currently is very low)