Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ€” furszy reviewed a pull request: "init: handle empty settings file gracefully"
(https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1797199209)
> see previous discussion in #23096, #22591, and [#21340 (comment)](https://github.com/bitcoin/bitcoin/issues/21340#issuecomment-880147010)

Hmm, okay, agree. Thanks.
It would probably be useful to introduce support for comments. This way, we can write something at the beginning of the file, ensuring that users and other software developers don't clean this file manually, thinking that it will be regenerated automatically. Do you know if something like this has been proposed before? @0xB10C.
...
πŸ’¬ GregTonoski commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1870318175)
Why not simply depracating OP_IF?
⚠️ GregTonoski opened an issue: "Blockspace price shouldn't be higher for a simple transaction (price discrimination against simple txs)"
(https://github.com/bitcoin/bitcoin/issues/29146)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Blockspace price for data of a simple transaction is higher than the one for data of other ("complex") transactions, e.g.
3=616 weight / 205 bytes [aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd](https://mempool.space/tx/aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd)
vs
1.49=1140 weight / 767 bytes [1c35521798dde4d1621e9aa5a3bacac03100fca40b6fb99be5
...
βœ… maflcko closed an issue: "[Bug]: Blockspace price shouldn't be higher for a simple transaction (price discrimination against simple txs)"
(https://github.com/bitcoin/bitcoin/issues/29146)
πŸ’¬ maflcko commented on issue "[Bug]: Blockspace price shouldn't be higher for a simple transaction (price discrimination against simple txs)":
(https://github.com/bitcoin/bitcoin/issues/29146#issuecomment-1870433246)
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 one of the Bitcoin subreddits, or any other place that you feel is well suited.

Network-wide consensus and/or P2P changes first need to be discussed with the greater community, for example the `bitcoin-dev` maili
...
πŸ’¬ maflcko commented on pull request "rpc: Remove deprecated -rpcserialversion":
(https://github.com/bitcoin/bitcoin/pull/28890#issuecomment-1870437050)
The deprecation was covered in https://bitcoinops.org/en/newsletters/2023/09/20/ and 26.0 was released a few weeks ago. Unless anyone heard someone complain, this seems good to move forward now?
πŸ€” sipa reviewed a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797358660)
utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
πŸ’¬ kristapsk commented on pull request "rpc: Remove deprecated -rpcserialversion":
(https://github.com/bitcoin/bitcoin/pull/28890#issuecomment-1870467659)
Concept ACK
πŸ‘ kristapsk approved a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797365533)
cr utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
πŸ€” stratospher reviewed a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797370883)
ACK fa1d495.
πŸ’¬ kristapsk commented on pull request "Modify command line help to show support for BIP21 URIs":
(https://github.com/bitcoin-core/gui/pull/752#discussion_r1437157234)
Square brackets mean that URI option is optional. Either use "[URI]" or "Optional URI" below, not "Optional [URI]".
```suggestion
"Optional URI is a bitcoin address in BIP21 URI format.\n";
```
⚠️ kristapsk opened an issue: ""Open bitcoin URI" dialog could give more feedback on what's wrong with BIP21 URI"
(https://github.com/bitcoin-core/gui/issues/784)
### Please describe the feature you'd like to see added.

Currently, when trying to open URI, if it's invalid, clicking "OK" will just colour it red, instead of giving any feedback, what's exactly wrong with URI.

![image](https://github.com/bitcoin-core/gui/assets/4500994/e4bed178-9fc2-4436-affe-7cc2a5695f7c)

In my test I added unknown required paramter `req-test=1`. Feedback on that would be useful for user, for example, [BIP77 Payjoin v2 draft](https://github.com/bitcoin/bips/pull/1483)
...
πŸ’¬ asggWa commented on issue "./bitcoin.conf file should not cause confusion with ./datadir/bitcoin.conf":
(https://github.com/bitcoin/bitcoin/issues/29139#issuecomment-1870516002)
$HOME/snap
πŸ’¬ kristapsk commented on pull request "Update about logo icon (colour) to denote the chain type of the QT instance in About/ Help Message Window/ Dialog":
(https://github.com/bitcoin-core/gui/pull/762#discussion_r1437190084)
nit
```suggestion
const QSize requiredSize(1024, 1024);
```
πŸ’¬ ybaidiuk commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1870530971)
Ok filter is bad idea because of censoring and disable OP_RETRUN is not an Option,
but we still have free market violation (fee)
People do not pay full price to put data in blockchain, they do abuse of fee-free size of OP_RETRUN.

In this case, will be doing nothing is a good solution.
But i think the best option will be to reduce size of OP_RETURN to 40 bytes like it was before.
It will make fee-abuse more expensive and create stimulation to move data into side chains.
πŸ€” mzumsande reviewed a pull request: "Change Luke Dashjr seed to dashjr-list-of-p2p-nodes-maybe-malware.us"
(https://github.com/bitcoin/bitcoin/pull/29145#pullrequestreview-1797445282)
@luke-jr : Slightly unrelated to this PR, but looking at the results from all seeders, it seems that yours returns only nodes running old versions `0.21.x` and `22.x`. I didn't get a single result with a newer subversion.
Given the current composition of nodes on the network and that none of the other DNS seeds show a similar pattern, this seems unlikely to just be an unlucky result of a random selection. Could this be a bug in your seeder?
πŸ‘ kristapsk approved a pull request: "Update Node window title with the chain type"
(https://github.com/bitcoin-core/gui/pull/758#pullrequestreview-1797448565)
ACK 9d37886a3b6ce24f4a4a05193eb0d071655a8457
πŸ€” murchandamus reviewed a pull request: "wallet: track mempool conflicts with wallet transactions"
(https://github.com/bitcoin/bitcoin/pull/27307#pullrequestreview-1797438722)
ACK 22778ac98f1bcb695de8ccf0b02fe9ebe39b01aa
πŸ’¬ murchandamus commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1437201563)
In "wallet: use CWalletTx member functions to determine tx state" (80ba1d97f179121736d702b2d54bd3938cb57d96):

Did you mean "An output is considered spent…"?
πŸ’¬ dimitaracev commented on pull request "wallet: add meaningful error message and fix test":
(https://github.com/bitcoin/bitcoin/pull/29143#issuecomment-1870566016)
> Also, an assertion crash fix, is not a "test" fix. I presume this can happen in production, no?

Initially I thought that this was the expected behavior, which is why this pull request just returns a different error message so that it can be caught in the test. But as @furszy said, the issue appears to be something completely different that needs fixing.

> Do you have steps to reproduce the test failure (usually a race can be reproduced by adding a sleep in the right place in the C++ cod
...