💬 furszy commented on issue "wallet: add destination (output) and bump fee":
(https://github.com/bitcoin/bitcoin/issues/22007#issuecomment-1537453901)
This can be closed. https://github.com/bitcoin/bitcoin/pull/25344 implemented the changes.
(https://github.com/bitcoin/bitcoin/issues/22007#issuecomment-1537453901)
This can be closed. https://github.com/bitcoin/bitcoin/pull/25344 implemented the changes.
✅ fanquake closed an issue: "wallet: add destination (output) and bump fee"
(https://github.com/bitcoin/bitcoin/issues/22007)
(https://github.com/bitcoin/bitcoin/issues/22007)
🤔 theStack reviewed a pull request: "mempool / rpc: add getprioritisedtransactions, delete a mapDeltas entry when delta==0"
(https://github.com/bitcoin/bitcoin/pull/27501#pullrequestreview-1415921058)
Code looks good to me, also agree with aj that `getprioritisedtranactions` is a better naming. Note that the first three commits still have the old names in their commit subjects and should be adapted accordingly.
(https://github.com/bitcoin/bitcoin/pull/27501#pullrequestreview-1415921058)
Code looks good to me, also agree with aj that `getprioritisedtranactions` is a better naming. Note that the first three commits still have the old names in their commit subjects and should be adapted accordingly.
💬 theStack commented on pull request "mempool / rpc: add getprioritisedtransactions, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186865746)
```suggestion
/** Return a vector of all entries in mapDeltas with, as value, their fee delta and whether the
```
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186865746)
```suggestion
/** Return a vector of all entries in mapDeltas with, as value, their fee delta and whether the
```
💬 pavel-vasin commented on pull request "Inscriptions option":
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537500528)
>you can still submit consensus compatible transactions directly to a miner
Is it time to remove the standard transaction policy?
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537500528)
>you can still submit consensus compatible transactions directly to a miner
Is it time to remove the standard transaction policy?
🤔 brunoerg reviewed a pull request: "rpc: append rpcauth.py hash in config and show pass"
(https://github.com/bitcoin/bitcoin/pull/27588#pullrequestreview-1415943834)
From CI:
```sh
102/264 -
rpc_users.py
failed, Duration: 1 s
stdout:
2023-05-06T19:48:12.787000Z TestFramework (INFO): PRNG seed is: 4992424049312590578
2023-05-06T19:48:12.806000Z TestFramework (INFO): Initializing test directory /tmp/cirrus-ci-build/ci/scratch/test_runner/test_runner_₿_🏃_20230506_193750/rpc_users_159
2023-05-06T19:48:13.197000Z TestFramework (ERROR): Unexpected exception caught during testing
Traceback (most recent call last):
File "/tmp/cirrus-ci-build/ci/scratc
...
(https://github.com/bitcoin/bitcoin/pull/27588#pullrequestreview-1415943834)
From CI:
```sh
102/264 -
rpc_users.py
failed, Duration: 1 s
stdout:
2023-05-06T19:48:12.787000Z TestFramework (INFO): PRNG seed is: 4992424049312590578
2023-05-06T19:48:12.806000Z TestFramework (INFO): Initializing test directory /tmp/cirrus-ci-build/ci/scratch/test_runner/test_runner_₿_🏃_20230506_193750/rpc_users_159
2023-05-06T19:48:13.197000Z TestFramework (ERROR): Unexpected exception caught during testing
Traceback (most recent call last):
File "/tmp/cirrus-ci-build/ci/scratc
...
💬 michaelfolkson commented on pull request "Inscriptions option":
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537510910)
@pavel-vasin: Discussed [here](https://github.com/bitcoin/bitcoin/pull/27578). Bitcoin StackExchange next time please.
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537510910)
@pavel-vasin: Discussed [here](https://github.com/bitcoin/bitcoin/pull/27578). Bitcoin StackExchange next time please.
💬 ArmchairCryptologist commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537513884)
Been seeing this on my 24.0.1 public nodes as well, it's not 100% CPU usage as such, but a single CPU core is spinning at 100%. One 24.0.1 node with listen=0 did not seem affected.
I noticed that after a node restart, the CPU usage went back to normal (and is still normal after a day) even though the mempool was loaded from disk - though it might be because it's not entirely full.
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537513884)
Been seeing this on my 24.0.1 public nodes as well, it's not 100% CPU usage as such, but a single CPU core is spinning at 100%. One 24.0.1 node with listen=0 did not seem affected.
I noticed that after a node restart, the CPU usage went back to normal (and is still normal after a day) even though the mempool was loaded from disk - though it might be because it's not entirely full.
💬 Fiach-Dubh commented on pull request "Inscriptions option":
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537519662)
> @Retropex: Ask on [Bitcoin StackExchange](https://bitcoin.stackexchange.com/) whether what you are suggesting is a good idea (short answer is any default policy change or custom policy option doesn't necessarily stop inscriptions as you can still submit consensus compatible transactions directly to a miner). There is already an [ordinals tag](https://bitcoin.stackexchange.com/questions/tagged/ordinals) with previous Q&A on this topic.
what if the intent of such a filter is not to stop them,
...
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537519662)
> @Retropex: Ask on [Bitcoin StackExchange](https://bitcoin.stackexchange.com/) whether what you are suggesting is a good idea (short answer is any default policy change or custom policy option doesn't necessarily stop inscriptions as you can still submit consensus compatible transactions directly to a miner). There is already an [ordinals tag](https://bitcoin.stackexchange.com/questions/tagged/ordinals) with previous Q&A on this topic.
what if the intent of such a filter is not to stop them,
...
📝 glozow opened a pull request: "rpc: distinguish between vsize and sigop-adjusted mempool vsize"
(https://github.com/bitcoin/bitcoin/pull/27591)
`CTxMemPoolEntry::GetTxSize()` returns the maximum between vsize and "sigop-adjusted size" which is used by mempool validation and mining code as a heuristic to avoid 2DKnapsacking the block weight and sigop limits.
Sigop-adjusted vsize is returned as the "vsize" value of a transaction for RPCs retrieving mempool entry information (e.g. `getmempoolentry` and`getrawmempool`) and mempool acceptance (`testmempoolaccept` and `submitpackage`). The [documentation](https://github.com/bitcoin/bitcoin
...
(https://github.com/bitcoin/bitcoin/pull/27591)
`CTxMemPoolEntry::GetTxSize()` returns the maximum between vsize and "sigop-adjusted size" which is used by mempool validation and mining code as a heuristic to avoid 2DKnapsacking the block weight and sigop limits.
Sigop-adjusted vsize is returned as the "vsize" value of a transaction for RPCs retrieving mempool entry information (e.g. `getmempoolentry` and`getrawmempool`) and mempool acceptance (`testmempoolaccept` and `submitpackage`). The [documentation](https://github.com/bitcoin/bitcoin
...
⚠️ embiimob opened an issue: "provide optional RPC parameter to not scramble sendmany transactions"
(https://github.com/bitcoin/bitcoin/issues/27592)
### Please describe the feature you'd like to see added.
passed bitcoin core 16.X the order of sendmany transactions is scrambled via RPC command forcing projects that utilizing the order of transactions to use older wallets.
### Is your feature related to a problem, if so please describe it.
_No response_
### Describe the solution you'd like
add an optional parameter to the sendmany RPC command that allows for the sendmany transaction to work as it did before. giving the option to scr
...
(https://github.com/bitcoin/bitcoin/issues/27592)
### Please describe the feature you'd like to see added.
passed bitcoin core 16.X the order of sendmany transactions is scrambled via RPC command forcing projects that utilizing the order of transactions to use older wallets.
### Is your feature related to a problem, if so please describe it.
_No response_
### Describe the solution you'd like
add an optional parameter to the sendmany RPC command that allows for the sendmany transaction to work as it did before. giving the option to scr
...
💬 darosior commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537531968)
Just to confirm, yours was in debug mode as well? Otherwise it'd be concerning.
-------- Original Message --------
On May 7, 2023, 8:39 PM, ArmchairCryptologist wrote:
> Been seeing this on my 24.0.1 public nodes as well, it's not 100% CPU usage as such, but a single CPU core is spinning at 100%. One 24.0.1 node with listen=0 did not seem affected.
>
> I noticed that after a node restart, the CPU usage went back to normal (and is still normal after a day) even though the mempool was loaded fro
...
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537531968)
Just to confirm, yours was in debug mode as well? Otherwise it'd be concerning.
-------- Original Message --------
On May 7, 2023, 8:39 PM, ArmchairCryptologist wrote:
> Been seeing this on my 24.0.1 public nodes as well, it's not 100% CPU usage as such, but a single CPU core is spinning at 100%. One 24.0.1 node with listen=0 did not seem affected.
>
> I noticed that after a node restart, the CPU usage went back to normal (and is still normal after a day) even though the mempool was loaded fro
...
💬 ArmchairCryptologist commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537534014)
> Just to confirm, yours was in debug mode as well? Otherwise it'd be concerning.
My nodes are NOT in debug mode, no. I run four public nodes (24.0.1) with different server hosts, and all four of them were spinning a CPU core at 100% and experiencing slowness with block/transaction handling when I checked them yesterday, two to the point where they started occasionally dropping connectivity to my private nodes. Like I mentioned, one 24.0.1 node which does not accept incoming connections (but
...
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537534014)
> Just to confirm, yours was in debug mode as well? Otherwise it'd be concerning.
My nodes are NOT in debug mode, no. I run four public nodes (24.0.1) with different server hosts, and all four of them were spinning a CPU core at 100% and experiencing slowness with block/transaction handling when I checked them yesterday, two to the point where they started occasionally dropping connectivity to my private nodes. Like I mentioned, one 24.0.1 node which does not accept incoming connections (but
...
💬 furszy commented on issue "provide optional RPC parameter to not scramble sendmany transactions":
(https://github.com/bitcoin/bitcoin/issues/27592#issuecomment-1537539811)
If your project requires control over the tx, could move to something like:
```python
raw_tx = wallet.createrawtransaction(inputs=[], outputs=["add outputs here"])
funded_tx = wallet.fundrawtranasction(raw_tx)
signed_tx = wallet.signrawtransactionwithwallet(funded_tx['hex'])
wallet.sendrawtransaction(signed_tx['hex'])
```
(https://github.com/bitcoin/bitcoin/issues/27592#issuecomment-1537539811)
If your project requires control over the tx, could move to something like:
```python
raw_tx = wallet.createrawtransaction(inputs=[], outputs=["add outputs here"])
funded_tx = wallet.fundrawtranasction(raw_tx)
signed_tx = wallet.signrawtransactionwithwallet(funded_tx['hex'])
wallet.sendrawtransaction(signed_tx['hex'])
```
💬 ajtowns commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537544963)
> PS: These nodes do **not** run in debug mode.
With the issue I described here patched around, I see a different problem that also results in b-msghand using ~100% of a single cpu. It seems to be spent in `make_heap` in `net_processing.cpp` which in turn seems to be due to the internal queues for which txs need to be INVed to which peers growing much too large (I've observed >60,000 entries in each of 6 peers, eg). It seems to be exacerbated by a combination of inbound peers that aren't real
...
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537544963)
> PS: These nodes do **not** run in debug mode.
With the issue I described here patched around, I see a different problem that also results in b-msghand using ~100% of a single cpu. It seems to be spent in `make_heap` in `net_processing.cpp` which in turn seems to be due to the internal queues for which txs need to be INVed to which peers growing much too large (I've observed >60,000 entries in each of 6 peers, eg). It seems to be exacerbated by a combination of inbound peers that aren't real
...
💬 ajtowns commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537545897)
Oh, if anyone wants to mitigate the `make_heap` thing; I think something like:
```sh
$ bitcoin-cli getpeerinfo | jq -j '.[] | (.bytessent_per_msg.inv, " ", .bytesrecv_per_msg.inv, " ", .addr, "\n")' | grep ' null ' | sort -n
```
should list the nodes where you're sending lots of inv data, without receiving anything in return. Doing a temporary "setban" on those to disconnect them will clear their inv queue and should speed things up temporarily.
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537545897)
Oh, if anyone wants to mitigate the `make_heap` thing; I think something like:
```sh
$ bitcoin-cli getpeerinfo | jq -j '.[] | (.bytessent_per_msg.inv, " ", .bytesrecv_per_msg.inv, " ", .addr, "\n")' | grep ' null ' | sort -n
```
should list the nodes where you're sending lots of inv data, without receiving anything in return. Doing a temporary "setban" on those to disconnect them will clear their inv queue and should speed things up temporarily.
💬 dzyphr commented on pull request "Inscriptions option":
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537551415)
It will be left up to personal choice no matter what, however I think we should take the approach of mitigating anything that really looks like spam which again will be personal choice.
(https://github.com/bitcoin/bitcoin/pull/27589#issuecomment-1537551415)
It will be left up to personal choice no matter what, however I think we should take the approach of mitigating anything that really looks like spam which again will be personal choice.
💬 instagibbs commented on issue "Avoid serving stale fees":
(https://github.com/bitcoin/bitcoin/issues/27555#issuecomment-1537586780)
looks like one of my nodes had a similar issue with a clean shutdown and restart
https://twitter.com/CoreFeeHelper/status/1655286815291588611 after restart, then an hour or so later: https://twitter.com/CoreFeeHelper/status/1655301916593668097
back up to expected min fee
(https://github.com/bitcoin/bitcoin/issues/27555#issuecomment-1537586780)
looks like one of my nodes had a similar issue with a clean shutdown and restart
https://twitter.com/CoreFeeHelper/status/1655286815291588611 after restart, then an hour or so later: https://twitter.com/CoreFeeHelper/status/1655301916593668097
back up to expected min fee
💬 ArmchairCryptologist commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537784340)
Of the four nodes, the one that was restarted on May 6th is now back to spinning 100% of a CPU core (60% average CPU usage on a two-core VM the last hour) while the three that were restarted yesterday are also seeing high CPU usage but not 100% all the time (between 30% and 38% average CPU usage on a two-core VM), so it's building back up relatively quickly. I also verified that the mempool is not fully committed (usage is at 251217552).
There were around 15 peers with bytessent_per_msg.inv o
...
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1537784340)
Of the four nodes, the one that was restarted on May 6th is now back to spinning 100% of a CPU core (60% average CPU usage on a two-core VM the last hour) while the three that were restarted yesterday are also seeing high CPU usage but not 100% all the time (between 30% and 38% average CPU usage on a two-core VM), so it's building back up relatively quickly. I also verified that the mempool is not fully committed (usage is at 251217552).
There were around 15 peers with bytessent_per_msg.inv o
...
💬 S3RK commented on pull request "wallet, tests: Expand and test when the blank wallet flag should be un/set":
(https://github.com/bitcoin/bitcoin/pull/25634#issuecomment-1537830694)
re code review ACK 7baa0971527ba3c8d87b82c7a2a4eabf6abbb2b7
My previous comment about exposing `blank` flag is still valid, but I don't think it's blocking. I like furszy's suggestion to return the flag only for regtest
(https://github.com/bitcoin/bitcoin/pull/25634#issuecomment-1537830694)
re code review ACK 7baa0971527ba3c8d87b82c7a2a4eabf6abbb2b7
My previous comment about exposing `blank` flag is still valid, but I don't think it's blocking. I like furszy's suggestion to return the flag only for regtest