Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 hebasto commented on pull request "Simplify network-adjusted time warning logic":
(https://github.com/bitcoin/bitcoin/pull/29623#issuecomment-2094140548)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/186.
💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2094145823)
Took two days, but everything matches!

Best to run this script in a few parallel windows, because after block 790K or so it gets extremely slow.

```sh
./compare.sh 709632 790000
```

```sh
./compare.sh 790000 800000
```

etc

```sh
#!/bin/bash
# Taproot activation: 709632
set -e
TIP=`bitcoin-cli getblockcount`
for height in $(seq $1 $2); do
if [ $height -eq $TIP ]; then
echo "Reached the tip at $height"
exit 0
fi
if [ $((height % 1000)) -eq 0 ]; then

...
💬 hebasto commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094192476)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/187.
💬 hebasto commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2094203809)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/188.
💬 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_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
...