Bitcoin Core Github
43 subscribers
123K links
Download Telegram
💬 hebasto commented on pull request "ci, iwyu: Update mappings":
(https://github.com/bitcoin/bitcoin/pull/27710#issuecomment-1569886912)
@fanquake
> ... looks like it's now just producing include suggestions that are incorrect/we don't want for the test code.

Can you point out these suggestions please? Asking because I've just skimmed suggestions for `test/*_tests.cpp` files again and I can see none of them in comparison to the master branch.
👍 dergoegge approved a pull request: "fuzz: Avoid timeout in utxo_total_supply"
(https://github.com/bitcoin/bitcoin/pull/27780#pullrequestreview-1452773063)
ACK fafb4da121b19ba1b7bd173e25651c64d1982fb4

Verified that the target still finds the CVE with the patch applied.
🚀 fanquake merged a pull request: "fuzz: fix wallet notifications.cpp"
(https://github.com/bitcoin/bitcoin/pull/27786)
👍 dergoegge approved a pull request: "doc: Remove unused NO_BLOOM_VERSION constant"
(https://github.com/bitcoin/bitcoin/pull/27657#pullrequestreview-1452792101)
ACK facbcd3742313625137907276628267ad90eee01
💬 willcl-ark commented on issue "bitcoind hangs waiting for `g_requests.empty()`":
(https://github.com/bitcoin/bitcoin/issues/27722#issuecomment-1569922589)
> @willcl-ark can you find what libevent version you're using?

I am using libevent 2.1.12 (like TheStack)
🚀 fanquake merged a pull request: "fuzz: Avoid timeout in utxo_total_supply"
(https://github.com/bitcoin/bitcoin/pull/27780)
💬 alexanderwiederin commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1211504043)
@jamesob line 1 (`#!/usr/bin/env bash`) sets the interpreter to Bash regardless of what the system default is.

@MarcoFalke you were right! macOS comes with an outdated version of bash (`3.2.57`). I have updated to `5.2.15`. Script runs like a charm now.

Thanks for the help!
🚀 fanquake merged a pull request: "doc: Remove unused NO_BLOOM_VERSION constant"
(https://github.com/bitcoin/bitcoin/pull/27657)
📝 stickies-v opened a pull request: "ci: label docker images and prune dangling images selectively"
(https://github.com/bitcoin/bitcoin/pull/27793)
Follow-up from https://github.com/bitcoin/bitcoin/pull/27777#discussion_r1210209382.

Labeling the docker images produced by the CI allows us/the user to apply batch operations to all images (including dangling ones) produced by the ci without affecting other, non-bitcoin-ci images. With labeling, we can safely always prune dangling bitcoin-ci-test images without checking for `RESTART_CI_DOCKER_BEFORE_RUN`, which we enable on our persistent runners.
💬 stickies-v commented on pull request "ci: Prune dangling images on RESTART_CI_DOCKER_BEFORE_RUN":
(https://github.com/bitcoin/bitcoin/pull/27777#discussion_r1211510058)
Done in https://github.com/bitcoin/bitcoin/pull/27793
💬 MarcoFalke commented on issue "configure: error: cannot figure out how to use std::filesystem":
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1569969718)
@wangtao19911111 The minimum required version is installed by default with `g++`, if you use the latest LTS release of your operating system.
⚠️ torkelrogstad opened an issue: "Indicate RBF replaceability, also after transactions have been confirmed "
(https://github.com/bitcoin/bitcoin/issues/27794)
### Please describe the feature you'd like to see added.

Wallet transactions retrieved with RPC should indicate RBF replaceability, also after they are confirmed.

### Is your feature related to a problem, if so please describe it.

Currently, RBF replaceability is set to a hard 'no' if the transaction has any confirmations:

https://github.com/bitcoin/bitcoin/blob/30d6c7d8c0441956fac37252921c795569002d07/src/wallet/rpc/transactions.cpp#L46-L55

This makes it hard to figure out if this tra
...
🤔 jonatack reviewed a pull request: "rpc: remove deprecated "warning" field from {create,load,restore,unload}wallet"
(https://github.com/bitcoin/bitcoin/pull/27757#pullrequestreview-1452883500)
Approach ACK. Did this a few weeks back in https://github.com/bitcoin/bitcoin/compare/master...jonatack:bitcoin:2023-05-remove-deprecated-warning-fields and the diff is the same except as where noted below. Feel free to pull in 39f14968b6f6dd6151f4fbb05c8fe385cff9a15e in that branch if you think it's worthwhile.
💬 jonatack commented on pull request "rpc: remove deprecated "warning" field from {create,load,restore,unload}wallet":
(https://github.com/bitcoin/bitcoin/pull/27757#discussion_r1211528780)
Suggestions/fixups

- s/can be accessed/is provided/

- missing comma before "which"

- perhaps mention when the "warnings" field was added

```suggestion
accessed with the "warnings" field added in v25.0, which returns a JSON array of strings.
```

s/single string field/"warning" string field/ seems clearer
💬 jonatack commented on pull request "rpc: remove deprecated "warning" field from {create,load,restore,unload}wallet":
(https://github.com/bitcoin/bitcoin/pull/27757#discussion_r1211523574)
See the diff [here](https://github.com/jonatack/bitcoin/commit/56ec947e698a8d73d147c0a28130a67326678541#diff-7b13e03c457b62251e26d2c366180c262a3fe9da45995277a9a9c1c5abbaae6cR484) in https://github.com/jonatack/bitcoin/commits/2023-05-remove-deprecated-warning-fields making the same change a few weeks ago. I moved the move back to its original position before the deprecation.
⚠️ MatthewLM opened an issue: "Remove Ambiguity of Script ASM Hex and Decimal Integer Representations"
(https://github.com/bitcoin/bitcoin/issues/27795)
### Please describe the feature you'd like to see added.

Distinguish between decimal and hex integers in the script ASM to avoid ambiguity. Hex integers/data can be prefixed with `0x` to avoid ambiguity.

### Is your feature related to a problem, if so please describe it.

When scripts are decoded into ASM, two different integers can be displayed identically, with one as hex and the other as decimal. `decodescript 0511121314150457c74942` produces ASM of `1112131415 1112131415` , despite the int
...
💬 MarcoFalke commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1569997837)
A confirmed transaction can not be in the mempool, so can not be replaced in the mempool, whether with bip125 or not.

I don't see a use case to run the bip125 signal logic on confirmed transactions, and it shouldn't be hard to run it yourself if you just want to do it despite no use case?
💬 torkelrogstad commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570021896)
I have a use case for this:

I'm developing a service that receives bitcoin, with a Bitcoin Core wallet as the underlying wallet. When a transaction comes in I check whether or not it is BIP125 replaceable. If it is _not_, I run it through certain actions when first seeing it in the mempool. Upon receiving a confirmed transaction I need to run the transaction through those actions, if that has not already happened when seeing it in the mempool (i.e. for confirmed transactions that _was_ repla
...
🤔 jonatack reviewed a pull request: "doc: Tor: fix link & generalize onion getnodeaddresses RPC"
(https://github.com/bitcoin/bitcoin/pull/27719#pullrequestreview-1452944104)
Concept ACK
💬 jonatack commented on pull request "doc: Tor: fix link & generalize onion getnodeaddresses RPC":
(https://github.com/bitcoin/bitcoin/pull/27719#discussion_r1211576918)
This was done because there are many peers returned by `./src/bitcoin-cli getnodeaddresses 0 onion`, and at the time, only a few hundred I2P ones and a handful of CJDNS ones.

Perhaps it would be best to make the I2P doc like the Tor doc here, or combine both approaches for all three docs (Tor, I2P, CJDNS), i.e. something like:

```markdown
To fetch a number of onion peers that your node knows, for example 7 addresses, run
`bitcoin-cli getnodeaddresses 7 onion`. You may also run
`bitcoin-
...