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 1Yxh1U-0001n4-1p for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 19:29:52 +0000 Received: from outbound.mailhostbox.com ([162.222.225.17]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Yxh10-0000ar-Ng for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 19:29:52 +0000 Received: from [0.0.0.0] (lumumba.torservers.net [77.247.181.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id BE725781BE9; Wed, 27 May 2015 19:29:04 +0000 (GMT) Message-ID: <55661AF7.9000006@sky-ip.org> Date: Wed, 27 May 2015 22:28:55 +0300 From: s7r User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Todd References: <20150525212638.GB12430@savin.petertodd.org> <20150526001034.GF21367@savin.petertodd.org> <475dfb44d4e54649839e6438ad748b59@airmail.cc> <5564E5B8.3090802@sky-ip.org> <20150527012520.GA7618@muck> In-Reply-To: <20150527012520.GA7618@muck> Content-Type: text/plain; charset=windows-1252 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=I/SYP4Ug c=1 sm=1 tr=0 a=SQx1UuVt3cFYMRHn6YOR6Q==:117 a=SQx1UuVt3cFYMRHn6YOR6Q==:17 a=ZDnEzkWgAAAA:8 a=-NIMs_s3AAAA:8 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=bvjBBkZ6AAAA:8 a=U1-g2CzsslHDmff-FNwA:9 a=pILNOxqGKmIA:10 X-CTCH-RefID: str=0001.0A020206.55661B03.00EB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: s7r@sky-ip.org X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Headers-End: 1Yxh10-0000ar-Ng Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90% X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: s7r@sky-ip.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 19:29:52 -0000 Hi Peter, Thanks for your reply. I know and bookmarked your branch - nice work. So, to clarify: - bitcoin core (official / default) 0.10.x currently has First-seen mempool behavior - your custom branch uses replace by fee mempool behavior which allows an user to change anything in a tx (I guess it needs just to have at least one same input, so it can link it to another previously signed tx with lower fee and substitute it in the mempool, correct?). - First Seen Safe Replace by Fee (FSF-RBF) mempool behavior which allows an user only to add inputs and/or increase the value of outputs will be in yet another branch, maintained by you, but not in default / official bitcoin core? Another thing, if FSF-RBF lets you change TXes in the manner described above, how does the client know which tx needs to be replaced in the mempool? Since the txid naturally changes. How does it map tx1 with tx2 (to know tx2 has a higher fee and needs to substitute tx1) if quite a lot of params from the transaction structure can change? Thanks! On 5/27/2015 4:25 AM, Peter Todd wrote: > On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote: >> What is wrong with the man testing some ideas on his custom branch? Th= is >> is how improvements come to life. I saw in the BIPs some really >> interesting ideas and nice brainstorming which came from Peter Todd. >> >> Now, my question, if replace by fee doesn't allow me to change the >> inputs or the outputs, I can only add outputs... what can I do with th= is >> feature? If I sent a tx and want to replace it with a higher fee one, >> the higher fee one can only have maybe additional change addresses or >> another payment, if the inputs suffice? Do we have any real use cases? >=20 > You're a bit mistaken there: standard RBF lets you change anything, and > FSS RBF lets you modify inputs and add outputs and/or make the value of > outputs higher. >=20 >> P.S. is it planned to include this by default in bitcoin core 10.0.3 o= r >> it will remain just on Peter's branch? >=20 > Any significant change to mempool policy like RBF is very unlikely to b= e > incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be > too large a change for a minor, mostly bugfix, release. >=20 > Having said that, I already maintain a standard RBF branch for v0.10.x, > and have been asked by a major minor to backport FSS RBF for v0.10.x as > well. >=20