💬 TheBlueMatt commented on issue "Wallet Missing Balances/Unspent":
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1796972545)
There doesn't appear to be anything in-wallet that is spending that output:
`bitcoin-cli listtransactions "*" 10000000 | jq '.[] | select(.confirmations <= 0) | .txid' | xargs -L1 bitcoin-cli gettransaction | grep bc1qag6gtevhvuhafph4d73ajlj5vyhh7k4xff0p4f` shows nothing.
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1796972545)
There doesn't appear to be anything in-wallet that is spending that output:
`bitcoin-cli listtransactions "*" 10000000 | jq '.[] | select(.confirmations <= 0) | .txid' | xargs -L1 bitcoin-cli gettransaction | grep bc1qag6gtevhvuhafph4d73ajlj5vyhh7k4xff0p4f` shows nothing.
💬 ajtowns commented on pull request "ArgsManager: support subcommand-specific options":
(https://github.com/bitcoin/bitcoin/pull/28802#discussion_r1384153284)
Renamed to `COMMAND_OPTIONS` and changed "subcommand" to "command" more generally.
(https://github.com/bitcoin/bitcoin/pull/28802#discussion_r1384153284)
Renamed to `COMMAND_OPTIONS` and changed "subcommand" to "command" more generally.
💬 TheBlueMatt commented on issue "Wallet Missing Balances/Unspent":
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1797031592)
Ah, okay, so what happened is two bugs and one need-package-relay issue:
The above snippet didn't work because of the bug you can see in the above `listtransactions` output: if a transaction spends from an address of ours to an address of ours its (correctly) listed twice, but both times with the output address, neither time with the input address, even though one listing is "send". That's a bug.
This did turn up a spending tx, but that tx was in the broader mempool because its parent didn
...
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1797031592)
Ah, okay, so what happened is two bugs and one need-package-relay issue:
The above snippet didn't work because of the bug you can see in the above `listtransactions` output: if a transaction spends from an address of ours to an address of ours its (correctly) listed twice, but both times with the output address, neither time with the input address, even though one listing is "send". That's a bug.
This did turn up a spending tx, but that tx was in the broader mempool because its parent didn
...
💬 achow101 commented on issue "Wallet Missing Balances/Unspent":
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1797041131)
> The above snippet didn't work because of the bug you can see in the above `listtransactions` output: if a transaction spends from an address of ours to an address of ours its (correctly) listed twice, but both times with the output address, neither time with the input address, even though one listing is "send". That's a bug.
It doesn't show input addresses since they don't exist (or something like that). However we do have the spent-by info so each "transaction" in `listtransactions` could
...
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1797041131)
> The above snippet didn't work because of the bug you can see in the above `listtransactions` output: if a transaction spends from an address of ours to an address of ours its (correctly) listed twice, but both times with the output address, neither time with the input address, even though one listing is "send". That's a bug.
It doesn't show input addresses since they don't exist (or something like that). However we do have the spent-by info so each "transaction" in `listtransactions` could
...
💬 TheBlueMatt commented on issue "Wallet Missing Balances/Unspent":
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1797050149)
> It doesn't show input addresses since they don't exist (or something like that). However we do have the spent-by info so each "transaction" in listtransactions could show that.
Right, then the "address" field should be skipped. A "send" entry is referring to the fact tat we spent some of our money, and generally we don't list an address, the address inclusion in a "send" entry that's unrelated to the "send" part of the transaction is...very confusing :)
> It only includes the utxo in the
...
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1797050149)
> It doesn't show input addresses since they don't exist (or something like that). However we do have the spent-by info so each "transaction" in listtransactions could show that.
Right, then the "address" field should be skipped. A "send" entry is referring to the fact tat we spent some of our money, and generally we don't list an address, the address inclusion in a "send" entry that's unrelated to the "send" part of the transaction is...very confusing :)
> It only includes the utxo in the
...
💬 DuneCruzade commented on issue "macos: dmg not working on macOS Sonoma (14.x)":
(https://github.com/bitcoin/bitcoin/issues/28767#issuecomment-1797086572)
[Captura de Tela 2023-11-06 às 21.33.58.png]The issue cannot be printed. There is no issue beyond the dmg file just does not run. Here there is a print of my os and chip.
Enviado com o e-mail seguro de [Proton Mail](https://proton.me/).
------- Original Message -------
Em quarta-feira, 1 de novembro de 2023 às 11:49, Hennadii Stepanov ***@***.***> escreveu:
> Does your issue look like [#15774 (comment)](https://github.com/bitcoin/bitcoin/issues/15774#issuecomment-548136595)?
>
> If not, plea
...
(https://github.com/bitcoin/bitcoin/issues/28767#issuecomment-1797086572)
[Captura de Tela 2023-11-06 às 21.33.58.png]The issue cannot be printed. There is no issue beyond the dmg file just does not run. Here there is a print of my os and chip.
Enviado com o e-mail seguro de [Proton Mail](https://proton.me/).
------- Original Message -------
Em quarta-feira, 1 de novembro de 2023 às 11:49, Hennadii Stepanov ***@***.***> escreveu:
> Does your issue look like [#15774 (comment)](https://github.com/bitcoin/bitcoin/issues/15774#issuecomment-548136595)?
>
> If not, plea
...
📝 ajtowns opened a pull request: "rpc: Add script verification flags to getdeploymentinfo"
(https://github.com/bitcoin/bitcoin/pull/28806)
Adds a `script_flags` field to the output of the `getdeploymentinfo` RPC that lists the flags selected by `GetBlockScriptFlags()`. This can be useful for seeing the detailed consequences of soft-fork activation behaviour, eg:
```sh
$ for a in 1 170060 227931 363725 388381 419328 481824 692261 709632; do echo -n "$a: "; bitcoin-cli getdeploymentinfo $(bitcoin-cli getblockhash $a) | jq -r .script_flags; done
1: P2SH,TAPROOT,WITNESS
170060:
227931: P2SH,TAPROOT,WITNESS
363725: DERSIG,P2SH,
...
(https://github.com/bitcoin/bitcoin/pull/28806)
Adds a `script_flags` field to the output of the `getdeploymentinfo` RPC that lists the flags selected by `GetBlockScriptFlags()`. This can be useful for seeing the detailed consequences of soft-fork activation behaviour, eg:
```sh
$ for a in 1 170060 227931 363725 388381 419328 481824 692261 709632; do echo -n "$a: "; bitcoin-cli getdeploymentinfo $(bitcoin-cli getblockhash $a) | jq -r .script_flags; done
1: P2SH,TAPROOT,WITNESS
170060:
227931: P2SH,TAPROOT,WITNESS
363725: DERSIG,P2SH,
...
💬 ajtowns commented on pull request "rpc: Add script verification flags to getdeploymentinfo":
(https://github.com/bitcoin/bitcoin/pull/28806#issuecomment-1797106931)
This patch has been included in bitcoin-inquisition for a few releases (https://github.com/bitcoin-inquisition/bitcoin/pull/5, https://github.com/bitcoin-inquisition/bitcoin/pull/15 and https://github.com/bitcoin-inquisition/bitcoin/pull/31). I used the same technique when in https://github.com/bitcoin/bitcoin/pull/23536#pullrequestreview-872777718 and found it helpful.
(https://github.com/bitcoin/bitcoin/pull/28806#issuecomment-1797106931)
This patch has been included in bitcoin-inquisition for a few releases (https://github.com/bitcoin-inquisition/bitcoin/pull/5, https://github.com/bitcoin-inquisition/bitcoin/pull/15 and https://github.com/bitcoin-inquisition/bitcoin/pull/31). I used the same technique when in https://github.com/bitcoin/bitcoin/pull/23536#pullrequestreview-872777718 and found it helpful.
⚠️ MarnixCroes opened an issue: "getaddrmaninfo RPC: add Transport v1/v2 to `tried` for ipv4 & ipv6"
(https://github.com/bitcoin/bitcoin/issues/28807)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Would be nice if the transport version is added to `getaddrmaninfo` RPC for ipv4 and ipv6, so the user can see how many Transport v1/v2 one's node has connected to.
current:
`getaddrmaninfo`
{
"ipv4": {
"new": x,
"tried": x,
"total": x
},
"ipv6": {
"new": x,
"tried": x,
"total": x
},
"onion": {
"new": x,
"tried": x,
"total"
...
(https://github.com/bitcoin/bitcoin/issues/28807)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Would be nice if the transport version is added to `getaddrmaninfo` RPC for ipv4 and ipv6, so the user can see how many Transport v1/v2 one's node has connected to.
current:
`getaddrmaninfo`
{
"ipv4": {
"new": x,
"tried": x,
"total": x
},
"ipv6": {
"new": x,
"tried": x,
"total": x
},
"onion": {
"new": x,
"tried": x,
"total"
...
💬 Sjors commented on pull request "Fix typos":
(https://github.com/bitcoin/bitcoin/pull/28605#issuecomment-1797121223)
Rebased to fix those two new typos.
(https://github.com/bitcoin/bitcoin/pull/28605#issuecomment-1797121223)
Rebased to fix those two new typos.
💬 Sjors commented on pull request "rpc: show P2(W)SH redeemScript in getrawtransaction #27637":
(https://github.com/bitcoin/bitcoin/pull/27638#discussion_r1384244572)
`redeemScrtipt` is a typo
(https://github.com/bitcoin/bitcoin/pull/27638#discussion_r1384244572)
`redeemScrtipt` is a typo
💬 Sjors commented on pull request "rpc: show P2(W)SH redeemScript in getrawtransaction #27637":
(https://github.com/bitcoin/bitcoin/pull/27638#issuecomment-1797145061)
Fixing the test is hopefully a matter of just adding the new field(s) to these tests.
Also make sure to [squash your commits](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits).
(https://github.com/bitcoin/bitcoin/pull/27638#issuecomment-1797145061)
Fixing the test is hopefully a matter of just adding the new field(s) to these tests.
Also make sure to [squash your commits](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits).
🤔 mzumsande reviewed a pull request: "Test: followups to #27823"
(https://github.com/bitcoin/bitcoin/pull/28612#pullrequestreview-1716628073)
I ran this locally a couple 100 times and the test failed for me maybe 1% of the time - haven't done any deeper analysis though.
(https://github.com/bitcoin/bitcoin/pull/28612#pullrequestreview-1716628073)
I ran this locally a couple 100 times and the test failed for me maybe 1% of the time - haven't done any deeper analysis though.
👍 pablomartin4btc approved a pull request: "Fix typos"
(https://github.com/bitcoin/bitcoin/pull/28605#pullrequestreview-1716628156)
re ACK 43de4d3630274e1287179c86896ed4c2d8b9eff4
(https://github.com/bitcoin/bitcoin/pull/28605#pullrequestreview-1716628156)
re ACK 43de4d3630274e1287179c86896ed4c2d8b9eff4
💬 mzumsande commented on issue "getaddrmaninfo RPC: add Transport v1/v2 to `tried` for ipv4 & ipv6":
(https://github.com/bitcoin/bitcoin/issues/28807#issuecomment-1797178738)
I think that this is not so straightforward because we don't save historic connection details in addrman (and I'm not sure if we want to start doing that). What we do save is the service flags , which could be dumped with the debug-only `getrawaddrman` rpc.
However, a BIP324 service flag for an addr in `tried` does not necessarily indicate that we connected to them via v2. The service flag may just be wrong (and we connected to them but downgraded the conection to v1), or maybe it is true now
...
(https://github.com/bitcoin/bitcoin/issues/28807#issuecomment-1797178738)
I think that this is not so straightforward because we don't save historic connection details in addrman (and I'm not sure if we want to start doing that). What we do save is the service flags , which could be dumped with the debug-only `getrawaddrman` rpc.
However, a BIP324 service flag for an addr in `tried` does not necessarily indicate that we connected to them via v2. The service flag may just be wrong (and we connected to them but downgraded the conection to v1), or maybe it is true now
...
💬 Sjors commented on pull request "validation: log which peer sent us a header":
(https://github.com/bitcoin/bitcoin/pull/27826#issuecomment-1797253502)
I get between 0 and 2 of these unsolicited blocks per day:
```
2023-11-07T02:19:56.507378Z Saw new header via unsolicited block hash=00000000000000000003310c8a9104bc38473171de3d2628ce608b7418384402 peer=0 peeraddr=x.x.x.x:8333
```
(https://github.com/bitcoin/bitcoin/pull/27826#issuecomment-1797253502)
I get between 0 and 2 of these unsolicited blocks per day:
```
2023-11-07T02:19:56.507378Z Saw new header via unsolicited block hash=00000000000000000003310c8a9104bc38473171de3d2628ce608b7418384402 peer=0 peeraddr=x.x.x.x:8333
```
📝 kevkevinpal opened a pull request: "refactor: Miniminer package linearization followups"
(https://github.com/bitcoin/bitcoin/pull/28808)
### Motivation
In https://github.com/bitcoin/bitcoin/pull/28762 there were some post merge comments which are being addressed in this PR with the following commits
### [8d4c46f](https://github.com/kevkevinpal/bitcoin/pull/5/commits/8d4c46f54d10fb67d20d7a9a6afa37ecfd2bdc18) Reorganizing `MiniMinerMempoolEntry` to match the order we have elsewhere
* https://github.com/bitcoin/bitcoin/pull/28762#discussion_r1381775670
### [7505ec2](https://github.com/kevkevinpal/bitcoin/pull/5/commits/7505e
...
(https://github.com/bitcoin/bitcoin/pull/28808)
### Motivation
In https://github.com/bitcoin/bitcoin/pull/28762 there were some post merge comments which are being addressed in this PR with the following commits
### [8d4c46f](https://github.com/kevkevinpal/bitcoin/pull/5/commits/8d4c46f54d10fb67d20d7a9a6afa37ecfd2bdc18) Reorganizing `MiniMinerMempoolEntry` to match the order we have elsewhere
* https://github.com/bitcoin/bitcoin/pull/28762#discussion_r1381775670
### [7505ec2](https://github.com/kevkevinpal/bitcoin/pull/5/commits/7505e
...
🤔 cacrowley reviewed a pull request: "bugfix: Make `CCheckQueue` RAII-styled (attempt 2)"
(https://github.com/bitcoin/bitcoin/pull/26762#pullrequestreview-1716829393)
#26762
(https://github.com/bitcoin/bitcoin/pull/26762#pullrequestreview-1716829393)
#26762
💬 Sjors commented on pull request "Show transactions as not fully confirmed during background validation":
(https://github.com/bitcoin/bitcoin/pull/28616#discussion_r1384403599)
82f19c7e97281bbd66a25e53f30fe2f80a4f9d11: I found this while loading an existing wallet into a fresh (signet) node, while it was loading doing the background sync. That's not a very common scenario, so I haven't bothered looking into deeper causes...
(https://github.com/bitcoin/bitcoin/pull/28616#discussion_r1384403599)
82f19c7e97281bbd66a25e53f30fe2f80a4f9d11: I found this while loading an existing wallet into a fresh (signet) node, while it was loading doing the background sync. That's not a very common scenario, so I haven't bothered looking into deeper causes...
💬 Sjors commented on pull request "Show transactions as not fully confirmed during background validation":
(https://github.com/bitcoin/bitcoin/pull/28616#discussion_r1384405176)
82f19c7e97281bbd66a25e53f30fe2f80a4f9d11: such a test seems hard to write without a (background sync aware) `stopatheight` RPC. So far I just tested manually that the value is correct: absent before loading a snapshot, `true` while background sync is below it, `false` once background sync passed the confirmation height.
(https://github.com/bitcoin/bitcoin/pull/28616#discussion_r1384405176)
82f19c7e97281bbd66a25e53f30fe2f80a4f9d11: such a test seems hard to write without a (background sync aware) `stopatheight` RPC. So far I just tested manually that the value is correct: absent before loading a snapshot, `true` while background sync is below it, `false` once background sync passed the confirmation height.