<Murch>
#proposedmeetingtopic To release mempoolfullrbf or not to release mempoolfullrbf
<jamesob>
hi
<achow101>
I think silent payments would be nice to have. not sure what bytes1440000 wanted to discuss
<lightlike>
looks like bytes1440000 isn't in the channel
bytes1440000 has joined #bitcoin-core-dev
<luke-jr>
he tends to lurk via logs or something
<luke-jr>
see
<achow101>
they also don't appear to be here, so perhaps we can skip this topic for this week
<Murch>
Yeah, silent payments seem pretty cool
<Murch>
Bring it up next week again
<brunoerg>
Agreed
<bytes1440000>
why?
<Murch>
Ah, they're here
<Murch>
What's your topic?
<bytes1440000>
its a basic thing thats lacking and nobody likes bip47
<sipa>
i don't think there is any disagreement about that
<instagibbs>
what's the call to action here
<sipa>
it seems like a cool scheme, i'm glad to see it being worked on
<bytes1440000>
ruben did the research why not use it
<luke-jr>
michaelfolkson seemed to be questioning it, but IMO there's no reason to exclude it when it's ready
<luke-jr>
bytes1440000: we should, as soon as it's ready
<bytes1440000>
i agree with luke-jr
<achow101>
no rason we shouldn't, but it's still work in progress, no?
<bytes1440000>
yes
<sipa>
the PR is listed as proof-of-concept, and there seem to be some unresolved discussion about the scheme's security
<bytes1440000>
pls review it
<RubenSomsen>
hey
<lightlike>
the PR says "The purpose of this PR is not a final version, but to start the discussion and get benchmarks based on a real implementation." - so it seems like it's not intended for merge anytime soon by the author?
<luke-jr>
I think it could benefit from being split up. Sending support seems like it should be a very small change as step 1 IMO.
<luke-jr>
as soon as the spec is finalised
<Murch>
Some people expressed interest in contributing to it when I talked to them in Atlanta
<instagibbs>
right I think it's chicken and spec egg
<Murch>
I think it'll get some attention
<RubenSomsen>
sipa: I discussed the security concerns with andytoshi and others, and it doesn't seem like there are any large issues
<luke-jr>
though I guess that may block on the wallet end
<sipa>
RubenSomsen: ah, good to hear
<instagibbs>
RubenSomsen, link to list of concerns just for my perusal
<instagibbs>
?
<instagibbs>
anyways, fine after meeting
<sipa>
instagibbs: chicken and spegg
<luke-jr>
bytes1440000: anything specific to discuss about it?
<bytes1440000>
i will bring chicken pls merge this... luke-jr: its pending because 2 major wallet devs in this repo didnt review and it was not never up for one review channel..
<achow101>
#topic To release mempoolfullrbf or not to release mempoolfullrbf (Murch)
<core-meetingbot>
topic: To release mempoolfullrbf or not to release mempoolfullrbf (Murch)
<bytes1440000>
Its a basic feature
<luke-jr>
bytes1440000: it's nowhere near ready for merge still AFAICT. there are no required specific-person reviews either.
<instagibbs>
it looks like it's getting reasonable attention for the stage it's at
<sipa>
bytes1440000: you won't find disagreement here, but it won't be merged without being finished (even by the author's own thoughts) and properly reviewed.
<luke-jr>
24.x is already feature-frozen with mempoolfullrbf as an option. There is no bug. So I see no justification to revert.
<bytes1440000>
luke-jr: whats lacking?
<Murch>
So, it seems that the `mempoolfullrbf` startup option is pretty controversial, but removing it is also getting NACKs, so I'm curious whether 24.0 should be released with or without the `mempoolfullrbf` option
<sipa>
bytes1440000: and it's not unreasonable to ask people to prioritize it, but that's ultimately up to them. As far as I can tell, it's getting plenty of attention, but it's not nearly there.
<luke-jr>
bytes1440000: I'd have to look at if my previous comments were addressed, but at least I don't see a BIP yet.
<sipa>
So perhaps it's worth putting on the high-prio list?
<brunoerg>
If we decide to release it with `mempoolfullrbf`, is it gonna be true or false by default?
<lightlike>
before even thinking about merging, it would be helpful for the author to put it out of draft - if they think it is mature enough for that.
<bytes1440000>
sipa: i do not disagree with you but get disappointed when prs like this are pending for years
<Murch>
brunoerg: It's currently defaulting to `false`
<jonatack>
It may be useful to list the open PR mempoolfullrbf proposals in question
<brunoerg>
Murch: sounds good, thanks
<sipa>
bytes1440000: This one seems to be making great progress. I wouldn't call it "pending" for anything.
<luke-jr>
brunoerg: it's currently false by default, and I think it should remain so for 24.x for the same reason
<jonatack>
as there are/have been several
<brunoerg>
luke-jr: I agree
<Murch>
bytes1440000: Silent payments was proposed in March this year. It's not been years.
<luke-jr>
bytes1440000: IMO once the authors are satisfied with the design, next steps are a BIP, and then wallet sending-only support
<bytes1440000>
then maybe wrong
<achow101>
jonatack: #26438 #26287 and the "do nothing" proposal
<Murch>
Are we still talking about silent payments or about mempoolfullrbf?
<luke-jr>
both >_<
<Murch>
Happy to finish SP if there is more to talk about
<Murch>
But I don't have the impression that there is.
<bytes1440000>
no just merge it
<achow101>
no, that's not helpful
<luke-jr>
I guess we could discuss the RPC interfaces. I think it should use the existing RPCs for the first wallet-support step. But that's past sending-only and BIP…
<sipa>
bytes1440000: Now you're being obnoxious. It clearly can't be merged before even the author thinks it's ready.
<Murch>
bytes1440000: If you're trying to be taken seriously, you're failing miserably.
<luke-jr>
bytes1440000: it's not even ready enough for me to consider for Knots. :/
<sipa>
Just because a scheme is cool doesn't mean it's ready.
<sipa>
Now let's move on.
<luke-jr>
bytes1440000: we all want it, but it's just not there yet.
<instagibbs>
Murch, take it away
<Murch>
Alright. So `mempoolfullrbf` is merged, it defaults to false. There are at least two proposals to revert it in one way or another, one to just move ahead, and a few dozen emails on the mailing list as well as numerous comments on PRs
<Murch>
Clearly, the feature is controversial
<Murch>
I find arguments on both sides rather weak
<luke-jr>
IMO there are no valid arguments for denying users the right to decide.
<RubenSomsen>
bytes1440000: josie[m] expressed interest in writing a Silent Payments BIP starting this January
<NorrinRadd>
is it possible to keep a running tally of how individuals feel on this topic. I've observed a couple weeks of meetings and I think the context gets forgotten from week to week. There is disagreement and without written records it is difficult for anyone to remember where everyone else stands
<luke-jr>
arguments for/against full RBF, are not arguments against letting users choose their own policy
<luke-jr>
NorrinRadd: it's not a consensus rule, or a rule at all. It's a policy, which each user can decide for himself.
<sipa>
luke-jr: But we need some bar for inclusion. We don't support every random policy choice that someone may come up with.
<achow101>
NorrinRadd: people's opinions have changed recently though
<Murch>
luke-jr: We do want mempools across the network to be homogeneous for blocks to propagate as well as possible, and the capability to “opt-out” of replaceability is actively being used on the network.
<bytes1440000>
no arguments against full RBF as an option
<luke-jr>
sipa: we should, if there are users who want it, and developers who will support it.
<sipa>
And everyone can already choose for themselves, by choosing the software they run.
<luke-jr>
Murch: no, mempools should not be homogeneous
<Murch>
luke-jr, care to elaborate?
<sipa>
I don't know where I stand right now. But it's a more nuanced discussion then "we have to let people choose".
<luke-jr>
sipa: if nobody wanted to support the feature, that's different from obstructing it when developers are willing to support it
<sipa>
That's fair.
<NorrinRadd>
achow101 yes the tally can always be updated accordingly
<jonatack>
Given the controversial nature of adding the option, the most prudent course may be "do no harm" and not include it for v24, while continuing discussion for future releases
<luke-jr>
Murch: homogeneous mempools implies a central policy dictator(s)
<luke-jr>
jonatack: it doesn't do harm
<achow101>
in the interest of getting 24 out the door, perhaps we should revert for 24.0 only, and then we can keep having this discussion for the next 6 months before 25
<luke-jr>
jonatack: users who don't want it (and who don't care) are entirely unaffected
<jonatack>
as it is clear that the current level of discussion did not fully take place when the decision to merge the option was made
<sipa>
luke-jr: I disagree with that. People have an incentive to choose largely similar policies, as long as they don't have specific objections.
<Murch>
jonatack: that sounds like a fair assessment to me
<luke-jr>
sipa: they might coincidentally overlap, but that's different IMO
<lightlike>
would reverting it in 24 but keeping it in master be a compromise?
<luke-jr>
reverting it in 24.x should require a bug in it.
<luke-jr>
there is no bug in it.
<luke-jr>
controversy over an option is not a bug.
<NorrinRadd>
achow101 i agree
<NorrinRadd>
jonatack i agree
<luke-jr>
you have a vocal minority arguing that they should force EVERYONE to use their policy preference
<bytes1440000>
NACK to all PRs trying to revert a basic option that is false by default
<luke-jr>
even if it was a majority, they should not be forcing it on people who disagree
<bytes1440000>
If some business or project is affected by this, they should hire new security devs
<NorrinRadd>
bruno and luke-jr seems to agree to leaving it to false also
<achow101>
the option to run use the option would still be there for those who care. it's in knots, its in 3 rcs, and it'll be in master too
<luke-jr>
achow101: doesn't mean we should give in to bullying for 24.0
<NorrinRadd>
businesses that depend zero conf should look to investing into lightning as soon as possible it seems.
<brunoerg>
NorrinRadd: +1
<Murch>
NorrinRadd: TBF, Muun and Bitrefill seem to agree, but just are asking for more time before an option is deployed
<NorrinRadd>
maybe there can be some economic way of incentivizing that more
<Murch>
Synonym seems to be a bit less flexible in their expectations.
<luke-jr>
there has been an option for years
<achow101>
luke-jr: however some of the people who supported the option originally have changed their minds about releasing it
<luke-jr>
achow101: does that matter?
<sipa>
I believe it's a misconception that the presence of a default-off option isn't going to materially affect anyone. But I've also learned that one of the reasons why the option was being proposed in the first place was perhaps not nearly as strong (there is little gained for any real use case today by the policy change).
<luke-jr>
achow101: they don't get to force users any more than anyone else
<sipa>
*is going to materially affect anyone
<bytes1440000>
murch: the kind of misinformation shared by those, I cannot trust not sure about others
<Murch>
I have recently gained more appreciation for the idea of people wanting to provide a social signal in the form of signaling the intent not to replace, even if that is technically not enforceable
<instagibbs>
sipa, removing an option will likely effect it more, perhaps
<achow101>
luke-jr: I wouldn't say that those against the option are bullying, especially since they have convinced some people, although there definitely are some people bullying
<bytes1440000>
its not default and okay
<luke-jr>
Murch: they can still signal that
<Murch>
Since everyone has to pick a `nSequence` for every input on every transaction, it's essentially already as much “opt-in” as it is “opt-out”
<sipa>
instagibbs: Yeah, I think the longer the controversy rages, the higher the percentage of people is going to be that go out of their way to turn on fullrbf. That may actually have a bigger effect than having the option available in a release.
<NorrinRadd>
achow101 you can mention who they are?
<instagibbs>
sipa, they're going to run preferential peering
<sipa>
Though I also think that that percentage will remain small.
<instagibbs>
most likely
<NorrinRadd>
(if someone does collect a tally, maybe chat logs can help populate it)
<instagibbs>
if it's "just a cherry pick", well, that one is pretty small
<NorrinRadd>
luke-jr what's the solution for synonym?
<luke-jr>
?
<bytes1440000>
Peter Todds mentioned privacy
<bytes1440000>
Privacy is worse with his method on ml
<sipa>
I don't feel this is the right place to discuss the disadvantages/advantages of actually having the fullrbf policy deployed on the network.
<luke-jr>
NorrinRadd: I don't know what Synonym is, but I'm sure if they're relying on unconfirmed transactions, their system is already broken
<bytes1440000>
just run knots and core
<bytes1440000>
and wait for core release
<NorrinRadd>
most here seem to agree to leaving the option present and defaulting it to off.
<Murch>
So, stupid question. We require rough consensus to merge stuff. `mempoolfullrbf` had support when it got merged, but the reversal doesn't seem to have rough consensus. I don't think it would have clear support to be merged today either.
<Murch>
So where does that leave us with the release?
<NorrinRadd>
I think that's ultimately the way it will fully activated, as it will be left up to users and not this minute group of people that dev but do not fully dictate to all users and miners
<achow101>
Murch: with releasing it I think
<luke-jr>
Murch: still feature-frozen, as it has been for weeks?
<NorrinRadd>
achow101 ++
<NorrinRadd>
unless there's some severe consequences to leaving the option and defaulting to off, i don't see why it cannot be left in
<Murch>
luke-jr: I think that the “rough consensus” that the feature had when it got merged predated the discussion that the feature prompted. so did it actually have rough consensus or just sneak by?
<NorrinRadd>
am i correct in thinking that the people that would directly affect the zero conf businesses would be miners if a good amount of them decided to begin prioritizing higher fee txs?
<luke-jr>
Murch: discussions after feature freeze, are for future releases
<bytes1440000>
NorrinRadd RBF by default is done-NACK
<bytes1440000>
ALL this is POLITICS
<Murch>
NorrinRadd: Businesses relying on providing unbacked credit on a transaction pinky promising finality, yes
<luke-jr>
bytes1440000: Full RBF has never been default in Core, and isn't now
<bytes1440000>
luke-jr: it was never and I never said it was
<Murch>
So, clearly such businesses are affected, but I have yet to see a direct benefit that we expect from releasing `mempoolfullrbf`
<Murch>
It seems such benefits are either theoretical or tenuous
<Murch>
So are we releasing it just to show zeroconf businesses that they shouldn't be relying on unconfirmed transactions?
<instagibbs>
You'll likely make uptake worse if you remove it
<achow101>
instagibbs: this entire discussion has made uptake worse
<Murch>
Because that's circular reasoning
<Murch>
And I don't think it's urgent to show them they're wrong
<sipa>
(or better)
<sipa>
depending on your POV
<instagibbs>
haha yes sipa
<Murch>
instagibbs: I'll take Streisand Effect for 100 plesae
<NorrinRadd>
Murch Re: direct benefit, i read something very convincing in glozow's summary page. it's basic economics. miners naturally want to select the highest fee txs. we can artificially tell them to not do that?
<Murch>
So, maybe we're all getting what we want by removing it? :D
<sipa>
NorrinRadd: It's really not that simple. But I think that's a discussion for the ML.
<Murch>
that was my idea of a joke, for the people later reading this log >_>
<luke-jr>
Murch: it's certainly tempting to just sit back and let Core remove it, then tell people it's yet another reason they should be using Knots instead :P
<achow101>
we're at the top of the hour so I'll going to end the meeting now, but feel free to continue discussing
<kanzure>
if zeroconf businesses like it for the convenience then they will really get a kick out of just giving away products for free (it's even more convenient)
<bytes1440000>
I just wanted to mention one thing before... privacy is everything... if alice sends 0.01 btc to bob but bob can verify nobody in the world should know what happened
varioust has joined #bitcoin-core-dev
<laanwj>
oops... i forgot about the hour change somehow
<instagibbs>
best privacy is to never move your coins ever
___nick___ has quit [Ping timeout: 252 seconds]
<sipa>
how about never having any coins to begin with?
<luke-jr>
XD
<sipa>
or other money, of any kind
___nick___ has joined #bitcoin-core-dev
<kanzure>
they can't sanction your property if you don't have any property
<achow101>
lose them all in a boating accident
<luke-jr>
reminds me of the meme where a gorilla says humans are dumb for having money
Talkless has quit [Quit: Konversation terminated!]
andrewtoth has quit [Remote host closed the connection]
andrewtoth has joined #bitcoin-core-dev
<bytes1440000>
sipa will find a way since everyone is talking about zkp
amovfx has quit [Remote host closed the connection]
nanotube has quit [Ping timeout: 246 seconds]
jonatack has quit [Ping timeout: 246 seconds]
<laanwj>
ah yess "welcome to 2030. i own nothing, have perfect privacy due to that, and life has never been better" wasn't it
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx has joined #bitcoin-core-dev
hg has quit [Ping timeout: 252 seconds]
hg has joined #bitcoin-core-dev
brunoerg has quit []
amovfx has quit [Remote host closed the connection]
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
jonatack has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 252 seconds]
jonatack has quit [Ping timeout: 246 seconds]
varioust has quit [Ping timeout: 272 seconds]
amovfx has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
bytes1440000 has quit [Quit: Client closed]
Aaronvan_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 272 seconds]
sudoforge has joined #bitcoin-core-dev
hg has quit [Quit: WeeChat 3.7.1]
<luke-jr>
kind of weird that chain.hasAssumedValidChain() has nothing to do with assumevalid :x
amovfx has quit [Remote host closed the connection]