Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 MarcoFalke commented on issue "configure: error: cannot figure out how to use std::filesystem":
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442059015)
gcc 7 doesn't have filesystem. You can try `CC=clang-10 CXX="clang++-10 -stdlib=libc++"`
💬 fanquake commented on issue "configure: error: cannot figure out how to use std::filesystem":
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442064307)
> This is the relevant chunk from config.log:

Installing `libstdc++-8-dev` will solve the problem.
💬 hebasto commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1442064325)
This part in the PR description
> I've changed `trusted-keys` from just a list of key ids to a csv file with each row being the key id, and the earliest and latest commits the key is allowed to have signed.

looks outdated.
💬 pinheadmz commented on issue "configure: error: cannot figure out how to use std::filesystem":
(https://github.com/bitcoin/bitcoin/issues/27148#issuecomment-1442066649)
>
> Installing `libstdc++-8-dev` will solve the problem.

YES! Thanks. Add to docs ?
💬 theuni commented on pull request "Fix various libbitcoinkernel DLL build problems":
(https://github.com/bitcoin/bitcoin/pull/27146#issuecomment-1442071126)
@hebasto: I'm not sure how it looked before, but after this PR the exports look nice and clean:

```
$ objdump -p .libs/libbitcoinconsensus-0.dll

...

[Ordinal/Name Pointer] Table
[ 0] bitcoinconsensus_verify_script
[ 1] bitcoinconsensus_verify_script_with_amount
[ 2] bitcoinconsensus_version

The Function Table (interpreted .pdata section contents)
vma: BeginAddress EndAddress UnwindData
000000006db81000: 000000006d
...
💬 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.
pinheadmz closed an issue: "configure: error: cannot figure out how to use std::filesystem"
(https://github.com/bitcoin/bitcoin/issues/27148)
💬 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
💬 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
💬 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
...
💬 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.
💬 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).
💬 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`.
MarcoFalke closed a pull request: "refactor: Avoid UniValue copies"
(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.
💬 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
💬 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.
💬 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...
💬 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.