🚀 fanquake merged a pull request: "fuzz: Avoid timeout in utxo_total_supply"
(https://github.com/bitcoin/bitcoin/pull/27780)
(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!
(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)
(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.
(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
(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.
(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
...
(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.
(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
(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.
(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
...
(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?
(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
...
(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
(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-
...
(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-
...
💬 jonatack commented on pull request "doc: Tor: fix link & generalize onion getnodeaddresses RPC":
(https://github.com/bitcoin/bitcoin/pull/27719#discussion_r1211560160)
Good catch on the obsolete link. The proposed new link doesn't seem relevant, however. I didn't immediately see a good replacement. For less future maintenance, maybe just drop this sentence from the doc.
(https://github.com/bitcoin/bitcoin/pull/27719#discussion_r1211560160)
Good catch on the obsolete link. The proposed new link doesn't seem relevant, however. I didn't immediately see a good replacement. For less future maintenance, maybe just drop this sentence from the doc.
💬 ryanofsky commented on pull request "RPC: Accept options as named-only parameters":
(https://github.com/bitcoin/bitcoin/pull/26485#issuecomment-1570046217)
> But also we should probably figure out a better way to deal with the conversions in general.
I think it was an unfortunate decision to hardcode parameter information into the client, and could think of various alternatives.
One alternative could be to avoid the need to process arguments on the client side at all and and add a new `exec` RPC method that takes an `args` array of strings and an optional `stdin` string parameter to figure out on the server side where there is full type infor
...
(https://github.com/bitcoin/bitcoin/pull/26485#issuecomment-1570046217)
> But also we should probably figure out a better way to deal with the conversions in general.
I think it was an unfortunate decision to hardcode parameter information into the client, and could think of various alternatives.
One alternative could be to avoid the need to process arguments on the client side at all and and add a new `exec` RPC method that takes an `args` array of strings and an optional `stdin` string parameter to figure out on the server side where there is full type infor
...
💬 MarcoFalke commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570106061)
I didn't get the use case. You can simply skip your action that checks the rbf status when the transaction is confirmed.
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570106061)
I didn't get the use case. You can simply skip your action that checks the rbf status when the transaction is confirmed.
💬 torkelrogstad commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570137331)
I have a set of actions S, that every transaction needs to go through.
If a transaction T does _not_ signal BIP125-replaceability, I want to run S when T is in the mempool. If T _does_ signal BIP125-replaceability, I want to run S when T is confirmed.
Currently it is not possible to find out (through the RPC interface, at least) whether or not T signals BIP125-replaceability once it is confirmed.
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570137331)
I have a set of actions S, that every transaction needs to go through.
If a transaction T does _not_ signal BIP125-replaceability, I want to run S when T is in the mempool. If T _does_ signal BIP125-replaceability, I want to run S when T is confirmed.
Currently it is not possible to find out (through the RPC interface, at least) whether or not T signals BIP125-replaceability once it is confirmed.
💬 sipa commented on issue "Indicate RBF replaceability, also after transactions have been confirmed ":
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570148419)
The `bip125-replaceable` field does not indicate whether the transaction itself signals replaceability, but whether replaceability rules currently apply to it. This is a function of both the transaction itself, and any unconfirmed ancestors it may have. As a result, it's expected to change over time.
And for confirmed transactions, the answer to the question "do replaceability rules currently apply to it?" is trivially no.
(https://github.com/bitcoin/bitcoin/issues/27794#issuecomment-1570148419)
The `bip125-replaceable` field does not indicate whether the transaction itself signals replaceability, but whether replaceability rules currently apply to it. This is a function of both the transaction itself, and any unconfirmed ancestors it may have. As a result, it's expected to change over time.
And for confirmed transactions, the answer to the question "do replaceability rules currently apply to it?" is trivially no.