Hi AJ,
Let's take the contra.
I would say the current post describes the state of Bitcoin Core and
beyond policy
rules with a high-degree of exhaustivity and completeness, though itt what
is, mostly a description. While I think it ends with a set of
recommendations on what could be the relation
During off-channel discussion, Suhas made a great point that even with
fullrbf, you can get stuck by bip125 rule#5 pinning if an adversary
controls a number of inputs(4 with default mempool settings).
Implication being, while we can mitigate rule#3 damage potentially with
fullrbf, we cannot actual
More generally, some of the arguments against full RBF seem like debatable
reasons (though not fully convincing) to possibly leave it off, and/or
disabled by default, but definitely NOT reasons to remove the option and
prevent users from deciding for themselves.
On Thursday 27 October 2022 15:3
> For instance, the double-spend could be low-feerate and large, and
effectively pin any attempt to replace it.
Yes, this is the biggest hole left. You *could* replace it with RBF when
before you simply could not, so perhaps the pinning door is slightly
smaller in scenarios where going feerates ar
I have more to say on this broader topic, but since you've brought up this
particular example I think it's worth commenting:
On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Is that true? Antoine claims [1] that opt-in RBF isn't enoug
On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalho via bitcoin-dev wrote:
> I took the time to read your whole post. Despite a diplomatic tone, I find
> your takeaways from all your references to remain conveniently biased for
> protecting the plan of RBF
Yes, I am heavily biased against zero
On Thu, Oct 27, 2022 at 01:36:47PM +0100, Gloria Zhao wrote:
> > The cutoff for that is probably something like "do 30% of listening
> > nodes have a compatible policy"? If they do, then you'll have about a
> > 95% chance of having at least one of your outbound peers accept your tx,
> > just by ran
On Thu, Oct 27, 2022 at 09:49:48AM -0400, Greg Sanders via bitcoin-dev wrote:
> So there is some precedence to including an option that protocol devs don't
> find useful, then removing it N years later to make sure it doesn't impact
> compact blocks.
I think the lesson there is we're willing to re
To add a wrinkle, or possibly a confirmation of your long message, up to
readers to decipher, there historically has been at least one more RBF
related option that was included, then removed later in Core.
Introduced as "permitrbf" in b768108d9c0b83330572711aef1e569543130d5e with
default "true", l
Hi AJ,
Not going to comment on what Bitcoin Core's philosophy on mempol policy is
or should be. I want to note that I think this:
> It's also possible that this is something of a one time thing: full rbf
> has been controversial for ages, but widely liked by devs, and other
> attempts (eg making
Anthony,
I took the time to read your whole post. Despite a diplomatic tone, I find
your takeaways from all your references to remain conveniently biased for
protecting the plan of RBF via passive aggression.
You show multiple examples where, when I read them, I assume the next thing
you will say
Hi, Greg.
I find this proposal super interesting, and IIUC something that seems
fairly "safe" to allow (assuming V3).
For LN having the commitment transaction pay a non-zero fee is a cause for
a lot of complexity in the channel state machine. Something like this would
remove a lot of edge cases a
On Wed, Oct 26, 2022 at 16:39:02 +, Pieter Wuille via bitcoin-dev wrote:
[...]
> Our idea is to start out with approach (1)
[...]
> That said, we're not all that convinced this is the best approach, and feel
> this more a community/process question than a technical one, so it would be
> good to
13 matches
Mail list logo
