MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.5.1]
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] ryanofsky closed pull request #30975: ci: build multiprocess on most jobs (master...2024/09/multiprocess-guix) https://github.com/bitcoin/bitcoin/pull/30975
<bitcoin-git>
[bitcoin] ryanofsky reopened pull request #30975: ci: build multiprocess on most jobs (master...2024/09/multiprocess-guix) https://github.com/bitcoin/bitcoin/pull/30975
kevkevin has quit [Remote host closed the connection]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
mcey_ has joined #bitcoin-core-dev
mcey has quit [Remote host closed the connection]
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
<PaperSword>
Hey! Question is there a way to determine if a mempool entry is TRUC via the RPC?
<PaperSword>
OR is the TXN being in the mempool V3 enough.
<PaperSword>
Wait: I just answered that.... sorry, yeah so being V3 you then can look at the array of descendants / ancestors to see if the TXN is TRUC and what set of rules for size apply.
kevkevin has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
jarthur_ has quit [Quit: jarthur_]
kevkevin has quit [Ping timeout: 244 seconds]
kevkevin has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
juleeho has joined #bitcoin-core-dev
juleeho has quit [Client Quit]
kevkevin has joined #bitcoin-core-dev
adiabat_ has quit [Ping timeout: 246 seconds]
Guest87 has joined #bitcoin-core-dev
adiabat_ has joined #bitcoin-core-dev
adiabat_ has quit [Remote host closed the connection]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
adiabat_ has joined #bitcoin-core-dev
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #bitcoin-core-dev
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
gnusha has quit [Ping timeout: 244 seconds]
gnusha has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 264 seconds]
SpellChecker has joined #bitcoin-core-dev
vasild_ has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
MyNetAz has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] fanquake merged pull request #31784: test: added additional coverage to waitforblock and waitforblockheight rpc's (master...moreTimeoutTests) https://github.com/bitcoin/bitcoin/pull/31784
<willcl-ark>
Do we support different debug levels (or categories) being sent to console and debug.log file?
<laanwj>
i'm getting a bit skeptical about #31177, sure, it'd be nice to report 1.0 exactly when we're sure we're entirely up to date, but solutions seem to muddle the estimate that makes it less useful in other ways
<laanwj>
willcl-ark: no, there's no such setting
<fjahr>
corebot seems dead? :/
<corebot>
fjahr: Error: "seems" is not a valid command.
<fjahr>
#31177
<corebot>
https://github.com/bitcoin/bitcoin/issues/31177 | rpc, logging: return "verificationprogress" of 1 when up to date by polespinasa · Pull Request #31177 · bitcoin/bitcoin · GitHub
<fjahr>
Oh, he's back :)
<laanwj>
bitcoin#31177
<laanwj>
huh
<willcl-ark>
laanwj: ok thanks for confirming what I suspected
eval-exec has joined #bitcoin-core-dev
<laanwj>
i can see how it can be useful, but having multiple sets of logging category/level filter settings would complicate the logging system even more
<willcl-ark>
Yeah, and I only want it for some benchmarking, but I don't think it would be a particularly generally-useful feature...
Guest87 has quit [Quit: Client closed]
theStack has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
<sipa>
laanwj: hmm, yes, my initial preference was not do anything, because "fully synced" isn't very well defined of you take the possibility of a block whose header you have not seen into account, but people really wanted to see a 1.0 number
cygnet3 has joined #bitcoin-core-dev
<laanwj>
sipa: sure, and i i can understand that, i do agree in theory it's an improvement to user friendliness, but doing it in a way that doesn't break other cases unexpectedly or makes questionable assumptions seems hard
<laanwj>
also, that code has no business being in validation.cpp
<laanwj>
(but that's orthogonal to the PR)
kevkevin has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
<sipa>
can i have some review on #30535? it adds the ability to evaluate FeeFrac at a given size, making it possible to use as replacement for CFeeRate, and comes with nice tests
<bitcoin-git>
[bitcoin] Sjors opened pull request #31802: Add bitcoin-{node,gui} to release binaries for IPC (master...2025/02/ipc-yea) https://github.com/bitcoin/bitcoin/pull/31802
Polaris has joined #bitcoin-core-dev
<abubakarsadiq>
@sipa I see that all the getter and setter methods of txgraph on a ref assume checking whether the ref belongs to that txgraph. Could this methods just be part of ref? Since ref can access its txgraph internals, this would prevent those `Assumes` and the issues they are meant to prevent.
<abubakarsadiq>
But I think you choose the current approach because it's better than my suggestion for some reasons?
<sipa>
abubakarsadiq: it's a good question
<sipa>
one reason is that it makes locking requirements clearer; we can't write those when operating on Refs directly (because the txgraph isn't in scope necessarily)
<abubakarsadiq>
I see, I have not reviewed the commit you introduced locks yet
<bitcoin-git>
[bitcoin] theuni opened pull request #31807: kernel: Avoid duplicating symbols in the kernel and downstream users (master...fix-dupe-kernel-symbols) https://github.com/bitcoin/bitcoin/pull/31807
monlovesmango has quit [Quit: leaving]
monlovesmango has joined #bitcoin-core-dev
monlovesmango has quit [Client Quit]
<sipa>
abubakarsadiq: to be clear, what i mean is that CTxMemPool would have a `TxGraph m_txgraph GUARDED_BY(cs);` variable, so that it can be checked that any interactions with m_txgraph require the mempool lock
monlovesmango has joined #bitcoin-core-dev
<sipa>
but a direct TxGraph::Ref::RemoveTransaction() would invisbly access m_txgraph, by holding its own reference to it
<sipa>
this problem does exist with TxGraph::Ref::~Ref, which one would need the mempool lock for too, but we can't avoid that
monlovesmango has quit [Client Quit]
<sipa>
maybe in a follow-up TxGraph can be given its own internal locks
<abubakarsadiq>
that will be better I think, the abstraction will be complete!
monlovesmango has joined #bitcoin-core-dev
monlovesmango has quit [Client Quit]
<sipa>
i don't know if it's really possible
<sipa>
with CTxMempoolEntry deriving from TxGraph::Ref, they are kind of intertwined from an access level
andrewtoth has joined #bitcoin-core-dev
<abubakarsadiq>
hmm yeah we will want the additions to be atomic (for both `TxGraph` and mempool entry)
<abubakarsadiq>
I think I will have to to look at #28676 on how the current `TxGraph` interface is used by the mempool
<abubakarsadiq>
anyway I dont think it's super important for `TxGraph` to handle it's threadsafety internally
Talkless has quit [Quit: Konversation terminated!]
<darosior>
Re the discussion about checking all consensus rules in ConnectBlock, i'm not sure if we should really be concerned about somehow an invalid block being let in by an unupgraded version being connected by an upgraded one, if the unupgraded version could just have connected it in the first place and the upgraded version wouldn't catch that either?
<darosior>
I guess there is a slight advantage to being able to catch it with `verifychain` or a `-reindex-chainstate` but..
cygnet3 has quit [Quit: Leaving]
<bitcoin-git>
[qa-assets] murchandamus opened pull request #218: Add Murch’s inputs February 2025 merged without sanitizers (main...2025-02-murch-inputs-no-san) https://github.com/bitcoin-core/qa-assets/pull/218
jonatack has joined #bitcoin-core-dev
Cory58 has quit [Quit: Client closed]
Cory58 has joined #bitcoin-core-dev
pyth has quit [Ping timeout: 244 seconds]
pyth has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
pyth has quit [Ping timeout: 248 seconds]
pyth has joined #bitcoin-core-dev
instagibbs4 has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
dongcarl4 has joined #bitcoin-core-dev
midnight_ has joined #bitcoin-core-dev
javi404_ has joined #bitcoin-core-dev
otoburb_ has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
otoburb has quit [Ping timeout: 252 seconds]
MyNetAz has quit [Ping timeout: 252 seconds]
adiabat_ has quit [Ping timeout: 252 seconds]
dongcarl has quit [Ping timeout: 252 seconds]
midnight has quit [Ping timeout: 252 seconds]
instagibbs has quit [Ping timeout: 252 seconds]
javi404 has quit [Ping timeout: 252 seconds]
instagibbs4 is now known as instagibbs
dongcarl4 is now known as dongcarl
flooded has quit [Remote host closed the connection]