Josh Lehan [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-05-13 to 2015-02-12
💬 Posted a total of 2 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:30:27

- reply

📅 Original date posted:2015-02-12
📝 Original message: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’s fee, something that happened to me once.
Stuck transactions are bad, both for the recipient (they aren’t 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’s fees) and additional outputs (to receive the change, if any is desired, from those inputs). So, now the sender is self-empowered to “shove through” 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 at petertodd.org> wrote:
>
> My replace-by-fee patch is now available for the v0.10.0rc4 release:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
>
> Along with demo scripts of the functionality:
>
> https://github.com/petertodd/replace-by-fee-tools
>
> New to this version is a comprehensive set of unittests under
> qa/replace-by-fee
>
> Additionally the preferential peering support now preferentially peers
> with Bitcoin XT¹ nodes that support Andresen/Harding's double-spend
> relaying² 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.³
>
> I've had a number of requests from miners for a version of
> replace-by-fee against Luke-Jr's Eligius patches⁴; I'll be also
> releasing that shortly once this release has undergone some more
> testing.
>
>
> What's replace-by-fee?
> ----------------------
>
> 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.
>
> 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⁵ 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.
>
> 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⁶ 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⁷ that a majority of miners be able to vote to
> confiscate the earnings of the minority and redistribute them at will.
>
>
> Installation
> ------------
>
> 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:
>
> 2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes
>
> 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:
>
> $ bitcoin-cli getpeerinfo | grep services | egrep '((0000000000000003)|(0000000004000001))'
> "services" : "0000000000000003",
> "services" : "0000000004000001",
> "services" : "0000000004000001",
> "services" : "0000000000000003",
> "services" : "0000000004000001",
> "services" : "0000000004000001",
> "services" : "0000000000000003",
> "services" : "0000000000000003",
>
> 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.
>
> 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.
>
> 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/msg05211.html
> 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
> 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html
>
> --
> '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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:21:15

- reply

📅 Original date posted:2014-05-13
📝 Original message:I agree, it looks very slick. Well done.
While on the subject of connected peers, what about the idea of adding the ping time from this node to other peers? The problem with fitting that information into the current design is that the graphs seem to be comprised of overall statistics for this node, not per-peer statistics that can vary between peers (such as ping time). If a line were to be added to a graph to represent each peer's ping time, the number of lines (statistics) on the graph would have to vary in real time as peers are added or removed, which would be a challenge.
I earlier added the "ping" feature to bitcoind, and it works to measure the ping time, however this feature is on-demand: it won't ping other nodes unless requested. So, something would have to send the "ping" RPC command on a regular schedule, to ensure the graph is updated with new information. Also, there is currently no support for overlapping pings (although that would be easy to add), so if a peer is slow enough to not respond at all to the first ping request, and a second ping request goes out in the meantime, any late response from the first ping request would then be discarded.
Great graphs, and these are just brainstorms for future ideas :)
Josh Lehan
Sent from my iPad
> On May 13, 2014, at 4:43, Wladimir <laanwj at gmail.com> wrote:
>
> Hello Jameson,
>
>> On Sun, May 11, 2014 at 7:14 PM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Since it seems unlikely that we'll be able to ship an integrated stats / monitoring feature in the short term, I went ahead and set up a public Statoshi instance and threw a nicer interface on top of it.
>>
>> http://statoshi.info
>
> Must say it looks very nice.
>
> One comment about the graphs: in the 'connected peers' chart you
> visualize some larger quantities (especially knownAddresses) and some
> very small ones (peer.(dis)connect). This makes the latter invisible
> due to scale.
>
> Some random stats may be useful as well:
>
> - Number of connected peers that are SPV clients or full nodes (NODE_NETWORK)
> - Current block height (so that it's possible to detect stuck nodes)
> - Number of transactions in mempool
> - Number of transactions in UTXO set
> - Maybe some fee statistics,
> https://github.com/bitcoin/bitcoin/pull/3959 would be useful here
> - Number of orphan blocks/orphan transactions
>
> Wladimir
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development