Re: [bitcoin-dev] On mempool policy consistency

[Antoine Riard via bitcoin-dev]

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 relations between miners, devs and
node operators w.r.t adopting policy rules, to me it doesn't explore enough
the hard part of the subject. What should be actually the design goals and
principles of Core's transaction-relay propagation rules

of which mempool accepts ones is a subset ? By such design goals, I'm
thinking either, a qualitative framework, like attacks game for a concrete
application ("Can

we prevent pinning against multi-party Coinjoin ?"). Or a quantitative
approach, e.g how fast should be transaction-relay throughput for a given
topology, or how much accurate is the block template against usual blocks
[0]


Assuming we would have technical principles and goals guiding our
development process, of which the discussion and revision should be an
inherent part of the process itself,  I believe we would come up with a
second-order observation. That we might not be able to satisfy every
use-case with the standard set of policy rules. E.g, a contracting protocol
could look for package size beyond the upper bound anti-Dos limit. Or even the
global ressources offered by the network of full-nodes are not high enough
to handle some application event. E.g a Lightning Service Provider doing a
liquidity maintenance round of all its counterparties, and as such
force-closing and broadcasting more transactions than can be handled at the
transaction-relay layer due to default MAX_PEER_TX_ANNOUNCEMENTS value.


My personal take on those subjects, we might have to realize we're facing
an heterogeneity of Bitcoin applications and use-cases [1]. And this sounds
like a long-term upward trend, akin to the history of the Internet: mail
clients, web browser, streaming applications, etc, all with different
service-level requirements in terms of latency, jitters and bandwidth. We might
observe that Bitcoin actors might adopt individual strategies for the
consumption of it. E.g a multi-party contracting protocol with asymmetric
states, a counterparty could "front-run" the others at the
transaction-relay to avoid encumbering the RBF penalty in case of
concurrent broadcast. Or they could deploy an additive layer of
communication channels, like private transaction-relay to miners, e.g a LN
node broadcasting a HTLC-preimage and restraining the odds of mapping to an
off-chain payment path. Those additive layers of communication can be also
seen as mitigations against components failure risks, e.g a
transaction-relay

censorship vector in the p2p stack. To put it simply, some advanced Bitcoin
applications might have to outgrow the "mempool policy rules" game, as
we're currently defining it to satisfy to a higher degree their security
and operational models. I think this has been historically the case with
some miners deciding to join FIBER, to improve their view of mined blocks.


While I still think we can come up with clear policy rules for some ideal
or reasonable use-case (let's say the Bitcoin hobbyist aiming to strong
censorship-resistance of its

payment). And I hold the belief we can improve on that front, as we've done
during the past years by formalizing a subset of policy rules in Bitcoin
Core documentation. In

parallel, we might acknowledge the heterogeneity of use-cases, and that we
cannot offer the same level of censorship-resistance, privacy or
cost-effectiveness (And that might be okay if we remember that e.g
censorship-resistance between a simple Bitcoin payment and a Lightning HTLC
isn't defined the same, due to the usage of timelocks by the latter).


What I'm expressing is a long-term perspective, and we might be too early
in the evolutionary process that is Bitcoin Core development to abandon yet
the "one-size-fits-all"

policy rules conception that I understand from your post. Though to me, as
we progress on modularity and flexibility of the Core codebase, we might
have to envision a Bitcoin ecosystem where configuring a client is on the
same bar as the kernel Kconfig (hopefully not because no drivers/ but
still..). Of course, you can have "blessed" config to avoid the complexity
turning away node operators and users, though at the price of increasing
the trust in your vendors.


More concretely, about the issue of today, full-rbf, I think the lack of
design heuristic in the sense of what should be the reasonable or average
use-case

supported by the Bitcoin base-layer transaction-relay rules. Should we
favor the historical ones (0confs) or the new incumbent (contracting
protocols) ? There is always the "First, do not harm" principle in lack of
clear guidelines in any area of Bitcoin protocol development. Though when
we're facing risk arbitrage like the current one, I don't think as protocol
devs we have any strong 

Re: [bitcoin-dev] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

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 actually make promises about mempool entry beyond quite
small transaction sizes. Adversary has to make 100 transactions, 4 chains
of 25, but it achieves the original pin.

On Thu, Oct 27, 2022 at 1:44 PM Greg Sanders  wrote:

> > 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 are significantly higher than min.
>
> > Or it could be higher feerate and confirm and B/C have to start all over.
>
> Coinjoins have "blame rounds" exactly for this. Ruling out the above hole
> where you don't want to pay the 100kvb rule#3 penalty, you can kick the
> griefer out. Without replacement, you likely can not.
>
> > Or, A could stall things in the signing phase and B/C have to figure out
> when to give up on the channel with A.
>
> Again, blame rounds solve this.
>
> So to recap, it makes it *possible* to over-bid your griefer, vs simply
> not able to and have funds tied up for weeks(or guess you're being pinned
> and double-spend your input, which again looks blame-worthy).
>
> Properly replacing rule#3 would give these protocols higher assurances,
> but this is where we're at now.
>
> On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 enough to avoid
>>> a DoS issue when utxos are jointly funded by untrusting partners, and,
>>> aiui, that's the main motivation for addressing this now.
>>>
>>> [1]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>>
>>> The scenario he describes is: A, B, C create a tx:
>>>
>>>   inputs: A1, B1, C1 [opts in to RBF]
>>>   fees: normal
>>>   outputs:
>>> [lightning channel, DLC, etc, who knows]
>>>
>>> they all analyse the tx, and agree it looks great; however just before
>>> publishing it, A spams the network with an alternative tx, double
>>> spending her input:
>>>
>>>   inputs: A1 [does not opt in to RBF]
>>>   fees: low
>>>   outputs: A
>>>
>>> If A gets the timing right, that's bad for B and C because they've
>>> populated their mempool with the 1st transaction, while everyone else
>>> sees the 2nd one instead; and neither tx will replace the other. B and
>>> C can't know that they should just cancel their transaction, eg:
>>>
>>>   inputs: B1, C1 [opts in to RBF]
>>>   fees: 50% above normal
>>>   outputs:
>>> [smaller channel, refund, whatever]
>>>
>>> and might instead waste time trying to fee bump the tx to get it mined,
>>> or similar.
>>>
>>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>>> solve that problem if they have only opt-in RBF available?
>>>
>>
>> I think this is not a real example of a DoS vector that is available
>> because we support non-rbf signaling transactions. Even in a world where
>> all transactions are replaceable, person A could double-spend their input
>> in a way that is annoying for B and C.  For instance, the double-spend
>> could be low-feerate and large, and effectively pin any attempt to replace
>> it.  Or it could be higher feerate and confirm and B/C have to start all
>> over.  Or, A could stall things in the signing phase and B/C have to figure
>> out when to give up on the channel with A.
>>
>> So I find this example to be unconvincing.  Are there any other examples
>> where having a non-replacement policy for some transactions causes problems
>> for protocols people are trying to build?
>>
>> Thanks,
>> Suhas
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[Luke Dashjr via bitcoin-dev]

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:37:27 Anthony Towns via bitcoin-dev wrote:
> "Can I prevent someone else's transaction from propagating" is almost
> the entirety of the question with -datacarrier, -datacarriersize and
> -permitbaremultisig though:

Not necessarily the entirety, no. Even if others would propagate it, you also 
don't want to waste _your_ bandwidth doing so. This also reveals a difference 
between the two policies: with RBF, you have _already_ spent resources 
propagating the first transaction (what this implies is not immediately 
obvious).

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

> 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 are significantly higher than min.

> Or it could be higher feerate and confirm and B/C have to start all over.

Coinjoins have "blame rounds" exactly for this. Ruling out the above hole
where you don't want to pay the 100kvb rule#3 penalty, you can kick the
griefer out. Without replacement, you likely can not.

> Or, A could stall things in the signing phase and B/C have to figure out
when to give up on the channel with A.

Again, blame rounds solve this.

So to recap, it makes it *possible* to over-bid your griefer, vs simply not
able to and have funds tied up for weeks(or guess you're being pinned and
double-spend your input, which again looks blame-worthy).

Properly replacing rule#3 would give these protocols higher assurances, but
this is where we're at now.

On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 enough to avoid
>> a DoS issue when utxos are jointly funded by untrusting partners, and,
>> aiui, that's the main motivation for addressing this now.
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>
>> The scenario he describes is: A, B, C create a tx:
>>
>>   inputs: A1, B1, C1 [opts in to RBF]
>>   fees: normal
>>   outputs:
>> [lightning channel, DLC, etc, who knows]
>>
>> they all analyse the tx, and agree it looks great; however just before
>> publishing it, A spams the network with an alternative tx, double
>> spending her input:
>>
>>   inputs: A1 [does not opt in to RBF]
>>   fees: low
>>   outputs: A
>>
>> If A gets the timing right, that's bad for B and C because they've
>> populated their mempool with the 1st transaction, while everyone else
>> sees the 2nd one instead; and neither tx will replace the other. B and
>> C can't know that they should just cancel their transaction, eg:
>>
>>   inputs: B1, C1 [opts in to RBF]
>>   fees: 50% above normal
>>   outputs:
>> [smaller channel, refund, whatever]
>>
>> and might instead waste time trying to fee bump the tx to get it mined,
>> or similar.
>>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>>
>
> I think this is not a real example of a DoS vector that is available
> because we support non-rbf signaling transactions. Even in a world where
> all transactions are replaceable, person A could double-spend their input
> in a way that is annoying for B and C.  For instance, the double-spend
> could be low-feerate and large, and effectively pin any attempt to replace
> it.  Or it could be higher feerate and confirm and B/C have to start all
> over.  Or, A could stall things in the signing phase and B/C have to figure
> out when to give up on the channel with A.
>
> So I find this example to be unconvincing.  Are there any other examples
> where having a non-replacement policy for some transactions causes problems
> for protocols people are trying to build?
>
> Thanks,
> Suhas
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[Suhas Daftuar via bitcoin-dev]

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 enough to avoid
> a DoS issue when utxos are jointly funded by untrusting partners, and,
> aiui, that's the main motivation for addressing this now.
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> The scenario he describes is: A, B, C create a tx:
>
>   inputs: A1, B1, C1 [opts in to RBF]
>   fees: normal
>   outputs:
> [lightning channel, DLC, etc, who knows]
>
> they all analyse the tx, and agree it looks great; however just before
> publishing it, A spams the network with an alternative tx, double
> spending her input:
>
>   inputs: A1 [does not opt in to RBF]
>   fees: low
>   outputs: A
>
> If A gets the timing right, that's bad for B and C because they've
> populated their mempool with the 1st transaction, while everyone else
> sees the 2nd one instead; and neither tx will replace the other. B and
> C can't know that they should just cancel their transaction, eg:
>
>   inputs: B1, C1 [opts in to RBF]
>   fees: 50% above normal
>   outputs:
> [smaller channel, refund, whatever]
>
> and might instead waste time trying to fee bump the tx to get it mined,
> or similar.
>
> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?
>

I think this is not a real example of a DoS vector that is available
because we support non-rbf signaling transactions. Even in a world where
all transactions are replaceable, person A could double-spend their input
in a way that is annoying for B and C.  For instance, the double-spend
could be low-feerate and large, and effectively pin any attempt to replace
it.  Or it could be higher feerate and confirm and B/C have to start all
over.  Or, A could stall things in the signing phase and B/C have to figure
out when to give up on the channel with A.

So I find this example to be unconvincing.  Are there any other examples
where having a non-replacement policy for some transactions causes problems
for protocols people are trying to build?

Thanks,
Suhas
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[Anthony Towns via bitcoin-dev]

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 zeroconf: there's no way I'd personally
be willing to trust it for my own incoming funds, no matter how much
evidence you show me that it's safe in practice. Show me a million
transactions where every single one worked fine, and I'm still going to
assume that the payment going to me is going to be the one that makes
the error rate tick up from 0% to 0.0001%. That's okay; just because I
wouldn't do something, doesn't mean other people shouldn't.

It does mean I'm not going to be a particularly good advocate for zeroconf
though. I mean, I might still be a fine advocate for giving people time
to react, making it clear what's going on, finding ways that might make
everyone happy, or just digging it to random technical details; but,
for me, I'm more interested in a world where chargebacks are impossible,
not where we just make the best of what was possible with technology
from five or ten years ago.

But that's fine: it just means that people, like yourself, who will
tolerate the risks of zeroconf, should be involved in the discussion.

> You show multiple examples where, when I read them, I assume the next thing
> you will say will be "so we really should stop trying to impose optional
> features, particularly when they affect existing use cases" but instead you
> persist.

Sure, that's natural: you read a sign saying "you can have any ice cream
you want for 5c" and think "Awesome, who wouldn't want cheap chocolate
ice cream!!" and see me going for a Golden Gaytime and think "wtf dude".
Different strokes.

For me, I see the gmaxwell github comment I quoted saying:

  There is also a matter of driving competent design rather than lazy
  first thing that works.

and think "yeah, okay, maybe we should be working harder to push lightning
adoption, rather than letting people stick with wallet UX from 2015"
and have altcoins take over >50% of payment volume.

Likewise,

  There is also a very clear pattern we've seen in the past where
  people take anything the system lets them do as strong evidence that
  they have a irrevocable right to use the system in that way, and that
  their only responsibility-- and if their usage harms the system it's
  the responsibility of the system to not permit it.

seems a pretty good match against your claim "I expect the things I do
with Bitcoin today to work FOREVER." Better to nip that thinking in the
bud; and even if the best time to do that was years ago, the second best
time to do it is still now.

By contrast, from the same post, I'd guess you're focussing on:

  Network behavior is one of the few bits of friction
  driving good technical design rather than "move fast, break things, and
  force everyone else onto my way of doing thing rather than discussing
  the design in public".

and thinking "yeah, move fast, break things, force everyone else --
that's exactly what's going on here, and shouldn't be".

But that's also okay: even when there is common ground to be found,
sometimes it requires actual work to get people who start from different
views to get there.

> The problem is that RBF has already been an option for years, and anyone
> that wants to use it can.

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, and,
aiui, that's the main motivation for addressing this now.

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

The scenario he describes is: A, B, C create a tx:

  inputs: A1, B1, C1 [opts in to RBF]
  fees: normal
  outputs:
[lightning channel, DLC, etc, who knows]

they all analyse the tx, and agree it looks great; however just before
publishing it, A spams the network with an alternative tx, double
spending her input:

  inputs: A1 [does not opt in to RBF]
  fees: low
  outputs: A

If A gets the timing right, that's bad for B and C because they've
populated their mempool with the 1st transaction, while everyone else
sees the 2nd one instead; and neither tx will replace the other. B and
C can't know that they should just cancel their transaction, eg:

  inputs: B1, C1 [opts in to RBF]
  fees: 50% above normal
  outputs:
[smaller channel, refund, whatever]

and might instead waste time trying to fee bump the tx to get it mined,
or similar.

What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?

If you're right that opt-in RBF is enough, that question has a good
answer. I don't believe anyone's presented an answer to it in the 17
months since Antoine raised the concern.

> passive aggression
> escalation
> unfair advantage
> oppressive, dark-pattern design
> 

Re: [bitcoin-dev] On mempool policy consistency

[Anthony Towns via bitcoin-dev]

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 random chance.
> Yes, in most cases, whether Bitcoin Core is restricting or loosening
> policy, the user in question is fine as long as they have a path from their
> node to a miner that will accept it. This is the case for something like
> -datacarriersize if the use case is putting stuff into OP_RETURN outputs,
> or if they're LN and using CPFP carveout, v3, package relay, etc.

> But
> replacement is not only a question of "will my transaction propagate" but
> also, "will someone else's transaction propagate, invalidating mine" or, in
> other words, "can I prevent someone else's transaction from propagating."

"Can I prevent someone else's transaction from propagating" is almost
the entirety of the question with -datacarrier, -datacarriersize and
-permitbaremultisig though: "we" don't want people to spam the utxo
set or the blockchain with lots of data (cf BSV's gigabytes worth of
dog pictures [0]), so for the people who are going to find some way
of putting data in we'd like to encourage them to make it small, and
do it in a way that's prunable and doesn't bloat the utxo set, whose
size matters even more than the overall blockchain's size does. As I
understand it, people were doing that by creating bare multisig utxos,
ie a bare (non-p2sh) scriptPubKey that perhaps looks like:

  1 my_key data1 data2 data3 data4 data5 5 CHECKMULTISIG

which is "bad" in two ways: you're only committing to the data, so why
not save 128 bytes by doing hash(data1 data2 data3 data4 data5) instead;
and even more so, that data is only interesting to you, not everyone else,
so why not do it in a way that doesn't bloat the utxo set, which we want
to keep small so that it's easier to efficiently look up potential spends.

Hence the -datacarriersize limitation that limits you to about 2.5
"dataN" entries per tx ("we'll prevent your tx from propagating if you
do much more than publish a hash") and hence at least the potential for
doing the same for baremultisig in general.

[0] https://twitter.com/bsvdata/status/1427866510035324936

> A
> zeroconf user relies on there *not* being a path from someone else's full
> RBF node to a full RBF miner. This is why I think RBF is so controversial
> in general,

Yes; but I think it's also true to say that this is why *zeroconf* is as
controversial as it is.

Likewise OP_RETURN has had its own "controversies" to some extent, too:

  https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/
  https://github.com/bitcoin/bitcoin/pull/3715
  https://github.com/bitcoin/bitcoin/pull/3939

> why -mempoolfullrbf on someone else's node is considered more
> significant than another policy option, and why full RBF shouldn't be
> compared with something like datacarriersize.

It's definitely a different scenario: unexpected RBF can cause you to
have less money than you expected; whereas more OP_RETURN data just
bloats the blockchain, and losing money that you thought was yours is
definitely more painful than more spam.

But while the level of pain is different; I don't think the mechanism is:
whether you're trying to preserve zeroconf or prevent utxo set spam,
you're still relying on a vast majority of nodes working together to
prevent even a small minority of hashpower from doing "bad" things, with
no cryptographic assurances that will continue to work well or at all.

> I don't think past patterns can be easily applied here,

I mean, technically they trivially could? We *could* roll out support for
full RBF in exactly the same way we rolled out support for opt-in RBF:
making it the default for all nodes, but supplying an option that node
operators can use to disable the feature for seven releases / ~4 years:

https://bitcoin.org/en/release/v0.12.0#opt-in-replace-by-fee-transactions
https://bitcoin.org/en/release/v0.19.0.1#deprecated-or-removed-configuration-options

If we don't want to do that immediately, but also want to make a definite
move forward, then we could:

 * just say that, and then keep our word about it
 * keep the feature in master, but remove it in 24.x
 * put a time delay on the feature so that it doesn't happen immediately
   but is locked in in the code for whenever we are ready to do it

> and I don't think this necessarily shows a
> different "direction" in thinking about mempool policy in general.

If we're not applying past patterns, then this is a different direction
in how we're thinking about things than what we did in the past.

That's not necessarily a bad thing -- maybe we should be thinking
differently; but I don't see how you can honestly dispute it: those are
just two ways of saying the exact same thing.

Cheers,
aj
___

Re: [bitcoin-dev] On mempool policy consistency

[Peter Todd via bitcoin-dev]

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 remove options that are
ridiculous. Replacements are widely used, and downright essential in high-fee
situations.

> Peering into the "precedence" lense, I think this does lend itself to the
> theory that the transition should be as uniform as possible to avoid
> degradation of fast block propagation. If not removing options(which is
> deemed user hostile by a number of folks including me), then at least for a
> flag day switchover.

Re: compact blocks, note that RBF is a special case: for the sake of
reconstruction, it'd make sense to temporarily cache transactions have have
been replaced rather than discarding them entirely, in case a prior version
gets mined. Irregardless of policy this will happen occasionally simple due to
propagation delays. Equally, if we cached transactions that we rejected due to
policy, that'd help with reconstruction success in the event that policy is
changing.

Anyway, since the compact blocks implementation efficiently deals with the case
where miners have policy that differs from most nodes, by immediately
forwarding missing transactions, I don't think the occasional full-rbf
replacement is going to have much impact. The nodes that had full-rbf disabled
will forward the tx to their peers directly, and then the subset of full-rbf
disabled peers will do the same again. So long as the network has a mix of both
types, and they're interconnected rather than in clusters, the latency impact
should be minimal.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[Greg Sanders via bitcoin-dev]

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", later renamed to "replacebyfee", then finally as
"mempoolreplacement".

It was later removed in 8053e5cdade87550f0381d51feab81dedfec6c46 with the
message:

"
Remove -mempoolreplacement to prevent needless block prop slowness.

At this point there is no reasonable excuse to disable opt-in RBF,
and, unlike when this option was added, there are now significant
issues created when disabling it (in the form of compact block
reconstruction failures). Further, it breaks a lot of modern wallet
behavior.
"

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.

Peering into the "precedence" lense, I think this does lend itself to the
theory that the transition should be as uniform as possible to avoid
degradation of fast block propagation. If not removing options(which is
deemed user hostile by a number of folks including me), then at least for a
flag day switchover.

Cheers,
Greg

On Wed, Oct 26, 2022 at 7:53 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 propose deprecation of opt-in RBF in favor of full-RBF
>
> > If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> > too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> > consistent deprecation process w.r.t to policy rules heavily relied-on by
> > Bitcoin users, if we do so let sets a precedent satisfying as many folks
> as
> > we can.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same:
>
>   Firstly, there is no "the mempool". There is no global mempool. Rather
>   each node maintains its own mempool and accepts and rejects transaction
>   to that mempool using their own internal policies. Most nodes have
>   the same policies, but due to different start times, relay delays,
>   and other factors, not every node has the same mempool, although they
>   may be very similar.
>
>   -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> nodes running core have been quite small, with essentially the following
> options available:
>
>  -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
>  -mempoolexpiry - how long to keep txs in the mempool
>
>  -datacarrier - reject txs creating OP_RETURN outputs
>
>  -datacarriersize - maximum size of OP_RETURN data
>
>  -permitbaremultisig - prevent relay of bare multisig
>
>  -bytespersigop - changes how SIGOP accounting works for relay and
>  mining prioritisation
>
> as well as these, marked as "debug only" options (only shown with
> -help-debug):
>
>  -incrementalrelayfee - make it easier/harder to spam txs by only
>  slightly bumping the fee; marked as a "debug only" option
>
>  -dustrelayfee - make it easier/harder to create uneconomic utxos;
>  marked as a "debug only" option
>
>  -limit{descendant,ancestor}{count,size} - changes how large the
>  transaction chains can be; marked as a "debug only" option
>
> and in theory, but not available on mainnet:
>
>  -acceptnonstdtxn - relay/mine non standard transactions
>
> There's also the "prioritisetransaction" rpc, which can cause you to keep
> a low feerate transaction in your mempool longer than you might otherwise.
>
> I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only
> ones of those options commonly set, and those only rarely result in any
> differences in the txs at the top of the mempool.
>
> There are also quite a few parameters that aren't even runtime
> configurable:
>
>  - MAX_STANDARD_TX_WEIGHT
>  - MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)
>  - MAX_P2SH_SIGOPS (see also #26348)
>  - MAX_STANDARD_TX_SIGOPS_COST
>  - MAX_STANDARD_P2WSH_STACK_ITEMS
>  - MAX_STANDARD_P2WSH_STACK_ITEM_SIZE
>  - MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE
>  - MAX_STANDARD_P2WSH_SCRIPT_SIZE
>  - MAX_STANDARD_SCRIPTSIG_SIZE
>  - EXTRA_DESCENDANT_TX_SIZE_LIMIT
>  - MAX_REPLACEMENT_CANDIDATES

Re: [bitcoin-dev] On mempool policy consistency

[Gloria Zhao via bitcoin-dev]

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 it available in knots) haven't actually achieved
> much of a result in practice. So maybe this is just a special case

is true.

> The second thing is that whatever your relay policy is, you still
> need a path all the way to miners through nodes that will accept your
> transaction at every step. If you're making your mempool more restrictive
> (eg -permitbaremultisig=0, -datacarrier=0), that's easy for you (though
> you're making life more difficult for people who do create those sorts
> of txs); but if you want a more permissive policy (package relay,
> version-3-rbf, full-rbf), you might need to do some work.

> 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.

Yes, in most cases, whether Bitcoin Core is restricting or loosening
policy, the user in question is fine as long as they have a path from their
node to a miner that will accept it. This is the case for something like
-datacarriersize if the use case is putting stuff into OP_RETURN outputs,
or if they're LN and using CPFP carveout, v3, package relay, etc. But
replacement is not only a question of "will my transaction propagate" but
also, "will someone else's transaction propagate, invalidating mine" or, in
other words, "can I prevent someone else's transaction from propagating." A
zeroconf user relies on there *not* being a path from someone else's full
RBF node to a full RBF miner. This is why I think RBF is so controversial
in general, why -mempoolfullrbf on someone else's node is considered more
significant than another policy option, and why full RBF shouldn't be
compared with something like datacarriersize. I don't think past patterns
can be easily applied here, and I don't think this necessarily shows a
different "direction" in thinking about mempool policy in general.

Best,
Gloria

On Thu, Oct 27, 2022 at 12:52 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 propose deprecation of opt-in RBF in favor of full-RBF
>
> > If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> > too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> > consistent deprecation process w.r.t to policy rules heavily relied-on by
> > Bitcoin users, if we do so let sets a precedent satisfying as many folks
> as
> > we can.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same:
>
>   Firstly, there is no "the mempool". There is no global mempool. Rather
>   each node maintains its own mempool and accepts and rejects transaction
>   to that mempool using their own internal policies. Most nodes have
>   the same policies, but due to different start times, relay delays,
>   and other factors, not every node has the same mempool, although they
>   may be very similar.
>
>   -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> nodes running core have been quite small, with essentially the following
> options available:
>
>  -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
>  -mempoolexpiry - how long to keep txs in the mempool
>
>  -datacarrier - reject txs creating OP_RETURN outputs
>
>  -datacarriersize - maximum size of OP_RETURN data
>
>  -permitbaremultisig - prevent relay of bare multisig
>
>  -bytespersigop - changes how SIGOP accounting works for relay and
>  mining prioritisation
>
> as well as these, marked as "debug only" options (only shown with
> -help-debug):
>
>  -incrementalrelayfee - make it easier/harder to spam txs by only
>  slightly bumping the fee; marked as a "debug only" option
>
>  -dustrelayfee - make it easier/harder to create uneconomic utxos;
>  marked as a "debug only" option
>
>  -limit{descendant,ancestor}{count,size} - changes how large the
>  transaction chains can be; marked as a "debug only" option
>
> and in 

Re: [bitcoin-dev] On mempool policy consistency

[John Carvalho via bitcoin-dev]

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 will be "so we really should stop trying to impose optional
features, particularly when they affect existing use cases" but instead you
persist.

The problem is that RBF has already been an option for years, and anyone
that wants to use it can. Any escalation in Bitcoin Core code to support it
more deeply, or by default, is basically an unfair advantage to force the
market to do what it already has decided not to.

If wallets want to default to RBF, they can already do so, as evidenced by
Green Wallet (which I stopped using because it breaks the UX at Bitrefill).

Instead of Core devs admitting RBF is a minority use case, you seem to be
proposing that the market should now be obligated to prove it can defeat
RBF in a stronger form if it really wants to prove other use cases. This is
oppressive, dark-pattern design. We all know that Core has little ability
to sense the market, and the market has little ability to express itself to
Core. The idea that the market can always downvote or defeat a feature or
new complexity proposal is idealistic and unrealistic.

Superficial features should be decided at the surface (app level) not in
the protocol or node.

The default answer to ALL proposals is "No." Changes need to win market
acceptance, not get special access through Core devs baking them deeper and
deeper into the protocol and policies until everyone is forced into a new
design.

As I mentioned before, this behavior, if we are lucky, will result in more
mempool types, more implementations, and a more-difficult to modify
protocol, but ALL feature changes, default settings that make decisions for
users, and even all scaling changes, are speculative risks with
unpredictable outcomes.

I urge the culture of Core to respect these dynamics and become much more
conservative with proposing change. Please focus on efficiencies, bugs,
cleanup, reducing overhead, etc.

The current RBF movement feels like Core is strong-arming and shoe-horning
in a change that the market is not actually asking for. It is okay to leave
things as they are. It is okay if RBF remains a niche feature. It is not
okay for a small group of RBF-interested engineers to make commercial
Bitcoin use cases worse.

Let us realize the Bitcoin we already have. We already have a largely
unexplored canvas of taproot, lightning, UX, etc.

I expect the things I do with Bitcoin today to work FOREVER.

--
John Carvalho
CEO, 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/plain; charset=us-ascii
>
> 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 propose deprecation of opt-in RBF in favor of full-RBF
>
> > If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> > too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> > consistent deprecation process w.r.t to policy rules heavily relied-on by
> > Bitcoin users, if we do so let sets a precedent satisfying as many folks
> as
> > we can.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same:
>
>   Firstly, there is no "the mempool". There is no global mempool. Rather
>   each node maintains its own mempool and accepts and rejects transaction
>   to that mempool using their own internal policies. Most nodes have
>   the same policies, but due to different start times, relay delays,
>   and other factors, not every node has the same mempool, although they
>   may be very similar.
>
>   -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> nodes running core have been quite small, with essentially the following
> options available:
>
>  -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
>  -mempoolexpiry - how long to keep txs in the mempool
>
>  -datacarrier - reject txs creating OP_RETURN outputs
>
>  -datacarriersize - maximum size of OP_RETURN data
>
>  -permitbaremultisig - 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Johan Torås Halseth via bitcoin-dev]

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 and add more flexibility around adding HTLCs.

Thanks!

- Johan

On Thu, Oct 20, 2022 at 3:42 PM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> So it doesn't look like I'm ignoring a good question:
>
> No solid noninteractive ideas, unless we get some very flexible sighash
> softfork. Interactively, I think you can get collaborative fee bumps under
> the current consensus regime and ephemeral anchors. The child will just be
> built with inputs from different people.
>
> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne 
> wrote:
>
>> I'm also very happy to see this proposal, since it gets us closer to
>> having a mechanism that allows the contribution to feerate in an
>> "unauthenticated" way, which seems to be a very helpful feature for vaults
>> and other contracting protocols.
>>
>> One possible advantage of the sponsors interface -- and I'm curious for
>> your input here Greg -- is that with sponsors, assuming we relaxed the "one
>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>> collaboratively bump a tx's feerate. A simple example would be a batch
>> withdrawal from an exchange could be created with a low feerate, and then
>> multiple users with a vested interest of expedited confirmation could all
>> "chip in" to raise the feerate with multiple sponsor transactions.
>>
>> Having a single ephemeral output seems to create a situation where a
>> single UTXO has to shoulder the burden of CPFPing a package. Is there some
>> way we could (possibly later) amend the ephemeral anchor interface to allow
>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>> ephemeral anchors that would allow this?
>>
>>
>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Excellent proposal and I agree it does capture much of the spirit of
>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>
>>> The only drawbacks I see is they don't work for lower tx version
>>> contracts, so there's still something to be desired there, and that the
>>> requirement to sweep the output must be incentive compatible for the miner,
>>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>>> The Ephemeral UTXO concept can be a consensus rule (see
>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>>> a cleanup one can punt.
>>>
>>> One question I have is if V3 is designed for lightning, and this is
>>> designed for lightning, is there any sense in requiring these outputs for
>>> v3? That might help with e.g. anonymity set, as well as potentially keep
>>> the v3 surface smaller.
>>>
>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 > does that effectively mark output B as unspendable once the child
 gets confirmed?

 Not at all. It's a normal spend like before, since the parent has been
 confirmed. It's completely unrestricted, not being bound to any
 V3/ephemeral anchor restrictions on size, version, etc.

 On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Greg,
>
> Thank you very much for sharing your proposal!
>
> I think there's one thing about the second part of your proposal that
> I'm missing. Specifically, assuming the scenario of a v3 transaction with
> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
> transaction spends A and OP_TRUE, does that effectively mark output B as
> unspendable once the child gets confirmed? If so, isn't the implication
> therefore that to safely spend a transaction with an ephemeral anchor, all
> outputs must be spent? Thanks!
>
> Best,
> Arik
>
> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>
> Hello Everyone,
>
> Following up on the "V3 Transaction" discussion here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
> , I would like to elaborate a bit further on some potential follow-on work
> that would make pinning severely constrained in many setups].
>
> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks
> under some constraints[0]. This means that when a replacement is to be 
> made
> and propagated, it costs the expected amount of fees to do so. This is a
> great start. What's left in this subset of pinning is *package limit*
> pinning. In other 

Re: [bitcoin-dev] Refreshed BIP324

[Vasil Dimov via bitcoin-dev]

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 see more opinions on the topic.
[...]

It all makes perfect sense to me.

-- 
Vasil Dimov
gro.DSBeerF@dv
%
If 10 years from now, when you are doing something quick
and dirty, you suddenly visualize that I am looking over your
shoulders and say to yourself, "Dijkstra would not have liked this",
well that would be enough immortality for me.
-- Edsger W. Dijkstra


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev