π¬ fanquake commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2089372464)
It's waiting for the PR linked in the description. Otherwise, should be mergable.
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2089372464)
It's waiting for the PR linked in the description. Otherwise, should be mergable.
π¬ ariard commented on pull request "policy: restrict all TRUC (v3) transactions to 25KvB":
(https://github.com/bitcoin/bitcoin/pull/29873#issuecomment-2089386661)
> Would this make things {broken, inconvenient} for potential users of TRUCs, e.g. by requiring swapping between v3 and v2?
For historical lightning channel who have already negotiated parameters above `max_accepted_htlcs` + witness spend size of legacy channel types. i.e anything before `option_anchors_zero_fee_htlc_tx`, I think. Legacy v2 commitment transactions are already opting to RBF, so shall be able to be replaced by v3. This is unclear for the splicing flow, where a counterparty coul
...
(https://github.com/bitcoin/bitcoin/pull/29873#issuecomment-2089386661)
> Would this make things {broken, inconvenient} for potential users of TRUCs, e.g. by requiring swapping between v3 and v2?
For historical lightning channel who have already negotiated parameters above `max_accepted_htlcs` + witness spend size of legacy channel types. i.e anything before `option_anchors_zero_fee_htlc_tx`, I think. Legacy v2 commitment transactions are already opting to RBF, so shall be able to be replaced by v3. This is unclear for the splicing flow, where a counterparty coul
...
π¬ kevkevinpal commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1586967904)
instead of number `298` would it make more sense to use `SNAPSHOT_BASE_HEIGHT`?
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1586967904)
instead of number `298` would it make more sense to use `SNAPSHOT_BASE_HEIGHT`?
π¬ kevkevinpal commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1586968840)
is this not the same as `START_HEIGHT`?
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1586968840)
is this not the same as `START_HEIGHT`?
π¬ kevkevinpal commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1586972804)
```suggestion
block_hash = node.getblockhash(START_HEIGHT + 1)
node.invalidateblock(block_hash)
assert_equal(node.getblockcount(), START_HEIGHT)
```
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1586972804)
```suggestion
block_hash = node.getblockhash(START_HEIGHT + 1)
node.invalidateblock(block_hash)
assert_equal(node.getblockcount(), START_HEIGHT)
```
π kevkevinpal opened a pull request: "test: create assert_less_than util"
(https://github.com/bitcoin/bitcoin/pull/30019)
In the functional tests there are lots of cases where we assert < which we now swap with assert_less_than to be more readable
This is motivated/uses logic from this PR which was closed https://github.com/bitcoin/bitcoin/pull/28528
This partially helps https://github.com/bitcoin/bitcoin/issues/23119
I've broken it up to just assert_less_than to keep the PR smaller as suggested in https://github.com/bitcoin/bitcoin/pull/28528#issuecomment-1959945805
[Similar change for assert_not_equal](
...
(https://github.com/bitcoin/bitcoin/pull/30019)
In the functional tests there are lots of cases where we assert < which we now swap with assert_less_than to be more readable
This is motivated/uses logic from this PR which was closed https://github.com/bitcoin/bitcoin/pull/28528
This partially helps https://github.com/bitcoin/bitcoin/issues/23119
I've broken it up to just assert_less_than to keep the PR smaller as suggested in https://github.com/bitcoin/bitcoin/pull/28528#issuecomment-1959945805
[Similar change for assert_not_equal](
...
π¬ ariard commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2089436259)
Concept ACK.
By the way, it would be great if mainnet DNS seeders are considering to sign by default the peers records. This could be amply checked in `ThreadDNSAddressSeed()` or in semi-automatic fashion in the logs. ECDSA secp256k1 isnβt supported by default in DNS, though you have ed25519 or ECDSA P256 which are widely supported by key management softwares.
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2089436259)
Concept ACK.
By the way, it would be great if mainnet DNS seeders are considering to sign by default the peers records. This could be amply checked in `ThreadDNSAddressSeed()` or in semi-automatic fashion in the logs. ECDSA secp256k1 isnβt supported by default in DNS, though you have ed25519 or ECDSA P256 which are widely supported by key management softwares.
π fanquake merged a pull request: "depends: build miniupnpc with CMake"
(https://github.com/bitcoin/bitcoin/pull/29707)
(https://github.com/bitcoin/bitcoin/pull/29707)
π¬ fanquake commented on pull request "[WIP] libevent @ master + use CMake":
(https://github.com/bitcoin/bitcoin/pull/29835#issuecomment-2089471495)
Rebased. Dropped the final patch commit, as that change happened upstream. Also bumped to current master.
(https://github.com/bitcoin/bitcoin/pull/29835#issuecomment-2089471495)
Rebased. Dropped the final patch commit, as that change happened upstream. Also bumped to current master.
π¬ saadbitcoin commented on pull request "wallet: Deniability API (Unilateral Transaction Meta-Privacy)":
(https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-2089476288)
Can you healp me
ΩΩ Ψ§ΩΨ£ΨΨ―Ψ Ω’Ω¨ Ψ£Ψ¨Ψ±ΩΩ Ω’Ω Ω’Ω€ Ω§:Ω’Ω¦ Ω 1440000bytes ***@***.***> ΩΨͺΨ¨:
> Tested it and I think it can be improved further before users can try it
> on mainnet: bitcoin-core/gui#733 (comment)
> <https://github.com/bitcoin-core/gui/pull/733#issuecomment-2081539227>
>
> β
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-2081540237>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHV67JU42HUR
...
(https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-2089476288)
Can you healp me
ΩΩ Ψ§ΩΨ£ΨΨ―Ψ Ω’Ω¨ Ψ£Ψ¨Ψ±ΩΩ Ω’Ω Ω’Ω€ Ω§:Ω’Ω¦ Ω 1440000bytes ***@***.***> ΩΨͺΨ¨:
> Tested it and I think it can be improved further before users can try it
> on mainnet: bitcoin-core/gui#733 (comment)
> <https://github.com/bitcoin-core/gui/pull/733#issuecomment-2081539227>
>
> β
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-2081540237>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHV67JU42HUR
...
π fanquake merged a pull request: "lint: [doc] Clarify Windows line endings (CR LF) not to be used"
(https://github.com/bitcoin/bitcoin/pull/30010)
(https://github.com/bitcoin/bitcoin/pull/30010)
π€ theStack reviewed a pull request: "rpc: Optimize serialization and enhance metadata of dumptxoutset output"
(https://github.com/bitcoin/bitcoin/pull/29612#pullrequestreview-2034745114)
Concept ACK on the enhanced metadata, I think this includes now everything we need. Will update #27432 in a bit to the new format and test.
(https://github.com/bitcoin/bitcoin/pull/29612#pullrequestreview-2034745114)
Concept ACK on the enhanced metadata, I think this includes now everything we need. Will update #27432 in a bit to the new format and test.
π¬ theStack commented on pull request "rpc: Optimize serialization and enhance metadata of dumptxoutset output":
(https://github.com/bitcoin/bitcoin/pull/29612#discussion_r1587015761)
nit: could use `std::array`, and use its methods (`.begin()`, `.end()`, `.size()`) in `Unserialize` below to avoid magic numbers
```suggestion
static constexpr std::array<uint8_t, 5> SNAPSHOT_MAGIC_BYTES = {'u', 't', 'x', 'o', 0xff};
```
(https://github.com/bitcoin/bitcoin/pull/29612#discussion_r1587015761)
nit: could use `std::array`, and use its methods (`.begin()`, `.end()`, `.size()`) in `Unserialize` below to avoid magic numbers
```suggestion
static constexpr std::array<uint8_t, 5> SNAPSHOT_MAGIC_BYTES = {'u', 't', 'x', 'o', 0xff};
```
π¬ theStack commented on pull request "rpc: Optimize serialization and enhance metadata of dumptxoutset output":
(https://github.com/bitcoin/bitcoin/pull/29612#discussion_r1587030435)
nit: for variables that are (de)serialized, it's imho preferred if the data type size is explicit
```suggestion
uint32_t m_base_blockheight;
```
(https://github.com/bitcoin/bitcoin/pull/29612#discussion_r1587030435)
nit: for variables that are (de)serialized, it's imho preferred if the data type size is explicit
```suggestion
uint32_t m_base_blockheight;
```
π¬ fanquake commented on pull request "opportunistic 1p1c followups":
(https://github.com/bitcoin/bitcoin/pull/30012#issuecomment-2089494872)
Can this also address:
```bash
txorphanage.cpp:281:21: error: loop variable 'child_iter' creates a copy from type '__gnu_debug::_Safe_iterator<std::_Rb_tree_iterator<std::pair<const transaction_identifier<false>, TxOrphanage::OrphanTx>>, std::map<transaction_identifier<false>, TxOrphanage::OrphanTx>> const' [-Werror,-Wrange-loop-construct]
281 | for (const auto child_iter : iters) {
| ^
txorphanage.cpp:281:10: note: use reference type '__gnu_debug::_Safe_iter
...
(https://github.com/bitcoin/bitcoin/pull/30012#issuecomment-2089494872)
Can this also address:
```bash
txorphanage.cpp:281:21: error: loop variable 'child_iter' creates a copy from type '__gnu_debug::_Safe_iterator<std::_Rb_tree_iterator<std::pair<const transaction_identifier<false>, TxOrphanage::OrphanTx>>, std::map<transaction_identifier<false>, TxOrphanage::OrphanTx>> const' [-Werror,-Wrange-loop-construct]
281 | for (const auto child_iter : iters) {
| ^
txorphanage.cpp:281:10: note: use reference type '__gnu_debug::_Safe_iter
...
β οΈ dominicusadinfinitum opened an issue: "Testsuite for Bitcoin Core 27.0.0 - FAIL: qt/test/test_bitcoin-qt"
(https://github.com/bitcoin/bitcoin/issues/30020)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
FAIL: qt/test/test_bitcoin-qt
============================================================================
Testsuite summary for Bitcoin Core 27.0.0
============================================================================
# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
...
(https://github.com/bitcoin/bitcoin/issues/30020)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
FAIL: qt/test/test_bitcoin-qt
============================================================================
Testsuite summary for Bitcoin Core 27.0.0
============================================================================
# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
...
π¬ laanwj commented on issue "Objdump can't parse our Linux debug information":
(https://github.com/bitcoin/bitcoin/issues/30016#issuecomment-2089648774)
Reopening with more accurate title (phew).
Filed upstream issue: https://sourceware.org/bugzilla/show_bug.cgi?id=31692
(https://github.com/bitcoin/bitcoin/issues/30016#issuecomment-2089648774)
Reopening with more accurate title (phew).
Filed upstream issue: https://sourceware.org/bugzilla/show_bug.cgi?id=31692
β οΈ laanwj reopened an issue: "Objdump can't parse our Linux debug information"
(https://github.com/bitcoin/bitcoin/issues/30016)
The debug information in the shipped `.dbg` artifacts seems to be unusable. The `.debug_info` section is corrupt:
```sh
$ tar -zxvf bitcoin-27.0-x86_64-linux-gnu-debug.tar.gz
$ objdump -Wi bitcoin-27.0/bin/bitcoin-cli.dbg
Section '.debug_info' has an invalid size: 0.
bitcoin-27.0/bin/bitcoin-cli.dbg: file format elf64-x86-64
Section '.debug_info' has an invalid size: 0.
```
i've checked various Linux architectures (at least x86_64, ARM, RISC-V) and the same issue exists there.
...
(https://github.com/bitcoin/bitcoin/issues/30016)
The debug information in the shipped `.dbg` artifacts seems to be unusable. The `.debug_info` section is corrupt:
```sh
$ tar -zxvf bitcoin-27.0-x86_64-linux-gnu-debug.tar.gz
$ objdump -Wi bitcoin-27.0/bin/bitcoin-cli.dbg
Section '.debug_info' has an invalid size: 0.
bitcoin-27.0/bin/bitcoin-cli.dbg: file format elf64-x86-64
Section '.debug_info' has an invalid size: 0.
```
i've checked various Linux architectures (at least x86_64, ARM, RISC-V) and the same issue exists there.
...
π laanwj unlocked an issue: "ops: Enable DNSSEC on all Bitcoin DNS Seed domain names"
(https://github.com/bitcoin/bitcoin/issues/19714)
(https://github.com/bitcoin/bitcoin/issues/19714)
π¬ laanwj commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2089734623)
> By the way, it would be great if mainnet DNS seeders are considering to sign by default the peers records. This could be amply checked in ThreadDNSAddressSeed()
There are some that do (#19714), but as far as i know, there is no cross-platform API for checking DNSSEC status from user code. i've unlocked that issue for discussion.
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2089734623)
> By the way, it would be great if mainnet DNS seeders are considering to sign by default the peers records. This could be amply checked in ThreadDNSAddressSeed()
There are some that do (#19714), but as far as i know, there is no cross-platform API for checking DNSSEC status from user code. i've unlocked that issue for discussion.