🤔 hodlinator reviewed a pull request: "Add assumeutxo chainparams to release-process.md"
(https://github.com/bitcoin/bitcoin/pull/31940#pullrequestreview-2652580681)
Concept ACK
Should we also add a later step in the release process for the actual generation of the assumeutxo snapshot, maybe referencing *doc/assumeutxo.md*?
(https://github.com/bitcoin/bitcoin/pull/31940#pullrequestreview-2652580681)
Concept ACK
Should we also add a later step in the release process for the actual generation of the assumeutxo snapshot, maybe referencing *doc/assumeutxo.md*?
💬 hodlinator commented on pull request "Add assumeutxo chainparams to release-process.md":
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1976492053)
Must be holding it wrong, but the `gettxoutsetinfo`-RPC isn't allowing me to specify both a `hash_type` and block height?
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1976492053)
Must be holding it wrong, but the `gettxoutsetinfo`-RPC isn't allowing me to specify both a `hash_type` and block height?
💬 willcl-ark commented on pull request "Add assumeutxo chainparams to release-process.md":
(https://github.com/bitcoin/bitcoin/pull/31940#issuecomment-2692422674)
We could do. Sjors has a tidy command in the linked PR.
(https://github.com/bitcoin/bitcoin/pull/31940#issuecomment-2692422674)
We could do. Sjors has a tidy command in the linked PR.
💬 Julian128 commented on issue "Bitcoin Core MacOS - Possible Miner Infection - Bitcoin Core MacOS - Possível Infecção por Minerador":
(https://github.com/bitcoin/bitcoin/issues/31970#issuecomment-2692423629)
you should verify your downloads or build from source and probably not use any of these antiviruses
(https://github.com/bitcoin/bitcoin/issues/31970#issuecomment-2692423629)
you should verify your downloads or build from source and probably not use any of these antiviruses
👍 hodlinator approved a pull request: "Add mainnet assumeutxo param at height 880,000"
(https://github.com/bitcoin/bitcoin/pull/31969#pullrequestreview-2652599416)
ACK 14f16748557faf57cf4b0f4c91c162592557434c
Thanks for doing this.
<details><summary>Testing procedure</summary>
(Testing performed at commit 8b5a50cb353d9524db38a3cfd537bac7a770e1a6, one markdown change away from recent master).
Generated my own snapshot (confirmed that recommended command roughly matches *doc/assumeutxo.md* (and `dumptxoutset`-help for specifying height):
```
₿ build/src/bitcoin-cli -rpcclienttimeout=0 -named dumptxoutset utxo-880000.dat rollback=880000
{
"c
...
(https://github.com/bitcoin/bitcoin/pull/31969#pullrequestreview-2652599416)
ACK 14f16748557faf57cf4b0f4c91c162592557434c
Thanks for doing this.
<details><summary>Testing procedure</summary>
(Testing performed at commit 8b5a50cb353d9524db38a3cfd537bac7a770e1a6, one markdown change away from recent master).
Generated my own snapshot (confirmed that recommended command roughly matches *doc/assumeutxo.md* (and `dumptxoutset`-help for specifying height):
```
₿ build/src/bitcoin-cli -rpcclienttimeout=0 -named dumptxoutset utxo-880000.dat rollback=880000
{
"c
...
💬 rishavtarway commented on issue "Revisiting us self-hosting parts of our CI":
(https://github.com/bitcoin/bitcoin/issues/31965#issuecomment-2692548770)
Will there be possibility we can think of more this idea :
1. Hybrid Approach with Optimized Caching:
=> Key Factors to this approach
i) Instead of a complete switch, maintain a smaller, more secure self-hosted infrastructure specifically for caching.
ii ) Use GitHub Actions or another cloud-based CI for the majority of the job execution.
iii) Develop a robust, distributed caching system (e.g., using a dedicated cloud storage service or a distributed cache like Redis) that integrates wit
...
(https://github.com/bitcoin/bitcoin/issues/31965#issuecomment-2692548770)
Will there be possibility we can think of more this idea :
1. Hybrid Approach with Optimized Caching:
=> Key Factors to this approach
i) Instead of a complete switch, maintain a smaller, more secure self-hosted infrastructure specifically for caching.
ii ) Use GitHub Actions or another cloud-based CI for the majority of the job execution.
iii) Develop a robust, distributed caching system (e.g., using a dedicated cloud storage service or a distributed cache like Redis) that integrates wit
...
📝 olaristo109 opened a pull request: "doc: Correct capitalization in release-process.md"
(https://github.com/bitcoin/bitcoin/pull/31971)
This PR corrects the capitalization of "if necessary" in the `doc/release-process.md` file.
The original sentence had "If necessary," with a capital "I". This has been corrected to "if necessary," with a lowercase "i" to maintain consistency.
This change improves the formatting and consistency of the documentation within the release process documentation file.
(https://github.com/bitcoin/bitcoin/pull/31971)
This PR corrects the capitalization of "if necessary" in the `doc/release-process.md` file.
The original sentence had "If necessary," with a capital "I". This has been corrected to "if necessary," with a lowercase "i" to maintain consistency.
This change improves the formatting and consistency of the documentation within the release process documentation file.
✅ fanquake closed a pull request: "doc: Correct capitalization in release-process.md"
(https://github.com/bitcoin/bitcoin/pull/31971)
(https://github.com/bitcoin/bitcoin/pull/31971)
📝 fanquake locked a pull request: "doc: Correct capitalization in release-process.md"
(https://github.com/bitcoin/bitcoin/pull/31971)
This PR corrects the capitalization of "if necessary" in the `doc/release-process.md` file.
The original sentence had "If necessary," with a capital "I". This has been corrected to "if necessary," with a lowercase "i" to maintain consistency.
This change improves the formatting and consistency of the documentation within the release process documentation file.
(https://github.com/bitcoin/bitcoin/pull/31971)
This PR corrects the capitalization of "if necessary" in the `doc/release-process.md` file.
The original sentence had "If necessary," with a capital "I". This has been corrected to "if necessary," with a lowercase "i" to maintain consistency.
This change improves the formatting and consistency of the documentation within the release process documentation file.
📝 fanquake locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/31934)
(https://github.com/bitcoin/bitcoin/pull/31934)
💬 romanz commented on pull request "contrib: add tool to convert compact-serialized UTXO set to SQLite database":
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2692696000)
In order to reduce conversion time, I have rewritten the above tool in Rust :)
https://github.com/romanz/utxo-to-parquet
It converts the serialized UTXO set into a Parquet file, allowing efficient querying.
For example, retrieving https://mempool.space/address/1BitcoinEaterAddressDontSendf59kuE unspent coins using DuckDB takes <1s :)
```sql
D SELECT txid, vout, amount, height FROM '/home/user/tmp/mainnet-886001-utxo.parquet'
WHERE script = from_hex('76a914759d6677091e973b9e9d99f19c68fb
...
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2692696000)
In order to reduce conversion time, I have rewritten the above tool in Rust :)
https://github.com/romanz/utxo-to-parquet
It converts the serialized UTXO set into a Parquet file, allowing efficient querying.
For example, retrieving https://mempool.space/address/1BitcoinEaterAddressDontSendf59kuE unspent coins using DuckDB takes <1s :)
```sql
D SELECT txid, vout, amount, height FROM '/home/user/tmp/mainnet-886001-utxo.parquet'
WHERE script = from_hex('76a914759d6677091e973b9e9d99f19c68fb
...
💬 RomainGratier commented on issue "Bitcoin Core MacOS - Possible Miner Infection - Bitcoin Core MacOS - Possível Infecção por Minerador":
(https://github.com/bitcoin/bitcoin/issues/31970#issuecomment-2692744621)
+1 on the last comment, and if I can give some context around security discussions around Bitcoin core (and malware detection), you can take a look at this thread: https://bitcoin.stackexchange.com/questions/98797/when-i-try-to-download-bitcoin-core-on-macos-it-says-apple-cannot-check-it-for
In any case, if you’re ever in doubt, always download from the official site and verify the digital signatures provided. Guessing that you trust Bitcoin Core source code.
(https://github.com/bitcoin/bitcoin/issues/31970#issuecomment-2692744621)
+1 on the last comment, and if I can give some context around security discussions around Bitcoin core (and malware detection), you can take a look at this thread: https://bitcoin.stackexchange.com/questions/98797/when-i-try-to-download-bitcoin-core-on-macos-it-says-apple-cannot-check-it-for
In any case, if you’re ever in doubt, always download from the official site and verify the digital signatures provided. Guessing that you trust Bitcoin Core source code.
🤔 Prabhat1308 reviewed a pull request: "qa: clarify and document assumeutxo tests"
(https://github.com/bitcoin/bitcoin/pull/31907#pullrequestreview-2652739998)
tACK [`dedc2d9`](https://github.com/bitcoin/bitcoin/pull/31907/commits/dedc2d9cecccb866230c07112d00288237d12eaa)
- tested the amount with compression and varint encoding to match .
- On the case of implementing varint serialization and compression logic , it would be a great addition to bring in the logic to test_framework (or in any other PR , no preference to bring it in this one).
(https://github.com/bitcoin/bitcoin/pull/31907#pullrequestreview-2652739998)
tACK [`dedc2d9`](https://github.com/bitcoin/bitcoin/pull/31907/commits/dedc2d9cecccb866230c07112d00288237d12eaa)
- tested the amount with compression and varint encoding to match .
- On the case of implementing varint serialization and compression logic , it would be a great addition to bring in the logic to test_framework (or in any other PR , no preference to bring it in this one).
💬 Prabhat1308 commented on pull request "qa: clarify and document assumeutxo tests":
(https://github.com/bitcoin/bitcoin/pull/31907#discussion_r1976641187)
as the above comment has already asked , I can't seem to understand why `VARINT(0)` was added considering we have already exceeded the max amount in the first amount written itself.
(https://github.com/bitcoin/bitcoin/pull/31907#discussion_r1976641187)
as the above comment has already asked , I can't seem to understand why `VARINT(0)` was added considering we have already exceeded the max amount in the first amount written itself.
💬 davidrobinsonau commented on pull request "Added rescan option for import descriptors":
(https://github.com/bitcoin/bitcoin/pull/31668#discussion_r1976743171)
What do you suggest as the return value for the function when never is passed? So that this can be easily checked against for rescan? it can't be 0 as "0 can be specified to scan the entire blockchain." -1, null?
static int64_t GetImportTimestamp(const UniValue& data, int64_t now)
```
{
if (data.exists("timestamp")) {
const UniValue& timestamp = data["timestamp"];
if (timestamp.isNum()) {
return timestamp.getInt<int64_t>();
} else if (timestamp.i
...
(https://github.com/bitcoin/bitcoin/pull/31668#discussion_r1976743171)
What do you suggest as the return value for the function when never is passed? So that this can be easily checked against for rescan? it can't be 0 as "0 can be specified to scan the entire blockchain." -1, null?
static int64_t GetImportTimestamp(const UniValue& data, int64_t now)
```
{
if (data.exists("timestamp")) {
const UniValue& timestamp = data["timestamp"];
if (timestamp.isNum()) {
return timestamp.getInt<int64_t>();
} else if (timestamp.i
...
💬 Crypt-iQ commented on issue "p2p: lingering entries in `mapBlockSource`":
(https://github.com/bitcoin/bitcoin/issues/29410#issuecomment-2693020111)
I left some details out of both the original PR and this issue and I think the missing information is needed to come to a solution:
- Node A is currently at height `h` and receives a `BLOCK` message from an _honest_ peer B for a stale block at height `h`. There are a couple ways that a `BLOCK` message could be sent instead of a `CMPCTBLOCK` message. For example, the compact-block slots could all be taken by an attacker or maybe there was a [collision for short ids](https://github.com/bitcoin/bit
...
(https://github.com/bitcoin/bitcoin/issues/29410#issuecomment-2693020111)
I left some details out of both the original PR and this issue and I think the missing information is needed to come to a solution:
- Node A is currently at height `h` and receives a `BLOCK` message from an _honest_ peer B for a stale block at height `h`. There are a couple ways that a `BLOCK` message could be sent instead of a `CMPCTBLOCK` message. For example, the compact-block slots could all be taken by an attacker or maybe there was a [collision for short ids](https://github.com/bitcoin/bit
...
💬 rkrux commented on pull request "Add assumeutxo chainparams to release-process.md":
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1977046435)
Yes, I see the same issue. This is as per the code: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp#L1019-L1021
Following commands work for me instead:
```
bitcoincli gettxoutsetinfo
bitcoincli gettxoutsetinfo muhash <block-height>
bitcoincli gettxoutsetinfo none <block-height>
```
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1977046435)
Yes, I see the same issue. This is as per the code: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp#L1019-L1021
Following commands work for me instead:
```
bitcoincli gettxoutsetinfo
bitcoincli gettxoutsetinfo muhash <block-height>
bitcoincli gettxoutsetinfo none <block-height>
```
👍 rkrux approved a pull request: "Add mainnet assumeutxo param at height 880,000"
(https://github.com/bitcoin/bitcoin/pull/31969#pullrequestreview-2653545385)
Concept ACK 14f16748557faf57cf4b0f4c91c162592557434c
I have not tested this because I run a pruned node and my block's prune height is more than the 880k.
In the PR description, the last command should pass `true` instead.
> Once the snapshot is loaded:
> ```
> bitcoin-cli setnetworkactive true
> ```
----------
> I'll upload a torrent later.
Any idea why don't we upload snapshots in [bitcoincore.org/bin](https://bitcoincore.org/bin/) as well?
(https://github.com/bitcoin/bitcoin/pull/31969#pullrequestreview-2653545385)
Concept ACK 14f16748557faf57cf4b0f4c91c162592557434c
I have not tested this because I run a pruned node and my block's prune height is more than the 880k.
In the PR description, the last command should pass `true` instead.
> Once the snapshot is loaded:
> ```
> bitcoin-cli setnetworkactive true
> ```
----------
> I'll upload a torrent later.
Any idea why don't we upload snapshots in [bitcoincore.org/bin](https://bitcoincore.org/bin/) as well?
💬 rkrux commented on pull request "rpc: add cli examples, update docs":
(https://github.com/bitcoin/bitcoin/pull/31958#discussion_r1977187442)
I tend to agree, updated.
(https://github.com/bitcoin/bitcoin/pull/31958#discussion_r1977187442)
I tend to agree, updated.
💬 rkrux commented on pull request "rpc: add cli examples, update docs":
(https://github.com/bitcoin/bitcoin/pull/31958#issuecomment-2693800784)
Updated example output of `walletcreatefundedpsbt` RPC:
```
Examples:
Create a PSBT with automatically picked inputs that sends 0.5 BTC to an address and has a fee rate of 2 sat/vB:
> bitcoin-cli walletcreatefundedpsbt "[]" "[{\"bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34hufdl\":0.5}]" 0 "{\"add_inputs\":true,\"fee_rate\":2}"
Create the same PSBT as the above one instead using named arguments:
> bitcoin-cli -named walletcreatefundedpsbt outputs="[{\"bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34huf
...
(https://github.com/bitcoin/bitcoin/pull/31958#issuecomment-2693800784)
Updated example output of `walletcreatefundedpsbt` RPC:
```
Examples:
Create a PSBT with automatically picked inputs that sends 0.5 BTC to an address and has a fee rate of 2 sat/vB:
> bitcoin-cli walletcreatefundedpsbt "[]" "[{\"bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34hufdl\":0.5}]" 0 "{\"add_inputs\":true,\"fee_rate\":2}"
Create the same PSBT as the above one instead using named arguments:
> bitcoin-cli -named walletcreatefundedpsbt outputs="[{\"bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34huf
...