<bitcoin-git>
bitcoin/master d256992 Greg Sanders: Verify PSBT inputs rather than check for fields being empty
<bitcoin-git>
bitcoin/master e133264 Greg Sanders: Add test for PSBT input verification
<bitcoin-git>
bitcoin/master 2ac71d2 fanquake: Merge bitcoin/bitcoin#25595: Verify PSBT inputs rather than check for fiel...
<bitcoin-git>
[bitcoin] fanquake merged pull request #25595: Verify PSBT inputs rather than check for fields being empty (master...verify_psbt_input) https://github.com/bitcoin/bitcoin/pull/25595
Zenton has quit [Ping timeout: 252 seconds]
sipsorcery has quit [Ping timeout: 246 seconds]
sipsorcery has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
sipsorcery has quit [Remote host closed the connection]
amovfx_ has quit [Ping timeout: 246 seconds]
<bitcoin-git>
[bitcoin] ishaanam opened pull request #26347: wallet: ensure the wallet is unlocked when needed for rescanning (master...rescanblockchain_unlock_wallet) https://github.com/bitcoin/bitcoin/pull/26347
amovfx has quit [Ping timeout: 252 seconds]
NorrinRadd has quit [Ping timeout: 272 seconds]
NorrinRadd has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 255 seconds]
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
jonatack1 has joined #bitcoin-core-dev
PaperSwordAlt has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 260 seconds]
PaperSwordAlt has quit [Ping timeout: 252 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
jonatack1 has quit [Read error: Connection reset by peer]
amovfx_ has quit [Ping timeout: 255 seconds]
<bitcoin-git>
[bitcoin] SergioDemianLerner opened pull request #26348: Make P2SH redeem script "IF .. PUSH x ELSE ... PUSH y ENDIF CHECKMULTISIG .. " standard (master...master) https://github.com/bitcoin/bitcoin/pull/26348
amovfx has quit [Ping timeout: 252 seconds]
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] w0xlt opened pull request #26349: rpc: make `address` field optional `list{transactions, sinceblock}` response (master...issue_26338) https://github.com/bitcoin/bitcoin/pull/26349
andrewtoth has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
fanta1 has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 258 seconds]
ghost43 has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
dviola has quit [Quit: WeeChat 3.7]
amovfx_ has quit [Ping timeout: 255 seconds]
_andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
sudoforge has quit [Quit: 404]
amovfx has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #26350: [22.x] Revert "build: Use Homebrew's sqlite package if it is available" (22.x...revert_slow_macos_sqlite_22_x) https://github.com/bitcoin/bitcoin/pull/26350
murrayn has quit [Ping timeout: 252 seconds]
amovfx_ has quit [Ping timeout: 246 seconds]
jarthur has quit [Quit: jarthur]
amovfx_ has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 272 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
Zenton has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx_ has quit [Ping timeout: 252 seconds]
chipxxx has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
dermoth has quit [Ping timeout: 264 seconds]
greypw2546002 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
dermoth has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
Guest6268 has joined #bitcoin-core-dev
Guest6268 has quit [Client Quit]
amovfx_ has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 255 seconds]
sipsorcery has quit [Ping timeout: 252 seconds]
amovfx_ has quit [Ping timeout: 255 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 248 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
vasild has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
murrayn has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 255 seconds]
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
amovfx_ has quit [Ping timeout: 246 seconds]
<bitcoin-git>
[bitcoin] Sjors opened pull request #26351: guix: bump time-machine to 39dcbc7fa3c02ff5c9682f25e1c29667dbfe7827 (master...2022/10/guix-bump-timemachine) https://github.com/bitcoin/bitcoin/pull/26351
vasild has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
fanta1 has quit [Quit: fanta1]
fanta1 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 255 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
fanta1 has quit [Quit: fanta1]
sipsorcery has quit [Ping timeout: 246 seconds]
amovfx_ has quit [Ping timeout: 255 seconds]
TheRec has quit []
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 268 seconds]
kexkey has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx has joined #bitcoin-core-dev
TheRec has joined #bitcoin-core-dev
TheRec has quit [Changing host]
TheRec has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
jonatack1 has joined #bitcoin-core-dev
amovfx_ has quit [Ping timeout: 255 seconds]
amovfx has quit [Ping timeout: 255 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
bomb-on_ has joined #bitcoin-core-dev
bomb-on has quit [Ping timeout: 252 seconds]
bitdex has quit [Quit: = ""]
amovfx has joined #bitcoin-core-dev
fanta1 has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
amovfx has quit [Ping timeout: 255 seconds]
yanmaani2 has quit [Ping timeout: 258 seconds]
vasild has quit [Ping timeout: 258 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
amovfx_ has quit [Ping timeout: 252 seconds]
vasild has joined #bitcoin-core-dev
yanmaani2 has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 246 seconds]
amovfx has quit [Ping timeout: 255 seconds]
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 255 seconds]
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master 05b8c76 furszy: bench: add "priority level" to the benchmark framework
<bitcoin-git>
bitcoin/master 3da7cd2 furszy: bench: explicitly make all current benchmarks "high" priority
<bitcoin-git>
[bitcoin] achow101 merged pull request #26158: bench: add "priority level" to the benchmark framework (master...2022_bench_priority_level) https://github.com/bitcoin/bitcoin/pull/26158
dviola has joined #bitcoin-core-dev
bomb-on_ has quit [Read error: Connection reset by peer]
bomb-on has joined #bitcoin-core-dev
hg has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 246 seconds]
amovfx_ has quit [Ping timeout: 246 seconds]
elichai2 has joined #bitcoin-core-dev
hg has quit [Ping timeout: 255 seconds]
jonatack1 has quit [Read error: Connection reset by peer]
amovfx has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
amovfx_ has quit [Ping timeout: 255 seconds]
amovfx has quit [Ping timeout: 246 seconds]
hg has joined #bitcoin-core-dev
amovfx has joined #bitcoin-core-dev
amovfx has quit [Remote host closed the connection]
amovfx has joined #bitcoin-core-dev
_Sam-- has joined #bitcoin-core-dev
amovfx has quit [Remote host closed the connection]
amovfx has joined #bitcoin-core-dev
<dhruv>
For the last couple days, when I try to run CirrusCI on my fork, most of the times, it fails with "Failed to checkout HEAD_SHA", and then occasionally it start to work. Are others seeing this too?
<dhruv>
starts**
amovfx has quit [Ping timeout: 252 seconds]
amovfx has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] theStack opened pull request #26352: doc: add `scanblocks` to list of descriptor RPCs (master...202210-doc-add_scanblocks_to_doc_descriptors) https://github.com/bitcoin/bitcoin/pull/26352
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
kexkey has quit [Ping timeout: 252 seconds]
amovfx_ has joined #bitcoin-core-dev
kexkey has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
amovfx_ has quit [Ping timeout: 255 seconds]
brunoerg has quit [Ping timeout: 246 seconds]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
amovfx_ has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has quit [Remote host closed the connection]
Guest9119 has quit [Client Quit]
greypw2546002 has joined #bitcoin-core-dev
Guest9144 has quit [Client Quit]
greypw2546002 has quit [Remote host closed the connection]
greypw2546002 has joined #bitcoin-core-dev
hg has quit [Quit: WeeChat 3.7]
sebareca has joined #bitcoin-core-dev
esneider has joined #bitcoin-core-dev
csgui has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dergoegge opened pull request #26355: p2p: Handle IsContinuationOfLowWorkHeadersSync return value correctly when new headers sync is started (master...2022-10-nbits-headerssync) https://github.com/bitcoin/bitcoin/pull/26355
<laanwj>
four meeting topics have been proposedin advance this time: Drop GUI repo and bring GUI work back to the main repo for now (achow101), Adding (more) maintainers as GitHub org owners (achow101), Moratorium on refactors that are not part of larger projects that bring tangible features and fixes (achow101), defer fullrbf for 24.0(or not) (instagibbs)
<dergoegge>
#25515 has quite a few concept acks now, so no longer chasing i guess
<gribble>
https://github.com/bitcoin/bitcoin/issues/25515 | net, test: Virtualise CConnman and add initial PeerManager unit tests by dergoegge · Pull Request #25515 · bitcoin/bitcoin · GitHub
<laanwj>
dergoegge: move it to blockers?
<dergoegge>
sure
<stickies-v>
LarryRuane: should we wait with (re-)reviewing until you've added the benchmark test, as you just announced?
<larryruane>
yes good idea, thanks
Guest35 has joined #bitcoin-core-dev
Guest35 has quit [Client Quit]
<bitcoin-git>
[bitcoin] NorrinRadd opened pull request #26356: test: Use a consistent assert functions: ref #23119 (master...issue/23119/part-1) https://github.com/bitcoin/bitcoin/pull/26356
<laanwj>
#topic Drop GUI repo and bring GUI work back to the main repo for now (achow101)
<core-meetingbot>
topic: Drop GUI repo and bring GUI work back to the main repo for now (achow101)
<jarolrod>
i don't have a strong opinion on wether we move in the development from bitcoin-core/gui into bitcoin/bitcoin
<achow101>
I was speaking with some contributors last week at CoreDev about repo separation, and some dissastisfaction with the current GUI repo split was discussed. In particular, some contributors felt that the separation makes it difficult to work on the GUI as it is not that obvious that there is a separate GUI repo. This has lead to things in the GUI repo getting little review since many forget that it even exists. It is also confusing to new
<achow101>
contributors as the GUI is in the main repo, so work can be done in a fork of the main repo before realizing that the GUI repo exists. There was also a concern about funding as some funders may not recognize that the GUI repo is in fact part of Bitcoin Core.
<luke-jr>
a fork of the main repo can push to the GUI repo just as well…
<achow101>
While I agree that we should want to have components of Bitcoin Core separated into separate repos, I think doing so now is premature. We should perhaps wait until it is possible to fully separate componenets before doing so. That way, cloning the main repo does not fetch the GUI repo, and work on each specific component requires going to each individual repo to even get the code.
<luke-jr>
and funding issues should be sorted out at the funding level, which really should not be specific to Core at all, much less a single repo :/
<hebasto>
quoting fanquake from oct 15 "I think merging GUI development back into the main repo would quite be a regression. As far as I'm aware, for non-GUI contributors, it's been a great filter for keeping all the not-related-to-bitcoin GUI stuff out of their inboxes (probably similar for the thousands of bitcoin/bitcoin subscribers)."
<laanwj>
it's mostly to have the PRs and issues separate, we can't really move them back
<hebasto>
agree with fanquake
<jarolrod>
The reality with gui development is that sometimes trivial things are discussed or trivial pr's are opened, if it's really annoying for some to see these discussions pop up, then it's best to keep the repo's as they are
<laanwj>
it would involve closing everything and reopening it in the main repo, which, yeah seems a lot of hassle
<luke-jr>
I don't feel strongly for keeping them split, but I don't think all the reasons are great for a re-merge
<ariard>
i think you're point is bundling few different things: a) a communication issue about the component existence, b) the management of interdependency and c) the social/professional recognition of working on the GUI
<achow101>
luke-jr: AFAICT GitHub does not allow you to open PRs unless the repo is a direct fork
<luke-jr>
achow101: you can still push your git repo to the fork of the GUI
<achow101>
luke-jr: yes, but this may be confusing to new contributors
<achow101>
hebasto: personally there are some gui things that I would like to review, but they always fall off my list because I forget it's existence
<luke-jr>
perhaps better docs?
<luke-jr>
and/or getting Github to fix it
<luke-jr>
if we move to Gitlab, does that resolve it?
<achow101>
I would find it easier if its issues and prs would be in the same repo
<laanwj>
add a link in the top-level README maybe?
<laanwj>
if there isn't, i wouldn't know
<achow101>
I don't think "user education" (dev education I guess) is really a good solution. It's just not intuitive
<ariard>
achow101: tbh, few contributors have already to live in a multi repo world, in the sense monitoring libsecp256k1, the bips repo, the bolts repo, maybe a lightning implem, maybe bitcoin-inquisition, sounds more a question of personal time-management
fanta1 has quit [Quit: fanta1]
amovfx has joined #bitcoin-core-dev
<jarolrod>
I would be ok with either option, but in terms of not redoing a time of work moving between repo's, I'd think that we should keep the repo's as they are
<jarolrod>
another point brought up was on the qml gui and the future of the gui
<jarolrod>
development on bitcoin-core/gui-qml has been slow, at times it's only been me working on it, but that is where the future of the gui is
<jarolrod>
What I can promise is i'll be spending as much time as possible as I can to finish this before the next release, it doesn't mean we'd include it in core at that time, but the conversation can start on what we're going to do with the gui in terms of the development process and the structure of repo's
<jarolrod>
We're building something special there, if you're interested in seeing how we're progressing you can join in on our calls every wednesday at 14 UTC here: https://meet.jit.si/BitcoinCoreAppDesignCall
<achow101>
re trivial stuff in gui: I don't think that's a strong argument. we get lots of dumb and trivial stuff in the main repo too
<achow101>
I don't think it would be any more annoying than it already is
<hebasto>
merging repos is going to bring more dissatisfaction among developers then now...
<luke-jr>
jarolrod: I'm against prematurely deciding QML is going to replace Widgets..
<jarolrod>
^ of course, not dictating, just my opinion :D
<achow101>
ariard: for the most part, those repos don't share any code. right now, the main repo and the gui repo are completely clones of each other, so if you want the gui, you can still get it in the main repo. this is not the case for the others you mentioned
<achow101>
my point was that repo separation should follow with code separation
<luke-jr>
achow101: I don't think you've made a strong argument for that
<luke-jr>
half of the reasons seem frankly like reasons _to_ keep them separated
<laanwj>
right it's just an organizational thing, so you an ignore GUI stuff if you want to
<achow101>
people forget that it exists and it's harder for new contributors is a reason to keep them separate??
<ariard>
achow101: at least, they share libsecp256k1; though my point was more an answer to "oh wait i've to remember there is a GUI repo" thought, it sounds to belong more to one's workflow and personal priorities
Talkless has quit [Quit: Konversation terminated!]
<laanwj>
if new contributors file a GUI pr/issue in the main repo it's not a big deal they usually just get pointed to the right one
<luke-jr>
achow101: no, those are the arguments to re-merge; but ultimately problems better dealt with other ways even then
brunoerg has quit [Remote host closed the connection]
<luke-jr>
I need to go pick up kids from school; but FWIW: there are some maintainers I don't trust with org ownership (and others I would); no opinion on refactor freeze; and against "anti-feature" fullrbf changes
brunoerg has joined #bitcoin-core-dev
<furszy>
I personally haven't seen much movement on the current GUI repo, which pulled me down from continue contributing there. Not sure if that is because of the separated repository or because all our resources are focused on the QML project (which make sense if we are just going to replace the GUI entirely)
<laanwj>
there's still 3 other topics left, we might want to move to a next one
<glozow>
(meta-meeting comment: i wonder if we'll run out of time to discuss v24.0 full rbf? not to discount achow's proposed topics, but perhaps worth reordering based on urgency...?)
<laanwj>
glozow: agree
<NorrinRadd>
achow101 would it help if the gui code is removed from the main report and instead referenced?
<ariard>
glozow: +1, we're already half-meeting time, and other subjects could be post-pone to next meetings
<achow101>
glozow: yes (my topics are not urgent)
<instagibbs>
glozow, sounds like volunteering to take on the topic]
* instagibbs
logs off
<NorrinRadd>
anecdote: I'm a very new comer and I came across the documentation that teh gui is maintained in a different repo
<achow101>
NorrinRadd: I think so. If we could get to a point where the gui could be removed from the main repo, and put into it's own repo with just the gui, then I think repo separation makes sense there
jonatack has joined #bitcoin-core-dev
<laanwj>
yes, true gui repo separation would definitely be better
<laanwj>
i think that's something to work towards, not going backwards
<hebasto>
our release process should be modified for that
<glozow>
agree working towards true separation would be great
<jonatack>
hi
<laanwj>
hi
bytes1440000 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
<laanwj>
ok, ew can continue this next meeting if needed, going for next topic
<laanwj>
#topic defer fullrbf for 24.0(or not) (instagibbs)
<core-meetingbot>
topic: defer fullrbf for 24.0(or not) (instagibbs)
<instagibbs>
mempoolfullrbf in mainnet(or not): #26323 does two things: disables mempoolfullrbf on mainnet until ~6 months from now, then switches the argument to default true. The intention was to get it into 24.0 This needs to be decided
<instagibbs>
specifically the "disable on mainnet" or not part, due to release. I have my own opinion, and there are many others of course
<achow101>
nack-ish. I don't like that I can't turn it on before the flag day.
sebareca has quit [Quit: Client closed]
sebareca has joined #bitcoin-core-dev
<ariard>
instagibbs: i think there are still voices of 0confs operators who sounds to oppose full-rbf itself, maybe a preliminary concern to think about before the deployment method we pick up
<instagibbs>
ariard, I feel pretty safe not stalling to people who dont understand it's changing eventually
<achow101>
I feel like we had this conversation 7 years ago
<instagibbs>
Anyways, this is about the release specifically. If there's general consensus against disabling, we should just say we're not doing that
<instagibbs>
then work on part 2 which is flag day window/strategy
<ariard>
instagibbs: i think this is reasonable outcome, evaluating we have done a satisfying work of communication ahead, and those folks are running after a subject already reaching majority of opinions
<ariard>
just notifiying the existence of those voices
<_aj_>
achow101: wasn't the result of the conversation 7 years ago that people who wanted rbf would opt-in to it, per bip 125?
<instagibbs>
I'd rather not relitigate, this is about 24.0 :)
<instagibbs>
If we need more time to discuss flag day, we need more time to discuss it and should just work that direction
<ariard>
i don't think 7 years ago the pinning issues which are affecting lightning/coinjoins and have been the original technical motivation of this renewed full-rbf deployment were known by the community, to be fair
<achow101>
I don't mind a flag day so long as it is _only_ to change the default to true. a flag day for disabling the option is nack from me
<achow101>
but then in that case, it doesn't seem to be much different from just releasing 25.0 with -mempoolfullrbf=1
<instagibbs>
so I motion to keep arg static and false, and continue conversation about flag day
<jonatack>
(fwiw, i found the serge kotliar (bitrefill) ML post on the topic (relating to FX volatility in addition to zero conf) interesting as well, though i haven't finished parsing it; suggest reading it along with the post by dario (muun wallet) regarding zero conf
<glozow>
I think whatever option we take, it should be made abundantly clear to users that Core does not control whether full RBF happens or not. We could revert 25353 and it could still happen. We could do a flag day activation and it could happen sooner than that. I imagine that a coordinated full RBF activation is the smoothest/safest if everybody reasonable agrees to it, but then others might yell at Core for "dictating policy."
<ariard>
let's phrase the discussion in another way; do we think the activation of full-rbf X months from now would cause unsolvable dangers for 0confs apps/services ?
<ariard>
in the sense, do we think the issues raised by full-rbf on their services, are technicall solvable if they allocate the engineering and operational efforts
<achow101>
ariard: I think all of the issues these services have raised are solvable, with the most basic solution that most services have decided to use being wait for a confirmation
<instagibbs>
"solve the free option problem" is a bit out of scope for Core
<glozow>
the free option problem is already a thing, according to Sergej's ml post
<_aj_>
ariard: for muun, which is lightning focussed anyway; 6 months sounds fine; for bitrefill, seems like it would take 2 years or more to get lightning adoption high enough to be smooth
<_aj_>
ariard: (going from what they've said on list)
<instagibbs>
_aj_, it would tie policy directly to a specific L2 protocol, so I nack on any metric like this
<ariard>
instagibbs: to me, that's a bit of the crux of the discussions between core and business, what is the scope of policy mechanisms and from what they should be responsible of?
<_aj_>
instagibbs: huh?
<instagibbs>
_aj_, "my deposits must be X% in this specific type"
<ariard>
_aj_: yes, the last muun replied also underscore other 0confs services, with less manpower/engineering resources might need more time
<_aj_>
instagibbs: it'd tie policy to having some replacement for on-chain zeroconf; with lightning being the most likely replacement
<_aj_>
instagibbs: if fedimint or something comes along and takes over in the meantime, that's fine too?
<instagibbs>
failed TTP business-y ideas have been around for almost 8 years
brunoerg has joined #bitcoin-core-dev
<glozow>
ariard: the technical issues are solvable, it sounds like muun just wants more time. Bitrefill is able to detect payment replacements and already has some double spend protections, the problem there is UX
<ariard>
glozow: i'm converging, though note a bad UX might be a source of users funds loss or freezing or mistakes, especially if they have to shipped it fast
<instagibbs>
_aj_, well, if they said "2 years", maybe I'd be fine
<glozow>
i mean they also told me they had revert using bech32 addresses because most users couldn't pay them
<glozow>
back in the day
<_aj_>
instagibbs: ziggamon just said "years", definitely not 2
<ariard>
and as we see more collaboritve constructions applications, we could deanonymizing attackers leveraging this vector during the next X months/years period of full-rbf transition, just saying
<ariard>
s/collaboritve/collaborative/g
_Sam-- has quit [Remote host closed the connection]
<NorrinRadd>
have the workarounds for 0 conf operators been documented in any one place where they can be easily referenced?
<_aj_>
there aren't workaround, though?
<ariard>
NorrinRadd: no single point documentation i'm aware of
<ariard>
_aj_: distributed monitoring of network mempools, Bitrefill does something like this iiuc
<_aj_>
ariard: they do that for txs that don't opt-in to rbf; things that are rbf-able just get excluded from zeroconf
<NorrinRadd>
'waiting for confirmation' doesn't seem desirable. stores with large foot traffic would have people standing around for an hour sometimes waiting for their payment to confirm.
<NorrinRadd>
if bitrefill is waiting to see if replacement transactions appear, then they're essentially not doing zero conf anymore?
<ariard>
_aj_: so i'm following correctly, if full-rbf happens and all the incoming transaction traffic is repleacable such protection would still allow to accept 0conf traffic
<NorrinRadd>
_aj_ oh thanks
<NorrinRadd>
so once everything is rbf it would effectively kill their zero conf transactions.
<ariard>
okay as we're reaching end of meeting, do we think we prefer to go with a smooth, uncoordinated deployment or a flag day activation ?
<instagibbs>
achow101, makes a reasoanble point, why not just flip it for future release
<_aj_>
ariard: at the moment, 15% of their txs are lightning, 20% are opt-in rbf, and the remaining 65% aren't rbf-able. of the 65% -- 60% are treated as zeroconf, 5% are excluded from zeroconf due to negative signals from the monitoring. with fullrbf, that entire 65% gets excluded from zeroconf, and lightning is the only way to get instant confirmations
<achow101>
26305 for a future release
<instagibbs>
right
<_aj_>
if we're not going to remove the mempoolfullrbf option from 24.0, we're going for an uncoordinated deployment either way
<instagibbs>
im already running full rbf with preferential peering...
<instagibbs>
ship has sailed, the question is will 5%+ set a variable. I suspect not
<ariard>
_aj_: that's a correct, though i don't think it's something like binary, more uncoordinated with the option existent or something like preferential peering
<_aj_>
instagibbs: uasf uacomment demonstrated it's easy to get ~11% to set a variable in just a couple of weeks
<lightlike>
i think that if a meaningful number of node operators and miners want a specific policy, it shouldn't be on the devs to tell them "you can't have that now". Devs can and should give a recommendation (by picking the default), but providing options to informed users should never be a problem.
<bytes1440000>
if 24.0 has mempoolrbf, devs have lot of time to discuss and convince a few nodes and miners to run it. no default required or will have better insights.
<laanwj>
lightlike: +1
<bytes1440000>
making default on signet, testnet still makes sense for testing
<instagibbs>
_aj_, exception that proves the rule
<ariard>
_aj_: about the 65% aren't rbf-able, what i don't understand is if Bitrefill is aware that you can still double-spend not rbf-able transactions, it's just higher technical bar?
<ariard>
(well i think they're aware of, what they say is they don't see that happening)
<vasild>
lightlike: +1
<ariard>
lightlike: that was the original thinking with #25600
<_aj_>
ariard: "can" equates to "less than a 0.0001% chance of it actually happening" according to ziggamon
<gribble>
https://github.com/bitcoin/bitcoin/issues/25600 | p2p: Advertise `NODE_FULL_RBF` and connect to 4 outbound full-rbf peers if `-mempoolfullrbf` is set by ariard · Pull Request #25600 · bitcoin/bitcoin · GitHub
<bytes1440000>
25600 is the worst possible way to make fullrbf default
<instagibbs>
2 minutes
<ariard>
_aj_: so according to that statement, they might be still be fine to not exclude this future 65% traffic from zero-conf acceptance
<_aj_>
ariard: no
<b10c>
i think only having an option defaulting to false for 24 (no preferable peering) won't result in a lot of node operators actually enabling it. Especially if no Umbrel/RaspiBlitz/etc enables it by default
<NorrinRadd>
someone can link to a document that shows the arguments for fullrbf?
<laanwj>
we'll have to close the meeting in a minute... but feel free to continue afterwards ofc
<instagibbs>
We'll put a blanket ban on hats in the interim
<ariard>
_aj_: let me read again Sergej mails, what's Bitrefill position if full-rbf become the norm? (we might def invite 0confs operators to irc meetings)
<glozow>
ariard: my impression is an agreement that it is inevitable, but if it happens before users have a lot of access to LN, it might just make Bitcoin worse
<lightlike>
b10c: I think enabling it for the miners is more critical anyway. Anyone could set up some manually adjusted full-RBF nodes that make hundreds of outbound connections to all reachable peers at quite low costs.
gnaf has quit [Quit: Konversation terminated!]
<NorrinRadd>
ariard i read it. it basically kills zero conf but he also said there's something worse; replacements will be further incentized by changes in exchange rates, where customers will adjust their sats paid lower if bitcoin goes up in price after the purchase was made. which creates business risk for the zero conf merchants.
<NorrinRadd>
ariard thank you
___nick___ has quit [Ping timeout: 260 seconds]
<ariard>
glozow: and letting dual-funded lightning channels susceptible to a DoS vector might slow down further the access to LN, maybe a bit of "chicken-and-eggs" here...
<ariard>
NorrinRadd: yeah see instagibbs thought expressed earlier, is fiat volatility risk really in the scope of Core, dik
<glozow>
ariard: i agree.
<ariard>
idk
<NorrinRadd>
Sergej did also mention that when they've asked people to pay in bech32 before, instead of filing issues, they simple left the site. so his thought is that if he's asking customers for LN, they will not seek out an LN wallet. They'll simple leave and go somewhere else.
<glozow>
quoted from Sergej's post about the american call option, "It's already possible to execute this form of abuse with opt-in RBF"
<instagibbs>
I noted that its in their incentive structure to CPFP if the price goes their way...
<instagibbs>
Merchants can only offload so much of their business complexity to others, sorry
<ariard>
NorrinRadd: i can opinate here, deploying a LN infrastructure server-side is a hard requirement on merchants, managing funds safety/liquidity, a different key management, hopefully we don't centralize the merchant ecosystem with short-timed full-rbf deployment
<_aj_>
instagibbs: easy to diss on stakeholders that aren't present...
<instagibbs>
not a diss, and I've personally discussed this issue with sergej many times
<ariard>
_aj_: i share the sentiment, sounds we don't have the right crowd to have a best-informed technical view
<instagibbs>
We just have different goals, and that's ok!
<instagibbs>
when goals conflict, we try for maximum understanding, and that's what we're doing I hope
<jonatack>
it may still be good to have this discussion with them present and participating
<ariard>
okay as it would be better to end the meeting at some point, i'm thinking to reply to last Dario's mail, saying while full-rbf is still liked people, there is no emergening majority opinion on the deployment method and what's an adequate timeframe would still benefit from more feedbacks from the merchant community
<jonatack>
instagibbs: yes!
<instagibbs>
the email thread is pretty high quality
<glozow>
i guess something that should be said is "for the people who want to turn full rbf on their own nodes, does it matter if the -mempoolfullrbf option doesn't go in v24.0?"
<ariard>
glozow: i think full-rbf setting is already used by at least one electrum server operator, and few other services
<glozow>
so then the question is, if this is one of our only blockers for v24.0, and the people who would use the option don't need it anyway... why not just take it out?
<glozow>
*ducks*
<glozow>
(just putting it out there)
<ariard>
glozow: imho, their use-cases are as much legitimate than the 0confs ones, and i have no strong idea on how we should arbiter in the present case...
<instagibbs>
I'm lobbying for it not to be a blocker
<instagibbs>
:P
bytes1440000 has left #bitcoin-core-dev [#bitcoin-core-dev]
<_aj_>
glozow: if you really want answers to that question, create a PR reverting it, and collect the nacks
<glozow>
well yes, that was #26287 and i nacked it. just wanted to put it out there