π¬ instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1499641781)
removed, since I stripped out the sorting function from `BuildDiagramFromUnsortedChunks`
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1499641781)
removed, since I stripped out the sorting function from `BuildDiagramFromUnsortedChunks`
π€ ryanofsky reviewed a pull request: "assumeutxo: Get rid of faked nTx and nChainTx values"
(https://github.com/bitcoin/bitcoin/pull/29370#pullrequestreview-1896432015)
Thanks for the review. Tried to answer some questions below and I will work on the suggestions
(https://github.com/bitcoin/bitcoin/pull/29370#pullrequestreview-1896432015)
Thanks for the review. Tried to answer some questions below and I will work on the suggestions
π¬ ryanofsky commented on pull request "assumeutxo: Get rid of faked nTx and nChainTx values":
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499608826)
re: https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499266054
> Just to clarify, the `is_active` check is just a belt-and-suspender, since `pindex == snap_base` implies `is_active`?
It's meant to be a real check. I should probably add a comment about it. The idea is that on the snapshot chain, the snapshot block should be in `setBlockIndexCandidates` even though earlier transactions may not be downloaded.
I don't think `pindex == snap_base` implies anything about `is_active`,
...
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499608826)
re: https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499266054
> Just to clarify, the `is_active` check is just a belt-and-suspender, since `pindex == snap_base` implies `is_active`?
It's meant to be a real check. I should probably add a comment about it. The idea is that on the snapshot chain, the snapshot block should be in `setBlockIndexCandidates` even though earlier transactions may not be downloaded.
I don't think `pindex == snap_base` implies anything about `is_active`,
...
π¬ ryanofsky commented on pull request "assumeutxo: Get rid of faked nTx and nChainTx values":
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499641472)
re: https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499519079
> Why would the _background_ chainstate have the _snapshot_ base? The comment seems wrong and the second branch of the if condition is never taken, no?
I think the comment is just saying that if pindex is an ancestor of the snapshot base, it should be in setBlockIndexCandidates. It's possible the snapshot base could be in there too, but the code is only checking for it to be there if the chain is active, or if all tra
...
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499641472)
re: https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1499519079
> Why would the _background_ chainstate have the _snapshot_ base? The comment seems wrong and the second branch of the if condition is never taken, no?
I think the comment is just saying that if pindex is an ancestor of the snapshot base, it should be in setBlockIndexCandidates. It's possible the snapshot base could be in there too, but the code is only checking for it to be there if the chain is active, or if all tra
...
β
maflcko closed a pull request: "assumeutxo, rpc: Add 'start' parameter to loadtxoutset"
(https://github.com/bitcoin/bitcoin/pull/28659)
(https://github.com/bitcoin/bitcoin/pull/28659)
π¬ maflcko commented on pull request "assumeutxo, rpc: Add 'start' parameter to loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/28659#issuecomment-1959967361)
Closing for now. This has been a placeholder for months now, with no code to review or merge, and the CI failing anyway. Feel free to open a new pull request once and if there is something to review. If you have questions, you can leave them in the existing thread: https://github.com/bitcoin/bitcoin/issues/28620
(https://github.com/bitcoin/bitcoin/pull/28659#issuecomment-1959967361)
Closing for now. This has been a placeholder for months now, with no code to review or merge, and the CI failing anyway. Feel free to open a new pull request once and if there is something to review. If you have questions, you can leave them in the existing thread: https://github.com/bitcoin/bitcoin/issues/28620
π cbergqvist approved a pull request: "test: test_bitcoin: allow -testdatadir=<datadir>"
(https://github.com/bitcoin/bitcoin/pull/26564#pullrequestreview-1896496278)
ACK 7b81dea. One follow-up suggestion.
(https://github.com/bitcoin/bitcoin/pull/26564#pullrequestreview-1896496278)
ACK 7b81dea. One follow-up suggestion.
π¬ cbergqvist commented on pull request "test: test_bitcoin: allow -testdatadir=<datadir>":
(https://github.com/bitcoin/bitcoin/pull/26564#discussion_r1499651040)
Suggestion: change to something like `"Test directory (not deleted until next run): "`
(https://github.com/bitcoin/bitcoin/pull/26564#discussion_r1499651040)
Suggestion: change to something like `"Test directory (not deleted until next run): "`
π¬ maflcko commented on pull request "assumeutxo state and locking cleanup":
(https://github.com/bitcoin/bitcoin/pull/28608#issuecomment-1959970631)
Not sure what the status here is? It would be good to rebase, so that reviewers can take a look, or close, so that it can be grabbed up, if there is need.
(https://github.com/bitcoin/bitcoin/pull/28608#issuecomment-1959970631)
Not sure what the status here is? It would be good to rebase, so that reviewers can take a look, or close, so that it can be grabbed up, if there is need.
π¬ ariard commented on pull request "[WIP] Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#issuecomment-1959971463)
> interesting what is the lowest performance linux host assumed for decentralization of the tx-relay network.
assume always 24/7 internet and on a vpcu instance, not baremetal.
Running this branch mainet on a 2 vcpu instance, with the following performance characteristics:
```
processor : 0
vendor_id : AuthenticAMD
cpu family : 25
model : 1
model name : AMD EPYC 7543 32-Core Processor
stepping : 1
microcode : 0xa0011d1
cpu MHz : 2
...
(https://github.com/bitcoin/bitcoin/pull/28676#issuecomment-1959971463)
> interesting what is the lowest performance linux host assumed for decentralization of the tx-relay network.
assume always 24/7 internet and on a vpcu instance, not baremetal.
Running this branch mainet on a 2 vcpu instance, with the following performance characteristics:
```
processor : 0
vendor_id : AuthenticAMD
cpu family : 25
model : 1
model name : AMD EPYC 7543 32-Core Processor
stepping : 1
microcode : 0xa0011d1
cpu MHz : 2
...
π¬ maflcko commented on pull request "miniscript: convert non-critical asserts to Assumes":
(https://github.com/bitcoin/bitcoin/pull/28678#issuecomment-1959974038)
Are you still working on this?
(https://github.com/bitcoin/bitcoin/pull/28678#issuecomment-1959974038)
Are you still working on this?
π¬ instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1499665791)
@sdaftuar that matches my understanding.
>Removing the sorting step in this function (moving it to the caller). The function can then take Span<const FeeFrac> as input too, and perhaps in a further iteration (in a later PR) this function could then be turned into one that actually performs chunking too.
Took this suggestion
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1499665791)
@sdaftuar that matches my understanding.
>Removing the sorting step in this function (moving it to the caller). The function can then take Span<const FeeFrac> as input too, and perhaps in a further iteration (in a later PR) this function could then be turned into one that actually performs chunking too.
Took this suggestion
π¬ maflcko commented on pull request "kernel: Remove dependency on CScheduler":
(https://github.com/bitcoin/bitcoin/pull/28960#issuecomment-1959978642)
Added to 28.0, since it looks rfm, but is probably waiting on the branch-off?
(https://github.com/bitcoin/bitcoin/pull/28960#issuecomment-1959978642)
Added to 28.0, since it looks rfm, but is probably waiting on the branch-off?
π¬ maflcko commented on pull request "RPC: add new `listmempooltransactions`":
(https://github.com/bitcoin/bitcoin/pull/29016#issuecomment-1959989869)
Are you still working on this? Looks like there are outstanding questions.
(https://github.com/bitcoin/bitcoin/pull/29016#issuecomment-1959989869)
Are you still working on this? Looks like there are outstanding questions.
β
maflcko closed a pull request: "wallet: move lock at the top of ReleaseWallet"
(https://github.com/bitcoin/bitcoin/pull/29155)
(https://github.com/bitcoin/bitcoin/pull/29155)
π¬ maflcko commented on pull request "wallet: move lock at the top of ReleaseWallet":
(https://github.com/bitcoin/bitcoin/pull/29155#issuecomment-1959993168)
Closing for now due to inactivity, and unclear status (why is this the correct fix?). However, a fix for this wallet crash is still needed and very much welcome.
(https://github.com/bitcoin/bitcoin/pull/29155#issuecomment-1959993168)
Closing for now due to inactivity, and unclear status (why is this the correct fix?). However, a fix for this wallet crash is still needed and very much welcome.
π¬ maflcko commented on issue "ci: failure in `wallet_multiwallet.py --legacy-wallet`":
(https://github.com/bitcoin/bitcoin/issues/29073#issuecomment-1959994612)
Added to 27.0, with the understanding that it is not a regression, and can be moved to 28.0, if needed.
(https://github.com/bitcoin/bitcoin/issues/29073#issuecomment-1959994612)
Added to 27.0, with the understanding that it is not a regression, and can be moved to 28.0, if needed.
π¬ maflcko commented on pull request "Compressed Bitcoin Transactions":
(https://github.com/bitcoin/bitcoin/pull/29134#issuecomment-1960003403)
> And if neither of those, then I don't think it's within the scope of Bitcoin Core. It seems to be a pretty significant maintenance burden for something that, as implemented, is only used by specific new RPCs.
My understanding is that it requires the chainstate, so this is written inside of Bitcoin Core. However, I am also wondering if existing RPCs can be used to query the chainstate, or extended, if needed. Putting this piece of code directly in the satellite broadcast software seems easie
...
(https://github.com/bitcoin/bitcoin/pull/29134#issuecomment-1960003403)
> And if neither of those, then I don't think it's within the scope of Bitcoin Core. It seems to be a pretty significant maintenance burden for something that, as implemented, is only used by specific new RPCs.
My understanding is that it requires the chainstate, so this is written inside of Bitcoin Core. However, I am also wondering if existing RPCs can be used to query the chainstate, or extended, if needed. Putting this piece of code directly in the satellite broadcast software seems easie
...
π¬ maflcko commented on pull request "Bugfix: RPC: Check for blank rpcauth on a per-param basis":
(https://github.com/bitcoin/bitcoin/pull/29141#issuecomment-1960012705)
> I'm not entirely sure what the expected behaviour here is...
Are you still working on this?
Not sure something that is unsupported does need fixing.
(https://github.com/bitcoin/bitcoin/pull/29141#issuecomment-1960012705)
> I'm not entirely sure what the expected behaviour here is...
Are you still working on this?
Not sure something that is unsupported does need fixing.
π¬ LarryRuane commented on pull request "test: test_bitcoin: allow -testdatadir=<datadir>":
(https://github.com/bitcoin/bitcoin/pull/26564#discussion_r1499718540)
Thanks, I _think_ it's clear enough as is. If it says "until next run", it might not be clear if that's before the next run of _any_ test or this _particular_ test. Clarifying that would add more text and be a bit too chatty. I think the current text is clear enough to convey "not deleted after the current run"; I think it's understood that if you specify the same data directory and the same test, it will overwrite that same directory.
(https://github.com/bitcoin/bitcoin/pull/26564#discussion_r1499718540)
Thanks, I _think_ it's clear enough as is. If it says "until next run", it might not be clear if that's before the next run of _any_ test or this _particular_ test. Clarifying that would add more text and be a bit too chatty. I think the current text is clear enough to convey "not deleted after the current run"; I think it's understood that if you specify the same data directory and the same test, it will overwrite that same directory.
π¬ ariard commented on issue "Cluster mempool, CPFP carveout, and V3 transaction policy":
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1960028293)
@sdaftuar While I'm sharing your opinion on the lack of necessity to not break downstream usersβs applications unnecessarily, I think you're missing my present observation on the lack of current benefit of the 2 anchor outputs on LN commitment transactions. As my test demonstrate just above, in the occurence of an adversarial scenario, the abibility to CPFPcon a counterparty commitment transaction can be neutralized by broadcasting one of the 2 commitment states in the target mempool. In the occ
...
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1960028293)
@sdaftuar While I'm sharing your opinion on the lack of necessity to not break downstream usersβs applications unnecessarily, I think you're missing my present observation on the lack of current benefit of the 2 anchor outputs on LN commitment transactions. As my test demonstrate just above, in the occurence of an adversarial scenario, the abibility to CPFPcon a counterparty commitment transaction can be neutralized by broadcasting one of the 2 commitment states in the target mempool. In the occ
...