Skip to content

Conversation

@laanwj
Copy link
Member

@laanwj laanwj commented Nov 28, 2016

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.

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.
@laanwj laanwj force-pushed the 2016_11_torcontrol_key_ttpe branch from 6da5810 to 7d3b627 Compare November 28, 2016 16:18
@btcdrak
Copy link
Contributor

btcdrak commented Nov 28, 2016

utACK

@sipa
Copy link
Member

sipa commented Nov 28, 2016

utACK 7d3b627

@fanquake
Copy link
Member

utACK 7d3b627

1 similar comment
@paveljanik
Copy link
Contributor

utACK 7d3b627

@gmaxwell
Copy link
Contributor

utACK; do we know how far back tor version wise this is supported?

@laanwj
Copy link
Member Author

laanwj commented Nov 29, 2016 via email

@laanwj
Copy link
Member Author

laanwj commented Nov 29, 2016

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.

@gits7r
Copy link

gits7r commented Nov 29, 2016

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 BEST key type when there is a p2p protocol 'address' limitation (I don't think the limit should go away, just increased just enough to keep up with current demands).

@gmaxwell
Copy link
Contributor

gmaxwell commented Nov 30, 2016

ACK. (tested now)

@laanwj laanwj merged commit 7d3b627 into bitcoin:master Nov 30, 2016
laanwj added a commit that referenced this pull request Nov 30, 2016
7d3b627 torcontrol: Explicitly request RSA1024 private key (Wladimir J. van der Laan)
laanwj added a commit that referenced this pull request Nov 30, 2016
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
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Nov 30, 2016
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
@maflcko
Copy link
Member

maflcko commented Nov 30, 2016

Was backported to 0.13 in 94531b5. (Removing label)

Added backport for 0.12 to #9211

UdjinM6 pushed a commit to UdjinM6/dash that referenced this pull request Mar 22, 2017
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
UdjinM6 added a commit to dashpay/dash that referenced this pull request Apr 11, 2017
* 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
thokon00 pushed a commit to faircoin/faircoin that referenced this pull request Apr 17, 2018
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
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants