β
torkelrogstad closed an issue: "Indicate RBF replaceability, also after transactions have been confirmed "
(https://github.com/bitcoin/bitcoin/issues/27794)
(https://github.com/bitcoin/bitcoin/issues/27794)
π¬ hebasto commented on pull request "Add public Boost headers explicitly":
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1211807185)
> Still, does using `multi_index_container_fwd.hpp` help at all?
No, it doesn't:
```
./txmempool.h:406:29: error: field βmapTxβ has incomplete type βCTxMemPool::indexed_transaction_setβ {aka βboost::multi_index::multi_index_container<CTxMemPoolEntry, boost::multi_index::indexed_by<boost::multi_index::hashed_unique<mempoolentry_txid, SaltedTxidHasher>, boost::multi_index::hashed_unique<boost::multi_index::tag<index_by_wtxid>, mempoolentry_wtxid, SaltedTxidHasher>, boost::multi_index::ordered
...
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1211807185)
> Still, does using `multi_index_container_fwd.hpp` help at all?
No, it doesn't:
```
./txmempool.h:406:29: error: field βmapTxβ has incomplete type βCTxMemPool::indexed_transaction_setβ {aka βboost::multi_index::multi_index_container<CTxMemPoolEntry, boost::multi_index::indexed_by<boost::multi_index::hashed_unique<mempoolentry_txid, SaltedTxidHasher>, boost::multi_index::hashed_unique<boost::multi_index::tag<index_by_wtxid>, mempoolentry_wtxid, SaltedTxidHasher>, boost::multi_index::ordered
...
π¬ sipa commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570343467)
@torkelrogstad I'm still confused about what you're trying to do. The only sensible answer to the question whether a confirmed transaction is replaceable is *no*. Whatever purpose you have for wondering about that, by the time a transaction confirms, it shouldn't matter anymore to anything.
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570343467)
@torkelrogstad I'm still confused about what you're trying to do. The only sensible answer to the question whether a confirmed transaction is replaceable is *no*. Whatever purpose you have for wondering about that, by the time a transaction confirms, it shouldn't matter anymore to anything.
π¬ brunoerg commented on issue "Erlay status in getpeerinfo":
(https://github.com/bitcoin/bitcoin/issues/26602#issuecomment-1570354537)
In order to test Erlay I've implemented this recently to help me with my tests, I can open a PR for that.
(https://github.com/bitcoin/bitcoin/issues/26602#issuecomment-1570354537)
In order to test Erlay I've implemented this recently to help me with my tests, I can open a PR for that.
π¬ jonatack commented on pull request "Raise on invalid -debug and -loglevel config options":
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1211826449)
Fixed, thank you.
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1211826449)
Fixed, thank you.
π¬ jonatack commented on pull request "Raise on invalid -debug and -loglevel config options":
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1211826908)
Kept the translation -- thank you.
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1211826908)
Kept the translation -- thank you.
π¬ sipa commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570364914)
@torkelrogstad Oh, I think I understand now, re-reading your earlier comments.
Having `bip125-replacable` return true for confirmed transaction is not a solution to your issue, because it can already change over time. Imagine a transaction T1 (which does signal) and a descendant transaction T2 (which does not signal), both unconfirmed. `bip125-replaceable` will be true for both, because the BIP125 rules say both are replaceable. Once T1 confirms, however, T2's `bip125-replaceable` will become
...
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570364914)
@torkelrogstad Oh, I think I understand now, re-reading your earlier comments.
Having `bip125-replacable` return true for confirmed transaction is not a solution to your issue, because it can already change over time. Imagine a transaction T1 (which does signal) and a descendant transaction T2 (which does not signal), both unconfirmed. `bip125-replaceable` will be true for both, because the BIP125 rules say both are replaceable. Once T1 confirms, however, T2's `bip125-replaceable` will become
...
π¬ jonatack commented on pull request "Raise on invalid -debug and -loglevel config options":
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1211830118)
Rebased to current master to be able to use `Result` with support for `<void>` and updated the return types from bool to void.
(https://github.com/bitcoin/bitcoin/pull/27632#discussion_r1211830118)
Rebased to current master to be able to use `Result` with support for `<void>` and updated the return types from bool to void.
π¬ fanquake commented on issue "Spurious (?) valgrind failure for p2p_compactblocks.py":
(https://github.com/bitcoin/bitcoin/issues/27741#issuecomment-1570372707)
> Looks like valgrind 3.21 still has this issue.
Valgrind 3.22 (master @ e3602b3eec0696b183722ea21da14588cf205c74) also still fails.
(https://github.com/bitcoin/bitcoin/issues/27741#issuecomment-1570372707)
> Looks like valgrind 3.21 still has this issue.
Valgrind 3.22 (master @ e3602b3eec0696b183722ea21da14588cf205c74) also still fails.
π¬ hebasto commented on pull request "Add public Boost headers explicitly":
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1211838351)
> Feel free to take:
Taken. Thank you!
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1211838351)
> Feel free to take:
Taken. Thank you!
π¬ hebasto commented on pull request "Add public Boost headers explicitly":
(https://github.com/bitcoin/bitcoin/pull/27783#issuecomment-1570376358)
Taken @MarcoFalke's [suggestion](https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1211170115).
(https://github.com/bitcoin/bitcoin/pull/27783#issuecomment-1570376358)
Taken @MarcoFalke's [suggestion](https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1211170115).
π¬ theuni commented on pull request "macOS: Bump minimum required runtime version and prepare for building with upstream LLVM":
(https://github.com/bitcoin/bitcoin/pull/27676#issuecomment-1570410809)
> Note that you'l have to drop the `lazy_bind` check (we'll follow up with a `fixup_chains` test later). I've got a branch here with that change, which Guix builds successfully: https://github.com/fanquake/bitcoin/tree/27676_minus_lazy_bind.
Whoops, yes, thanks. Patch taken.
So this is now 100% working, just need to decide out what to do about guix.
(https://github.com/bitcoin/bitcoin/pull/27676#issuecomment-1570410809)
> Note that you'l have to drop the `lazy_bind` check (we'll follow up with a `fixup_chains` test later). I've got a branch here with that change, which Guix builds successfully: https://github.com/fanquake/bitcoin/tree/27676_minus_lazy_bind.
Whoops, yes, thanks. Patch taken.
So this is now 100% working, just need to decide out what to do about guix.
π brunoerg opened a pull request: "rpc, net: add erlay status in `getpeerinfo`"
(https://github.com/bitcoin/bitcoin/pull/27797)
Fixes #26602
Adds `m_tx_reconciliation` in `Peer` struct
to know whether the peer supports Erlay and
exposes it in `getpeerinfo` rpc.
(https://github.com/bitcoin/bitcoin/pull/27797)
Fixes #26602
Adds `m_tx_reconciliation` in `Peer` struct
to know whether the peer supports Erlay and
exposes it in `getpeerinfo` rpc.
π¬ brunoerg commented on pull request "rpc, net: add erlay status in `getpeerinfo`":
(https://github.com/bitcoin/bitcoin/pull/27797#issuecomment-1570411351)
cc: @Sjors
(https://github.com/bitcoin/bitcoin/pull/27797#issuecomment-1570411351)
cc: @Sjors
π¬ jamesob commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1211880620)
Fixed, thanks
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1211880620)
Fixed, thanks
π¬ jamesob commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1211880971)
Fixed, thanks all.
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1211880971)
Fixed, thanks all.
π¬ hebasto commented on pull request "refactor: Make `CCheckQueue` RAII-styled":
(https://github.com/bitcoin/bitcoin/pull/26762#issuecomment-1570428398)
Rebased 2076d846cc917cbafe61937a99b7867067011341 -> b023c26eb8eda4c7f80ad2e7ebe1fb046e87d2ee ([pr26762.09](https://github.com/hebasto/bitcoin/commits/pr26762.09) -> [pr26762.10](https://github.com/hebasto/bitcoin/commits/pr26762.10)) due to the conflict with #27636.
(https://github.com/bitcoin/bitcoin/pull/26762#issuecomment-1570428398)
Rebased 2076d846cc917cbafe61937a99b7867067011341 -> b023c26eb8eda4c7f80ad2e7ebe1fb046e87d2ee ([pr26762.09](https://github.com/hebasto/bitcoin/commits/pr26762.09) -> [pr26762.10](https://github.com/hebasto/bitcoin/commits/pr26762.10)) due to the conflict with #27636.
π¬ jamesob commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1570432290)
Rebased
Also fixed the minor issues with the `test_utxo_snapshots.sh` demo script.
Since last push, I've completed a full test of the mainnet snapshot; after a few days having finished the background sync, `-prune=550` (and everything else) working as expected.
```
759M /home/james/tmp/bitcoin-au-testing/blocks
total 650M
drwx------ 3 james users 4.0K May 31 10:54 .
drwx------ 5 james users 4.0K May 31 11:09 ..
-rw------- 1 james users 127M May 29 15:33 blk03626.dat
-rw-------
...
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1570432290)
Rebased
Also fixed the minor issues with the `test_utxo_snapshots.sh` demo script.
Since last push, I've completed a full test of the mainnet snapshot; after a few days having finished the background sync, `-prune=550` (and everything else) working as expected.
```
759M /home/james/tmp/bitcoin-au-testing/blocks
total 650M
drwx------ 3 james users 4.0K May 31 10:54 .
drwx------ 5 james users 4.0K May 31 11:09 ..
-rw------- 1 james users 127M May 29 15:33 blk03626.dat
-rw-------
...
π¬ Sjors commented on pull request "rpc, net: add erlay status in `getpeerinfo`":
(https://github.com/bitcoin/bitcoin/pull/27797#issuecomment-1570438683)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/27797#issuecomment-1570438683)
Concept ACK
π¬ mzumsande commented on pull request "rpc, net: add erlay status in `getpeerinfo`":
(https://github.com/bitcoin/bitcoin/pull/27797#issuecomment-1570459426)
I'd definitely like this eventually, but I'm not sure how much sense it makes to have it before Erlay is functional (unfortunately, there hasn't been much progress lately in #26283, and even after this is merged Erlay still won't be functional yet).
(https://github.com/bitcoin/bitcoin/pull/27797#issuecomment-1570459426)
I'd definitely like this eventually, but I'm not sure how much sense it makes to have it before Erlay is functional (unfortunately, there hasn't been much progress lately in #26283, and even after this is merged Erlay still won't be functional yet).