I read Antoine's original post on this and got the general gist, and
here also, it makes sense, but I'd like to ask: is it necessary that
(B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
replace it
Is it
Bob has staked liquidity in a payment channel with Alice who later
double spends the same inputs (at a very low feerate) resulting in a
stalemate where neither can spend the UTXOs.
I just realized I made a mistake. RBF will always mine the higher fee
transaction, so in this case, full-rbf
Peter,
It sounds like there are two attack vectors; neither of which require
full-rbf (correct me if I'm wrong).
1) Bob has staked liquidity in a payment channel with Alice who later
double spends the same inputs (at a very low feerate) resulting in a
stalemate where neither can spend the
Hi aj and list,
(questions inline)
--- Original Message ---
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via bitcoin-dev
wrote:
>
> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
> a DoS issue when utxos are jointly funded by untrusting partners,
>
>
> With full-rbf, who saw what transaction first doesn't matter: the higher
> fee paying transaction will always(*) replace the lower fee one. With
> opt-in RBF, spamming the network can beat out the alternative.
>
incentivised predictability is critical when designing low level protocols,
On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
wrote:
>
>AJ/Antoine et al
>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>
>Assuming Alice is a well funded advisory, with enough resources to
On Mon, Oct 31, 2022 at 09:02:02AM -0400, Suhas Daftuar via bitcoin-dev wrote:
Sending this email for the sake of repeating a point I made on GitHub for the
mailing list audience:
> AJ,
>
> Thanks for the thoughtful post. I think your observations about how we view
> mempool policy in the
Peter,
There's nothing special about a "full-rbf transaction" other than the
fact
that it's replacing a previously broadcast transaction that didn't
signal
replacement.
Thanks, this is a piece I haven't seen. It sounds like "full-rbf"
policy is fundamentally different from BIP125, where
AJ/Antoine et al
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
Assuming Alice is a well funded advisory, with enough resources to spam
the network so that enough nodes see her malicious transaction first,
how
Hi Suhas,
>From my understanding, the main crux of the reasoning exposed in your post
would be to solidify the transaction-relay paradigm we have been following
during the last years, e.g introducing the carve-out rule specifically for
lightning commitment transactions, or more recently version=3
> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.
To be clear, a pinner is attempting to
On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev wrote:
> For 0-conf services we have potential thieves who are willing
> to *out-bid themselves* to have funds come back to themselves. It's not a
> "legitimate" use-case, but a rational one.
I think that's a huge
On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote:
>
> Protocol Devs,
>
> After reading through this email thread and BIP125, I'm curious if non-rbf
> nodes will relay full-rbf transactions and vice versa. That is to say, if
> only one non-rbf node exists on the network,
Protocol Devs,
After reading through this email thread and BIP125, I'm curious if
non-rbf nodes will relay full-rbf transactions and vice versa. That is
to say, if only one non-rbf node exists on the network, however, every
other node implements full-rbf, will the transaction still be
Thanks for your full thoughts Suhas,
The idea of V3 is that we're currently leaving fees on the table by
allowing use-cases to be pinned, not that we like Lightning and we think
miners should stop being profit maximizing somehow to enable safer/better
layer 2 systems.
If someone wants to bump
AJ,
Thanks for the thoughtful post. I think your observations about how we view
mempool policy in the Bitcoin Core project, and how that seems to be
changing in the discussions around `-mempoolfullrbf`, are on-point and
provide a helpful baseline for considering future policy changes.
For a long
Whether that's terrible or not depends on how easy it is to retry (and
how
likely the retry is to succeed) after a failure -- if a TCP packet
fails,
it just gets automatically resent, and if that succeeds, there's a
little
lag, but your connection is still usable
I'm not sure if that
On Sun, Oct 30, 2022 at 11:02:43AM +1000, Anthony Towns via bitcoin-dev wrote:
> > Some napkin math: there are about 250,000 transactions a day; if
> > we round that up to 100 million a year and assume we only want one
> > transaction per year to fail to initially propagate on a network where
> >
On Thu, Oct 27, 2022 at 09:29:47PM +0100, Antoine Riard via bitcoin-dev wrote:
> Let's take the contra.
(I don't think I know that phrase? Is it like "play devil's advocate"?)
> I would say the current post describes the state of Bitcoin Core and
> beyond policy
> rules with a high-degree of
On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Harding via bitcoin-dev
wrote:
> I think this might be understating the problem. A 95% chance of having
> an outbound peer accept your tx conversely implies 1 in 20 payments will
> fail to propagate on their initial broadcast.
Whether that's
On 2022-10-26 13:52, Anthony Towns via bitcoin-dev 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 random chance.
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
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
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
> 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
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
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
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
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
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",
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
oday to work FOREVER.
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
> Date: Thu, 27 Oct 2022 09:52:10 +1000
> From: Anthony Towns
> To: Bitcoin Protocol Discussion
>
> Subject: [bitcoin-dev] On mempool policy consistency
> Message-ID:
> Content-Type: text/
Hi *,
TLDR: Yes, this post is too long, and there's no TLDR. If it's any
consolation, it took longer to write than it does to read?
On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev wrote:
> Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> I'm writing to
33 matches
Mail list logo
