antanst has quit [Read error: Connection reset by peer]
antanst9 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] achow101 opened pull request #32597: wallet: Always set descriptor cache upgraded flag for new wallets (master...desc-cache-is-upgraded) https://github.com/bitcoin/bitcoin/pull/32597
<bitcoin-git>
[bitcoin] achow101 opened pull request #32598: walletdb: Log additional exception error messages for corrupted wallets (master...loadwallet-log-runtime_error) https://github.com/bitcoin/bitcoin/pull/32598
<jon_atack>
Would someone with label privileges add the Review club label to the pull for next week's meeting, please?
maflcko has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
maflcko has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
Guest74 has joined #bitcoin-core-dev
Guest74 has quit [Client Quit]
charlie_capt has joined #bitcoin-core-dev
Christoph__ has quit [Quit: Christoph__]
charlie_capt has quit [Client Quit]
<TheCharlatan>
cfields, mind linking that github comment re cuckoocache locking? Was working on that a couple of days ago, but was also not clear to me what might have been the original intention of externalizing the locks.
charlie_capt has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
antanst9 has quit [Remote host closed the connection]
<gmaxwell>
sipa: on the unlikely hypothetical of bare multisig txouts becoming commercially popular. The obvious solution in that case is that for any output >>256 bits in size it should just be stored in the utxo set as a hash and transactions should have to come with the preimage. ... and I think an example of the answer to problematic tx flux is to just fix the problem.
antanst9 has joined #bitcoin-core-dev
<gmaxwell>
(or, consider the sigops limit ... to consensus ban them)
<gmaxwell>
(creating them)
Holz has quit [Ping timeout: 252 seconds]
Holz has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
Christoph_ has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
<sipa>
gmaxwell: UHS !
jespada has joined #bitcoin-core-dev
charlie_capt has quit [Quit: Client closed]
antanst91 has joined #bitcoin-core-dev
antanst9 has quit [Ping timeout: 268 seconds]
antanst91 is now known as antanst9
Guest13 has joined #bitcoin-core-dev
Guest13 has quit [Client Quit]
Christoph_ has quit [Quit: Christoph_]
Christoph_ has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
jespada has quit [Client Quit]
jespada has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #32601: test: Fix `system_tests/run_command` test (master...250523-run-comand-test) https://github.com/bitcoin/bitcoin/pull/32601
<bitcoin-git>
[bitcoin] hebasto closed pull request #32577: subprocess: Let shell parse command on non-Windows systems (master...250521-subprocess-split) https://github.com/bitcoin/bitcoin/pull/32577
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
<instagibbs>
gmaxwell think cfields was punting that idea around years ago
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
Earnestly has quit [Ping timeout: 268 seconds]
Earnestly has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 244 seconds]
bugs_ has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 252 seconds]
jamesob443688173 has joined #bitcoin-core-dev
jamesob156659 has joined #bitcoin-core-dev
Guest39 has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
Guest39 has quit [Client Quit]
kevkevin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] marcofleon opened pull request #32602: fuzz: Add target for coins database (master...2025/05/coins-view-db-fuzztest) https://github.com/bitcoin/bitcoin/pull/32602
bugs_ has quit [Remote host closed the connection]
<gmaxwell>
I stumbled into this somewhat old PR https://github.com/bitcoin/bitcoin/issues/28272 I think it's a moderately severe privacy problem. Consider a wallet in blocksonly mode. An attacker can race to send it an unsolicited compact block to determine what transactions the node sent. There is a straightforward fix: drop or treat as header messages any compact block where you hadn't asked the peer
<gmaxwell>
for it.
<gmaxwell>
(and blocksonly nodes won't do so)
<gmaxwell>
that behavior avoids another kind of potential abuse where someone spams the network with unsolicited corrupted compact blocks to gum operations (fortunately that attack would not be so effective) or an attack where they mass broadcast faithful compact blocks to speed up their own propagation (more effective, but less harmful).
<bitcoin-git>
[bitcoin] rkrux opened pull request #32603: wallet, rpc: clarify wallet version in getwalletinfo help (master...wallet-version) https://github.com/bitcoin/bitcoin/pull/32603
<gmaxwell>
(or perhaps ideally disconnect the peer, unless they had recently been HB-- simply because treating it as a header might gum block propagation a little given that we already can tell the peer is violating the protocol)
dzxzg has joined #bitcoin-core-dev
<lightlike>
gmaxwell: doesn't the fact that we are in blocksonly mode, and still sent out txns (which would have need to be done directly via rpc) mean that all expectations for privacy are already abandoned anyway?
<gmaxwell>
lightlike: hm? you can run a wallet in blocksonly mode, no rpc required AFAIK.
<gmaxwell>
lightlike: you certantly have way less private since there is no cover for anyone who saw your announcement.
<lightlike>
-blocksonly "Disables automatic broadcast and rebroadcast of transactions"
<lightlike>
... unless the source peer has the 'forcerelay' permission
<gmaxwell>
or you've set walletbroadcast=1 ?
<gmaxwell>
(yes)
spynxic has quit [Ping timeout: 272 seconds]
<lightlike>
yes, I guess you can overwrite it. but my point is if you send out txns when in blocksonly mode (whatever way) you already told all your peers that they are yours, so no one needs to perform an elaborate compact block attack on you
spynxic has joined #bitcoin-core-dev
<gmaxwell>
lightlike: Good point, I had been thinking that the non-broadcast txn was still in your mempool just not announced. Actually checking the code I see that that isn't so, if broadcast is off it's not even mempooled.
<gmaxwell>
lightlike: thanks!
<lightlike>
gmaxwell: even if it was mempooled, how would attackers know what txid to probe for? they'd have to have learnt about the tx some other way i guess?
<gmaxwell>
lightlike: they don't even have to probe for it if it's mined, just offer you the block and learn which txn you *don't* request. :P but also on that general point, for leak attacks you can just guess and keep trying.
<gmaxwell>
(I mean guess among txn you know of via some other means, indeed)
<gmaxwell>
the annoying thing about information leaks is that the attacker can just keep trying and eventually the evidence becomes overwhelming, unless you're like .. only transacting once a year.
<gmaxwell>
and like, someone doesn't need total certanty before they decide you're worth taking a wrench to. :P
bugs_ has joined #bitcoin-core-dev
<gmaxwell>
but you convinced me that there is no big additional concern here. (I mean, I still think unsolicited unexpected messages need to be dropped, but it's not a big privacy issue)
<lightlike>
sorry, I feel like I'm missing something important. How did the tx that I never announced (but put into my mempool) end up in a block? How does anyone but me know its txid / on what basis do you probe?
<gmaxwell>
lightlike: because you announced it seperately. This is a thing some people do-- by submitting it using wumpus python tool over tor, or using one of the web submission APIs over tor.
<gmaxwell>
but I read the code(tm) just now and see that it doesn't appear to be mempooled.
<lightlike>
gmaxwell: ok, gotcha. yes, in that case I'm vulnerale, agreed.
<gmaxwell>
I think no? just because it won't be in your mempool.
<gmaxwell>
(but it was my (mis)understanding until a few minutes ago that it would be mempolled, probably primed by reading the issue)
<lightlike>
right, okay.
<gmaxwell>
I think in general private wallet use is an important area, since just using a wallet privately is a big reason to use bitcoin core. Essentially all other wallet approaches (except perhaps obscure ones) end up identifying you to third parties even when you're not sending a txn. Best you can do is use them over tor which has pretty significant limitations for long lived usage.
<bitcoin-git>
[bitcoin] hebasto reopened pull request #32577: subprocess: Let shell parse command on non-Windows systems (master...250521-subprocess-split) https://github.com/bitcoin/bitcoin/pull/32577
eugenesiegel has joined #bitcoin-core-dev
Cory80 has quit [Quit: Client closed]
Cory80 has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 252 seconds]
<bitcoin-git>
[bitcoin] mzumsande closed pull request #31714: validation: Do less work in NeedsRedownload (master...202501_simpler_segwit_check) https://github.com/bitcoin/bitcoin/pull/31714
eugenesiegel has quit [Quit: Client closed]
Cory80 has quit [Quit: Client closed]
Cory80 has joined #bitcoin-core-dev
bugs_ has quit [Ping timeout: 276 seconds]
<dzxzg>
wouldn't disallowing unsolicited compact block messages delay block propagation by a round trip?
<lightlike>
dzxzg: The one's we actually want (from a high-bandwidth peer) wouldn't count as unsolicited and wouldn't be affected.
<dzxzg>
ah, I see, that makes sense. But, a node would still be if it were unlucky enough to have selected a nosy peer as high bandwidth (doesn't apply to blocksonly since they never mark peers as high bandwidth)
<dzxzg>
*would still be vulnerable
<lightlike>
dzxzg: yes, but in the non-blocksonly case the question is vulnerable to what: in general the mempool (all txns older than our last inv to the peer) can also be queried with simple GETDATAs, see my post in #28272
<gmaxwell>
dzxzg: lightlike convinced me the leak issue was a nothing burger, though I think it should still drop them to discourage other abusive behavior.
<gmaxwell>
dzxzg: I'm not sure what the status of random transaction requests are. Previously the relay pool prevented you from doing that generally, and I know there was at least private-security discussion about further restricting it so that someone else being relayed a transaction wouldn't permit you to request it. But there were also some complications around orphan parent fetching.
mcey_ has joined #bitcoin-core-dev
<sipa>
gmaxwell: i think #27675 is probably the latest there (tldr: whenever an INV is sent, you permit the peer to request whatever was in your mempool at the time of the INV)
jonatack has quit [Read error: Connection reset by peer]
<gmaxwell>
sipa: ah, thats pretty good. At least to the extent that when you INV you will have sent ~all the relayable things up to that point (ignoring rate limiting corner cases I guess, and the fact that the peer may not have been connected forever)
<gmaxwell>
Also means that CB stuff there is an information leak, not the most cosmic since it requires that attacker to have possession of a block header you'd accept.
<sipa>
gmaxwell: i think prior to that PR, the rule was that only transactions which (a) have been in the mempool for at least some amount of time (like a few minutes) or (b) were recently announced to the peer, were requestable. But the observation of the PR was that the INV ratelimiting is only for saving bandwidth, and isn't a privacy gain, and because of that, allowed dropping the recently-announced
<sipa>
set
<gmaxwell>
yeah I think the relay behavior post that PR sounds fine.
<gmaxwell>
An observation on that issue is that compact blocks can be used to interogate the mempool in varrious ways that bypass that limit. Like you get a new block header and then quickly go tell a peer a made up compact block that has a bunch of short IDs that correspond to txid you want to probe for in their mempool which may not have been relayed out by them at all, and then observe what they
<gmaxwell>
getblocktxn.
<gmaxwell>
To close it completely would require replacing compact blocks with something that uses FEC to covey missed txn, as that gives you a high amount of automatic privacy over what you're fetching.
<gmaxwell>
But it could be reduced by not processing unsolicited compact blocks.
<sipa>
Or adding a ZKP that the short IDs actually correspond to wtxids whose txids's Merkle root is the one in the header
<gmaxwell>
yes but I think that's strictly less good than FEC fill in data.
<gmaxwell>
sipa: or just sending the wtxids as your 'compact block' then it's self proving but the communications performance is poor.
<sipa>
wtxids + coinbase merkle path
<sipa>
but, indeed
<gmaxwell>
I think at one point there was discussion of constructing the CB nonce in such a way that the block could have a commitment to the short-ids, but I think the cost of the reveal on that proof makes it kinda unattractive.
MrHAPPY has joined #bitcoin-core-dev
<gmaxwell>
and then we also decided that having diverse CB nonces was just really nice because any collision would at least be a localized transmission fault.
<gmaxwell>
(which made it easier to justify having pretty short shortids)
<bitcoin-git>
bitcoin/master db465a5 Sebastian Falbesoner: wallet, rpc: remove obsolete "keypoololdest" result field/code
<bitcoin-git>
bitcoin/master 7a05f94 Sebastian Falbesoner: rpc: doc: drop descriptor wallet mentions in fast wallet rescan related RP...
<bitcoin-git>
bitcoin/master e5cbea4 Sebastian Falbesoner: rpc: doc: remove redundant "descriptors" parameter in `createwallet` examp...
<bitcoin-git>
[bitcoin] achow101 merged pull request #32596: wallet, rpc, doc: various legacy wallet removal cleanups in RPCs (master...2025-wallet-rpc-related_legacy_wallet_cleanups) https://github.com/bitcoin/bitcoin/pull/32596
jamesob443688173 has quit [Ping timeout: 252 seconds]
jamesob156659 has quit [Ping timeout: 252 seconds]
jamesob443688173 has joined #bitcoin-core-dev
jamesob156659 has joined #bitcoin-core-dev
rmatte has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Crypt-iQ opened pull request #32604: log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError (master...log_ratelimiting_05192025) https://github.com/bitcoin/bitcoin/pull/32604
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32606: p2p: Drop unsolicited CMPCTBLOCK from non-HB peer (master...5-23-25-ignore-unsolicited) https://github.com/bitcoin/bitcoin/pull/32606
<bitcoin-git>
[bitcoin] benthecarman opened pull request #32607: rpc: Note in fundrawtransaction doc, fee rate is for package (master...fundawtx-pkg-doc) https://github.com/bitcoin/bitcoin/pull/32607