From mboxrd@z Thu Jan 1 00:00:00 1970 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 1YM1mi-0000GQ-H6 for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 21:58:56 +0000 X-ACL-Warn: Received: from transmat.krellan.net ([70.36.220.56] helo=tardis.krellan.net) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YM1mg-0003f6-7h for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 21:58:56 +0000 Received: from [IPv6:2001:470:1f05:12fe:21f:f3ff:fe55:c215] (unknown [IPv6:2001:470:1f05:12fe:21f:f3ff:fe55:c215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tardis.krellan.net (Postfix) with ESMTPSA id ADBF8400C9F; Thu, 12 Feb 2015 13:40:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Josh Lehan In-Reply-To: <20150212064719.GA6563@savin.petertodd.org> Date: Thu, 12 Feb 2015 13:40:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <13DBC715-3EFB-42DB-9003-C7AA72D7BCC6@krellan.net> References: <20150212064719.GA6563@savin.petertodd.org> To: Peter Todd X-Mailer: Apple Mail (2.2070.6) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YM1mg-0003f6-7h Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 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, 12 Feb 2015 21:58:56 -0000 Probably out of my league, but I will respond here anyway. I am in favor of replace-by-fee, but only if it were to be applied to a = very limited subset of transactions: namely, transactions that seek to = supplement, not replace, the original transaction. In other words, a replacement transaction would only be accepted if it = were adding additional value (additional transaction inputs and/or = outputs). Otherwise, the original transaction would stand. Reducing = any of the promised outputs, or diverting them to some other recipient, = would not be allowed. This would solve the problem of a stuck transaction: a transaction that = is taking seemingly forever to confirm, because one forgot to pay the = miner=E2=80=99s fee, something that happened to me once. Stuck transactions are bad, both for the recipient (they aren=E2=80=99t = getting paid) and the sender (some of their funds are still tied up, = because change from that transaction has not returned yet). With replace-by-fee, the sender of a transaction can send it again, with = additional inputs (to pay more miner=E2=80=99s fees) and additional = outputs (to receive the change, if any is desired, from those inputs). = So, now the sender is self-empowered to =E2=80=9Cshove through=E2=80=9D = their stuck transaction, by voluntarily choosing to pay more for it, a = market-driven solution to the problem. There are really good reasons to not allow replace-by-fee as a general = policy that can apply to all transactions, as others have already = mentioned. However, I still believe the idea has merit, for this = special limited case of supplementing a transaction. Josh Lehan > On Feb 11, 2015, at 22:47, Peter Todd wrote: >=20 > My replace-by-fee patch is now available for the v0.10.0rc4 release: >=20 > https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 >=20 > Along with demo scripts of the functionality: >=20 > https://github.com/petertodd/replace-by-fee-tools >=20 > New to this version is a comprehensive set of unittests under > qa/replace-by-fee >=20 > Additionally the preferential peering support now preferentially peers > with Bitcoin XT=C2=B9 nodes that support Andresen/Harding's = double-spend > relaying=C2=B2 patch. While Bitcoin XT nodes don't accept = double-spends into > their mempool, they do relay them perfectly well and thus are an asset > to those doing replace-by-fee mining.=C2=B3 >=20 > I've had a number of requests from miners for a version of > replace-by-fee against Luke-Jr's Eligius patches=E2=81=B4; I'll be = also > releasing that shortly once this release has undergone some more > testing. >=20 >=20 > What's replace-by-fee? > ---------------------- >=20 > Currently most Bitcoin nodes accept the first transaction they see > spending an output to the mempool; all later transactions are = rejected. > Replace-by-fee changes this behavior to accept the transaction paying > the highest fee, both absolutely, and in terms of fee-per-KB. Replaced > children are also considered - a chain of transactions is only = replaced > if the replacement has a higher fee than the sum of all replaced > transactions. >=20 > Doing this aligns standard node behavior with miner incentives: earn = the > most amount of money per block. It also makes for a more efficient > transaction fee marketplace, as transactions that are "stuck" due to = bad > fee estimates can be "unstuck" by double-spending them with higher > paying versions of themselves. With scorched-earth techniques=E2=81=B5 = it gives > a path to making zeroconf transactions economically secure by relying = on > economic incentives, rather than "honesty" and alturism, in the same = way > Bitcoin mining itself relies on incentives rather than "honesty" and > alturism. >=20 > Finally for miners adopting replace-by-fee avoids the development of = an > ecosystem that relies heavily on large miners punishing smaller ones = for > misbehavior, as seen in Harding's proposal=E2=81=B6 that miners = collectively 51% > attack miners who include doublespends in their blocks - an = unavoidable > consequence of imperfect p2p networking in a decentralized system - or > even Hearn's proposal=E2=81=B7 that a majority of miners be able to = vote to > confiscate the earnings of the minority and redistribute them at will. >=20 >=20 > Installation > ------------ >=20 > Once you've compiled the replace-by-fee-v0.10.0rc4 branch just run = your > node normally. With -debug logging enabled, you'll see messages like = the > following in your ~/.bitcoin/debug.log indicating your node is = replacing > transactions with higher-fee paying double-spends: >=20 > 2015-02-12 05:45:20 replacing tx = ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with = c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for = 0.00798 BTC additional fees, -1033 delta bytes >=20 > Additionally you can tell if you are connected to other replace-by-fee > nodes, or Bitcoin XT nodes, by examining the service bits advertised = by > your peers: >=20 > $ bitcoin-cli getpeerinfo | grep services | egrep = '((0000000000000003)|(0000000004000001))' > "services" : "0000000000000003", > "services" : "0000000004000001", > "services" : "0000000004000001", > "services" : "0000000000000003", > "services" : "0000000004000001", > "services" : "0000000004000001", > "services" : "0000000000000003", > "services" : "0000000000000003", >=20 > Replace-by-fee nodes advertise service bit 26 from the experimental = use > range; Bitcoin XT nodes advertise service bit 1 for their getutxos > support. The code sets aside a certain number of outgoing and incoming > slots just for double-spend relaying nodes, so as long as everything = is > working you're node should be connected to like-minded nodes a within = 30 > minutes or so of starting up. >=20 > If you *don't* want to advertise the fact that you are running a > replace-by-fee node, just checkout a slightly earlier commit in git; = the > actual mempool changes are separate from the preferential peering > commits. You can then connect directly to a replace-by-fee node using > the -addnode command line flag. >=20 > 1) https://github.com/bitcoinxt/bitcoinxt > 2) https://github.com/bitcoin/bitcoin/pull/3883 > 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 > 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP > 5) = http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/ms= g05211.html > 6) = http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg0= 6970.html > 7) = http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/ms= g04972.html >=20 > --=20 > 'peter'[:-1]@petertodd.org > 000000000000000013c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3 > = --------------------------------------------------------------------------= ---- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, = is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. = Take a > look and join the conversation now. = http://goparallel.sourceforge.net/________________________________________= _______ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development