💬 instagibbs commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078738029)
@kurapika007
> So why not increase it to 10 sats/vB—reducing bandwidth consumption by 10×, making the network 10× more resilient to spam, and sending the right economic signal for long-term sustainability?
Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new "optimal". If we enter a 90% drawdown bear market, we aren't going to revisit th
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078738029)
@kurapika007
> So why not increase it to 10 sats/vB—reducing bandwidth consumption by 10×, making the network 10× more resilient to spam, and sending the right economic signal for long-term sustainability?
Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new "optimal". If we enter a 90% drawdown bear market, we aren't going to revisit th
...
💬 maflcko commented on issue "getbestblockhash is sometimes taking a very long time":
(https://github.com/bitcoin/bitcoin/issues/32733#issuecomment-3078781773)
Does `-forcecompactdb` improve the situation for you?
(https://github.com/bitcoin/bitcoin/issues/32733#issuecomment-3078781773)
Does `-forcecompactdb` improve the situation for you?
💬 martinatime commented on issue "getbestblockhash is sometimes taking a very long time":
(https://github.com/bitcoin/bitcoin/issues/32733#issuecomment-3078804148)
I don't think I have tried that. Is there a way I can tell if the db needs to be compacted before I attempt this?
(https://github.com/bitcoin/bitcoin/issues/32733#issuecomment-3078804148)
I don't think I have tried that. Is there a way I can tell if the db needs to be compacted before I attempt this?
💬 sr-gi commented on pull request "Adds transaction propagation information to mempool transactions":
(https://github.com/bitcoin/bitcoin/pull/32986#issuecomment-3078827018)
> > I'm unsure whether the added complexity is justified, given that it's unlikely to be used beyond that specific context.
>
> Would adding tracepoint(s) be a suitable alternative? More overhead for the user, but probably much less in this repo?
I think existing tracepoints can be used as the base to build something similar outside Core, like `net:outbound_message` and `net:inbound_message`. Similarly, a log grabber (grepper?) can also work in some cases. The issue I see with both solutio
...
(https://github.com/bitcoin/bitcoin/pull/32986#issuecomment-3078827018)
> > I'm unsure whether the added complexity is justified, given that it's unlikely to be used beyond that specific context.
>
> Would adding tracepoint(s) be a suitable alternative? More overhead for the user, but probably much less in this repo?
I think existing tracepoints can be used as the base to build something similar outside Core, like `net:outbound_message` and `net:inbound_message`. Similarly, a log grabber (grepper?) can also work in some cases. The issue I see with both solutio
...
💬 kurapika007 commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078830847)
> @kurapika007
>
> Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new "optimal". If we enter a 90% drawdown bear market, we aren't going to revisit this value and raise it, are we?
>
Perhaps the solution lies not simply in arbitrarily adjusting technical parameters, but rather in adopting rules that better align the economic incentives of
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078830847)
> @kurapika007
>
> Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new "optimal". If we enter a 90% drawdown bear market, we aren't going to revisit this value and raise it, are we?
>
Perhaps the solution lies not simply in arbitrarily adjusting technical parameters, but rather in adopting rules that better align the economic incentives of
...
👍 TheCharlatan approved a pull request: "init: [gui] Avoid UB/crash in InitAndLoadChainstate"
(https://github.com/bitcoin/bitcoin/pull/32987#pullrequestreview-3025283492)
Thanks for fixing, should have thought of this when I started making the destructors more powerful! ACK on the fixes, the functional test is a bit hacky, but I don't have a better idea either. Maybe we could hook into the ui interface instead, but that's not necessarily cleaner and we only have one caller of `ThreadSafeQuestion` anyway.
(https://github.com/bitcoin/bitcoin/pull/32987#pullrequestreview-3025283492)
Thanks for fixing, should have thought of this when I started making the destructors more powerful! ACK on the fixes, the functional test is a bit hacky, but I don't have a better idea either. Maybe we could hook into the ui interface instead, but that's not necessarily cleaner and we only have one caller of `ThreadSafeQuestion` anyway.
💬 darosior commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078906634)
> If we enter a 90% drawdown bear market, we aren't going to revisit this value and raise it, are we?
Plus, we wouldn't be able to at all for software that is already released. Better have a conservative value that is resistant to an asset price decrease than an optimistic value that tries to captivate very low fees in times of high asset prices and low usage.
I am not against lowering the minrelay value, especially if it is shown that there is sustained usage of sub-1sat/vb transactions t
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078906634)
> If we enter a 90% drawdown bear market, we aren't going to revisit this value and raise it, are we?
Plus, we wouldn't be able to at all for software that is already released. Better have a conservative value that is resistant to an asset price decrease than an optimistic value that tries to captivate very low fees in times of high asset prices and low usage.
I am not against lowering the minrelay value, especially if it is shown that there is sustained usage of sub-1sat/vb transactions t
...
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2210633065)
Correct, I did not want to loop twice over the block's transactions to compute the actual number of spent inputs.
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2210633065)
Correct, I did not want to loop twice over the block's transactions to compute the actual number of spent inputs.
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2210635923)
How can I find the tx without the block's offset ?
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2210635923)
How can I find the tx without the block's offset ?
💬 l0rinc commented on pull request "[IBD] log start of script validation past `assumevalid` block":
(https://github.com/bitcoin/bitcoin/pull/32975#discussion_r2210648124)
Many users are surprised by the slowdowns that suddenly happen during IBD, this should clarify that. If this doesn't work for some corner cases, I think that should be fine, it's just meant to help explain the shift in IBD performance.
I can change it to include the case when script verification starts initially, but I explicitly meant this log to signal when the effect of assumevalid gets turned off, i.e. to explain "grinding to a halt" that many users were reporting.
> See also https://g
...
(https://github.com/bitcoin/bitcoin/pull/32975#discussion_r2210648124)
Many users are surprised by the slowdowns that suddenly happen during IBD, this should clarify that. If this doesn't work for some corner cases, I think that should be fine, it's just meant to help explain the shift in IBD performance.
I can change it to include the case when script verification starts initially, but I explicitly meant this log to signal when the effect of assumevalid gets turned off, i.e. to explain "grinding to a halt" that many users were reporting.
> See also https://g
...
💬 Rob1Ham commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078947536)
A naive question I have is how does this relate to another policy change like mempoolfullrbf? We currently have 20% of hashrate now mining sub 1 sat/vbyte ([source](https://x.com/mononautical/status/1944942585384198259)) and some mining pools are leaving revenue on the table due to not having the right mempool policy ([source](https://x.com/mononautical/status/1945328731821892043)), couldn't the argument be made that some mining pools are being advantaged by using the default values?
A fair c
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078947536)
A naive question I have is how does this relate to another policy change like mempoolfullrbf? We currently have 20% of hashrate now mining sub 1 sat/vbyte ([source](https://x.com/mononautical/status/1944942585384198259)) and some mining pools are leaving revenue on the table due to not having the right mempool policy ([source](https://x.com/mononautical/status/1945328731821892043)), couldn't the argument be made that some mining pools are being advantaged by using the default values?
A fair c
...
🤔 furszy reviewed a pull request: "wallet: Remove `upgradewallet` RPC"
(https://github.com/bitcoin/bitcoin/pull/32944#pullrequestreview-3025398994)
It seems we're already thinking about upgrades in #32895 ?.
If that's the case, I'd rather keep the RPC. The maintenance cost should be minimal.
(https://github.com/bitcoin/bitcoin/pull/32944#pullrequestreview-3025398994)
It seems we're already thinking about upgrades in #32895 ?.
If that's the case, I'd rather keep the RPC. The maintenance cost should be minimal.
🤔 stickies-v reviewed a pull request: "Adds transaction propagation information to mempool transactions"
(https://github.com/bitcoin/bitcoin/pull/32986#pullrequestreview-3025461492)
I'm generally not in favour of making bespoke changes to production code or extending the public interface just to facilitate tests, monitoring, ... if there exists a workaround, especially for temporary projects. In this case, after speaking with @sr-gi offline a bit more, it seems it seems like tracepoints, logging, small patchsets, ... are feasible alternatives, so I'm Concept NACK on this one. (but I am open to making minimal changes to ensure the necessary erlay simulations can be ran)
(https://github.com/bitcoin/bitcoin/pull/32986#pullrequestreview-3025461492)
I'm generally not in favour of making bespoke changes to production code or extending the public interface just to facilitate tests, monitoring, ... if there exists a workaround, especially for temporary projects. In this case, after speaking with @sr-gi offline a bit more, it seems it seems like tracepoints, logging, small patchsets, ... are feasible alternatives, so I'm Concept NACK on this one. (but I am open to making minimal changes to ensure the necessary erlay simulations can be ran)
🤔 stickies-v reviewed a pull request: "doc: clarify GetAddresses documentation"
(https://github.com/bitcoin/bitcoin/pull/32994#pullrequestreview-3025490230)
Concept ACK. I would strongly prefer to go further and rename the trusted function to `GetAddressesUncached`. Overloads that behave vastly differently and can lead to dangerous behaviour is a big red flag for me.
(https://github.com/bitcoin/bitcoin/pull/32994#pullrequestreview-3025490230)
Concept ACK. I would strongly prefer to go further and rename the trusted function to `GetAddressesUncached`. Overloads that behave vastly differently and can lead to dangerous behaviour is a big red flag for me.
🤔 theuni reviewed a pull request: "depends: fix libevent `_WIN32_WINNT` usage"
(https://github.com/bitcoin/bitcoin/pull/32837#pullrequestreview-3025518171)
Concept ACK and vague post-merge utACK.
I don't understand all of the upstream changes, but it makes sense to take that patch if it fixes our issue.
(https://github.com/bitcoin/bitcoin/pull/32837#pullrequestreview-3025518171)
Concept ACK and vague post-merge utACK.
I don't understand all of the upstream changes, but it makes sense to take that patch if it fixes our issue.
💬 theuni commented on pull request "depends: fix libevent `_WIN32_WINNT` usage":
(https://github.com/bitcoin/bitcoin/pull/32837#discussion_r2210729180)
Why was this undef'd before and not now?
(https://github.com/bitcoin/bitcoin/pull/32837#discussion_r2210729180)
Why was this undef'd before and not now?
💬 fanquake commented on pull request "depends: fix libevent `_WIN32_WINNT` usage":
(https://github.com/bitcoin/bitcoin/pull/32837#discussion_r2210782699)
The upstream change just removed all the undefining: https://github.com/libevent/libevent/pull/1498.
(https://github.com/bitcoin/bitcoin/pull/32837#discussion_r2210782699)
The upstream change just removed all the undefining: https://github.com/libevent/libevent/pull/1498.
💬 fanquake commented on pull request "fuzz: wallet: add target for tx scanning":
(https://github.com/bitcoin/bitcoin/pull/32993#issuecomment-3079192425)
https://cirrus-ci.com/task/4897452429410304?logs=ci#L6267:
```bash
[10:48:30.374] Run wallet_scan with args ['/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/bin/fuzz', '-max_total_time=60']INFO: Running with entropic power schedule (0xFF, 100).
[10:48:30.374] INFO: Seed: 1927962085
[10:48:30.374] INFO: Loaded 1 modules (634026 inline 8-bit counters): 634026 [0x5573df666fb8, 0x5573df701c62),
[10:48:30.374] INFO: Loaded 1 PC tables (634026 PCs): 634026 [0x5573df701c68,0x5573e00ae7
...
(https://github.com/bitcoin/bitcoin/pull/32993#issuecomment-3079192425)
https://cirrus-ci.com/task/4897452429410304?logs=ci#L6267:
```bash
[10:48:30.374] Run wallet_scan with args ['/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/bin/fuzz', '-max_total_time=60']INFO: Running with entropic power schedule (0xFF, 100).
[10:48:30.374] INFO: Seed: 1927962085
[10:48:30.374] INFO: Loaded 1 modules (634026 inline 8-bit counters): 634026 [0x5573df666fb8, 0x5573df701c62),
[10:48:30.374] INFO: Loaded 1 PC tables (634026 PCs): 634026 [0x5573df701c68,0x5573e00ae7
...
📝 brunoerg converted_to_draft a pull request: "fuzz: wallet: add target for tx scanning"
(https://github.com/bitcoin/bitcoin/pull/32993)
Tracking issue (#29901)
This PR adds a fuzz target for wallet tx scanning (`ScanForWalletTransactions`). Unfortunately, it's not a regression test for the issue #31474 since it would require a more complex scenario/async operations.
(https://github.com/bitcoin/bitcoin/pull/32993)
Tracking issue (#29901)
This PR adds a fuzz target for wallet tx scanning (`ScanForWalletTransactions`). Unfortunately, it's not a regression test for the issue #31474 since it would require a more complex scenario/async operations.
💬 murchandamus commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3079233470)
> > @BitcoinMechanic:
> > > > The most persuasive argument for this would be that miners have diverged from defaults
> > >
> > > You continue to confuse cause and effect. Miners mine what gets relayed, not the reverse.
> > > Default relay policy for Core essentially controls what ends up in the blockchain and what doesn't. It's pointless to keep pretending otherwise.
> >
> > Neither Bitcoin Core, nor Knots, not even [LibreRelay nodes](https://github.com/petertodd/bitcoin/blob/af41065cb2a
...
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3079233470)
> > @BitcoinMechanic:
> > > > The most persuasive argument for this would be that miners have diverged from defaults
> > >
> > > You continue to confuse cause and effect. Miners mine what gets relayed, not the reverse.
> > > Default relay policy for Core essentially controls what ends up in the blockchain and what doesn't. It's pointless to keep pretending otherwise.
> >
> > Neither Bitcoin Core, nor Knots, not even [LibreRelay nodes](https://github.com/petertodd/bitcoin/blob/af41065cb2a
...