<bitcoin-git>
[bitcoin] achow101 opened pull request #26656: tests: Improve runtime of some tests when `--enable-debug` (master...faster-test-runner-when-debug) https://github.com/bitcoin/bitcoin/pull/26656
yanmaani1 has quit [Ping timeout: 255 seconds]
ghost43 has quit [Ping timeout: 255 seconds]
ghost43 has joined #bitcoin-core-dev
_andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
yanmaani1 has joined #bitcoin-core-dev
vasild has quit [Ping timeout: 255 seconds]
vasild has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
bitdex has joined #bitcoin-core-dev
b_101_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 264 seconds]
test__ has joined #bitcoin-core-dev
test_ has quit [Ping timeout: 260 seconds]
jtraub91 has joined #bitcoin-core-dev
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
<ariard>
bitcoinerrorlog: on the actual benefit of mempoolfullrbf, abstraction made of the coinjoin/ln DoS that could be solved under a new replacement regime (e.g spent nversion-based signaling) there is the use-case of non-signaling replacement of external transactions by a supporting wallet as exposed here: https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1304370679
jtraub91 has quit [Quit: WeeChat 3.7.1]
ghost43 has quit [Ping timeout: 255 seconds]
jonatack1 has joined #bitcoin-core-dev
b_101_ has quit [Ping timeout: 264 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
_andrewtoth_ has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master c75e3d2 Andrew Toth: rest: reduce LOCK(cs_main) scope in rest_block
<bitcoin-git>
bitcoin/master 7d253c9 Andrew Toth: zmq: remove LOCK(cs_main) from NotifyBlock
<bitcoin-git>
bitcoin/master f00808e Andrew Toth: rpc: reduce LOCK(cs_main) scope in GetBlockChecked and getblock
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26308: rpc/rest/zmq: reduce LOCK(cs_main) scope: ~6 times as many requests per second (master...no-lock-for-read-block) https://github.com/bitcoin/bitcoin/pull/26308
<glozow>
sdaftuar: Murch: ah okay, re: "room for underestimation" I was thinking of the basic case where the direct conflicts are CPFP'd by their descendants when I originally read your message. And there's the "low feerate ancestor, but actually they have another child bumping them" case that we've talked about.
<glozow>
I agree understimating the original transactions usually means less pinning, but it might make the "attacker replaces your ACP tx with something with a lower miner score, i.e. delays your tx" case worse. Or even "I made an RBF bringing in new unconfirmed outputs, e.g. to CPFP another thing, but my wallet (like most wallets, including Core) doesn't really handle unconfirmed UTXOs properly and now i've accidentally made my transactions confirm
<glozow>
even later."
b_101 has quit [Ping timeout: 260 seconds]
<glozow>
Would a more precise quantity be something like "the replacement miner score has to be X% higher" ?
b_101 has joined #bitcoin-core-dev
rozehnal_paul has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 248 seconds]
sipsorcery has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 264 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
b_101 has quit [Ping timeout: 256 seconds]
Guest49 has joined #bitcoin-core-dev
Guest49 has quit [Client Quit]
b_101 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] aureleoules closed pull request #25183: rpc: Filter inputs by type during CoinSelection (master...2022-05-witness-only-fundrawtransaction) https://github.com/bitcoin/bitcoin/pull/25183
<_aj_>
so pretty much what's in the issue (#26556) -- i'd find it helpful to be able to tell whether people are looking for general feedback on prs, or if they're in a "final"-ish state where they're just looking for bugs and acks
<_aj_>
and it seems like you can do that pretty nicely with the way the modern project boards work; so i wonder if other people would be interested in trying something like that out
<josie[m]>
i would definitely be interested in trying that out.
<instagibbs>
getting a couple volunteers to religiously use it is probably good next step
<lightlike>
who would make the judgement calls to move things between the categories?
<laanwj>
no objections from me, i don't see why there would be, though we've had similar initiatives in the past and it's not entirely clear to me it wlil be maintained actively (it's why we have only specific boards for specific projects someone has an interest in)
<_aj_>
i was thinking that mostly PR authors could do that (if they're members of the org, anyway)
<josie[m]>
lightlike: authors, i would think. but other reviewers could likely recommend that something move if they feel it needs to
<josie[m]>
im not sure if this is the envisioned use, but i would love to use this for facilitating more design review before opening a concrete implementation
<fjahr>
Can issues also get on the board or only PRs?
<fjahr>
If issues are possible as well then that should work to do that as well with a board
<achow101>
_aj_: would you be willing to setup the project views, etc.?
<_aj_>
the categories (seeking concept ack / initial review / detailed review / ready for merge) seem more applicable to PRs than issues; but technically issues would work too
<_aj_>
achow101: sure
<sipa>
hi
<fjahr>
Maybe there could be a high prio brainstorming column, but not sure if that is a good idea...
<lightlike>
this removes the "blocker" notion that is currently still part of the high-prio board, right? So it'll be ok to have things as high-prio even if they don't block any future work.
<ariard>
on the "concept ack" i think it could be understood in a larger meaning, in the sense seeking concept ack beyond the Core project boundaries, especially for things like mempool policy rules
<_aj_>
lightlike: i'm roughly thinking of it as "this is the pr i'm most actively working on"
<fjahr>
_aj_ +1 I think most people interpret it as "blocking me from focussing on the next big thing, I want to get this done soon"
b_101 has joined #bitcoin-core-dev
<laanwj>
so it looks like no one has any objections, let's do it
<lightlike>
yes, seems like a good idea to try this out
<fanquake>
is the main point of the new effort mostly just increased visibility?
<fanquake>
obviously for the last few years, a PRs existence in the high prio board has made no material difference to how much (extra) review it actually gets
<laanwj>
that's hard to measure :)
brunoerg has quit [Remote host closed the connection]
<lightlike>
I wouldn't agree, several people have told me that they sometimes use the board to find things to review. I definitely have as well.
brunoerg has joined #bitcoin-core-dev
<jonatack1>
i used the board these past few years.
b_101 has quit [Ping timeout: 252 seconds]
<fanquake>
heh. mostly judging based on the duration that PRs remain in the board / get dropped out. Personally I have a number that receive 0 attention despite being in the board. Obviously dependant on the change as well.
<fanquake>
just trying to get a better understanding of the hopeful outcome. If it leads to increased focus / throughput for certain projects, that’d be great
<laanwj>
yeah…it's just very hard to drum up (review) attention for things it's been always that way, but if people get involved in this new project board it might help a bit
<fjahr>
I have used the board as well. I think the high prios are often much more complex than the average PR and I feel like in some cases it has helped my PRs to be on there.
<fanquake>
Ultimately the problem is still very limited number of reviewers, with limited time. However if we can help them prioritise somehow, that is also useful
brunoerg has quit [Ping timeout: 260 seconds]
<fanquake>
and yes, given that high priority changes are generally complex, or harder to review, that constraints the group of reviewers even further
<jonatack1>
no opinion on adding a board, other than try and see, i guess. yes, the high prio board sometimes has PRs that are more difficult, longer or critical to review, which might be intimidating
<jonatack1>
fanquake: right
<fanquake>
In any case. Let’s give it a go
<_aj_>
fanquake: i get confused by: which PRs people actually care about when they have many open; whether PRs are looking for broad review or just want to get ACKs to get merged; whether it's worth putting "easy" things on high-pri, or when it's worth pinging maintainers/reviewers to look at things; i'm hoping some of those might be improved
<fanquake>
_aj_: yea, that sounds worthwhile. I have recently been trying to enact that in some way, by marking more PRs as drafts, to at least try and push review attention to dependant PRs etc. More triage / organisation will likely also help there
<jonatack1>
would it be helpful to add a link to the board(s) when joining this irc channel, a la "please see *url(s)* for review"
brunoerg has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
<laanwj>
a good idea but i don't think the topic can be any longer
brunoerg has quit [Ping timeout: 255 seconds]
<laanwj>
it's always a good question, how to get attention to something that is supposed to give attention, but could at least add a link to the appropriate documents ni the repo like REVIEWING.md
<laanwj>
any other topics?
<lightlike>
instagibbs suggested one above
b_101 has quit [Ping timeout: 265 seconds]
<laanwj>
#topic Replace MIN_STANDARD_TX_NONWITNESS_SIZE to preclude 64 non-witness bytes only (instagibbs)
<core-meetingbot>
topic: Replace MIN_STANDARD_TX_NONWITNESS_SIZE to preclude 64 non-witness bytes only (instagibbs)
<instagibbs>
I think all opinions have been given on the topic, whether restricting to <65 bytes or restricting 64 bytes exactly, I have preferences, but wondering what the path forward is
<instagibbs>
_aj_, feelings on that?
<_aj_>
nothing to add to what's already in the pr?
<instagibbs>
Ok, so there's mild(?) disagreement on implemetnation cost, and I'm not sure what goes from here
<achow101>
are there competing prs or is it just disagreement in one?
<instagibbs>
#26265 was the alternative
<gribble>
https://github.com/bitcoin/bitcoin/issues/26265 | POLICY: Relax MIN_STANDARD_TX_NONWITNESS_SIZE to 65 non-witness bytes by instagibbs · Pull Request #26265 · bitcoin/bitcoin · GitHub
<instagibbs>
most people(including me) seem to prefer the new one, but in my case it's a mild preference, and I'd rather something be done
<instagibbs>
vs sit on two possibilities with no new data to be had
<instagibbs>
if there's nothing to be done but languish, I guess that happens but I'd rather now. achow101 maybe take a look and give some sage advice?
<achow101>
I don't see any NACKs
<instagibbs>
_aj_, I guess I'm formally asking for a nack or I'll ask for merge, that ends the topic
<instagibbs>
?
<instagibbs>
thanks
<_aj_>
instagibbs: i don't really see how adding a nack is productive, but sure
brunoerg has joined #bitcoin-core-dev
<instagibbs>
ok we can take this offline
<achow101>
it's just not clear to my how strong the disagreement is
<instagibbs>
^
b_101 has joined #bitcoin-core-dev
<instagibbs>
I see lots of text that is opposing the underlying idea, I take it as an unknown strength nack
<instagibbs>
2 minutes if anyone wants to speak on anythign else
<_aj_>
i guess i don't really think encouraging "strong" disagreement is really healthy
brunoerg has quit [Ping timeout: 252 seconds]
<jonatack1>
i tend to prefer 26265 to not special-case, i think
b_101 has quit [Ping timeout: 268 seconds]
<laanwj>
it's time to wrap up the meeting
<instagibbs>
ok, I'll just put some thoughts down on the PR on what I think the state is
<laanwj>
we can continue this after, or pick up the topic again next week
<bitcoin-git>
[bitcoin] furszy opened pull request #26668: wallet: if only have one output type, don't perform "mixed" coin selection (master...2022_wallet_double_coin_selection) https://github.com/bitcoin/bitcoin/pull/26668
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
<achow101>
instagibbs, _aj_: What does a standard tx <64 bytes even look like?
<instagibbs>
non-batched burn to dust, mostly
<achow101>
the absolute minimum is 60 bytes, making the spk a single OP_RETURN makes that 61, but an empty scriptSig is still nonstandard
<instagibbs>
I just disagree that having an indirect restriction makes things easier for anyone
<instagibbs>
native segwit spend f.e.
brunoerg has quit [Ping timeout: 248 seconds]
<achow101>
yes, but that puts the size well above 64
<instagibbs>
nonwitness size*
Talkless has quit [Quit: Konversation terminated!]
<achow101>
oh, the check ignores witness size entirely?
<achow101>
not even doing vbytes stuff?
<instagibbs>
it's stripped serialization, making sure it doesn't "look like" an inner node of the merkle tree
<achow101>
I see
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
<_aj_>
achow101: (afaics core api's only let you create an op_return with non-empty data, so you end up with at least OP_RETURN PUSH["x"] for 3 additional bytes rather than just once, and a minimum size of 63B)
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 252 seconds]
jesseposner has quit [Read error: Connection reset by peer]
jesseposner has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
bitcoinerrorlog1 has quit [Ping timeout: 256 seconds]
CoinForensics has quit []
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
metallicc has quit [Remote host closed the connection]
b_101 has joined #bitcoin-core-dev
metallicc has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
bitdex has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
metallicc has quit [Ping timeout: 256 seconds]
brunoerg has quit [Ping timeout: 256 seconds]
metallicc has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
_andrewtoth_ has quit [Remote host closed the connection]