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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UepjQ-0001Xk-NV for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 16:48:12 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of quinnharris.me designates 67.223.164.214 as permitted sender) client-ip=67.223.164.214; envelope-from=btcdev@quinnharris.me; helo=fza.durangomail.com; Received: from fza.durangomail.com ([67.223.164.214]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UepjN-0007w6-EW for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 16:48:12 +0000 Received: from localhost (localhost [127.0.0.1]) by fza.durangomail.com (Postfix) with ESMTP id 1562E1EB03E for ; Tue, 21 May 2013 10:48:04 -0600 (MDT) X-Virus-Scanned: amavisd-new at fza.durangomail.com Received: from fza.durangomail.com ([127.0.0.1]) by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzVZ6jnUvs5K for ; Tue, 21 May 2013 10:48:03 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by fza.durangomail.com (Postfix) with ESMTP id 5AED91EB041 for ; Tue, 21 May 2013 10:48:03 -0600 (MDT) X-Virus-Scanned: amavisd-new at fza.durangomail.com Received: from fza.durangomail.com ([127.0.0.1]) by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lNHxgF_HpGEE for ; Tue, 21 May 2013 10:48:03 -0600 (MDT) Received: from [192.168.1.74] (172-3-184-238.lightspeed.sntcca.sbcglobal.net [172.3.184.238]) by fza.durangomail.com (Postfix) with ESMTPSA id 0188E1EB03E for ; Tue, 21 May 2013 10:48:02 -0600 (MDT) Message-ID: <519BA53F.7090404@quinnharris.me> Date: Tue, 21 May 2013 10:47:59 -0600 From: Quinn Harris User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <519AC3A8.1020306@quinnharris.me> <20130521130534.GA27580@tilt> In-Reply-To: <20130521130534.GA27580@tilt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1UepjN-0007w6-EW Subject: Re: [Bitcoin-development] Double Spend Notification 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, 21 May 2013 16:48:12 -0000 What if a transaction is tagged as eligible for replace by fee possibly using the lock_time (0xFFFFFFFE) so the parties involved can decide which approach works best for them. If the receiving side doesn't see the type of transaction they want they consider it invalid. The payment protocol can be used to negotiate which method should be used. If lock_time is final as it is now for all standard transactions, the current behaviour for transaction propagation would be kept with the addition of double spend proof notifications as I described. But if the transactions are tagged appropriately, they would be replaced by fee. In the recommended implementation, once a node sees a transaction that is not eligible to be replaced by fee it would treat all successive transactions that way despite the tag. This shouldn't hurt merchants that wish to use just double spend notification while still enabling replace by fee for those who think it is preferred. I do find the burn coins and buyer pays twice with a merchant refund to be compelling solutions, but you can't always trust the merchant (face to face street merchant). Also, there is a short window of time were a block can be mined before the burn coin counter measure is received. It is isn't guaranteed this will work better than current behaviour with double spend notification especially considering notification don't cost the merchant when it works. - Quinn