💬 hebasto commented on issue "configure: error: cannot figure out how to use std::filesystem":
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442074169)
> Add to docs ?
Probably, it does not worth, considering that Ubuntu 18 is about to [reach](https://wiki.ubuntu.com/Releases) "End of Standard Support" soon.
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442074169)
> Add to docs ?
Probably, it does not worth, considering that Ubuntu 18 is about to [reach](https://wiki.ubuntu.com/Releases) "End of Standard Support" soon.
✅ pinheadmz closed an issue: "configure: error: cannot figure out how to use std::filesystem"
(https://github.com/bitcoin/bitcoin/issues/27148)
(https://github.com/bitcoin/bitcoin/issues/27148)
💬 MarcoFalke commented on issue "configure: error: cannot figure out how to use std::filesystem":
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442077762)
See also https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md#dependencies:
* https://github.com/bitcoin/bitcoin/pull/24164
* https://github.com/bitcoin/bitcoin/pull/23060
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442077762)
See also https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md#dependencies:
* https://github.com/bitcoin/bitcoin/pull/24164
* https://github.com/bitcoin/bitcoin/pull/23060
💬 achow101 commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442098740)
> looks outdated.
Updated the description
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442098740)
> looks outdated.
Updated the description
💬 achow101 commented on pull request "rpc: Add a parameter to sendrawtransaction which sets a maximum value for unspendable outputs.":
(https://github.com/bitcoin/bitcoin/pull/25943#issuecomment-1442102227)
re-ACK 7013da07fbcddb04abae9759767a9419ab90444c
(https://github.com/bitcoin/bitcoin/pull/25943#issuecomment-1442102227)
re-ACK 7013da07fbcddb04abae9759767a9419ab90444c
💬 petertodd commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442123316)
@Sjors
> The rule would then be that a [OpenTimestamps] timestamp must exist with a median time past before that date.
The median time past is *not* the correct way to interpret a Bitcoin block time for the purpose of timestamping. The problem is median time past is in the past; a timestamp proof is a **stronger** statement if it's backdated, not weaker.
Instead, the OpenTimestamps client rounds off timestamps to the nearest day in the local timezone to give users the right impression
...
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442123316)
@Sjors
> The rule would then be that a [OpenTimestamps] timestamp must exist with a median time past before that date.
The median time past is *not* the correct way to interpret a Bitcoin block time for the purpose of timestamping. The problem is median time past is in the past; a timestamp proof is a **stronger** statement if it's backdated, not weaker.
Instead, the OpenTimestamps client rounds off timestamps to the nearest day in the local timezone to give users the right impression
...
💬 Sjors commented on pull request "wallet: skip R-value signature grinding for external signers":
(https://github.com/bitcoin/bitcoin/pull/26032#discussion_r1116021694)
Good point, I introduced a `const bool` in both places where it's used in a loop.
(https://github.com/bitcoin/bitcoin/pull/26032#discussion_r1116021694)
Good point, I introduced a `const bool` in both places where it's used in a loop.
💬 jamesob commented on pull request "fix: contrib: allow multi-sig binary verification":
(https://github.com/bitcoin/bitcoin/pull/23020#issuecomment-1442170863)
I've rebased/squashed/simplified the script here to
- incorporate the removal of builder keys from this repo, and
- remove support for single-sig release signing (users are referred to old versions of this script for that).
(https://github.com/bitcoin/bitcoin/pull/23020#issuecomment-1442170863)
I've rebased/squashed/simplified the script here to
- incorporate the removal of builder keys from this repo, and
- remove support for single-sig release signing (users are referred to old versions of this script for that).
💬 Sjors commented on pull request "wallet: skip R-value signature grinding for external signers":
(https://github.com/bitcoin/bitcoin/pull/26032#discussion_r1116029872)
Though perhaps it's overkill, because `IsWalletFlagSet` is just `m_wallet_flags & flag`.
(https://github.com/bitcoin/bitcoin/pull/26032#discussion_r1116029872)
Though perhaps it's overkill, because `IsWalletFlagSet` is just `m_wallet_flags & flag`.
✅ MarcoFalke closed a pull request: "refactor: Avoid UniValue copies"
(https://github.com/bitcoin/bitcoin/pull/25429)
(https://github.com/bitcoin/bitcoin/pull/25429)
💬 Sjors commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442240383)
@petertodd in practice things should be fine if there's at least a few days between when a maintainer last merges something and the date we put in a CSV to track when they are no longer authorised. Maybe a bit more if there's a congestion delay in when the timestamp gets included. In the case of Wladimir there was a full year between his last merge and revoking his key.
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442240383)
@petertodd in practice things should be fine if there's at least a few days between when a maintainer last merges something and the date we put in a CSV to track when they are no longer authorised. Maybe a bit more if there's a congestion delay in when the timestamp gets included. In the case of Wladimir there was a full year between his last merge and revoking his key.
💬 Sjors commented on pull request "assumeutxo: keep cache when flushing snapshot (#17487 followup)":
(https://github.com/bitcoin/bitcoin/pull/27008#issuecomment-1442246762)
re-utACK 937016b1917a0a07fa579c96fc797237f5027cd1
(https://github.com/bitcoin/bitcoin/pull/27008#issuecomment-1442246762)
re-utACK 937016b1917a0a07fa579c96fc797237f5027cd1
💬 Sjors commented on pull request "assumeutxo: keep cache when flushing snapshot (#17487 followup)":
(https://github.com/bitcoin/bitcoin/pull/27008#discussion_r1116102760)
Same question about `AbortNode` vs. `error` though.
(https://github.com/bitcoin/bitcoin/pull/27008#discussion_r1116102760)
Same question about `AbortNode` vs. `error` though.
💬 Sjors commented on pull request "assumeutxo: background validation completion":
(https://github.com/bitcoin/bitcoin/pull/25740#issuecomment-1442260424)
I'd like to test this with `loadtxoutset`. I wonder if I just cherry-pick a few things from #15606 to do that myself, or a more rigorous rebase is needed...
(https://github.com/bitcoin/bitcoin/pull/25740#issuecomment-1442260424)
I'd like to test this with `loadtxoutset`. I wonder if I just cherry-pick a few things from #15606 to do that myself, or a more rigorous rebase is needed...
💬 furszy commented on pull request "wallet: skip R-value signature grinding for external signers":
(https://github.com/bitcoin/bitcoin/pull/26032#discussion_r1116121819)
yeah, I think that the only place that worth is inside `AvailableCoins`. And not only because of the overhead that introduces (it's one "AND" operation on an atomic variable per wallet UTXO), I was more thinking about the code structure and what we should do if we want to decrease the `cs_wallet` lock contention there.
still, this is still a tiny nit from a person that is thinking about future stuff.
(https://github.com/bitcoin/bitcoin/pull/26032#discussion_r1116121819)
yeah, I think that the only place that worth is inside `AvailableCoins`. And not only because of the overhead that introduces (it's one "AND" operation on an atomic variable per wallet UTXO), I was more thinking about the code structure and what we should do if we want to decrease the `cs_wallet` lock contention there.
still, this is still a tiny nit from a person that is thinking about future stuff.
✅ achow101 closed an issue: "rpc: prevent non-zero value OP_RETURN outputs in sendrawtransaction"
(https://github.com/bitcoin/bitcoin/issues/25899)
(https://github.com/bitcoin/bitcoin/issues/25899)
🚀 achow101 merged a pull request: "rpc: Add a parameter to sendrawtransaction which sets a maximum value for unspendable outputs."
(https://github.com/bitcoin/bitcoin/pull/25943)
(https://github.com/bitcoin/bitcoin/pull/25943)
💬 petertodd commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442293610)
> @petertodd in practice things should be fine if there's at least a few days between when a maintainer last merges something and the date we put in a CSV to track when they are no longer authorised. Maybe a bit more if there's a congestion delay in when the timestamp gets included. In the case of Wladimir there was a full year between his last merge and revoking his key.
My comment is about what standard an automated tool should apply. Obviously, if some humans are looking at it and manually
...
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442293610)
> @petertodd in practice things should be fine if there's at least a few days between when a maintainer last merges something and the date we put in a CSV to track when they are no longer authorised. Maybe a bit more if there's a congestion delay in when the timestamp gets included. In the case of Wladimir there was a full year between his last merge and revoking his key.
My comment is about what standard an automated tool should apply. Obviously, if some humans are looking at it and manually
...
💬 Sjors commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1116158372)
I find the explanation in the function body more clear. Maybe say:
```md
// Because we expect to have received the headers for the IBD chain
// contents before receiving blocks, when the (shared) block manager
// doesn't include a header for this block, it must go to
// to the snapshot chain.
```
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1116158372)
I find the explanation in the function body more clear. Maybe say:
```md
// Because we expect to have received the headers for the IBD chain
// contents before receiving blocks, when the (shared) block manager
// doesn't include a header for this block, it must go to
// to the snapshot chain.
```
💬 Sjors commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1116169293)
IIUC: maybe clarify here that `m_chain.Contains` searches both the snapshot headers _and_ the IBD headers it's built on top of. When a `pblock` exists but is not contained in the chainstate it's a fork, and it's up to the snapshot chainstate to explore those.
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1116169293)
IIUC: maybe clarify here that `m_chain.Contains` searches both the snapshot headers _and_ the IBD headers it's built on top of. When a `pblock` exists but is not contained in the chainstate it's a fork, and it's up to the snapshot chainstate to explore those.