Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Josh Lehan <krellan@krellan.net>
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 <pete@petertodd.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Precedence: list

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 <pete@petertodd.org> 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