kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 246 seconds]
pyth has quit [Remote host closed the connection]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
manny68 has quit [Quit: Client closed]
robszarka has quit [Quit: Leaving]
szarka has joined #bitcoin-core-dev
flow has quit [Ping timeout: 268 seconds]
OGU has quit [Ping timeout: 252 seconds]
flow has joined #bitcoin-core-dev
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
eval-exec has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
agentcasey_ has quit [Remote host closed the connection]
agentcasey has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] stutxo opened pull request #32181: BIP-777 (GPR) The Great Poker Restoration: Add the poker client back to bitcoin (master...master) https://github.com/bitcoin/bitcoin/pull/32181
agentcasey has quit [Quit: ZNC 1.10.x-git-38-e8c4cda0 - https://znc.in]
agentcasey has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
agentcasey has quit [Quit: ZNC 1.10.x-git-38-e8c4cda0 - https://znc.in]
agentcasey has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 244 seconds]
pyth has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
Christoph_ has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
agentcasey has quit [Quit: ZNC 1.10.x-git-38-e8c4cda0 - https://znc.in]
agentcasey has joined #bitcoin-core-dev
agentcasey has quit [Ping timeout: 260 seconds]
agentcasey has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
eval-exec has quit [Ping timeout: 276 seconds]
Cory21 has quit [Quit: Client closed]
Cory21 has joined #bitcoin-core-dev
OGU has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
noonien808310429 has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 244 seconds]
<bitcoin-git>
[bitcoin] hebasto opened pull request #32182: ci: Switch to dynamic library linkage in native Windows job (master...250401-ci-dll) https://github.com/bitcoin/bitcoin/pull/32182
<pinheadmz>
Did stutxo actually write a full working poker client? Wow really dedicated to the bit
SpellChecker_ has quit [Remote host closed the connection]
kevkevin has quit [Ping timeout: 260 seconds]
Cory21 has quit [Quit: Client closed]
Cory21 has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 272 seconds]
kevkevin has joined #bitcoin-core-dev
<laanwj>
pinheadmz: haven't tried it yet, but the scoring looks entirely functional at first glance, the only thing i've noticed missing is there's no betting and no decision capacity for the computer player (it will just go along and show cards on showdown)
<laanwj>
but yes it's definitely some serious commitment to the bit
<sliv3r__>
@laanwj that's bc he is going with multiplayer lobbies in the future :)
<laanwj>
sliv3r__: satoshi's original vision !
sliv3r__ has quit [Read error: Connection reset by peer]
<bitcoin-git>
[bitcoin] rkrux opened pull request #32186: descriptor: handle listdescriptors(private=true) in case of taproot descriptors having partial keys (master...taproot-list-desc) https://github.com/bitcoin/bitcoin/pull/32186
<sipa>
instagibbs, dergoegge: indeed. ideas (1) add a sequence number to clusters (which would need to be 64 bits so it never overflows, adding 8 bytes to every cluster, which is a bit unfortunate for future memory-saving ideas), (2) use (QualityLevel, ClusterSetIndex) as identifier, which means quality changes require redoing all chunkindexes in the cluster (post 31444), or (3) use GraphIndex of first
<sipa>
element as representative (meaning redoing all chunkindexes...
<sipa>
when adding/removing transaction, but i think that needs those anyway)
Christoph_ has joined #bitcoin-core-dev
<sipa>
oh but (3) would be annoying when compacting
<hebasto>
re "It's crazy how often the Windows CIs are broken..." -- in this case, it is libevent maintainers' responsibility; we are also applying a patch that addresses exactly the same issue in depends
Guyver2 has joined #bitcoin-core-dev
eval-exec has joined #bitcoin-core-dev
Cory21 has quit [Quit: Client closed]
Christoph_ has quit [Quit: Christoph_]
Cory21 has joined #bitcoin-core-dev
<instagibbs>
(2) sounds ok-ish? Transition only happens from ACCEPTABLE->OPTIMAL
<instagibbs>
ah no, optimal->acceptable too
<sipa>
i'll just add a sequence number now
<sipa>
i have a few ideas for memory reduction, which can all be added in a later PR
<instagibbs>
can always go another direction in the future, I guess
<instagibbs>
sgtm
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] ryanofsky merged pull request #32096: Move some tests and documentation from testnet3 to testnet4 (master...2025/03/testnet3-4) https://github.com/bitcoin/bitcoin/pull/32096
<eugenesiegel>
ah ok, that's what I was looking at. I wasn't sure if there were other docs
PennyEther has quit [Changing host]
PennyEther has joined #bitcoin-core-dev
<PennyEther>
Hi all. Looking to find out how Block Tree Spam is avoided. Eg, if an attacker sent a ton of valid blocks at N-400,000, what prevents Core from adding those headers to the block tree?
<PennyEther>
Perhaps you can teach me to fish -- would there be a way to find this answer without knowing the appropriate search terms like "disk fill attack" or "header pre-synchronization"?
<PennyEther>
My next question is: Suppose I secretly had 55% of hashrate, and started mining a "ghost fork" from block N. Some time (T), let's say 144 of (my) blocks later, I decide to broadcast all those blocks. Assume that at that time T nodes are only up to N+130 (assume this is less total work, eg, difficulty is constant)... is it safe to say all nodes
<PennyEther>
would reorg to my chain? And would the ramification be that TX's within those 130 of "reorged" blocks would go back into the mempool (except for any TXs contained in my new chain)?
<sipa>
Yes, it should reorg. No, over some limit (I think 10 blocks deep reorgs?) we don't bother moving transactions back to the mempool
<PennyEther>
Is there a limit to how many blocks I could reorg? The example used 130
<sipa>
You should in theory be able to reorg back all the way to the genesis block.
<bitcoin-git>
bitcoin-detached-sigs/29.x 20b376c glozow: 29.0 win sig for rc3
<PennyEther>
That would seem to imply I could spam some sort of data structure required to determine the longest chain. Eg, I could submit 1m blocks at height = 2... the node can't know if they might be part of a longer chain or not. Perhaps this is addressed in the article and I have to grok it
<PennyEther>
Yeah, I just have to read it.
<PennyEther>
Anyway, back to this reorg thing. So the TXs in the 130 blocks... they would have to be resubmitted?
<sipa>
Up until the point where the attacker convinces the victim that they indeed have a sufficient-PoW chain, that datastructure is an O(1)-sized per-peer thing only.
pyth has quit [Remote host closed the connection]
<sipa>
PennyEther: yes, they'll need to be resubmitted (if they're still valid at all)
<sipa>
but anyone could do that
<PennyEther>
True. Thought in the real world, logistically, it may be challenging to resubmit some TXs
<PennyEther>
Especially if N is >> 130
<sipa>
in the real world, we might have bigger things to worry about than some transactions not immediately being remined
<PennyEther>
Agreed.
Christoph_ has quit [Quit: Christoph_]
<PennyEther>
I've lately been ruminating over the incentive to do such an attack, vs the cost. It would seem that "renting" 51% hashrate by starting several "independent" pools would not be very cost prohibitive. Suppose I started some pools that paid 10% more than FPPS, and paid in BTC hourly. Once I've collectively achieved 51%, my cost drops to 0... I could
<PennyEther>
pay them BTC on the consensus chain then rugpull it later with a big reorg. The only way miners could detect my attack is if a) they validate the templates I send them to ensure the parent is a block they are aware of ... or b) they notice network hashrate dropping and determine it is due to some set of pools (of which they are a participant)
<PennyEther>
and switch pools
<PennyEther>
That's my current understanding -- curious to hear thoughts on this. If this is an inappropriate venue to discuss, let me know
<sipa>
This sounds more like something for delvingbitcoin.org
<darosior>
you lost me at "renting 51% of Bitcoin's hashrate wouldn't be cost prohibitive" :p
<darosior>
But yeah this is starting to drift off-topic for this channel
<PennyEther>
The sum total cost would be 10% of the rewards mined in my pools before I got to 51%
<PennyEther>
Ok, apologies -- I'll take this idea elsewhere.
<glozow>
agh. there is something wrong with the win signature, sorry. need to revert that
<bitcoin-git>
[bitcoin] marcofleon opened pull request #32189: refactor: Txid type safety (parent PR) (master...2025/03/full-txid-type-safety) https://github.com/bitcoin/bitcoin/pull/32189
OGU has joined #bitcoin-core-dev
<instagibbs>
marcofleon liked and subscribed
<glozow>
err.... April Fools
Talkless has quit [Quit: Konversation terminated!]
<Murch[m]>
@pennyEther: Generally, I have had good results using a common search engine restricted to bitcoin.stackexchange.com, as the search function on BSE itself is not great. There are a ton of discussions of "majority attacks" and "chain-reorganizations" there, though.
OGU has quit [Read error: Connection reset by peer]
Cory38 has joined #bitcoin-core-dev
Cory76 has quit [Ping timeout: 240 seconds]
OGU has joined #bitcoin-core-dev
Cory66 has quit [Ping timeout: 240 seconds]
<sliv3r__>
@PennyEther: I'm going to contradict @Murch[m] here, the SE search engine works fine for me (maybe I've been lucky with my searches). Many times I start typing in questions and the similar question recommender gives me what I'm looking for.
<sipa>
Turns out searching works a lot better when you already know what you're looking for.
<Murch[m]>
sliv3r__: Yeah, when you start writing a question it is pretty good, but using the search field, I often don’t even find the question I know I’m looking for when I am using the exact terms that appear in the question’s title
<sliv3r__>
Yeah, could be I always start asking before searching that's why :)
<bitcoin-git>
[bitcoin] kevkevinpal opened pull request #32190: test: added coverage to bitcoin-chainstate testing invalid block header (master...invalidHeaderTestChainstate) https://github.com/bitcoin/bitcoin/pull/32190
Cory2 has joined #bitcoin-core-dev
Cory38 has quit [Ping timeout: 240 seconds]
Cory85 has joined #bitcoin-core-dev
Cory25 has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
Cory2 has quit [Ping timeout: 240 seconds]
Cory85 has quit [Ping timeout: 240 seconds]
Cory84 has joined #bitcoin-core-dev
Cory25 has quit [Ping timeout: 240 seconds]
jon_atack has quit [Ping timeout: 245 seconds]
eugenesiegel has quit [Quit: Client closed]
pablomartin4btc has quit [Quit: Leaving]
hernanmarino_ has quit [Ping timeout: 248 seconds]
hernanmarino has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] sipa opened pull request #32191: Make TxGraph fuzz tests more deterministic (master...202504_txgraph_deterministic) https://github.com/bitcoin/bitcoin/pull/32191
brunoerg_ has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] hebasto opened pull request #32194: ci, windows: Do not exclude `wallet_migration.py` in command line (master...250401-excluded) https://github.com/bitcoin/bitcoin/pull/32194
bugs_ has quit [Quit: Leaving]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]