<bitcoin-git>
bitcoin/master fa825bd MarcoFalke: util: Include full version id in bug reports
<bitcoin-git>
bitcoin/master 272fb0a MarcoFalke: Merge bitcoin/bitcoin#26645: util: Include full version id in bug reports
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26645: util: Include full version id in bug reports (master...2212-full-version-id-🍁) https://github.com/bitcoin/bitcoin/pull/26645
zeropoint has quit [Quit: leaving]
AaronvanW has joined #bitcoin-core-dev
<vasild>
If PR1 introducing some feature gets merged seemingly without controversy and shortly afterwards PR2 attempts to revert PR1 and PR2 turns out to be strongly controversal with many strong ACKs and NACKs, then I think it follows that PR1 would have been controversal too if the people ACKings the reversal were aware of it and its implications. Could that be a reason to merge the reversal PR2 even
<vasild>
though it is controversal? (I am not taking side in the fullrbf debate)
sipsorcery has joined #bitcoin-core-dev
lowhope has quit [Ping timeout: 260 seconds]
lowhope_ has joined #bitcoin-core-dev
Guest6 has joined #bitcoin-core-dev
Guest6 has quit [Client Quit]
_andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Ping timeout: 255 seconds]
<josie[m]>
vasild: "then I think it follows that PR1 would have been controversal too if the people ACKings the reversal were aware of it and its implications" i dont think this is necessarily always true. it may apply to some cases but not enough to prescribe as a general rule. better to treat PRs on a case by case basis, imo
<vasild>
josie[m]: yeah, I agree
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 260 seconds]
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
andrewtoth_ has joined #bitcoin-core-dev
vasild has quit [Ping timeout: 255 seconds]
<BitcoinErrorLog>
In the case of RBF topics, I think it's fair to say they have always been controversial. In the case of mempoolfullrbf, I think it is fair to say there was controversy before v24 actually shipped, evidenced by quite a few mailing list posts, the original version of my PR by Suhas, etc. The current debate is made more complicated by uncertainty around what is procedure, what the actual benefit of mempoolfullrbf might
<BitcoinErrorLog>
n/whether it is okay to break the user space.
_andrewtoth_ has quit [Ping timeout: 255 seconds]
vasild has joined #bitcoin-core-dev
<fanquake>
To github.com:bitcoin-core/bitcoin-detached-sigs.git
<fanquake>
* [new tag] v24.0.1 -> v24.0.1
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #26651: test: Avoid intermittent timeout in feature_assumevalid.py (master...2212-test-fix-assumevalid-🌞) https://github.com/bitcoin/bitcoin/pull/26651
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
szkl has joined #bitcoin-core-dev
Lightsword has quit [Quit: ZNC]
windsok has quit [Quit: No Ping reply in 180 seconds.]
Lightsword has joined #bitcoin-core-dev
windsok has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
GregTonoski has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
GregTonoski has quit [Quit: Client closed]
sipsorcery has joined #bitcoin-core-dev
ajonas has quit [Quit: Connection closed for inactivity]
sipsorcery has quit [Ping timeout: 252 seconds]
vasild has quit [Ping timeout: 255 seconds]
vasild has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 255 seconds]
bitdex has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26517: test: Changed small_txpuzzle_randfee to return the virtual size instead of the transaction hex for feerate calculation. (master...use-vsize-for-fee-tests) https://github.com/bitcoin/bitcoin/pull/26517
AaronvanW has joined #bitcoin-core-dev
pablomartin4btc has joined #bitcoin-core-dev
pablomartin has quit [Ping timeout: 248 seconds]
Guest52 has quit [Quit: Client closed]
Ombre has left #bitcoin-core-dev [#bitcoin-core-dev]
ghost43_ has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 255 seconds]
yashraj has joined #bitcoin-core-dev
ghost43_ has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] brunoerg opened pull request #26653: test, init: perturb file to ensure failure instead of only deleting them (master...2022-12-stress-test-perturbing) https://github.com/bitcoin/bitcoin/pull/26653
<sdaftuar>
glozow: i was just looking at your comment in #26451 about the mining-on-a-mempool-cluster code in #26152, which i just took a look at.
<sdaftuar>
glozow: am i correct in understanding that the CalculateCluster function could pull in the whole mempool, and isn't constrained by ancestor/descendant limits?
<sdaftuar>
(that's my read of what connectedness means, so i want to check to see if i might have misunderstood)
<sdaftuar>
Murch: ^ you may know the answer to this as well?
<glozow>
sdaftuar: yes correct, that is possible
<sdaftuar>
thank you!
Talkless has joined #bitcoin-core-dev
<glozow>
(so yeah, not really acceptable if calling from p2p)
<glozow>
it should be very easy to implement a stopping point based on number of entries visited for example. but if we need an answer...
<sdaftuar>
glozow: i was thinking that perhaps we could just look at the direct conflicts + ancestors. that has the benefit of the RBF reasoning being "local", in the sense that unrelated transactions are excluded from the logic (which seems better for reasoning), and also limits computational complexity
<sdaftuar>
however that is still potentially a lot of transactions (roughly 2500 i think, with the 100-reaplcement rule in effect)
<sdaftuar>
also, you might want to consider putting in some kind of similar limit for the wallet
<sdaftuar>
but i haven't reviewed the PR so can't really comment, just seems worrisome on its face
b_101 has quit [Ping timeout: 252 seconds]
yashraj has quit [Remote host closed the connection]
yashraj has joined #bitcoin-core-dev
yashraj has quit [Ping timeout: 256 seconds]
sipsorcery has joined #bitcoin-core-dev
<glozow>
agree a limit makes sense for wallet-only as well yes
<glozow>
My initial reaction is that limiting to direct conflicts + ancestors leaves quite a bit of room for underestimation, as I tend to think of these things as "can somebody pin." Improving the heuristic even if still perfect seems worthwhile given the current Rule #2 has little impact on "can somebody pin" anyway.
<bitcoin-git>
[bitcoin] john-moffett opened pull request #26654: util: Show descriptive error messages when FileCommit fails (master...2022_12_BetterSystemErrorLogging) https://github.com/bitcoin/bitcoin/pull/26654
rozehnal_paul has quit [Quit: Connection closed]
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
Talkless has joined #bitcoin-core-dev
bitcoinerrorlog1 has joined #bitcoin-core-dev
BitcoinErrorLog has quit [Ping timeout: 260 seconds]
zeropoint has joined #bitcoin-core-dev
codo has joined #bitcoin-core-dev
cotsuka9 has joined #bitcoin-core-dev
jonatack1 has joined #bitcoin-core-dev
cotsuka has quit [Ping timeout: 268 seconds]
cotsuka9 is now known as cotsuka
<Murch>
glozow: We chatted a bunch about this today at lunch. I think that if we considered all ancestors and only our own other relatives for each UTXO, we would only be prone to overestimating bump fees by essentially not relying on bumping by foreign descendants of our ancestry.
<sdaftuar>
glozow: er i misspoke when i said "direct conflicts and ancestors". what i was thinking in my head was "all conflicts and their ancestors"
<sdaftuar>
glozow: but not sure i follow what you mean by leaving room for underestimation, can you clarify?
<sdaftuar>
i think that underestimating the mining scores of what is in the mempool (eg because we exclude parts of the transaction graph which might make those conflicting transactions actually have a higher score)
<sdaftuar>
results in less "pinning" because new transactions don't need to pay as much as they really should
<sdaftuar>
that's an incentive compatibility issue, though -- but maybe a small isssue in practice
<sdaftuar>
where it gets murkier is exactly what comparison we do. in the world where we use a mini-miner on a transaction subgraph, is the right calculation to ensure that the mining score of the new transaction is strictly better than that of all the to-be-replaced transactions? or do we quantify things in some more precise way?
SpellChecker has quit [Quit: bye]
SpellChecker has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
sipsorcery has quit [Ping timeout: 256 seconds]
sipsorcery has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
jonatack1 has quit [Ping timeout: 252 seconds]
andrewtoth_ has quit [Remote host closed the connection]
Guest42 has joined #bitcoin-core-dev
andrewtoth_ has joined #bitcoin-core-dev
Guest42 has quit [Client Quit]
jtraub91 has quit [Ping timeout: 260 seconds]
pablomartin4btc has quit [Ping timeout: 260 seconds]