💬 sipa commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094216364)
@jamesob Feel like benchmarking a reindex or so with this?

💬 tdb3 commented on issue "RfC: increase minimum prune target?":
(https://github.com/bitcoin/bitcoin/issues/30037#issuecomment-2094223248)
It seems reasonable and safer to increase the min prune target, since blocks can be larger post-segwit (and we've seen it, e.g. 774628). Some rough napkin math for a new value (correct me if something looks off):
- 4MB per block, 288 blocks = 1152MB
- Add 15% for Undo data = 1325MB
- Add 20% for Orphan block rate = 1590MB
- Add one block file + added 15% undo data = 147MB
- Target >= 1737MB, so something like 1750MB seems at first glance that it could work

I would recommend we minimize
...

💬 katesalazar commented on pull request "doc: fix broken relative md links":
(https://github.com/bitcoin/bitcoin/pull/30025#issuecomment-2094235168)
Concept ACK

💬 Eunovo commented on pull request "rpc: parse legacy pubkeys consistently with specific error messages":
(https://github.com/bitcoin/bitcoin/pull/28336#issuecomment-2094267853)
Tested ACK https://github.com/bitcoin/bitcoin/pull/28336/commits/98570fe29bb08d7edc48011aa6b9731c6ab4ed2e
Verified that all checks are covered in tests

💬 laanwj commented on pull request "[PoC, nomerge] PCP IPv4 portmap+IPv6 pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#issuecomment-2094269014)
@sjors It creates a IPv4 as well as IPv6 mappings now. The added complexity isn't even too bad, mostly a matter of using CNetAddr/CService/Sock abstraction that we already have.

💬 laanwj commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2094289500)
> TXT records could work but that will require lot of other changes (out of scope)

Right-DNS can serve arbitrary information, but it would complicate things in the client: the cross-platform libc resolver, `getaddrinfo`, can only resolve addresses. So for that'd we'd need to add some dependency library for DNS resolving. The question is whether it's worth it.

Also, IIRC caching DNS servers don't always cache TXT records (*because* they can store arbitrary data); the caching and the privacy
...

💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014513)
this looks like an actual assert_greater_than
```suggestion
assert_greater_than(conflicted_A_tx["confirmations"], 0)
```

🤔 paplorinc requested changes to a pull request: "test: use assert_greater_than util"
(https://github.com/bitcoin/bitcoin/pull/30019#pullrequestreview-2039497086)
The errors will improve this way, even though I wouldn't call the code more readable.
And to not make it less readable, I suggested a few other places where these changes could be applied.

💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014819)
```suggestion
assert_greater_than(MAX_NODES + 1, idx)
```

💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590015083)
Do we need the `Decimal` here?
Seems basically the same as https://github.com/bitcoin/bitcoin/pull/30019/files?diff=split&w=1#diff-c1987c24fa3e5c788d16de5359500a19a1fea4f379e4288d076cf92be89541dcR478

💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014213)
```suggestion
assert_greater_than(202, tx['locktime'])
```

💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590015182)
```suggestion
assert_greater_than(size, 6400)
```

💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590015754)
```suggestion
assert_equal(len(txTo.vin), len(spent_utxos))
```

💬 laanwj commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094295273)
Are there any drawbacks to this?

💬 willcl-ark commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094299677)
Might partially address https://github.com/bitcoin/bitcoin/issues/29662

💬 fjahr commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2094300149)
I will try to summarize a bit where I think we stand on the issues and ideas being discussed. Note, I am biased to keep things out that didn't get strong support, if we don't fix all the holes and things go wrong again, there is always Testnet5 and we will have more practice with it after we are done with Testnet4.

- On preventing block storms while allowing developers to get their non standard txs into blocks
- Fixing the difficulty adjustment bug: Both solutions (disallowing min-difficul
...

💬 maciejsszmigiero commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094301313)
> Are there any drawbacks to this?

I didn't notice any.

It's worth mentioning that the total amount of data stored in this database is at least two orders of magnitude higher than even 128 MiB file size.

💬 laanwj commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094304507)
> It's worth mentioning that the total amount of data stored in this database is at least two orders of magnitude higher than even 128 MiB file size.

Oh yes, i asked because i like this even from a "leveldb creates less files" point of view, eg anecdotally on one of my nodes the counter exceeds 6 digits bitcoin-core/bitcoin-maintainer-tools#161 . Of course, this includes deleted files, the active number is "only" about 6000.

💬 emc99 commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094335773)
Are you looking for someone to compile this file on msvc?

💬 emsit commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2094340609)
> * Genesis Block
>
> * @jlopp suggested block received rejections on the content of the message and "self-advertisement" though it wasn't very clear to me what this was referring to. I think at least we need another variation with the latest block hash in the message.
>

I came across the fact that Lopp was conducting a 'Griefing Attack' on testnet3 and wants to embed his message into the genesis block, which refers to this article:

https://www.ccn.com/news/crypto/bitcoin-testnet
...