Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 achow101 commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1383975379)
In 003efbbe45079c4416810a025b2bc372559dff15 "test: Add tests for wallet mempool conflicts"

nit: No need to make another wallet for the receiver, just use the default wallet.
💬 achow101 commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1384035046)
In 003efbbe45079c4416810a025b2bc372559dff15 "test: Add tests for wallet mempool conflicts"

This isn't actually necessary since `listunspent` has these fields already and the extra ones are just ignored.
💬 achow101 commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1384024252)
In 003efbbe45079c4416810a025b2bc372559dff15 "test: Add tests for wallet mempool conflicts"

This can be compressed into one line using the `send` RPC.

```suggestion
raw_tx1 = alice.send(outputs=[{bob.getnewaddress(): 24.9999}], inputs=[unspents[0]], add_to_wallet=False)["hex"]
```
💬 achow101 commented on pull request "Test: followups to #27823":
(https://github.com/bitcoin/bitcoin/pull/28612#issuecomment-1796622219)
ACK 5ab6419f380cc0a8cde78b125f3eeee5fcba43ae
💬 achow101 commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1384073170)
In eeee4a5779ea20d859cff2e411ad46dd52384f1d "mempool: persist with XOR"

Closing and reopening the file once we have the xor seems kinda clunky. Why not have a function on `CAutoFile` that lets us set the xor key after the fact?
achow101 closed an issue: "Extend feature_init.py file perturbations"
(https://github.com/bitcoin/bitcoin/issues/28603)
🚀 achow101 merged a pull request: "Test: followups to #27823"
(https://github.com/bitcoin/bitcoin/pull/28612)
📝 mzumsande opened a pull request: "test: Make existing functional tests compatible with --v2transport"
(https://github.com/bitcoin/bitcoin/pull/28805)
This makes the functional test suite compatible with BIP324, so that
`python3 test_runner.py --v2transport`
should succeed (currently, 12 tests fail for me on master).
Includes two commits by TheStack I found in an old discussion https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1326714164

Note that even thought all tests should pass, the python `p2p.py` module will only do v2 connections only after the merge of #24748.
Some of the fixed tests were added with `--v2transport` to t
...
💬 mzumsande commented on pull request "test: Make existing functional tests compatible with --v2transport":
(https://github.com/bitcoin/bitcoin/pull/28805#issuecomment-1796828203)
FYI @stratospher @TheStack
💬 fanquake commented on pull request "snapshots: don't core dump when running -checkblockindex after `loadtxoutset`":
(https://github.com/bitcoin/bitcoin/pull/28791#issuecomment-1796851218)
cc @pablomartin4btc
💬 TheBlueMatt commented on issue "Wallet Missing Balances/Unspent":
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-1796963490)
Nothing has ever been imported into this wallet, its pretty much bog-standard, except that transactions are built with the raw transaction interface (eg the linked transaction, which spends my money back to myself and adds another input, in this case a lightning anchor). Nothing touching this wallet uses `lockunspent`.
💬 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.
💬 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.
💬 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
...
💬 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
...
💬 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
...
💬 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
...
📝 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,
...
💬 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.
⚠️ 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"
...