💬 BrandonOdiwuor commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#discussion_r1471166805)
Looks like I need at least `1.25GB` (`sudo mount -t tmpfs -o size=1250M none /tmp`) to run the tests on my system with no errors
I have plotted a map using gnuplot from the data collected tracking the size of the tmpdir when running the tests using:
`watch -n 10 "sudo du -s /tmp/test_runner_₿_🏃_20240130_153709/ | awk '{print strftime(\"%H:%M:%S\"), int(\$1/1024)}' | tee -a ~/watch-tee1.log"`
Looks like I need at least `1.25GB` (`sudo mount -t tmpfs -o size=1250M none /tmp`) to run the tests on my system with no errors
I have plotted a map using gnuplot from the data collected tracking the size of the tmpdir when running the tests using:
`watch -n 10 "sudo du -s /tmp/test_runner_₿_🏃_20240130_153709/ | awk '{print strftime(\"%H:%M:%S\"), int(\$1/1024)}' | tee -a ~/watch-tee1.log"`
![directory_size_plot1](https://github.com/bitcoin/bitcoin/assets/15610188/735e07ca-44ec-43d5-807
...
💬 Rucade commented on issue "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded":
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1916810231)
> > 2024-01-19T10:49:39Z Bitcoin Core version v22.0.0 (release build)
>
> Are you sure you are running 26.0? Your logs claim 22.0.
You may be right there. I had v.22 but I downloaded v.26 later because of serious errors and it may have kept the debug log from 22 but I did erase all the blockdir and started again fresh. So, should I erase everything delete all the files in .bitcoin linux ubuntu and start fresh on windows?
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1916810231)
> > 2024-01-19T10:49:39Z Bitcoin Core version v22.0.0 (release build)
>
> Are you sure you are running 26.0? Your logs claim 22.0.
You may be right there. I had v.22 but I downloaded v.26 later because of serious errors and it may have kept the debug log from 22 but I did erase all the blockdir and started again fresh. So, should I erase everything delete all the files in .bitcoin linux ubuntu and start fresh on windows?
💬 instagibbs commented on issue "Cluster mempool, CPFP carveout, and V3 transaction policy":
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1916831473)
> I think that this approach shouldn't generate any false positive. Once such an anchor transaction is identified, we would imbue its parent from the input that matches that script with v3 semantics.
Reminder we probably have to be aware of simple taproot channels, or we should just move fast enough to get CPFP carveout replaced via v3+sibling eviction, then only focus on imbuing segwitv0 channels? We'll likely need @Roasbeef to weigh in
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1916831473)
> I think that this approach shouldn't generate any false positive. Once such an anchor transaction is identified, we would imbue its parent from the input that matches that script with v3 semantics.
Reminder we probably have to be aware of simple taproot channels, or we should just move fast enough to get CPFP carveout replaced via v3+sibling eviction, then only focus on imbuing segwitv0 channels? We'll likely need @Roasbeef to weigh in
💬 instagibbs commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#issuecomment-1916837538)
This PR is essentially focusing on the max fee check during submission to local mempool feature only. Wallet features to reduce accidental overpayment are also welcome, and may already exist in some forms?
(https://github.com/bitcoin/bitcoin/pull/28950#issuecomment-1916837538)
This PR is essentially focusing on the max fee check during submission to local mempool feature only. Wallet features to reduce accidental overpayment are also welcome, and may already exist in some forms?
💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471200471)
ok that's better even if it's not sigops adjusted(?) thanks!
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471200471)
ok that's better even if it's not sigops adjusted(?) thanks!
💬 furszy commented on pull request "wallet: guard against dangling to-be-reverted db transactions":
(https://github.com/bitcoin/bitcoin/pull/29253#discussion_r1471199191)
> It is also unclear to me what "transaction data outside the context of the 'SQLiteBatch'" would refer to if SQLiteBatch is the class responsible for creating transactions.
The purpose of this sentence was to describe what could happen if we don't rollback the transaction and explain why we rollback the transaction inside the `SQLiteBatch` destructor.
The complete sentence, "This prevents dangling transaction data outside the context of the 'SQLiteBatch' that initiated such a transaction,
...
(https://github.com/bitcoin/bitcoin/pull/29253#discussion_r1471199191)
> It is also unclear to me what "transaction data outside the context of the 'SQLiteBatch'" would refer to if SQLiteBatch is the class responsible for creating transactions.
The purpose of this sentence was to describe what could happen if we don't rollback the transaction and explain why we rollback the transaction inside the `SQLiteBatch` destructor.
The complete sentence, "This prevents dangling transaction data outside the context of the 'SQLiteBatch' that initiated such a transaction,
...
💬 furszy commented on pull request "wallet: guard against dangling to-be-reverted db transactions":
(https://github.com/bitcoin/bitcoin/pull/29253#discussion_r1471205237)
Great, thanks 👌🏼. Unified `ExecHandler` and `SQliteExecHandler` and added your doxygen comment.
(https://github.com/bitcoin/bitcoin/pull/29253#discussion_r1471205237)
Great, thanks 👌🏼. Unified `ExecHandler` and `SQliteExecHandler` and added your doxygen comment.
💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471209343)
```suggestion
tx_mut.nVersion = fuzzed_data_provider.ConsumeBool() ? CTransaction::CURRENT_VERSION : TX_MAX_STANDARD_VERSION;
```
more what I meant
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471209343)
```suggestion
tx_mut.nVersion = fuzzed_data_provider.ConsumeBool() ? CTransaction::CURRENT_VERSION : TX_MAX_STANDARD_VERSION;
```
more what I meant
💬 furszy commented on pull request "wallet: guard against dangling to-be-reverted db transactions":
(https://github.com/bitcoin/bitcoin/pull/29253#discussion_r1471209737)
Done as suggested.
(https://github.com/bitcoin/bitcoin/pull/29253#discussion_r1471209737)
Done as suggested.
💬 sipa commented on pull request "net: enable v2transport by default":
(https://github.com/bitcoin/bitcoin/pull/29347#issuecomment-1916865507)
@willcl-ark I believe @mzumsande is planning to open a PR to enable it everywhere in the tests.
(https://github.com/bitcoin/bitcoin/pull/29347#issuecomment-1916865507)
@willcl-ark I believe @mzumsande is planning to open a PR to enable it everywhere in the tests.
👍 willcl-ark approved a pull request: "net: enable v2transport by default"
(https://github.com/bitcoin/bitcoin/pull/29347#pullrequestreview-1851387736)
crACK 0bef1042ce6c459acb1de965cbccd98867a417f1
(https://github.com/bitcoin/bitcoin/pull/29347#pullrequestreview-1851387736)
crACK 0bef1042ce6c459acb1de965cbccd98867a417f1
👍 BrandonOdiwuor approved a pull request: "net: enable v2transport by default"
(https://github.com/bitcoin/bitcoin/pull/29347#pullrequestreview-1851430061)
ACK 0bef1042ce6c459acb1de965cbccd98867a417f1
(https://github.com/bitcoin/bitcoin/pull/29347#pullrequestreview-1851430061)
ACK 0bef1042ce6c459acb1de965cbccd98867a417f1
💬 glozow commented on issue "assumeutxo: nTx and nChainTx violations in CheckBlockIndex":
(https://github.com/bitcoin/bitcoin/issues/29261#issuecomment-1916993905)
Let me know if I should reopen this issue?
(https://github.com/bitcoin/bitcoin/issues/29261#issuecomment-1916993905)
Let me know if I should reopen this issue?
💬 maflcko commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#issuecomment-1916996716)
The test fails for me:
```
146/294 - p2p_v2_earlykeyresponse.py failed, Duration: 1 s
stdout:
2024-01-30T13:33:10.051000Z TestFramework (INFO): PRNG seed is: 5518845862592986813
2024-01-30T13:33:10.052000Z TestFramework (INFO): Initializing test directory /tmp/test_runner_₿_🏃_20240130_142948/p2p_v2_earlykeyresponse_133
2024-01-30T13:33:10.370000Z TestFramework (INFO): Sending ellswift bytes in parts to ensure that response from responder is received only when
2024-01-30T13:33:10.3700
...
(https://github.com/bitcoin/bitcoin/pull/24748#issuecomment-1916996716)
The test fails for me:
```
146/294 - p2p_v2_earlykeyresponse.py failed, Duration: 1 s
stdout:
2024-01-30T13:33:10.051000Z TestFramework (INFO): PRNG seed is: 5518845862592986813
2024-01-30T13:33:10.052000Z TestFramework (INFO): Initializing test directory /tmp/test_runner_₿_🏃_20240130_142948/p2p_v2_earlykeyresponse_133
2024-01-30T13:33:10.370000Z TestFramework (INFO): Sending ellswift bytes in parts to ensure that response from responder is received only when
2024-01-30T13:33:10.3700
...
💬 furszy commented on pull request "Add max_tx_weight to transaction funding options":
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471245338)
To not add `policy/policy.h` dependency, which comes with other dependencies (`script/interpreter.h`, `script/solver.h`, etc..), would suggest to make this field optional. Treating `std::nullopt` as `MAX_STANDARD_TX_WEIGHT` internally. This is what we already do for other default values.
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471245338)
To not add `policy/policy.h` dependency, which comes with other dependencies (`script/interpreter.h`, `script/solver.h`, etc..), would suggest to make this field optional. Treating `std::nullopt` as `MAX_STANDARD_TX_WEIGHT` internally. This is what we already do for other default values.
💬 furszy commented on pull request "Add max_tx_weight to transaction funding options":
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471333943)
@instagibbs, see https://github.com/furszy/bitcoin-core/commit/b2d3ac32cb51a1f350b5a4005e6da39d712b8fa9. It makes the process consistent, returning the same "weight exceeded" error message when such scenario occurs.
Still, I would like to revisit this PR further after https://github.com/bitcoin/bitcoin/pull/29264/commits/7bfc80b70e3955c2c3b6f820f51a7d8d45aaff8e#r1464525381 and most other comments.
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471333943)
@instagibbs, see https://github.com/furszy/bitcoin-core/commit/b2d3ac32cb51a1f350b5a4005e6da39d712b8fa9. It makes the process consistent, returning the same "weight exceeded" error message when such scenario occurs.
Still, I would like to revisit this PR further after https://github.com/bitcoin/bitcoin/pull/29264/commits/7bfc80b70e3955c2c3b6f820f51a7d8d45aaff8e#r1464525381 and most other comments.
💬 furszy commented on pull request "Add max_tx_weight to transaction funding options":
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471278057)
@murchandamus, I'm not entirely sure about this naming change. At this point, we are placed at the coin selection algos level, which are situated a level below the transaction creation process. There is no concept of transaction weight here; only selection weight.
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471278057)
@murchandamus, I'm not entirely sure about this naming change. At this point, we are placed at the coin selection algos level, which are situated a level below the transaction creation process. There is no concept of transaction weight here; only selection weight.
💬 furszy commented on pull request "Add max_tx_weight to transaction funding options":
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471255355)
Same as above, the `policy.h` dependency generates some noise on me. Would suggest to not default initialize `m_max_tx_weight`. Callers are already forced to provide the weight in the constructor.
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1471255355)
Same as above, the `policy.h` dependency generates some noise on me. Would suggest to not default initialize `m_max_tx_weight`. Callers are already forced to provide the weight in the constructor.
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471340914)
Oof oops :facepalm: fixed
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471340914)
Oof oops :facepalm: fixed
💬 willcl-ark commented on issue "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded":
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1917041373)
This sounds most likely like a hardware malfunction to me too.
In any case you could try rotating your debug log (to start a fresh one) and this time be sure to use v26.0, then upload _that_ debug log here if the problem persists? Something like:
```bash
# rotate debug log
$ mv ~/.bitcoin/debug.log ~/.bitcoin/debug.log.1
# check that you are going to run v26.0
$ bitcoind --version
Bitcoin Core version v26.0
Copyright (C) 2009-2023 The Bitcoin Core developers
# Start v26.0
$ bit
...
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1917041373)
This sounds most likely like a hardware malfunction to me too.
In any case you could try rotating your debug log (to start a fresh one) and this time be sure to use v26.0, then upload _that_ debug log here if the problem persists? Something like:
```bash
# rotate debug log
$ mv ~/.bitcoin/debug.log ~/.bitcoin/debug.log.1
# check that you are going to run v26.0
$ bitcoind --version
Bitcoin Core version v26.0
Copyright (C) 2009-2023 The Bitcoin Core developers
# Start v26.0
$ bit
...