Bitcoin Core Github
44 subscribers
120K links
Download Telegram
💬 fanquake commented on issue "Proposed Timeline for Legacy Wallet and BDB removal":
(https://github.com/bitcoin/bitcoin/issues/20160#issuecomment-1623400014)
> @fanquake Does it not need the performance fix for bdb wallets with a lot of keys first?

I'm not sure. However if we are going to ship this warning that instructs users to use `migratewallet`, I don't think we can leave it marked as experimental.
📝 MarcoFalke opened a pull request: "test: Ignore UTF-8 errors in assert_debug_log"
(https://github.com/bitcoin/bitcoin/pull/28035)
Fix two bugs:

* `debug_log_bytes` returned "an opaque number when in text mode" (https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects), not the number of bytes.
* `read()` fails in text mode when the unicode hasn't been fully written yet. Fixes https://github.com/bitcoin/bitcoin/issues/28030

Fix both bugs by using `"rb"` instead of `"utf-8"`, and by using a non-throwing decode helper.
💬 MarcoFalke commented on issue "wallet_importdescriptors.py: can't decode bytes in position 228861-228863: unexpected end of data":
(https://github.com/bitcoin/bitcoin/issues/28030#issuecomment-1623410610)
https://cirrus-ci.com/task/4872686879375360?logs=ci#L1867

```
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 440222: unexpected end of data
💬 MarcoFalke commented on issue "Intermittent CI failure "fee too high" in wallet_send.py --descriptors ":
(https://github.com/bitcoin/bitcoin/issues/25164#issuecomment-1623414316)
https://cirrus-ci.com/task/4746240760479744?logs=ci#L2770

```
node0 2023-06-30T14:46:07.294496Z [httpworker.1] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=testmempoolaccept user=__cookie__
test 2023-06-30T14:46:07.295000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/tmp/cirrus-ci-build/ci/scratch/build/bitcoin-i686-pc-linux-gnu/test/functional/test_framework/tes
...
⚠️ MarcoFalke reopened an issue: "Intermittent CI failure "fee too high" in wallet_send.py --descriptors "
(https://github.com/bitcoin/bitcoin/issues/25164)
https://cirrus-ci.com/task/6295015969259520

```
test 2022-04-22T21:26:09.984000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/tmp/cirrus-ci-build/ci/scratch/build/bitcoin-i686-pc-linux-gnu/test/functional/test_framework/test_framework.py", line 133, in main
self.run_test()
File "/tmp/cirrus-ci-build/ci/
...
💬 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_r1254282411)
Indeed :-( see https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1253478816 unless @vasild disagrees I'll revert part of my last update and put `keep_alive` back in socks5.py
💬 MarcoFalke commented on pull request "net: Use serialization parameters for CAddress serialization":
(https://github.com/bitcoin/bitcoin/pull/25284#issuecomment-1623488101)
rebased
💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1254309734)
Oh, yes, this is in the "nonce match" branch of the logic that handles PONG. So, the answer to "Could that ever happen before we send our tx messages out?" is just "No".
💬 pinheadmz commented on pull request "exclude ipc scheme from port check":
(https://github.com/bitcoin/bitcoin/pull/28020#issuecomment-1623553674)
See also https://github.com/bitcoin/bitcoin/pull/27679 which closes the same issue and has tests
📝 MarcoFalke opened a pull request: "test: Restore unlimited timeout in IndexWaitSynced"
(https://github.com/bitcoin/bitcoin/pull/28036)
The timeout was unlimited before, so just restore that value for now: https://github.com/bitcoin/bitcoin/pull/27988#issuecomment-1619218007
👍 fanquake approved a pull request: "ci: Print full lscpu output"
(https://github.com/bitcoin/bitcoin/pull/28034#pullrequestreview-1516419650)
ACK fa956d20480b21b0f348b83dd451667620010d8e

https://cirrus-ci.com/task/6617265752244224?logs=ci#L180
```bash
+ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Vendor ID: AuthenticAMD
Model name: AMD EPYC 7B13
...
🚀 fanquake merged a pull request: "ci: Print full lscpu output"
(https://github.com/bitcoin/bitcoin/pull/28034)
💬 MarcoFalke commented on pull request "test: bugfix, synchronize indexes synchronously":
(https://github.com/bitcoin/bitcoin/pull/28026#issuecomment-1623588603)
Went ahead and created the alternative: https://github.com/bitcoin/bitcoin/pull/28036, if reviewers want it. Happy to close it, if this is merged in the meantime.
💬 josibake commented on pull request "[Silent Payments]: Base functionality":
(https://github.com/bitcoin/bitcoin/pull/27827#issuecomment-1623602185)
> > Adds support to the Bitcoin Core wallet for receiving silent payments
>
> Prefer to leave this for a second PR

Can you explain your reasoning for wanting to split it up? I'd prefer to keep them together only because I see no reason to merge sending without receiving support in Bitcoin Core. In terms of work, if the goal is to merge both sending and receiving support, the amount of review doesn't change, and splitting into two PRs seems like unnecessary shuffling of commits
💬 ishaanam commented on pull request "Bump unconfirmed ancestor transactions to target feerate":
(https://github.com/bitcoin/bitcoin/pull/26152#discussion_r1254378046)
In that test don't all of the pre-selected inputs belong to the wallet?
💬 ismaelsadeeq commented on issue "EstimateMedianVal returns higher fee for higher confTarget":
(https://github.com/bitcoin/bitcoin/issues/20725#issuecomment-1623679114)
I try recreating this issue on master HEAD bc4f6b13feb29146b7e10e86f93dc7f6fb6937f2
with the same command `test/functional/feature_fee_estimation.py --randomseed 108574360997204915`

The tests passed.
💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1254444996)
> sending the TX without doing INV/GETDATA first risks having the TX be ignored as unrequested

I thought about doing `INV` first and waiting for get data but decided to not do that for the following reasons:

1. Bitcoin Core accepts unsolicited transactions. According to https://developer.bitcoin.org/reference/p2p_networking.html#tx there is already some software that sends unsolicited transactions.
2. It would add complexity to the implementation.
3. After `INV` we would have to wait for
...
💬 MarcoFalke commented on issue "EstimateMedianVal returns higher fee for higher confTarget":
(https://github.com/bitcoin/bitcoin/issues/20725#issuecomment-1623698708)
@ismaelsadeeq Can you try with the commit specified in OP as well? If it fails, can you try bisecting?
🤔 furszy reviewed a pull request: "index: make startup more efficient"
(https://github.com/bitcoin/bitcoin/pull/27607#pullrequestreview-1516581154)
Updated per feedback, [small diff](https://github.com/bitcoin/bitcoin/compare/94c9b1f37e335c43c739b853bb9457737b67d73a..30b2511f39d32e29f9f05859aa8a97b84c22376b). Thanks ryanofsky!

Changes:
* Documented behavior change when tip has no data in 7944974 commit description.
* Removed the introduced `pruneblockchain` "nothing to prune" error.
* Made `getblockchaininfo` "pruneheight" result consistent with the RPC documentation.