Bitcoin Core Github
44 subscribers
120K links
Download Telegram
πŸ’¬ hodlinator commented on pull request "miniscript refactor: Remove unique_ptr-indirection (#30866 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/31713#discussion_r2172530750)
(Forgot to mention but I changed from `to_be_stripped` + `stripping` to `queue` + `flattening`).
https://github.com/bitcoin/bitcoin/blob/2bb86e371c21ca996cf8c1fbc80bc9b39f3d1dec/src/script/miniscript.h#L536-L544
πŸ’¬ Christewart commented on pull request "tests: Add witness commitment if we have a witness transaction in `FullBlockTest.update_block()`":
(https://github.com/bitcoin/bitcoin/pull/31823#discussion_r2172558100)
The line wasn't necessary, I removed it in 43d2613. Thanks for pointing this out though as the DrahtBot message wasn't clear to me!
πŸ’¬ instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#issuecomment-3013959756)
@sipa simulation looks solid from a few minutes going through it, I think it's a good addition
πŸ’¬ instagibbs commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172597431)
older comment
πŸ’¬ furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2172705028)
Hmm, sorry for the very very late response @andrewtoth. I missed this message completely.

> I still think we would want to abandon the work queue if we are interrupted instead of waiting for it to finish, no? My naive approach of not waiting for the queue to be empty does not work though.

Yeah, I don’t think that’s safe. Other threads might be waiting on the tasks' futures to complete, so exiting without notifying them would leave them blocked forever.
What we could do (and I think you me
...
πŸ’¬ furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2172711323)
> Can we modify this to be more generic and return a type? And add logic to collect all returned values into a shared vector which can then be atomically swapped out by an observer? Possibly not in this PR, but if this will be split out into a generic thread pool.

We could keep track of the task futures' promises, if that's what you're referring to. In other words, this void() function is just a wrapper that executes a generic function which sets the result inside the caller’s future.
πŸ’¬ achow101 commented on pull request "blocks: force hash validations on disk read":
(https://github.com/bitcoin/bitcoin/pull/32638#issuecomment-3014267780)
ACK 9341b5333ad54ccdb7c16802ff06c51b956948e7
πŸš€ achow101 merged a pull request: "blocks: force hash validations on disk read"
(https://github.com/bitcoin/bitcoin/pull/32638)
πŸ’¬ achow101 commented on pull request "test: added fuzz coverage for consensus/merkle.cpp":
(https://github.com/bitcoin/bitcoin/pull/32243#issuecomment-3014283854)
ACK 95969bc58ae0cd928e536d7cb8541de93e8c7205
πŸš€ achow101 merged a pull request: "test: added fuzz coverage for consensus/merkle.cpp"
(https://github.com/bitcoin/bitcoin/pull/32243)
πŸ’¬ achow101 commented on pull request "rpc: use CScheduler for HTTPRPCTimer":
(https://github.com/bitcoin/bitcoin/pull/32796#issuecomment-3014309449)
> `walletpassphrase` is currently the only RPC that schedules a new event, so all this PR will add to the queue are calls to `CWallet::Lock()` after the user needs a private key

`WalletContext` has its own `CScheduler` as well. I think it would probably make more sense to drop `HTTPRPCTimer` altogether and have the RPC schedule the lock by itself instead of taking a trip through the interfaces.
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851169)
Removed
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851273)
Made it >> 1
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851365)
done
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851409)
done
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851511)
done
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851580)
fixed
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172851840)
done
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172852325)
done
πŸ’¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2172852584)
Yes! Removed, thanks