Bitcoin Core Github
44 subscribers
120K links
Download Telegram
πŸ’¬ TheCharlatan commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1187890064)
Adding `Assert(false)` seems to throw an error:
```
util/chaintype.cpp: In function β€˜std::string ChainTypeToString(ChainType)’:
./util/check.h:73:89: error: control reaches end of non-void function [-Werror=return-type]
73 | #define Assert(val) inline_assertion_check<true>(val, __FILE__, __LINE__, __func__, #val)
| ^
util/chaintype.cpp:23:5: note: in expansion of macro β€˜Assert’
23 | Ass
...
πŸ“ furszy opened a pull request: "wallet: don't duplicate change output if already exist"
(https://github.com/bitcoin/bitcoin/pull/27601)
If the transaction includes an output that goes to the custom change
address (`CoinControl::destChange`), the transaction creation process
should avoid creating duplicate outputs to the same address.

Instead, it should reuse the existing output to prevent revealing
which address is the change address, which could compromise privacy.

Side note:
This is something that will be using for the #26732 rework.
πŸ“ sr-gi opened a pull request: "net: avoid serving non-announced txs as a result of a MEMPOOL message"
(https://github.com/bitcoin/bitcoin/pull/27602)
Currently, non-announced transactions can be served after a BIP35 MEMPOOl message has been received from a peer. By following this pattern, we are potentially allowing peers to fingerprint transactions that may have originated in our node and to perform timing analysis on the propagation of transactions that enter our mempool.

This simply removes the relay bypass so only announced transactions are served to peers.
πŸ’¬ sr-gi commented on pull request "net: avoid serving non-announced txs as a result of a MEMPOOL message":
(https://github.com/bitcoin/bitcoin/pull/27602#issuecomment-1539074312)
Motivation: this fix was discussed over IRC by @willcl-ark @glozow @sipa and @darosior

https://gnusha.org/bitcoin-core-dev/2023-05-02.log
πŸ’¬ TheCharlatan commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#issuecomment-1539094705)
Thank you for the reviews!

Updated 95744f9cf1f143b6449a5046a914557b3886e3a2 -> 43dec8806f679005d4484b229f433687526c9133 ([kernelChainType_4](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_4) -> [kernelChainType_5](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_5), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelChainType_4..kernelChainType_5))
* Addressed @MarcoFalke's [comment](https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1187440836),
...
πŸ’¬ desirepl commented on issue "Bitcoin ignores datadir and blocksdir parameter in .conf":
(https://github.com/bitcoin/bitcoin/issues/27246#issuecomment-1539136159)
@pinheadmz
2023-05-08T22:11:59Z Using data directory W:\BitcoinCore\_strDataDir (this was read from hive)
2023-05-08T22:11:59Z Config file: W:\BitcoinCore\_strDataDir\bitcoin.conf (exist...)
2023-05-08T22:11:59Z Config file arg: blocksdir="W:/BitcoinCore/BlocksDir_/_.no_params"
2023-05-08T22:11:59Z Config file arg: datadir="W:/BitcoinCore/DataDir_/_.no_params" (this is in 2nd line bitcoin.conf, *ignored*)
πŸ‘ furszy approved a pull request: "wallet: Load database records in a particular order"
(https://github.com/bitcoin/bitcoin/pull/24914#pullrequestreview-1417686210)
diff ACK 265b9e3
πŸ“ kevkevinpal opened a pull request: "test: added coverage to mining_basic.py"
(https://github.com/bitcoin/bitcoin/pull/27603)
Included a test that checks if the block.vtx.empty() does it throw the correct error, currently we only check if !block.vtx->IsCoinBase()

I've tested to make sure this actually doing what I intended by breaking up this if block into two if blocks with different error messages and running the functional test
https://github.com/bitcoin/bitcoin/blob/322ec63b01499c1ec52d3912ee382ebd59f2366b/src/rpc/mining.cpp#L963

This change should increase the test coverage for the `submitblock()` rpc in `.
...
πŸ“ ryanofsky opened a pull request: "add ryanofsky to trusted-keys"
(https://github.com/bitcoin/bitcoin/pull/27604)
For maintaining interfaces and other areas of the codebase. Some previous discussion in IRC meeting https://gnusha.org/bitcoin-core-dev/2023-05-04.log
πŸ’¬ MarcoFalke commented on issue "make check errors on big endian OpenBSD 7.2":
(https://github.com/bitcoin/bitcoin/issues/26492#issuecomment-1539515588)
The unit tests pass? (Well, except for ./test/util/test_runner.py ?)

What is the output of one of the functional tests failing with --tracerpc Print out all RPC calls as they are made
` set?
πŸ’¬ MarcoFalke commented on pull request "Move IsDeprecatedRPCEnabled to rpc/util, rm redundant rpcEnableDeprecated":
(https://github.com/bitcoin/bitcoin/pull/27322#issuecomment-1539543097)
Is gArgs guaranteed to be identical in different processes? If not, it would be good to explain why this behavior change is intentional. If yes, it would be good to explain as well.
πŸ’¬ MarcoFalke commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1188242770)
ah ok, maybe `assert(false)`
πŸ’¬ darosior commented on pull request "add ryanofsky to trusted-keys":
(https://github.com/bitcoin/bitcoin/pull/27604#issuecomment-1539625613)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK 59ebee3fb4181baf20fab263cf1b587ece1bd5e2 for adding ryanofsky as a maintainer.

I have not checked the key `4D1B3D5ECBA1A7E05371EEBE46800E30FC748A66`.
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEEWQtykmla/6W2csuy4T/BRc0/QwQFAmRZ+qsACgkQ4T/BRc0/
QwT3lQv/Qud7HqLisikdjcg7jrqa9YBS5j8CwFFIJW5TpY5zqLsm/7nI8RlkakRg
gvj1Ok92RTnhEGaleN/80Bco9uH5PEW+6V0tda5ZS/VqD4P0l3Jra9U0kvnTeWAR
aFRWCK14nelsU2+ccG0cf0yHnqrX3/jJGzINJzx2nJt1xDNVKxrkqahYSZf
...
πŸ“ MarcoFalke opened a pull request: "refactor: Replace global find_value function with UniValue::find_value method"
(https://github.com/bitcoin/bitcoin/pull/27605)
The global function has issues:

* It causes gcc-13 warnings, see https://github.com/bitcoin/bitcoin/issues/26926
* There is no rationale for it being a global function, when it acts like a member function

Fix all issues by making it a member function.
πŸ’¬ ajtowns commented on pull request "net processing: avoid serving non-announced txs as a result of a MEMPOOL message":
(https://github.com/bitcoin/bitcoin/pull/27602#discussion_r1188287489)
Doesn't this just change the fingerprinting vector from `GETDATA txid` to `FILTERCLEAR; FILTERADD whatever; MEMPOOL` ? In which case we're just as easily fingerprinted, but we spend more cpu while being fingerprinted?
πŸ’¬ Sjors commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1539677521)
The above command on my listening node (running a mess of commits on top of master from ~March) returns localhost (probably my mempool instance) plus about 11 other peers. CPU use looks normal to me, it's not compiled with --enable-debug nor does it run with -debug. Last restart was 3 days ago.
πŸ’¬ MarcoFalke commented on issue "GCC 13: `-Wdangling-reference` output":
(https://github.com/bitcoin/bitcoin/issues/26926#issuecomment-1539683573)
See https://github.com/bitcoin/bitcoin/pull/27605 for a code change. An alternative might be to locally or globally disable the warning.

For testing, one can use a fresh install of Fedora 38:

```
dnf install gcc-c++ libtool make autoconf automake python3 clang llvm lbzip2 patch xz cmake curl wget htop git vim ccache libevent-devel boost-devel qt5-qttools-devel qt5-qtbase-devel -y && git clone https://github.com/bitcoin/bitcoin.git ./bitcoin-core && cd bitcoin-core && ./autogen.
...
πŸ‘ hebasto approved a pull request: "add ryanofsky to trusted-keys"
(https://github.com/bitcoin/bitcoin/pull/27604#pullrequestreview-1418209420)
ACK 59ebee3fb4181baf20fab263cf1b587ece1bd5e2

My local gpg output:
```
$ gpg --list-keys 4D1B3D5ECBA1A7E05371EEBE46800E30FC748A66
pub rsa4096 2022-01-07 [SC] [expires: 2024-01-07]
4D1B3D5ECBA1A7E05371EEBE46800E30FC748A66
uid [ unknown] Ryan Ofsky <ryan@ofsky.org>
sub rsa4096 2022-01-07 [E] [expires: 2024-01-07]

```
πŸ’¬ ArmchairCryptologist commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1539774342)
Just to confirm, after a day or so I'm seeing the same kind of CPU load increasing over time with the node I downgraded to 23.0.0, so this other issue probably was not introduced with 24.0.1.

Reducing maxconnections to a low-ish number (100 or less) seems to at least significantly delay the problem, though I can't say yet whether it'll mitigate it entirely.

> I didn't restart the node, but used the setban approach as pointed out here https://github.com/bitcoin/bitcoin/issues/27586#issuecom
...
⚠️ ETCorps opened an issue: "ihsota ottomakan"
(https://github.com/bitcoin/bitcoin/issues/27606)
### Motivation

```

> 3D33H333A3C33M333-3@33#333O3r33p333h3e33u333s3a33n333g3e33l333s3
> AutomaticRegenerativeHex:Binary hash:For protection of account info 3@3(*?)3#33{*?#/!}(*?)3O3r3(*?)3p3{*?#/!}3(*?)3h3e3(*?)3{*?#/!}u33(*?)3s3a3{*?#/!}(*?)3n33(*?)3g3{*?#/!}e3(*?)3l33(*?)3{*?#/!}s3
>
> (*?)=randomly generated alpha numerical value based on the roll of a six sided dice begining with 1 dice then two then three then for then five and on the sixth roll it will be no dice then the process
...