π¬ sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925757556)
Thanks for all the benchmarks, see some graphs I created to compare their relative performance:



(code & data to generate them is [here](https://gist.github.com/sipa/f002a7e552fedabd5d727eb4a55624f0
...
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925757556)
Thanks for all the benchmarks, see some graphs I created to compare their relative performance:



(code & data to generate them is [here](https://gist.github.com/sipa/f002a7e552fedabd5d727eb4a55624f0
...
π¬ fjahr commented on pull request "index: Check all necessary block data is available before starting to sync":
(https://github.com/bitcoin/bitcoin/pull/29770#discussion_r2118296430)
Ok, I have addressed this by pulling the handing of this special case up and doing a check for block data of genesis if that is what's needed by an index that requires undo data.
(https://github.com/bitcoin/bitcoin/pull/29770#discussion_r2118296430)
Ok, I have addressed this by pulling the handing of this special case up and doing a check for block data of genesis if that is what's needed by an index that requires undo data.
π¬ fjahr commented on pull request "index: Check all necessary block data is available before starting to sync":
(https://github.com/bitcoin/bitcoin/pull/29770#issuecomment-2925784992)
Rebased, sorry for the long delay!
(https://github.com/bitcoin/bitcoin/pull/29770#issuecomment-2925784992)
Rebased, sorry for the long delay!
π¬ Jezmaul commented on something "":
(https://github.com/bitcoin/bitcoin/commit/2b51dd384b4a2655ee066e8bccd254270d0f5f6c#r158717712)
3E6RsQwEWiCLvZ3Lq33X1dR43VLTzYK9gg
(https://github.com/bitcoin/bitcoin/commit/2b51dd384b4a2655ee066e8bccd254270d0f5f6c#r158717712)
3E6RsQwEWiCLvZ3Lq33X1dR43VLTzYK9gg
β
fanquake closed an issue: "seeds: seed.bitcoin.jonasschnelli.ch not returning results"
(https://github.com/bitcoin/bitcoin/issues/32590)
(https://github.com/bitcoin/bitcoin/issues/32590)
β
ismaelsadeeq closed a pull request: "init: deprecate `-blockmaxweight` startup option"
(https://github.com/bitcoin/bitcoin/pull/32654)
(https://github.com/bitcoin/bitcoin/pull/32654)
π¬ ismaelsadeeq commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2926865658)
> Concept NACK. Lowering the block max weight can be a useful thing to do to (eg, signet blocks are limited to 1M weight units in order to help generate fee pressure, and mildly discourage wasteful usage), and having to pretend to pad the coinbase is a very awkward alternative.
Not sure what you mean by βhaving to pretend to pad the coinbase is a very awkward alternative.β
The reservedweight isnβt just for the coinbase it also applies to the block header and transaction count. It seems r
...
(https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2926865658)
> Concept NACK. Lowering the block max weight can be a useful thing to do to (eg, signet blocks are limited to 1M weight units in order to help generate fee pressure, and mildly discourage wasteful usage), and having to pretend to pad the coinbase is a very awkward alternative.
Not sure what you mean by βhaving to pretend to pad the coinbase is a very awkward alternative.β
The reservedweight isnβt just for the coinbase it also applies to the block header and transaction count. It seems r
...
π¬ ismaelsadeeq commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118919977)
Yes thats correct, this increases the weight by 8000.
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118919977)
Yes thats correct, this increases the weight by 8000.
π¬ ismaelsadeeq commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118920258)
yes that correct.
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118920258)
yes that correct.
π¬ glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2119024575)
Oof yes! Should be replaced with an "IsUnique" type of thing.
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2119024575)
Oof yes! Should be replaced with an "IsUnique" type of thing.
π fanquake opened a pull request: "depends: sqlite 3.50.0; switch to autosetup"
(https://github.com/bitcoin/bitcoin/pull/32655)
We currently use SQLite `3.46.1` in depends. Migrating to any version after `3.49.0` (with our use of the amalgamation tarball), requires migrating to to building SQLite with [`autosetup`](https://msteveb.github.io/autosetup/), which is a replacement for Autoconf. This is what that will look like.
(https://github.com/bitcoin/bitcoin/pull/32655)
We currently use SQLite `3.46.1` in depends. Migrating to any version after `3.49.0` (with our use of the amalgamation tarball), requires migrating to to building SQLite with [`autosetup`](https://msteveb.github.io/autosetup/), which is a replacement for Autoconf. This is what that will look like.
π fanquake opened a pull request: "depends: don't install & then delete sqlite pkgconf"
(https://github.com/bitcoin/bitcoin/pull/32656)
(https://github.com/bitcoin/bitcoin/pull/32656)
π fanquake's pull request is ready for review: "build: add -Wthread-safety-pointer"
(https://github.com/bitcoin/bitcoin/pull/32647)
(https://github.com/bitcoin/bitcoin/pull/32647)
π¬ fanquake commented on pull request "wallet: add `seeds` argument to `importdescriptors`":
(https://github.com/bitcoin/bitcoin/pull/27351#issuecomment-2927097331)
PIcked up in ##32652.
(https://github.com/bitcoin/bitcoin/pull/27351#issuecomment-2927097331)
PIcked up in ##32652.
π¬ romanz commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2119135815)
In https://github.com/bitcoin/bitcoin/pull/32540/commits/62e68bd46726dc17b657c4c334b06351fc761868, I have added `/blockundo/` REST endpoint (which is using `ReadBlockRawUndo` and **client-side** deserilalization).
I have used https://github.com/romanz/bench-rest/commit/084e07764fdb76d4bc25d2090769c0ef3f0a44c5 to benchmark it against `/spenttxouts/` REST endpoint (which is using `ReadBlockUndo` and **server-side** deserialization) by reading 10k blocks from height=800000.
In addition, I hav
...
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2119135815)
In https://github.com/bitcoin/bitcoin/pull/32540/commits/62e68bd46726dc17b657c4c334b06351fc761868, I have added `/blockundo/` REST endpoint (which is using `ReadBlockRawUndo` and **client-side** deserilalization).
I have used https://github.com/romanz/bench-rest/commit/084e07764fdb76d4bc25d2090769c0ef3f0a44c5 to benchmark it against `/spenttxouts/` REST endpoint (which is using `ReadBlockUndo` and **server-side** deserialization) by reading 10k blocks from height=800000.
In addition, I hav
...
π¬ romanz commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2119137893)
Would it be OK to switch this PR back to use `/spenttxouts/` (i.e. removing 62e68bd467 and keeping 1e2b26e4f8)?
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2119137893)
Would it be OK to switch this PR back to use `/spenttxouts/` (i.e. removing 62e68bd467 and keeping 1e2b26e4f8)?
π€ theStack reviewed a pull request: "descriptors: MuSig2"
(https://github.com/bitcoin/bitcoin/pull/31244#pullrequestreview-2885837240)
According to BIP 390 [_"Repeated participant public keys are not allowed."_](https://github.com/bitcoin/bips/blob/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0390.mediawiki?plain=1#L36), but it seems there is currently no check preventing that? Example test case that passes but shouldn't (IIUC): https://github.com/theStack/bitcoin/commit/f260c7ec06e8bbb7148877a9a9b7e96707c41fa1
(https://github.com/bitcoin/bitcoin/pull/31244#pullrequestreview-2885837240)
According to BIP 390 [_"Repeated participant public keys are not allowed."_](https://github.com/bitcoin/bips/blob/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0390.mediawiki?plain=1#L36), but it seems there is currently no check preventing that? Example test case that passes but shouldn't (IIUC): https://github.com/theStack/bitcoin/commit/f260c7ec06e8bbb7148877a9a9b7e96707c41fa1
π¬ RandyMcMillan commented on something "":
(https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#r158827732)
π
(https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#r158827732)
π
π¬ RandyMcMillan commented on something "":
(https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#r158827735)
π
(https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#r158827735)
π
π¬ pinheadmz commented on something "":
(https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#r158844306)
Did you mean to comment on an 8 year old segwit commit?
(https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#r158844306)
Did you mean to comment on an 8 year old segwit commit?