<scg>
Is my understanding correct?: parity encoded in TapLeaf version is only needed in witness? Seems to me that You do not need to care about it when constructing or signing PSBT. Only when one builds witness is properly encoded parity flag required in TapLeaf version.
Guest36 has joined #bitcoin-core-dev
Guest36 has quit [Client Quit]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
puchka has quit [Ping timeout: 256 seconds]
b_101 has quit [Ping timeout: 268 seconds]
jon_atack has quit [Ping timeout: 240 seconds]
bitdex has quit [Quit: = ""]
jon_atack has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
stevenwy37 has quit [Remote host closed the connection]
stevenwy37 has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 240 seconds]
jon_atack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 268 seconds]
pablomartin4btc_ has quit [Quit: Leaving]
pablomartin has joined #bitcoin-core-dev
puchka has joined #bitcoin-core-dev
Guest98 has joined #bitcoin-core-dev
Guest98 has quit [Client Quit]
ZeroMaster_ has quit [Read error: Connection reset by peer]
ZeroMaster_ has joined #bitcoin-core-dev
scg has quit [Quit: Client closed]
scg has joined #bitcoin-core-dev
ZeroMaster_ has quit [Read error: Connection reset by peer]
<bitcoin-git>
[bitcoin] fanquake merged pull request #27580: msvc: Cleanup after upgrading libsecp256k1 up to 0.3.0 (master...230505-cleanup) https://github.com/bitcoin/bitcoin/pull/27580
bugs_ has joined #bitcoin-core-dev
flooded has joined #bitcoin-core-dev
test_ has quit [Ping timeout: 260 seconds]
scg has quit [Quit: Client closed]
preimage has joined #bitcoin-core-dev
stevenwy37 has quit [Quit: Leaving...]
<jamesob>
hey, there's no way we can do Github access just to maintain a particular project is there? The assumeutxo board is out of date: https://github.com/bitcoin/bitcoin/projects/11
<achow101>
jamesob: I can add just you to maintain that
<achow101>
we can add individuals to each project board's access
<achow101>
I think
<_aj_>
need to convert to an org project first, i think?
<_aj_>
or a non-classic project or whatever
<fanquake>
yea a couple there we should probably migrate or close
<jb55>
my core node was getting spammed with "Cache size (23509456) exceeds total space (15701232)" yesterday and then eventually just stopped working/got stale tip errors until I restarted. first time this has happened, has anyone experienced this?
<fjahr>
jb55: What do you mean by getting spammed? The log message isn't a big issue by itself afaict. It just means that the cache will need to be flushed to disk. But that doesn't mean we shouldn't look into this of course. What disk do you run this node on?
<jb55>
fjahr: means it was repeated 100 times or so. slow disk (HDD)
<jb55>
then it just stopped and started to get stale tip warnings.
<jb55>
a bit concerning if mempool activity could bring down my node :(
<jb55>
I assumed that's what the message was about, not sure
infernix has joined #bitcoin-core-dev
<instagibbs>
it means it should flush to disk immediately, seeing it repeated that much is sketchy
<fjahr>
Hmm, yeah, absolutely. Could it be that the cache is growing so fast that it fills up the memory and renders core unable to flush on a slow disk?
<fjahr>
summoning cache all stars jamesob, ryanofsky :)
<instagibbs>
ghost43 looks like you're having repeated timeouts from peers. I've seen more lately, but nothing like that 3 times in a row
<provoostenator>
ghost43: does getchaintips tell you which block triggered the bad-witness-nonce-size?
<ghost43>
I have another node I am running addnoded bidirectionally with this one, which is not stuck. I would have hoped they can get blocks from each other :/
<instagibbs>
miner either made a stoopid block, or someone relayed a malleated block witness data for some reason
<sdaftuar>
instagibbs: or hardware failure i think?
<instagibbs>
sdaftuar always a possibility sure
<jb55>
same
<sdaftuar>
i'd have to guess hardware failure as most likely. can try to submitblock the hex of what we all think is valid and see if the node takes it
<instagibbs>
^ good idea, shove the next block in, see if it takes
<sipa>
It says headers-only, not invalid.
<sdaftuar>
malleation would cause that though
<sdaftuar>
er, what was detected as malleation
<sipa>
So it has never received the block (except perhaps malleated versions of it).
<instagibbs>
MUTATED
<darosior>
I was trying to send you the output of getblock so you can submitblock but i can't find a paste site that accepts such large data
<instagibbs>
"BLOCK_MUTATED,"
<sipa>
Mutated.
<sipa>
Yes.
<sipa>
But why are all copies mutated?
<sipa>
Of all the versions ghost43 is receiving?
MatrixBot123456 has joined #bitcoin-core-dev
<provoostenator>
So there's no recent invalid block in that getchaintips output. I guess we don't store failures related to maleation?
<instagibbs>
I'm seeing "Timeout" from his log, not rejection again
<provoostenator>
(since we want to try again)
<instagibbs>
provoostenator a peer could stuff logs/state cheaply with BLOCK_MUTATED I think
<sdaftuar>
instagibbs: oops
<provoostenator>
Sounds like we should add the block hash to log messages when this happens for easier debugging later.
<instagibbs>
only behind verbose logging, otherwise it's free to trigger
<instagibbs>
(IIUC)
<instagibbs>
sdaftuar what's the oops
<sdaftuar>
your logging observation!
<provoostenator>
instagibbs: good poin
<provoostenator>
But we're already logging this rejection, so adding the hash wouldn't make it worse :-)
<provoostenator>
I do not understand the code comment above that check by the way: "The malleation check is ignored; as the transaction tree itself already does not permit it, it is impossible to trigger in the witness tree."
<sdaftuar>
we don't need to look for transaction duplicates there
<provoostenator>
In particular what is being "ignored" here.
<provoostenator>
Oh it's the malleated result from the previous call that we ignore.
<sdaftuar>
provoostenator: right we don't have to worry about merkle root malleation like we do in CheckBlock, because we've already done those checks
<instagibbs>
it might fix itself on next block peers get
<ghost43>
yes it has the headers
<instagibbs>
oh
<instagibbs>
check getpeerinfo for "inflight"s? would that be the place?
<provoostenator>
cfields: SaveBlockToDisk is called after ContextualCheckBlock
<b10c>
then I had the same issue. It knew the headers but kept timing out while downloading the blocks.
Guest80 has joined #bitcoin-core-dev
<sdaftuar>
cfields: AcceptBlock is where we store to disk; in that function we invoke ContextualCheckBlock which is what reported the bad-witness-nonce-size error that ghost43 reported. so i don't see how the block could have been stored after that?
<cfields>
sdaftuar / provoostenator: yep, you're right, I see. thanks to both of you.
<fjahr>
b10c: I misread "headers-only" for "valid-headers" and that would have been confusing
<instagibbs>
b10c ghost43 are the stuck nodes listening nodes?
<ghost43>
yes, it is listening on ipv4 and onion
<ghost43>
"Timeout downloading block 00000000000000000001081dd49ade1108f0b5415605249804a0a95a8e63a3f6 from peer" in log :/
Guest80 has left #bitcoin-core-dev [#bitcoin-core-dev]
<instagibbs>
I've had no timeouts on my non-listening nodes, anecdotally
<sdaftuar>
jb55: do you have the last UpdateTip line your node saw before the cache size messages? the end of those UpdateTip lines shows how big your coins cache was at the end of block validation
<b10c>
instagibbs: yes
<ghost43>
well, ok, I've restarted bitcoind and it instantly caught up to the tip
<sdaftuar>
interesting!
<fjahr>
jb55: do you have a custom maxmempool setting?
puchka has joined #bitcoin-core-dev
<sdaftuar>
i'll be afk for a bit, but if someone can open an issue and log some of this i think it's worth more investigation
<fjahr>
jb55: also, I would be curious if this happened around the time when we had the 2 block reorg ~20h ago, i.e. around 788685-788688
<fjahr>
I can open an issue if nobody else has started it already
<ghost43>
my bitcoind got stuck again on 788809, due to "Timeout downloading block", so basically after the restart it caught up to tip fast and then it failed to download any subsequent blocks. (now tip is 788812) now I've restarted and again it caught up very fast to current tip...
<bugs_>
hopefully its just network bandwidth problems and not a new sybil
<achow101>
ghost43: are you seeing a lot of cpu usage?
flooded has quit [Ping timeout: 240 seconds]
<fjahr>
ghost43: please take note of the peers you are connected to. Have you tried to connect to a new, public node to see if that changes anything?
<ghost43>
achow101: not really. server has 8 virtual cpus (I think 4 real cores, times two SMT), load averages below 2.0
<ghost43>
bugs_: it cannot be sybilled in the naive sense because I have addnoded other nodes I control and they are running fine
<ghost43>
btw it logged "ERROR: AcceptBlock: bad-witness-nonce-size, ContextualCheckBlock : invalid witness reserved value size" again
<achow101>
just on the block you got stuck on?
<bugs_>
ah it might have gotten stuck on an ht core
<bugs_>
ht core gets no cycles if the real cores are running sufficiently optimized code
<fjahr>
ghost43: could it be that the server host or their providers are blocking bitcoin traffic? Or do you have other nodes on servers in the same infra that don't have the issue?
<ghost43>
achow101: I think so because the tip was 788812 and it had header for 788813, and it logged that line then; however the log does not say which block height or hash the error is for
<bugs_>
i always disable HT
<ghost43>
this is a hetzner server with 1810 days uptime; I doubt its peering issues. last time I restarted it was when I dist-upgraded to ubuntu 18.04 when that got released :D
<instagibbs>
that sounds like hardware failure or a sybil attacker which has figured out how to stall you out by mutating a tx (sounds like hardware ...)
<achow101>
was it the same peer as before?
<instagibbs>
mutating a block*
<bugs_>
i had heard heztner decided to become crypto unfriendly a few months ago
<achow101>
being able to see the block itself would also be interesting
<fjahr>
ok, I mean hetzner has said that they don't want crypto stuff but if they had started to block traffic widely we would hear more complaints
<bugs_>
but i'd definetly try turning off ht thats my bet
<bugs_>
there is a way to do it in linux without rebooting
<sipa>
@bugs_ That really seems unrelated.
<bugs_>
but turning it off in the vbios is best
<bugs_>
if something that owns a lock gets scheduled on an ht core bad things can happen
<bugs_>
like an nfs lock
<ghost43>
but it's been running like this for *years*, it cannot be ht :P
<ghost43>
anyway, I am running the unreleased 24.0.0, if that matters; so I'll just upgrade to the v25.0rc1 tag, and also do a dist-upgrade from this ancient ubuntu (though that's only the host, the docker container running bitcoind is modern), and see if the hang reappears after that
<instagibbs>
run in non-listening mode
<achow101>
maybe also run tcpdump to catch the block data?
<jb55>
sdaftuar: unfortunately no this is just a tmux backbuffer since I was rebuilding my utxo due to some kind of leveldb corruption. wasn't my main systemd logs. @fjahr: I don't have any custom maxmempool settings. This started happening 20hrs ago yes when mempool was hot
<jb55>
sdaftuar: earliest log line I have of the cache spam thing is 2023-05-07T17:21:08Z
<fjahr>
ghost43: I don't think the 24.0.1 fixes are related (#26616 if anyone else wants to check)
<jamesob>
One thought for jb55's issue: FlushStateToDisk ultimately issues the log he's getting spammed with, and the coins cache flush there is gated `by if (fDoFullFlush && !CoinsTip().GetBestBlock().IsNull())` (with no corresponding log in the `else`), so his coinstip's bestblock somehow got nullified, he'd be in a position where the cache gets critical
<jamesob>
but doesn't get flushed
<jamesob>
*so if his coinstip's bestblock
<jamesob>
but the only way I can see that happening is exceptionally unlucky memory fault?
<jamesob>
I forgot that every ATMP call also calls FlushStateToDisk(..., PERIODIC)
test_ has quit [Ping timeout: 256 seconds]
vincenzopalazzo has joined #bitcoin-core-dev
scg has quit [Quit: Client closed]
Dionysus has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
Dionysus has quit []
<bitcoin-git>
[bitcoin] pinheadmz opened pull request #27600: Make peer eviction slightly more aggresive to make room for whitelisted inbound connections (master...whitebind-evict) https://github.com/bitcoin/bitcoin/pull/27600
jarthur has joined #bitcoin-core-dev
<jb55>
jamesob: what is ATMP
chutner has joined #bitcoin-core-dev
<instagibbs>
AcceptToMemPool
<jb55>
ah k
<bitcoin-git>
[bitcoin] furszy opened pull request #27601: wallet: don't duplicate change output if already exist (master...2023_wallet_double_change_output) https://github.com/bitcoin/bitcoin/pull/27601
chutner has quit [Client Quit]
<bitcoin-git>
[bitcoin] sr-gi opened pull request #27602: net: avoid serving non-announced txs as a result of a MEMPOOL message (master...mempool-not-inved) https://github.com/bitcoin/bitcoin/pull/27602
preimage has quit [Quit: WeeChat 3.8]
jackjack has joined #bitcoin-core-dev
jackjack has quit [Ping timeout: 256 seconds]
bitdex has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
andytosh1 has quit [Quit: leaving]
Guest9 has joined #bitcoin-core-dev
Guest9 has quit [Client Quit]
aielima has quit [Quit: Ciao]
SpellChecker_ has quit [Remote host closed the connection]
ghost43 has quit [Remote host closed the connection]
yanmaani1 has quit [Remote host closed the connection]