💬 fanquake commented on issue "./contrib/guix/guix-build does not work on riscv64":
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845195847)
> Are you sure, because if new guix features are available in the the time-machine, then bug fixes should be as well?
Yea, new Guix features could be compiled/available inside the time-machine, but if you can't even run a time-machine, because your guix 1.4 binary can't launch a container, you are still stuck.
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845195847)
> Are you sure, because if new guix features are available in the the time-machine, then bug fixes should be as well?
Yea, new Guix features could be compiled/available inside the time-machine, but if you can't even run a time-machine, because your guix 1.4 binary can't launch a container, you are still stuck.
💬 Sjors commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418839247)
You could create a pre-v22 wallet, upgrade to master (which won't add the `tr()` descriptor) and then continue the test.
Although I don't think we care that deeply about downgrading that far, testing a wallet without a `tr()` descriptor is useful - for followup PR's that enable adding that desciptor.
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418839247)
You could create a pre-v22 wallet, upgrade to master (which won't add the `tr()` descriptor) and then continue the test.
Although I don't think we care that deeply about downgrading that far, testing a wallet without a `tr()` descriptor is useful - for followup PR's that enable adding that desciptor.
💬 maflcko commented on issue "./contrib/guix/guix-build does not work on riscv64":
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845200103)
Ah ok. I forgot to clarify, the time-machine itself is working (so far). For example:
```
# guix time-machine --commit=77386bdbfe6b0c649c05ab37f08051d1ab3e5074 -- shell --pure hello
accepted connection from pid 3274252, user root
hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables.
# hello
Hello, world!
# exit
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845200103)
Ah ok. I forgot to clarify, the time-machine itself is working (so far). For example:
```
# guix time-machine --commit=77386bdbfe6b0c649c05ab37f08051d1ab3e5074 -- shell --pure hello
accepted connection from pid 3274252, user root
hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables.
# hello
Hello, world!
# exit
💬 fanquake commented on issue "./contrib/guix/guix-build does not work on riscv64":
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845213666)
Ok, so then this seems to be a bug with just the usage `--container`, (on riscv64 hardware?) that likely still exists in Guix. We should report the minimal reproducer upstream.
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845213666)
Ok, so then this seems to be a bug with just the usage `--container`, (on riscv64 hardware?) that likely still exists in Guix. We should report the minimal reproducer upstream.
📝 fanquake opened a pull request: "doc: add historical release notes for 26.0"
(https://github.com/bitcoin/bitcoin/pull/29023)
Bins are now up, used for GH release etc.
(https://github.com/bitcoin/bitcoin/pull/29023)
Bins are now up, used for GH release etc.
💬 kristapsk commented on pull request "wallet: No BDB creation, unless -deprecatedrpc=create_bdb":
(https://github.com/bitcoin/bitcoin/pull/28597#issuecomment-1845254045)
This should have had release notes.
(https://github.com/bitcoin/bitcoin/pull/28597#issuecomment-1845254045)
This should have had release notes.
💬 sgs2018 commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1845257078)
maybe is hard to define spam ,
it is very fuzzy .
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1845257078)
maybe is hard to define spam ,
it is very fuzzy .
💬 willcl-ark commented on pull request "doc: add historical release notes for 26.0":
(https://github.com/bitcoin/bitcoin/pull/29023#issuecomment-1845259000)
We might want to add a release note for `-deprecatedrpc=create_bdb` as per : https://github.com/bitcoin/bitcoin/pull/28597#issuecomment-1845254045
(https://github.com/bitcoin/bitcoin/pull/29023#issuecomment-1845259000)
We might want to add a release note for `-deprecatedrpc=create_bdb` as per : https://github.com/bitcoin/bitcoin/pull/28597#issuecomment-1845254045
⚠️ FacehuggerCZ opened an issue: "Obscure problem with sent transactions and wallet balance"
(https://github.com/bitcoin/bitcoin/issues/29024)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Hello,
I need help explaining this problem:
...
(https://github.com/bitcoin/bitcoin/issues/29024)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Hello,
I need help explaining this problem:
...
💬 maflcko commented on issue "Obscure problem with sent transactions and wallet balance":
(https://github.com/bitcoin/bitcoin/issues/29024#issuecomment-1845296159)
A transaction may have a change output, if the amounts of all input coins is larger than the transaction fee and the transaction recipient outputs.
(https://github.com/bitcoin/bitcoin/issues/29024#issuecomment-1845296159)
A transaction may have a change output, if the amounts of all input coins is larger than the transaction fee and the transaction recipient outputs.
💬 MarnixCroes commented on issue "Obscure problem with sent transactions and wallet balance":
(https://github.com/bitcoin/bitcoin/issues/29024#issuecomment-1845296907)
@FacehuggerCZ
In Bitcoin Core the outgoing amount of a transaction is the amount you entered to send + mining fee.
So that's why you see on an explorer that the address received 0.1, but the outgoing tx amount in Bitcoin core is 0.10061201.
0.1 plus the fee add up to the tx outgoing amount.
The second questions "What are these addresses", those are the change addresses. It's how Bitcoin work
...
(https://github.com/bitcoin/bitcoin/issues/29024#issuecomment-1845296907)
@FacehuggerCZ
In Bitcoin Core the outgoing amount of a transaction is the amount you entered to send + mining fee.
So that's why you see on an explorer that the address received 0.1, but the outgoing tx amount in Bitcoin core is 0.10061201.
0.1 plus the fee add up to the tx outgoing amount.
The second questions "What are these addresses", those are the change addresses. It's how Bitcoin work
...
💬 maflcko commented on pull request "wallet: No BDB creation, unless -deprecatedrpc=create_bdb":
(https://github.com/bitcoin/bitcoin/pull/28597#issuecomment-1845299642)
> This should have had release notes.
A label was added after merge, but it looks like no one went through those. Currently there are 4 tagged: https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+release+note%22+is%3Aclosed
(https://github.com/bitcoin/bitcoin/pull/28597#issuecomment-1845299642)
> This should have had release notes.
A label was added after merge, but it looks like no one went through those. Currently there are 4 tagged: https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+release+note%22+is%3Aclosed
💬 Retropex commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1845301063)
The problem is that they use a diverted means to include data instead of using `OP_RETURN` which has been more or less adapted for this, in particular by not bloating the UTXOs set, that they have an unfair fee reduction compared to `OP_RETURN` and that they unbalance the incentives of miners.
Miners could, for example, start creating this kind of tx (BRC-20) to get richer than it will by mining normal financial txs.
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1845301063)
The problem is that they use a diverted means to include data instead of using `OP_RETURN` which has been more or less adapted for this, in particular by not bloating the UTXOs set, that they have an unfair fee reduction compared to `OP_RETURN` and that they unbalance the incentives of miners.
Miners could, for example, start creating this kind of tx (BRC-20) to get richer than it will by mining normal financial txs.
💬 maflcko commented on issue "Obscure problem with sent transactions and wallet balance":
(https://github.com/bitcoin/bitcoin/issues/29024#issuecomment-1845308131)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or any other place that you feel is well suited.
(https://github.com/bitcoin/bitcoin/issues/29024#issuecomment-1845308131)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or any other place that you feel is well suited.
💬 fanquake commented on pull request "doc: add historical release notes for 26.0":
(https://github.com/bitcoin/bitcoin/pull/29023#issuecomment-1845335433)
Hmm. Looks like a few things [missed out on being added](https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+release+note%22+). Generally we don't change the release notes after they've been finalized, and any updates we make here, wont be reflected on the website, in the 26.x branch, on the mailing list etc, but it might still be worth doing.
(https://github.com/bitcoin/bitcoin/pull/29023#issuecomment-1845335433)
Hmm. Looks like a few things [missed out on being added](https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+release+note%22+). Generally we don't change the release notes after they've been finalized, and any updates we make here, wont be reflected on the website, in the 26.x branch, on the mailing list etc, but it might still be worth doing.
💬 fanquake commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#issuecomment-1845335825)
Removing label, as this got a release note.
(https://github.com/bitcoin/bitcoin/pull/28331#issuecomment-1845335825)
Removing label, as this got a release note.
🤔 Sjors reviewed a pull request: "wallet: Have the wallet store the key for automatically generated descriptors"
(https://github.com/bitcoin/bitcoin/pull/26728#pullrequestreview-1770044461)
Mostly happy with a86756aed266a1c7569dc3849f66f468f3810821.
Still need to re-review ea7a61ca94cc0d59cfe25307cd60fcda2aedec5f.
(https://github.com/bitcoin/bitcoin/pull/26728#pullrequestreview-1770044461)
Mostly happy with a86756aed266a1c7569dc3849f66f468f3810821.
Still need to re-review ea7a61ca94cc0d59cfe25307cd60fcda2aedec5f.
💬 Sjors commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418907338)
e67898f47152b756acc7ccafb654e2600b0e7a03 nit: could be its own commit?
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418907338)
e67898f47152b756acc7ccafb654e2600b0e7a03 nit: could be its own commit?
💬 Sjors commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418884402)
e491e5c4e6eb2f9b9ec53f4c2df602a755178726: could make it more clear that this only needs to happen for _one_ descriptor: `if (!wallet_key && …`
Additionally, either here or elsewhere, it's useful to clarify the following:
```cpp
// Although at this point in the loading process we can't tell if a descriptor is active,
// checking inactive descriptors is necessary in any case. The private key for the active
// wallet master extended public key will initially be found in all active descript
...
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418884402)
e491e5c4e6eb2f9b9ec53f4c2df602a755178726: could make it more clear that this only needs to happen for _one_ descriptor: `if (!wallet_key && …`
Additionally, either here or elsewhere, it's useful to clarify the following:
```cpp
// Although at this point in the loading process we can't tell if a descriptor is active,
// checking inactive descriptors is necessary in any case. The private key for the active
// wallet master extended public key will initially be found in all active descript
...
💬 Sjors commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418940623)
a5ba1d83827475ef3f8f3851733007db5b8dc848: not a fan of touching legacy wallets even in the slightest if we don't have to… in that respect I prefer fca4584ad3.
It seems contradictory to the fact that we _always_ generate the global hd key field when migrating a legacy wallet, whether it was newly created or not. We _could_ set this field when creating a legacy wallet, but we (gladly) choose not to. It wouldn't do anything useful and would suffer from the same downgrade->encrypt->upgrade incorr
...
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1418940623)
a5ba1d83827475ef3f8f3851733007db5b8dc848: not a fan of touching legacy wallets even in the slightest if we don't have to… in that respect I prefer fca4584ad3.
It seems contradictory to the fact that we _always_ generate the global hd key field when migrating a legacy wallet, whether it was newly created or not. We _could_ set this field when creating a legacy wallet, but we (gladly) choose not to. It wouldn't do anything useful and would suffer from the same downgrade->encrypt->upgrade incorr
...