-
Notifications
You must be signed in to change notification settings - Fork 36.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v22.0 testing #22634
Comments
For now two issues have been spotted:
|
Compiled v22.0rc2 on PopOS!20.10 (Ubuntu 20.10) and have been testing the External Signers feature. Noticed some strange behaviors which are summarized here: |
Small user issue feedback: Hebastos key cannot be imported from
But import was possible from key server |
bitcoin-22.0rc2 connects to ten Tor nodes with this
|
@wodry thanks -- do you see an I2P local address in -netinfo or getnetworkinfo (if not, have you installed an I2P router, like i2p-router or i2pd)? |
@jonatack No I2P local address with What must be allowed in firewall for I2P for minimum functionality? |
@wodry Do you see 127.0.0.1:7656 in |
According to my understanding first line in this is printed because there was no response in 1 second from i2p router: Line 191 in 39d597d
Line 250 in 39d597d
if( Line 254 in 39d597d
Line 160 in d8f1e13
And Line 19 in 39d597d
|
After allowing TCP+UDP outbound to all ports, it looks better. Now I get log message Testing feedback from me so far:
Addition: |
Thanks for the report!
I'll look at updating |
I think it would be better to have the SHA256SUMS file not contain the directory structure. It's unlikely that a user will have downloaded the release into the directory structure that the SHA256SUMS file expects so a command to verify the hash(es) may not work as expected. It also diverges from what we have done previously so existing verification tooling will probably fail. I've written a fix for this in #22654 |
Compiled Bitcoin core v22.0rc2 on Ubuntu 18.04 and have got the TOR changes and I2P tested. Able to connect to v2 TOR addresses for initial block download and v3 TOR addresses as well. Able to run Bitcoin core over I2P, was able to see the connected peers. Worked as expected in 22.0rc-testing-guide for these two tests. |
Compiled the v22.0rc2 on Ubuntu 20.04 successfully. |
@Saviour1001 possibly many node operators are already moving out of v2 |
Compiled v22.0rc2 from source on Manjaro Linux successfully.
|
Compiled successfully from source: https://github.com/bitcoin/bitcoin/archive/refs/tags/v22.0rc2.zip on Ubuntu20.04 x86_64 GNU/Linux 5.11.0-25-generic
|
@rohitRanjanGIT I believe this error indicates you need to create a wallet on the trezor before you can use it (i.e using trezor suite or the online wallet tool). this will prompt you to create a pin and backup your seed phrase. then you will be able to use the wallet with HWI. apologies, I may have forgotten to mention this step in the testing guide |
I've been running One thing I noticed is that when the node temporarily loses Internet connectivity and gets disconnected from its peers, Tor is much faster to reconnect once Internet is back. Not sure why that is. A few comments on what others have said:
I think the name
I created the referenced issue (I found this thread via the backlink 💯 ). Just one comment here, the warning message did not impact functionality in any visible way, and I'm not even sure if they went away after the upgrade or if they've just been replaced with other ones. I still get a bunch of errors and warnings, see a selection below. I assume it's just Here are my top errors (please note that I use
I only have around 2 of those per week in my logs. Think it's just some harmless & intermittent failure.
I don't know much about By the way, none of the ports need to be reachable from the outside for |
This is expected (based on my research). I had also tried to list few difference and trade-offs in https://bitcoin.stackexchange.com/questions/107060/tor-and-i2p-tradeoffs-in-bitcoin-core
Agree. Maybe we can change it to |
Curious, why do you think it's not more important? If people know that a full IBD sync means 2.4 Terabytes of Tor traffic per node (plus ongoing daily TX traffic) and if people have spare bandwidth, why would they not turn on the relay switch in I think most people just don't realize (a) how taxing it is, (b) how easy it is to flip on the relay switch, and (c) that in most countries there is virtually 0 legal risk & effort for non-exit relay operators (Link 1, Link 2). If you know those facts, why not support something as useful as Tor/I2P? It would help Bitcoin and privacy / free speech / anti-censorship, things that most Bitcoiners like. |
Its important. My comment was based on experience in trying to add such things in doc/tor.md which I tried in PRs: 21157, 22317, 22316 and Issue: 22356. I can write a post about it here: https://blockchaincommons.github.io/Bitcoin-Camouflage/blog/ If you have the patience to work on a PR for months, convince everyone and respond to NACKs (if any) then you should open PR. I will ACK it and don't mind adding few sentences to highlight the importance of running Tor/i2p nodes. |
Tested GUIX-built
|
Tested: Tested the wallet Built with: |
Verified following the testing guide that Note that this part of the testing guide only works with versions of Tor up to 0.4.5.x. Beginning with Tor 0.4.6, which has been available since March, |
Is it reproducible from the clean state? Just checked the downloading source:
|
Can anyone with a PGP key and |
@xanoni anyone can participate and you are welcome to join! For more info, see Also, @hebasto wrote a very helpful summary how-to at https://gist.github.com/hebasto/7293726cbfcd0b58e1cfd5418316cee3 |
Maybe I am doing it wrong but I can't manage to compile on an ubuntu1804 (WSL). Here is my output :
Here is the list of intalled packages:
|
? |
@hebasto as simple as that. Thanks. I finally compiled v22.0rc2 on Ubuntu 1804. nourou@nourou4them:~/bitcoin-22.0rc3$ $BINARY_PATH/bitcoin-cli -datadir=$DATA_DIR -netinfo 4
Bitcoin Core v22.0.0rc3 - 70016/Satoshi:22.0.0/
ipv4 ipv6 onion total block
in 0 0 0 0
out 0 0 0 0 0
total 0 0 0 0
Local addresses: n/a
nourou@nourou4them:~/bitcoin-22.0rc3$ $BINARY_PATH/bitcoin-cli -datadir=$DATA_DIR getpeerinfo
[
] |
Test ok for v3 TOR addresses and I could run bitcoin core over I2P. |
Yes, the Tor v2 network is expected to more or less shut down soon, and when I ran the testing guide with tor 0.4.5 that still supports v2, only two or three of the listed tor v2 addresses seemed up (see also #22634 (comment)). If you run tor 0.4.6 then v2 support is removed. |
Compiled Bitcoin Core version v22.0.0rc3
With hwi.py version 1.2.1, when I try to create the wallet it lets me choose the wallet name and when I click 'Create' it'll show the small window with the loading animation but then it'll abort unexpectedly with the following error message:
When I start up bitcoin qt again I can open the newly created wallet but the button for 'Create new receiving address' is greyed out. note that hwi.py (v1.2.1) is able to connect to the ledger while this happens
|
Closing this issue, as 22.0 was released yesterday. |
ca85967 Don't duplicate builder GPG key in bin verify (James O'Beirne) 41ec90e Clean up obtain_release_key and add keys.txt link (James O'Beirne) cdbe711 Add note about importance of binary verification (James O'Beirne) ca4c331 Remove single release key (James O'Beirne) 5c57c61 Update binary verification instructions for multiple signers (James O'Beirne) Pull request description: Fixes #793. This updates the binary verification instructions to account for the new process, which uses multiple builder signatures on the `SHA256SUMS` file. See bitcoin/bitcoin#22634 for more details. ![image](https://user-images.githubusercontent.com/73197/133864620-c6046d0e-34eb-448c-8769-2e22beb4563e.png) ### Possible follow-ups - [ ] include instructions on how to elevate GPG trust of imported public keys. - [ ] include a reference to bitcoin/bitcoin#23020, pending its merge. ACKs for top commit: harding: Mostly tested ACK ca85967 . Built a preview, carefully read the instructions for all three platforms, and ran the Linux instructions. Windows and MacOS instructions not tested, but the only real difference from the instructions I wrote and had reviewed originally is the filenames, so I'm confident in them. Tree-SHA512: 7396660b7b70a91bf023b4fb6b1a0dec73da98081aa149fddea6ba79e450639e840144a8cf861264dbcf22ca39ee3e5253649fe8324e0bd34db5d6a3e16fdabe
Umbrella issue for 22.0 testing. As there have been changes to the release process and distribution (thanks to the hard work of @dongcarl and others), I expect some more issues to come up than with the usual major release. Please help testing on a wide variety of supported platforms, as well as interaction with different software.
Let us know which version you tested on which operating system.
If you find an issue, please search Github for known issues first and then open a new Github issue. This meta issue should not be used to report bugs, as a single thread makes it impossible to track more than one topic.
See Draft Release Notes for a list of changes, and testing reports for earlier releases (v0.19.0), for an idea what to test.
For suggestion on how and what to test see the 22.0 Release Candidate Testing Guide.
rc2 announcement: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2021-August/000100.html
Release schedule: Release schedule for 22.0 #20851
Note on verifying the binaries
(updated as of rc2)
We are retiring the Bitcoin Core binary release signing key for new major releases. This single key (by @laanwj) was always used to sign
SHA256SUMS.asc
.Instead, the idea is to use the attestations of the deterministic builders (GUIX builders) directly. Instead of a single
SHA256SUMS.asc
there will be two files shipped with the distribution:SHA256SUMS
with hashes of the distributed binaries.SHA256SUMS.asc
file with concatenated GPG signatures of the different builders/attesters who attest to the same single output:To verify, first check the signatures
This will show an output like:
Make sure it has good signatures by people you trust to do a Bitcoin Core release.
Then, verify the file hashes:
The text was updated successfully, but these errors were encountered: