abubakarsadiq has quit [Quit: Connection closed for inactivity]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
andrew_m_ has quit [Ping timeout: 248 seconds]
luke-jr has quit [Ping timeout: 250 seconds]
bomb-on has quit [Quit: aллилѹіа!]
brunoerg has joined #bitcoin-core-dev
luke-jr has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
vysn has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
test_ has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 240 seconds]
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
instagibbs has quit [Quit: Ping timeout (120 seconds)]
instagibbs has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 265 seconds]
andrew_mo_ has joined #bitcoin-core-dev
bcdarc has quit [Server closed connection]
bcdarc has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
preimage has quit [Ping timeout: 248 seconds]
preimage has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
justache has quit [Server closed connection]
justache has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 240 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
andrew_m_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
b_101 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
flooded has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
test_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
darosior has quit [Server closed connection]
andrew_mo_ has joined #bitcoin-core-dev
darosior has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
brunoerg has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
andrew_mo_ has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
jakob[m] has left #bitcoin-core-dev [#bitcoin-core-dev]
b_101 has quit [Ping timeout: 240 seconds]
andrew_mo_ has quit [Ping timeout: 240 seconds]
preimage has quit [Quit: WeeChat 3.8]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
b_101 has quit [Ping timeout: 240 seconds]
kevkevin_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
kevkevin has quit [Ping timeout: 255 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
andrew_m_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 248 seconds]
andrew_mo_ has quit [Ping timeout: 240 seconds]
andrew_m_ has quit [Ping timeout: 240 seconds]
b_101 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 240 seconds]
b_101 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 265 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
test_ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 240 seconds]
andrew_mo_ has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #27892: refactor: Avoid copy of bilingual_str when formatting (master...2306-translate-copy-) https://github.com/bitcoin/bitcoin/pull/27892
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has quit [Ping timeout: 268 seconds]
Guyver2 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
andrew_mo_ has quit [Ping timeout: 248 seconds]
b_101 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
b_101 has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
puchka has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
puchka has joined #bitcoin-core-dev
lowhope has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
lowhope_ has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
<josie>
is there a reason we use bcrt for regtest in bitcoin core? its not defined in BIP173 or BIP350 and it seems easier to use the same HRP for all test networks
<josie>
_aj_: thanks for the links! these are very helpful
b_101 has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
AaronvanW has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
flooded has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
test_ has quit [Ping timeout: 246 seconds]
b_101 has quit [Ping timeout: 258 seconds]
<bitcoin-git>
[bitcoin] dimitaracev opened pull request #27895: test: clean up is node stopped (master...test-cleanup-is-node-stopped) https://github.com/bitcoin/bitcoin/pull/27895
<sipa>
that sounds vaguely related to cluster linearization...
<_aj_>
sipa: i thought so too
<instagibbs>
Status quo means we're not considering subpackages at all, so I'm not sure I'm too worried about weird edge cases
<glozow>
yeah. it also gets a bit more complicated if rbf is enabled…
<Murch>
All transactions are rbf-able, some are just in denial :p
<achow101>
istm a simple chain would be O(n^2) PreChecks? which includes utxo lookup
<lightlike>
will these problems be made trivial to handle after clustermempool?
<instagibbs>
PreChecks are cheap, but can also be split out sure
<instagibbs>
(or are they not)
<glozow>
yeah. i mean there is a coinsview cache so you only load utxos once
<instagibbs>
If we're not worried about prechecks, then the other concern is doing more work elsewhere than necessary, so tightening up when we retry is another thing we could try
<instagibbs>
I think right now it's kind of broad?
<josie>
Murch: miner deniers lol
<glozow>
i dont think cluster mempool would make a difference here, as these txns arent in mempool yet. though perhaps there could be code/algos to reuse?
<instagibbs>
linearization should be doing all the fee analysis bits though?
<sipa>
We'll have code for "given a set of interconnected transactions, find a good linearization for it". Would that be helpful, as in the linearization gives you an order to try transactions in? (I haven't paid attention to package validation at all, this may be wildly off)
<sdaftuar>
sorry i'm a bit behind on the conversation. the issue is whether we should evaluate a subpackage instead of a full package?
<sdaftuar>
and if so, how do we find the subpackages?
<instagibbs>
sipa "good linearization" in which terms, to clue me and others in
<sdaftuar>
i believe this is equivalent to determining whether a package would be chunked together in the cluster-mempool model, which should be straightforward to do
<glozow>
i think the issue is that this algo might not be handling all the edge cases we may be concerned about, and also it’s unclear if the computational complexity is ok.
<sipa>
instagibbs: A linearization is always topologically valid (as in: parents always go before children). It's good if it moves as much of the feerate to the front of the linearization (e.g. respecting CPFP would make a linearization better).
b_101 has joined #bitcoin-core-dev
<glozow>
er, what do u do if an earlier tx in the package rbfs something, impacting a later tx in the package? 😅
<sipa>
If it's just chunking (you're already given the order that transaction go in in, but you wonder which ones should be considered together for CPFP like reasons), we have an O(n) algorithm.
<sdaftuar>
glozow: my model for RBF right now is to simulate what the mempool would look like assuming all RBFs go through, sort the cluster of the RBF transaction (or package) to determine mining score of the new transaction (or package, i guess), and then compare against what would be evicted
<sdaftuar>
i think that can all happen fast enough that there's not a CPU concern
<_aj_>
yeah, fee calculations should be fast, so doing that for lots of different possible subpackages seems okay (as long as it's not 2**n different subpackages..)
andrew_mo_ has joined #bitcoin-core-dev
<sdaftuar>
_aj_: i believe in the cluster mempool world, we would just need to do a single cluster sort to get mining score for all transactions in a package.
<sdaftuar>
and the chunks that are output would be the subpackages to consider
<glozow>
so we could do something like: grab all utxos, linearize to find subpackages, validate assuming everything goes in, delete invalid ones, then do final fee analysis before submitting?
<sdaftuar>
yes i think so. to expand a bit, "validate assuming everythign goes in" is just removing transactions from the cluster that the new package would be joining that are conflicted by the package.
<sdaftuar>
i should say, tentatively removing transactions, from a putative new cluster that includes the new transactions
<sdaftuar>
then we sort that, and look at the chunks.
b_101 has quit [Ping timeout: 260 seconds]
<_aj_>
sdaftuar: we need to actually check sigs on the new txs at some point; i think that's what glozow meant by validate here
<sdaftuar>
ah, yes i think we would do that last
<sdaftuar>
after checking feerates from the cluster sort
<glozow>
also actually i change my previous answer, cluster mempool would eliminate concerns about submitting something that is handled poorly by the eviction algo
b_101 has joined #bitcoin-core-dev
<glozow>
what do we do if we find a bad sig? it’d impact the fee analysis, so would we linearize again and run rbf checks again after removing the invalid one(s)?
<instagibbs>
post-linearization, I'd kind of expect it to just stop with failure?
<sipa>
Is it a problem to in that case just treat the entire package as invalid?
<sdaftuar>
sipa: not permanently invalid, but yes i don't think we need to find a valid subpackage
<sipa>
Right.
<_aj_>
could just leave the linearization, but drop any descendents of the invalid thing?
<instagibbs>
^ yeah
pablomartin has joined #bitcoin-core-dev
<glozow>
yeah it should be ok as long as we are willing to try again with another peer
<sdaftuar>
_aj_: that could admit non-feerate-passing transasctions into the mempool
<sdaftuar>
seems simpler to give up, no peer should give us an invalid signature
<sdaftuar>
so as long as we try from other peers, i think it's fine?
<_aj_>
sdaftuar: i was treating the linearisation as giving us chunks which we'd validate as a set, i guess
<sdaftuar>
_aj_: ok, i guess it woudl work if we required that chunks get accepted all-or-none
<sdaftuar>
so if there's a package with two distinct chunks, we evaluate those separately and atomically
<_aj_>
i can't see any reason not to just drop a package with a bad sig in it though
<glozow>
is there linearization code available to use? i can mark 26711 as draft and rework it to do this
<_aj_>
(and the peer that sent it)
<sdaftuar>
glozow: uh i can share a branch. it needs a lot of work though
<_aj_>
speaking of, review beg for #26291 :)
<sdaftuar>
but it should show the idea for how this would work
<achow101>
sounds like we might get (part of) cluster mempool sooner than expected :)
<sdaftuar>
glozow: also this only works with bounded clusters -- otherwise CPU DoS is not something we can deal with
<glozow>
sdaftuar: that’d be good! yeah maybe we can push bits of cluster mempool in :P
<sdaftuar>
honestly i'm not sure how feasible that is but happy to get more eyes on it :)
<sipa>
We're thinking up to 64 transactions can probably run in <0.1 ms on decent hardware (for ancestor-based sort, not optimal).
<glozow>
oh yeah this came up in the bip as well. is 100 a realistic cluster limit?
<fanquake>
what is the definition of "decent hardware" at the moment?
<sipa>
fanquake: My Ryzen 5950X?
<glozow>
(ie do you see cluster limit being bigger than 100?)
<sdaftuar>
also my power9 machine i think
<fanquake>
sipa: ok
<instagibbs>
(or chunk limit)
<sipa>
100 seems high already
<glozow>
asking because trying to come up with a good maximum count for getpkgtxns
b_101 has quit [Ping timeout: 258 seconds]
<glozow>
i thought so as well
<achow101>
I think we're getting a little bit off topic, so I'm gonna cut y'all of there for time, but this is definitely something that should be continued after the meeting/offline.
<TheCharlatan>
The shutdown PR got split up a bit for ease of review, focus should currently be on #27866 and #27862. They are both small changes and self-contained.
<_aj_>
on cirrus ci, i seem to only be able to rerun jobs for my own PRs; i thought i used to be able to trigger reruns for other people's prs as well. is that new, and if so, is it deliberate?
<brunoerg>
Perhaps #26969 seems ready for merge I guess, but if more reviews is needed could it be added? seems good to move on to not cause rebase problems
<achow101>
_aj_: I don't think we've changed any permissions recently, could be a cirrus change. but iirc it was always the case that you could only re-run your own prs
<_aj_>
achow101: entirely possible that i may be misremembering
<fanquake>
brunoerg: unfortunate that you've had to rebase a number of times, but the other conflicting changes were higher priority, and we don't want to merge random refactors in between bug fixes, that need to be backported, as that only pointlessly complicates the backporting
<achow101>
#endmeeting
b_101 has quit [Ping timeout: 248 seconds]
b_101 has joined #bitcoin-core-dev
<_aj_>
achow101: thanks for another meeting!
andrew_mo_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 248 seconds]
<brunoerg>
fanquake: I understand it, I thought the main blocker for this was parallel compact blocks PR, so I was just wondering if now is time to have this to not cause any conflict with any possible-near-future important change. anyway, thanks for the clarification.
andrew_mo_ has quit [Ping timeout: 258 seconds]
<fanquake>
brunoerg: I think now is fine, if you just want to address the last query by aj
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 240 seconds]
b_101 has joined #bitcoin-core-dev
<kanzure>
eventually i will adjust to the new time
andrew_mo_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 258 seconds]
<instagibbs>
brunoerg grepping for the phrase "Dirty hack" was very useful during parallel compact blocks work, finding my place
<instagibbs>
you're removing it, shame
<brunoerg>
haha
<brunoerg>
sorry!
andrew_mo_ has quit [Ping timeout: 265 seconds]
andrew_mo_ has joined #bitcoin-core-dev
<josie>
exit
AaronvanW has quit [Quit: Leaving...]
andrew_mo_ has quit [Ping timeout: 240 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 240 seconds]
b_101 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
<preimage>
o/
<preimage>
☺
b_101 has quit [Ping timeout: 240 seconds]
b_101 has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
b_101 has quit [Ping timeout: 258 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 258 seconds]
face has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 258 seconds]
face has quit [Client Quit]
face has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
pablomartin has quit [Quit: Leaving]
<instagibbs>
is there a good way to fetch a branch in a PR that was replaced by a force push?
<instagibbs>
on github*
b_101 has joined #bitcoin-core-dev
<preimage>
you mean without using the cli, or you mean “for a repo on github” but using the cli is fine?
dimitaracev has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
<instagibbs>
“for a repo on github” using git
<preimage>
if you have the fork the branch lives on configured as a remote and you're locally checked-out on the branch, `git fetch <remote> && git reset --hard <remote>/<branch>` should put you in-sync with the branch's new HEAD. If you need to preserve your commits, then you'd rebase instead after the fetch
salvatoshi has quit [Ping timeout: 240 seconds]
andrew_mo_ has quit [Ping timeout: 268 seconds]
b_101 has quit [Ping timeout: 268 seconds]
<instagibbs>
i dont want the new head, I want a prior
<preimage>
ahhh, I completely misunderstood your question; I'm not aware of a way to do that remotely. If that force-push was done from your clone, the ref log will let you get back to the prior state, but I'm not sure how to accomplish that remotely ☹
<preimage>
(my apologies for the misunderstanding)
<instagibbs>
no worries, i didnt think it was, just in case i was wrong
andrew_mo_ has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
<fjahr>
instagibbs: as long as it wasn't removed from github you can just fetch it if I understand what you want correctly
<achow101>
instagibbs: you can do `git fetch origin <commit>` as long as the commit is still on github
<achow101>
but they prune things eventually
<instagibbs>
tried it, no dice
<instagibbs>
it's ok, I'll just be more consistent about checking out things
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 240 seconds]
b_101 has quit [Ping timeout: 240 seconds]
<preimage>
achow101: it wouldn't be `origin` right; it'd be the fork's remote?
<achow101>
origin has worked for me before
<preimage>
(well, I suppose the fork's remote could be named origin, but that'd be odd)
<preimage>
hmm
andrew_m_ has quit [Ping timeout: 240 seconds]
<fjahr>
it works with origin if the commit was part of a pull
<preimage>
is that github doing something magical in the background? I wouldn't think git could do that unless the commit was actually pushed somewhere in `origin` before the force-push on the pull
<preimage>
(also, this is kind of OT if it wouldn't help instagibbs anyway; so I can leave it alone)
flooded has joined #bitcoin-core-dev
<fjahr>
that's what I am saying, if a commit was part of a pull it was "pushed somewhere in origin", origin being bitcoin/bitcoin
<preimage>
part of a pull that got merged
<preimage>
?
<achow101>
github exposes all of the refs for all prs, so all of the commits in all prs can be fetched from origin directly
<preimage>
ah
<preimage>
so it is github doing something magical in the background
<achow101>
yes
<preimage>
TIL
<preimage>
achow101: thanks!
<achow101>
there's a dev note somewhere about how you can configure your upstream to fetch all prs without having to add the other person's fork as a remote