π¬ earuak commented on issue "BIP158: block filter encoding is inefficient in case of hash collisions":
(https://github.com/bitcoin/bitcoin/issues/27003#issuecomment-1505742416)
The problem described in relation to the BIP158 is indeed a real problem. When two different elements map to the same hash value (hash collision), the block filter ends up containing a higher number of false positives than expected.
The most common solution for dealing with hash collisions is to use a hash function with a lower collision probability, such as SHA-256 instead of SHA-512. In addition, insertion of duplicate elements in the block filter can be avoided by adding functionality to r
...
(https://github.com/bitcoin/bitcoin/issues/27003#issuecomment-1505742416)
The problem described in relation to the BIP158 is indeed a real problem. When two different elements map to the same hash value (hash collision), the block filter ends up containing a higher number of false positives than expected.
The most common solution for dealing with hash collisions is to use a hash function with a lower collision probability, such as SHA-256 instead of SHA-512. In addition, insertion of duplicate elements in the block filter can be avoided by adding functionality to r
...
π¬ earuak commented on pull request "#24049 Issue: Update nScore datatype":
(https://github.com/bitcoin/bitcoin/pull/27386#issuecomment-1505745232)
948 / 5.000
Resultados de traduΓ§Γ£o
Resultado da traduΓ§Γ£o
Got it, but it's important to remember that by changing the nScore data type from int to int64_t, you may be affecting other parts of the code that depend on the nScore data type. Make sure all other nScore related variables and functions have also been updated to the correct data type.
Also, remember to verify that the required storage size for the int64_t data type is supported on all platforms and operating systems your code will
...
(https://github.com/bitcoin/bitcoin/pull/27386#issuecomment-1505745232)
948 / 5.000
Resultados de traduΓ§Γ£o
Resultado da traduΓ§Γ£o
Got it, but it's important to remember that by changing the nScore data type from int to int64_t, you may be affecting other parts of the code that depend on the nScore data type. Make sure all other nScore related variables and functions have also been updated to the correct data type.
Also, remember to verify that the required storage size for the int64_t data type is supported on all platforms and operating systems your code will
...
π¬ pinheadmz commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1164505857)
sure, done thanks!
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1164505857)
sure, done thanks!
π¬ earuak commented on pull request "contrib: add tool to convert compact-serialized UTXO set to SQLite database":
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1505768561)
Based on the description of the problem and the proposed solution, I can say that adding a simple Python script to create an SQLite database for the UTXO set looks like a viable solution. Scripting appears to be an effective solution for handling the UTXO set in a format that is readable and manageable. Additionally, the included functional testing appears to be a good practice to ensure data integrity. Overall, it appears to be a reasonable solution to users' demand to get the UTXO set in an SQ
...
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1505768561)
Based on the description of the problem and the proposed solution, I can say that adding a simple Python script to create an SQLite database for the UTXO set looks like a viable solution. Scripting appears to be an effective solution for handling the UTXO set in a format that is readable and manageable. Additionally, the included functional testing appears to be a good practice to ensure data integrity. Overall, it appears to be a reasonable solution to users' demand to get the UTXO set in an SQ
...
π¬ benthecarman commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#discussion_r1164527141)
added
(https://github.com/bitcoin/bitcoin/pull/27446#discussion_r1164527141)
added
π¬ earuak commented on pull request "doc: remove incorrect line from example":
(https://github.com/bitcoin/bitcoin/pull/27454#issuecomment-1505774463)
My suggestion would be to revise the example and remove the offending line to avoid confusion for users. Perhaps you could add a brief explanation about the automatic presence of entries when using **walletcreatefundedpsbt** to help clarify this for users. Something like:
"Note that when using **walletcreatefundedpsbt**, entries are automatically included in the transaction and do not need to be specified separately."
(https://github.com/bitcoin/bitcoin/pull/27454#issuecomment-1505774463)
My suggestion would be to revise the example and remove the offending line to avoid confusion for users. Perhaps you could add a brief explanation about the automatic presence of entries when using **walletcreatefundedpsbt** to help clarify this for users. Something like:
"Note that when using **walletcreatefundedpsbt**, entries are automatically included in the transaction and do not need to be specified separately."
π¬ pinheadmz commented on issue "Export a watch wallet only (with descriptors and without private keys) for an air gap setup":
(https://github.com/bitcoin/bitcoin/issues/24829#issuecomment-1505778435)
Ok I just pulled v24.0.1 and repeated steps with CLI and GUI, same outcome -- are you still unable to do this?
(https://github.com/bitcoin/bitcoin/issues/24829#issuecomment-1505778435)
Ok I just pulled v24.0.1 and repeated steps with CLI and GUI, same outcome -- are you still unable to do this?
π¬ jonatack commented on pull request "Fix logging RPC and -debugexclude with 0/none values, add test coverage, improve docs":
(https://github.com/bitcoin/bitcoin/pull/27231#discussion_r1164530898)
Good question. Both of the `EnableOrDisableLogCategories()` functions are created in this PR. They are doing pretty much the same thing, but are not trivially combinable into one function (maybe for a follow-up). If one is changed, it's likely that both should be (maybe a comment to that effect should be added to them), so I named them the same in order that searching/git grepping returns both. That, along with how extracting that function simplifies `SetLoggingCategories` to highlight that bot
...
(https://github.com/bitcoin/bitcoin/pull/27231#discussion_r1164530898)
Good question. Both of the `EnableOrDisableLogCategories()` functions are created in this PR. They are doing pretty much the same thing, but are not trivially combinable into one function (maybe for a follow-up). If one is changed, it's likely that both should be (maybe a comment to that effect should be added to them), so I named them the same in order that searching/git grepping returns both. That, along with how extracting that function simplifies `SetLoggingCategories` to highlight that bot
...
π¬ pinheadmz commented on pull request "Fix logging RPC and -debugexclude with 0/none values, add test coverage, improve docs":
(https://github.com/bitcoin/bitcoin/pull/27231#discussion_r1164533054)
Cool, just to be clear I meant combining this `EnableOrDisableLogCategories()` into ` SetLoggingCategories()` and then you only have one named `EnableOrDisableLogCategories()` in the code over in node.cpp
> That, along with how extracting that function simplifies SetLoggingCategories to highlight that both options are being plugged into the same code, were the motivations.
okie doke π
(https://github.com/bitcoin/bitcoin/pull/27231#discussion_r1164533054)
Cool, just to be clear I meant combining this `EnableOrDisableLogCategories()` into ` SetLoggingCategories()` and then you only have one named `EnableOrDisableLogCategories()` in the code over in node.cpp
> That, along with how extracting that function simplifies SetLoggingCategories to highlight that both options are being plugged into the same code, were the motivations.
okie doke π
β οΈ Bandarfaqih opened an issue: "Enhancing Bitcoin Privacy Protocol Bip Proposal"
(https://github.com/bitcoin/bitcoin/issues/27455)
### Please describe the feature you'd like to see added.
This BIP proposes the direct implementation of several privacy and anonymity-enhancing features in the Bitcoin protocol, including CoinJoin, zk-SNARKs, ring signatures, and stealth addresses directly into the Bitcoin protocol. These features were envisioned by Satoshi Nakamoto and other contributors as essential tools for preserving user privacy on the network.
Motivation
Bitcoin's and Bitcoin current level of privacy and anonymity
...
(https://github.com/bitcoin/bitcoin/issues/27455)
### Please describe the feature you'd like to see added.
This BIP proposes the direct implementation of several privacy and anonymity-enhancing features in the Bitcoin protocol, including CoinJoin, zk-SNARKs, ring signatures, and stealth addresses directly into the Bitcoin protocol. These features were envisioned by Satoshi Nakamoto and other contributors as essential tools for preserving user privacy on the network.
Motivation
Bitcoin's and Bitcoin current level of privacy and anonymity
...
π¬ fanquake commented on issue "Enhancing Bitcoin Privacy Protocol Bip Proposal":
(https://github.com/bitcoin/bitcoin/issues/27455#issuecomment-1505791472)
Thanks. However as I said last time you posted this. This is not the right place to post this.
(https://github.com/bitcoin/bitcoin/issues/27455#issuecomment-1505791472)
Thanks. However as I said last time you posted this. This is not the right place to post this.
β
fanquake closed an issue: "Enhancing Bitcoin Privacy Protocol Bip Proposal"
(https://github.com/bitcoin/bitcoin/issues/27455)
(https://github.com/bitcoin/bitcoin/issues/27455)
π¬ Bandarfaqih commented on issue "Enhancing Bitcoin Privacy Protocol Bip Proposal":
(https://github.com/bitcoin/bitcoin/issues/27455#issuecomment-1505791936)
I have discussed this with the BITCOIN development team and they were welcoming the idea but incentive me to do a discussion feature here in the BTC community before further implementation to have a more mature final consensus proposal for the development and processing of the BIP therefore everyone is welcome to discuss further technical implementation and thoughts.
(https://github.com/bitcoin/bitcoin/issues/27455#issuecomment-1505791936)
I have discussed this with the BITCOIN development team and they were welcoming the idea but incentive me to do a discussion feature here in the BTC community before further implementation to have a more mature final consensus proposal for the development and processing of the BIP therefore everyone is welcome to discuss further technical implementation and thoughts.
β οΈ Bandarfaqih opened an issue: "Thanks. However as I said last time you posted this. This is not the right place to post this."
(https://github.com/bitcoin/bitcoin/issues/27456)
Thanks. However as I said last time you posted this. This is not the right place to post this.
_Originally posted by @fanquake in https://github.com/bitcoin/bitcoin/issues/27455#issuecomment-1505791472_
I have discussed this with the BITCOIN development team and they were welcoming the idea but incentive me to do a discussion feature here in the BTC community before further implementation to have a more mature proposal for the development and processing of the BIP therefore
...
(https://github.com/bitcoin/bitcoin/issues/27456)
Thanks. However as I said last time you posted this. This is not the right place to post this.
_Originally posted by @fanquake in https://github.com/bitcoin/bitcoin/issues/27455#issuecomment-1505791472_
I have discussed this with the BITCOIN development team and they were welcoming the idea but incentive me to do a discussion feature here in the BTC community before further implementation to have a more mature proposal for the development and processing of the BIP therefore
...
β
fanquake closed an issue: "Thanks. However as I said last time you posted this. This is not the right place to post this."
(https://github.com/bitcoin/bitcoin/issues/27456)
(https://github.com/bitcoin/bitcoin/issues/27456)
:lock: fanquake locked an issue: "Thanks. However as I said last time you posted this. This is not the right place to post this."
(https://github.com/bitcoin/bitcoin/issues/27456)
(https://github.com/bitcoin/bitcoin/issues/27456)
:lock: fanquake locked an issue: "Enhancing Bitcoin Privacy Protocol Bip Proposal"
(https://github.com/bitcoin/bitcoin/issues/27455)
(https://github.com/bitcoin/bitcoin/issues/27455)
π¬ Tracachang commented on issue "Export a watch wallet only (with descriptors and without private keys) for an air gap setup":
(https://github.com/bitcoin/bitcoin/issues/24829#issuecomment-1505803844)
> Ok I just pulled v24.0.1 and repeated steps with CLI and GUI, same outcome -- are you still unable to do this?
Just tried again following this commands and I am still unable to see taproot in GUI
```
$ bitcoin-cli createwallet original
{
"name": "original",
"warning": ""
}
$ bitcoin-cli -rpcwallet=original listdescriptors | jq .descriptors -c >> ~/Desktop/watchonly.json
$ bitcoin-cli -named createwallet wallet_name=watchonly disable_private_keys=true
{
"name": "watchonly
...
(https://github.com/bitcoin/bitcoin/issues/24829#issuecomment-1505803844)
> Ok I just pulled v24.0.1 and repeated steps with CLI and GUI, same outcome -- are you still unable to do this?
Just tried again following this commands and I am still unable to see taproot in GUI
```
$ bitcoin-cli createwallet original
{
"name": "original",
"warning": ""
}
$ bitcoin-cli -rpcwallet=original listdescriptors | jq .descriptors -c >> ~/Desktop/watchonly.json
$ bitcoin-cli -named createwallet wallet_name=watchonly disable_private_keys=true
{
"name": "watchonly
...
π¬ pinheadmz commented on pull request "validation: implement MaybeInvalidateFork() and call from rpc getchaintips":
(https://github.com/bitcoin/bitcoin/pull/27434#issuecomment-1505813377)
Since I'm already here, I added a commit that fixes the incorrect usage of the term "orphan blocks" in rpc `getchaintips` code
cc: @MarcoFalke (fa0dfdf447d5b84a1849dc823d8508463600136a) and @mrbandrews (87049e832d97d4f2808c0b479b21fc7b16c86934)
(https://github.com/bitcoin/bitcoin/pull/27434#issuecomment-1505813377)
Since I'm already here, I added a commit that fixes the incorrect usage of the term "orphan blocks" in rpc `getchaintips` code
cc: @MarcoFalke (fa0dfdf447d5b84a1849dc823d8508463600136a) and @mrbandrews (87049e832d97d4f2808c0b479b21fc7b16c86934)
π¬ benthecarman commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1505813908)
If anyone is interested in testing, I am running this for a custom signet.
```
[signet]
signetchallenge=512102f7561d208dd9ae99bf497273e16f389bdbd6c4742ddb8e6b216e64fa2928ad8f51ae
signetblocktime=30
addnode=45.79.52.207:38333
dnsseed=0
```
Block explorer: https://mutinynet.com
faucet: https://faucet.mutinynet.com
There is also a rapid gossip sync server and some lightning nodes as well
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1505813908)
If anyone is interested in testing, I am running this for a custom signet.
```
[signet]
signetchallenge=512102f7561d208dd9ae99bf497273e16f389bdbd6c4742ddb8e6b216e64fa2928ad8f51ae
signetblocktime=30
addnode=45.79.52.207:38333
dnsseed=0
```
Block explorer: https://mutinynet.com
faucet: https://faucet.mutinynet.com
There is also a rapid gossip sync server and some lightning nodes as well