💬 instagibbs commented on pull request "rpc: add `descriptorprocesspsbt` rpc":
(https://github.com/bitcoin/bitcoin/pull/25796#issuecomment-1536435297)
ACK https://github.com/bitcoin/bitcoin/pull/25796/commits/80f8bdfeb3d9301e0aec4b797689cbe569eff5a6
(https://github.com/bitcoin/bitcoin/pull/25796#issuecomment-1536435297)
ACK https://github.com/bitcoin/bitcoin/pull/25796/commits/80f8bdfeb3d9301e0aec4b797689cbe569eff5a6
💬 fanquake commented on pull request "doc: Add post branch-off note about fuzz input pruning":
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536436413)
> "corpora",
This isn't a typo. It's a commonly used term when talking about fuzzing.
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536436413)
> "corpora",
This isn't a typo. It's a commonly used term when talking about fuzzing.
🚀 fanquake merged a pull request: "doc: Add post branch-off note about fuzz input pruning"
(https://github.com/bitcoin/bitcoin/pull/27574)
(https://github.com/bitcoin/bitcoin/pull/27574)
💬 ishaanam commented on pull request "wallet: when a block is disconnected, update transactions that are no longer conflicted":
(https://github.com/bitcoin/bitcoin/pull/27145#discussion_r1186241747)
Yes, the user would need to manually re-submit them or wait for the wallet to re-submit them automatically.
(https://github.com/bitcoin/bitcoin/pull/27145#discussion_r1186241747)
Yes, the user would need to manually re-submit them or wait for the wallet to re-submit them automatically.
💬 dergoegge commented on pull request "doc: Add post branch-off note about fuzz input pruning":
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536439992)
@fanquake It is actually a typo, in the readme it is currently spelled "copora" not "corpora"
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536439992)
@fanquake It is actually a typo, in the readme it is currently spelled "copora" not "corpora"
💬 fanquake commented on pull request "doc: Add post branch-off note about fuzz input pruning":
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536441503)
Right. Confusion over posting the correct spelling and calling it a typo.
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536441503)
Right. Confusion over posting the correct spelling and calling it a typo.
💬 fanquake commented on pull request "doc: Add post branch-off note about fuzz input pruning":
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536458503)
Fixed in https://github.com/bitcoin-core/qa-assets/pull/123.
(https://github.com/bitcoin/bitcoin/pull/27574#issuecomment-1536458503)
Fixed in https://github.com/bitcoin-core/qa-assets/pull/123.
📝 fanquake opened a pull request: "ci: fix asan task name"
(https://github.com/bitcoin/bitcoin/pull/27584)
Pointed out in https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1536434598.
(https://github.com/bitcoin/bitcoin/pull/27584)
Pointed out in https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1536434598.
💬 benthecarman commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536480635)
Okay I'll admit defeat. I was unware of all the DoS vectors in pre-taproot non-std txs. I still believe there should be a way for users to opt into allowing any kinds of txs into their mempool that doesn't have to do with DoS (0 value outputs, number of op_returns, taproot annex, tx size, etc).
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536480635)
Okay I'll admit defeat. I was unware of all the DoS vectors in pre-taproot non-std txs. I still believe there should be a way for users to opt into allowing any kinds of txs into their mempool that doesn't have to do with DoS (0 value outputs, number of op_returns, taproot annex, tx size, etc).
✅ benthecarman closed a pull request: "Allow accepting non-standard transactions on mainnet"
(https://github.com/bitcoin/bitcoin/pull/27578)
(https://github.com/bitcoin/bitcoin/pull/27578)
💬 fanquake commented on pull request "refactor: Remove need to pass chainparams to BlockManager methods":
(https://github.com/bitcoin/bitcoin/pull/27570#issuecomment-1536482035)
cc @jamesob, this is going to conflict with #15606.
(https://github.com/bitcoin/bitcoin/pull/27570#issuecomment-1536482035)
cc @jamesob, this is going to conflict with #15606.
💬 jamesob commented on pull request "refactor: Remove need to pass chainparams to BlockManager methods":
(https://github.com/bitcoin/bitcoin/pull/27570#issuecomment-1536490676)
Is this some kind of dependency for libbitcoinkernel or for something other than general tidy-up impulses? If so, feel free to merge - assumeutxo is fresh in my brain and handling the rebase won't be so painful as a result.
Otherwise, wouldn't mind this getting shelved for later. But really no big deal either way. I'd say if you're going to merge do it soon so that I can manage the rebase with fresh context.
(https://github.com/bitcoin/bitcoin/pull/27570#issuecomment-1536490676)
Is this some kind of dependency for libbitcoinkernel or for something other than general tidy-up impulses? If so, feel free to merge - assumeutxo is fresh in my brain and handling the rebase won't be so painful as a result.
Otherwise, wouldn't mind this getting shelved for later. But really no big deal either way. I'd say if you're going to merge do it soon so that I can manage the rebase with fresh context.
💬 fanquake commented on pull request "refactor: Remove need to pass chainparams to BlockManager methods":
(https://github.com/bitcoin/bitcoin/pull/27570#issuecomment-1536499967)
> Is this some kind of dependency for libbitcoinkernel or for something other than general tidy-up impulses?
It spawned out of here: https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1183556059. If you're happy to rebase over then I'm just going to go-ahead and merge this now. @TheCharlatan can then address any of his own comments as part of #27125 (which is also going to conflict with 15606, so probably worth having a look there as well.)
(https://github.com/bitcoin/bitcoin/pull/27570#issuecomment-1536499967)
> Is this some kind of dependency for libbitcoinkernel or for something other than general tidy-up impulses?
It spawned out of here: https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1183556059. If you're happy to rebase over then I'm just going to go-ahead and merge this now. @TheCharlatan can then address any of his own comments as part of #27125 (which is also going to conflict with 15606, so probably worth having a look there as well.)
🚀 fanquake merged a pull request: "refactor: Remove need to pass chainparams to BlockManager methods"
(https://github.com/bitcoin/bitcoin/pull/27570)
(https://github.com/bitcoin/bitcoin/pull/27570)
💬 hebasto commented on pull request "test: Explicitly specify directory where to search tests for":
(https://github.com/bitcoin/bitcoin/pull/27561#issuecomment-1536525721)
@stickies-v
> Would it be possible to provide instructions on replicating how to make this fail without`sys.path.append(tests_dir)`?
Sure. I've updated the PR description with steps to replicate the failure.
(https://github.com/bitcoin/bitcoin/pull/27561#issuecomment-1536525721)
@stickies-v
> Would it be possible to provide instructions on replicating how to make this fail without`sys.path.append(tests_dir)`?
Sure. I've updated the PR description with steps to replicate the failure.
💬 hebasto commented on pull request "test: Explicitly specify directory where to search tests for":
(https://github.com/bitcoin/bitcoin/pull/27561#issuecomment-1536535154)
Updated a3108880fac89d4472fe3b24d133e9645bed41cf -> fdff2156e1ebc11818f34759bff80e7d37dfff7d ([pr27561.01](https://github.com/hebasto/bitcoin/commits/pr27561.01) -> [pr27561.02](https://github.com/hebasto/bitcoin/commits/pr27561.02), [diff](https://github.com/hebasto/bitcoin/compare/pr27561.01..pr27561.02)):
- addressed @stickies-v's [comment](https://github.com/bitcoin/bitcoin/pull/27561#discussion_r1186191720)
(https://github.com/bitcoin/bitcoin/pull/27561#issuecomment-1536535154)
Updated a3108880fac89d4472fe3b24d133e9645bed41cf -> fdff2156e1ebc11818f34759bff80e7d37dfff7d ([pr27561.01](https://github.com/hebasto/bitcoin/commits/pr27561.01) -> [pr27561.02](https://github.com/hebasto/bitcoin/commits/pr27561.02), [diff](https://github.com/hebasto/bitcoin/compare/pr27561.01..pr27561.02)):
- addressed @stickies-v's [comment](https://github.com/bitcoin/bitcoin/pull/27561#discussion_r1186191720)
💬 hebasto commented on pull request "test: Explicitly specify directory where to search tests for":
(https://github.com/bitcoin/bitcoin/pull/27561#discussion_r1186317263)
Thanks! [Updated](https://github.com/bitcoin/bitcoin/pull/27561#issuecomment-1536535154).
(https://github.com/bitcoin/bitcoin/pull/27561#discussion_r1186317263)
Thanks! [Updated](https://github.com/bitcoin/bitcoin/pull/27561#issuecomment-1536535154).
💬 pinheadmz commented on pull request "net: call getaddrinfo() in detachable thread to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/27557#issuecomment-1536552393)
added call to `thread.join()` in the "happy path" so the only threads we should be abandoning are those that time out. Also setup the unit test to stub in a black hole for `getaddressinfo` to ensure the 2-second timeout is enforced. On my machine at least with thread and memory sanitizers I'm not getting any errors for the abandoned thread. I'm going to try some more experiments with a mainnet node as well.
(https://github.com/bitcoin/bitcoin/pull/27557#issuecomment-1536552393)
added call to `thread.join()` in the "happy path" so the only threads we should be abandoning are those that time out. Also setup the unit test to stub in a black hole for `getaddressinfo` to ensure the 2-second timeout is enforced. On my machine at least with thread and memory sanitizers I'm not getting any errors for the abandoned thread. I'm going to try some more experiments with a mainnet node as well.
💬 glozow commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536583890)
I agree that the network functions best when everybody hears about transactions before they are mined, but we should never _assume_ that mempool policies are homogeneous. I also believe that policy has room for improvement and we should change rules if they are harmful and unhelpful. Miners accepting out-of-band nonstandard transactions can be a symptom of Bitcoin Core's rules not being accommodating enough. (fwiw it can also mean that people are doing kind of spammy things).
However, I haven
...
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536583890)
I agree that the network functions best when everybody hears about transactions before they are mined, but we should never _assume_ that mempool policies are homogeneous. I also believe that policy has room for improvement and we should change rules if they are harmful and unhelpful. Miners accepting out-of-band nonstandard transactions can be a symptom of Bitcoin Core's rules not being accommodating enough. (fwiw it can also mean that people are doing kind of spammy things).
However, I haven
...
📝 brunoerg opened a pull request: "fuzz: improve `coinselection`"
(https://github.com/bitcoin/bitcoin/pull/27585)
This PR:
- Moves coin creation to its own function called `CreateCoins`.
- Add coverage for `EligibleForSpending`
- Add coverage for `AddInputs`: get result of each algorithm (srd, knapsack and bnb), call `CreateCoins` and add into them.
- Add coverage for `GetShuffledInputVector` and `GetInputSet` using the result of each algorithm (srd, knapsack and bnb).
- Add coverage for `Merge`: Call SRD with the new utxos and, if successful, try to merge with the previous SRD result.
(https://github.com/bitcoin/bitcoin/pull/27585)
This PR:
- Moves coin creation to its own function called `CreateCoins`.
- Add coverage for `EligibleForSpending`
- Add coverage for `AddInputs`: get result of each algorithm (srd, knapsack and bnb), call `CreateCoins` and add into them.
- Add coverage for `GetShuffledInputVector` and `GetInputSet` using the result of each algorithm (srd, knapsack and bnb).
- Add coverage for `Merge`: Call SRD with the new utxos and, if successful, try to merge with the previous SRD result.