-
Notifications
You must be signed in to change notification settings - Fork 38.7k
torcontrol: Explicitly request RSA1024 private key #9234
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
Conversation
When generating a new service key, explicitly request a RSA1024 one. The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit. See bitcoin#9214.
6da5810 to
7d3b627
Compare
|
utACK |
|
utACK 7d3b627 |
|
utACK 7d3b627 |
1 similar comment
|
utACK 7d3b627 |
|
utACK; do we know how far back tor version wise this is supported? |
|
I'm quite sure choosing "RSA1024" instead of "BEST" has always been
supported - why have a key type parameter otherwise.
The only reason I've chosen "BEST" here originally was that I was unaware
that a different key type could change the address format to something
bitcoin can't handle.
|
|
The parameter is documented here: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1446 There is no mention of any version constraints relevant to KeyBlob. |
|
ACK. I confirm explicitly asking for the key type is supported for as far back as ADD_ONION is. Until RSA1024 keys (v2 HS) are permanently rejected in the Tor network, this patch should work. It's useless to ask for |
|
ACK. (tested now) |
7d3b627 torcontrol: Explicitly request RSA1024 private key (Wladimir J. van der Laan)
When generating a new service key, explicitly request a RSA1024 one. The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit. See #9214. Rebased-From: 7d3b627 Github-Pull: #9234
When generating a new service key, explicitly request a RSA1024 one. The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit. See bitcoin#9214. Github-Pull: bitcoin#9234 Rebased-From: 7d3b627
When generating a new service key, explicitly request a RSA1024 one. The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit. See bitcoin#9214. Github-Pull: bitcoin#9234 Rebased-From: 7d3b627
Tor ephemeral hidden services Cherry-picked from the following upstream PRs: - bitcoin/bitcoin#6503 (included to reduce merge conflicts) - bitcoin/bitcoin#6639 - bitcoin/bitcoin#6643 - bitcoin/bitcoin#7090 - bitcoin/bitcoin#7035 - bitcoin/bitcoin#7170 - bitcoin/bitcoin#7218 (non-QT part) - bitcoin/bitcoin#7313 - bitcoin/bitcoin#7438 - bitcoin/bitcoin#7553 - bitcoin/bitcoin#7637 - bitcoin/bitcoin#7683 - bitcoin/bitcoin#7813 - bitcoin/bitcoin#7703 - bitcoin/bitcoin#8203 - bitcoin/bitcoin#9004 - bitcoin/bitcoin#9234 - bitcoin/bitcoin#9911 (partial) Closes #2061.
* Implement BIP 9 GBT changes - BIP9DeploymentInfo struct for static deployment info - VersionBitsDeploymentInfo: Avoid C++11ism by commenting parameter names - getblocktemplate: Make sure to set deployments in the version if it is LOCKED_IN - In this commit, all rules are considered required for clients to support * qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates * getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not * getblocktemplate: Use version/force mutation to support pre-BIP9 clients * Don't use floating point Github-Pull: bitcoin#8317 Rebased-From: 477777f * Send tip change notification from invalidateblock This change is needed to prevent sync_blocks timeouts in the mempool_reorg test after the sync_blocks update in the upcoming commit "[qa] Change sync_blocks to pick smarter maxheight". This change was initially suggested by Suhas Daftuar <[email protected]> in bitcoin#8680 (comment) Github-Pull: bitcoin#9196 Rebased-From: 67c6326 * torcontrol: Explicitly request RSA1024 private key When generating a new service key, explicitly request a RSA1024 one. The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit. See bitcoin#9214. Github-Pull: bitcoin#9234 Rebased-From: 7d3b627 * Bugfix: FRT: don't terminate when keypool is empty Github-Pull: bitcoin#9295 Rebased-From: c24a4f5 * add fundrawtransaction test on a locked wallet with empty keypool Github-Pull: bitcoin#9295 Rebased-From: 1a6eacb
When generating a new service key, explicitly request a RSA1024 one. The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit. See bitcoin#9214. Github-Pull: bitcoin#9234 Rebased-From: 7d3b627
When generating a new service key, explicitly request a RSA1024 one.
The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit.
See #9214.