Re: [bitcoin-dev] Improving RBF Policy

2022-03-17 Thread Billy Tetrud via bitcoin-dev
@Antoine > B overrides A and starts to replace package A in the network mempools nearest to Alice. I think those peers won't have bandwidth saving from adopting a replacement staggering strategy. That's an interesting point, but even with that fact, the method would be effective at limiting

Re: [bitcoin-dev] Improving RBF Policy

2022-03-17 Thread Antoine Riard via bitcoin-dev
Hi Mempoololic Anonymous fellow, > 2. Staggered broadcast of replacement transactions: within some time > interval, maybe accept multiple replacements for the same prevout, but only > relay the original transaction. If the goal of replacement staggering is to save on bandwidth, I'm not sure it's

Re: [bitcoin-dev] Improving RBF Policy

2022-03-15 Thread Billy Tetrud via bitcoin-dev
Hi Gloria, It seems you're responding to what I wrote on github. Happy to respond, but perhaps we should keep it there so the conversation is kept linearly together? I'm curious what you think of my thoughts on what you brought up most recently in this thread about rate limiting / staggered

Re: [bitcoin-dev] Improving RBF Policy

2022-03-14 Thread Gloria Zhao via bitcoin-dev
Hi Billy, > We should expect miners will be using a more complex, more optimal way of determining what blocks they're working on [...] we should instead run with the assumption that miners keep all potentially relevant transactions in their mempools, including potentially many conflicting

Re: [bitcoin-dev] Improving RBF Policy

2022-03-12 Thread Billy Tetrud via bitcoin-dev
In reading through more of the discussion, it seems the idea I presented above might basically be a reformulation of t-bast's rate-limiting idea presented in this comment . Perhaps he

Re: [bitcoin-dev] Improving RBF Policy

2022-03-11 Thread Billy Tetrud via bitcoin-dev
Hi Gloria, > 1. Transaction relay rate limiting I have a similar concern as yours, that this could prevent higher fee-rate transactions from being broadcast. > 2. Staggered broadcast of replacement transactions: within some time interval, maybe accept multiple replacements for the same

Re: [bitcoin-dev] Improving RBF Policy

2022-03-09 Thread Gloria Zhao via bitcoin-dev
Hi RBF friends, Posting a summary of RBF discussions at coredev (mostly on transaction relay rate-limiting), user-elected descendant limit as a short term solution to unblock package RBF, and mining score, all open for feedback: One big concept discussed was baking DoS protection into the p2p

Re: [bitcoin-dev] Improving RBF Policy

2022-02-09 Thread lisa neigut via bitcoin-dev
Changing the way that RBF works is an excellent idea. Bitcoin is overdue for revisiting these rules. Thanks to @glowzo et al for kicking off the discussion. I've been thinking about RBF for a very long time[1], and it's been fun to see other people's thoughts on the topics. Here's my current

Re: [bitcoin-dev] Improving RBF Policy

2022-02-07 Thread Anthony Towns via bitcoin-dev
On Mon, Feb 07, 2022 at 11:16:26AM +, Gloria Zhao wrote: > @aj: > > I wonder sometimes if it could be sufficient to just have a relay rate > > limit and prioritise by ancestor feerate though. Maybe something like: > > - instead of adding txs to each peers setInventoryTxToSend immediately, > >

Re: [bitcoin-dev] Improving RBF Policy

2022-02-07 Thread Gloria Zhao via bitcoin-dev
Hi everyone, Thanks for giving your attention to the post! I haven't had time to write responses to everything, but sending my thoughts about what has been most noteworthy to me: @jeremy: > A final point is that a verifiable delay function could be used over, e.g., each of the N COutpoints

Re: [bitcoin-dev] Improving RBF Policy

2022-02-07 Thread Bastien TEINTURIER via bitcoin-dev
Good morning, > The tricky question is what happens when X arrives on its own and it > might be that no one ever sends a replacement for B,C,D) It feels ok to me, but this is definitely arguable. It covers the fact that B,C,D could have been fake transactions whose sole purpose was to do a

Re: [bitcoin-dev] Improving RBF Policy

2022-02-05 Thread Michael Folkson via bitcoin-dev
Thanks for this Bastien (and Gloria for initially posting about this). I sympathetically skimmed the eclair PR (https://github.com/ACINQ/eclair/pull/2113) dealing with replaceable transactions fee bumping. There will continue to be a (hopefully) friendly tug of war on this probably for the

Re: [bitcoin-dev] Improving RBF Policy

2022-02-02 Thread Anthony Towns via bitcoin-dev
On Tue, Feb 01, 2022 at 10:30:12AM +0100, Bastien TEINTURIER via bitcoin-dev wrote: > But do you agree that descendants only matter for DoS resistance then, > not for miner incentives? There's an edge case where you're replacing tx A with tx X, and X's fee rate is higher than A's, but you'd be

Re: [bitcoin-dev] Improving RBF policy

2022-02-01 Thread Eric Voskuil via bitcoin-dev
> On Feb 1, 2022, at 00:32, Bram Cohen wrote: > >> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote: >> >> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev wrote: >>> Is it still verboten to acknowledge that RBF is normal behavior and >>> disallowing it is the feature,

Re: [bitcoin-dev] Improving RBF Policy

2022-02-01 Thread Bastien TEINTURIER via bitcoin-dev
Hi AJ, Prayank, > I think that's backwards: we're trying to discourage people from wasting > the network's bandwidth, which they would do by publishing transactions > that will never get confirmed -- if they were to eventually get confirmed > it wouldn't be a waste of bandwith, after all. But if

Re: [bitcoin-dev] Improving RBF policy

2022-02-01 Thread Bram Cohen via bitcoin-dev
On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote: > > > On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Is it still verboten to acknowledge that RBF is normal behavior and > disallowing it is the feature, and that feature is mostly

Re: [bitcoin-dev] Improving RBF Policy

2022-02-01 Thread Prayank via bitcoin-dev
Hi Bastein, > This work will highly improve the security of any multi-party contract trying > to build on top of bitcoin Do you think such multi party contracts are vulnerable by design considering they rely on policy that cannot be enforced? > For starters, let me quickly explain why the

Re: [bitcoin-dev] Improving RBF policy

2022-01-31 Thread Antoine Riard via bitcoin-dev
> Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on. If

Re: [bitcoin-dev] Improving RBF policy

2022-01-31 Thread Eric Voskuil via bitcoin-dev
> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev > wrote: … > Is it still verboten to acknowledge that RBF is normal behavior and > disallowing it is the feature, and that feature is mostly there to appease > some people's delusions that zeroconf is a thing? It seems a bit overdue

Re: [bitcoin-dev] Improving RBF Policy

2022-01-30 Thread Antoine Riard via bitcoin-dev
Hi Gloria, Thanks for this RBF sum up. Few thoughts and more context comments if it can help other readers. > For starters, the absolute fee pinning attack is especially > problematic if we apply the same rules (i.e. Rule #3 and #4) in > Package RBF. Imagine that Alice (honest) and Bob

Re: [bitcoin-dev] Improving RBF Policy

2022-01-27 Thread Jeremy via bitcoin-dev
Gloria, This is a brilliant post! Great job systematizing many of the issues. Quite a lot to chew on & I hope other readers of this list digest the post fully. Three things come to mind as partial responses: under: - **DoS Protection**: Limit two types of DoS attacks on the node's > mempool:

[bitcoin-dev] Improving RBF Policy

2022-01-27 Thread Gloria Zhao via bitcoin-dev
Hi everyone, This post discusses limitations of current Bitcoin Core RBF policy and attempts to start a conversation about how we can improve it, summarizing some ideas that have been discussed. Please reply if you have any new input on issues to be solved and ideas for improvement! Just in case