From: Andy Schroder <info@AndySchroder•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Authentication BIP
Date: Mon, 8 Aug 2016 13:09:45 -0400 [thread overview]
Message-ID: <57A8BCD9.7050402@AndySchroder.com> (raw)
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>
[-- Attachment #1.1: Type: text/plain, Size: 3877 bytes --]
On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.
I have mixed feelings about strictly tying the identity-public-keys with
a network identifier. I think the purpose of this is to detect if
someone has physically stolen and compromised my bitcoin node and placed
it on another network under control of an attacker. This seems to be a
bit of a benefit, however, an attacker could always spoof the original
network identifier anyway.
I run my bitcoin node on an internet connection that does not guarantee
a static IP address (although it usually stays the same for several
weeks or months at a time). I'd like to be able to make secure
connections back to my own node, even if I know the IP address may
change from time to time. There are several reasons for wanting to this
with a changing IP. The first is because the bandwidth on my internet
connection with a guaranteed static IP address is considerably more
expensive than my internet connection without a guaranteed static IP
address. The second reason is because the DNS PTR record for my static
IP address is personally identifiable based on other reasons/services.
The internet connection that my bitcoin node is using without a
guaranteed static IP address just has a PTR record that basically
includes my IP address and ISP name. This isn't much use to the general
public (although my ISP obviously knows who I am). The third reason is
that I consider it a good thing from a privacy perspective if my IP
address changes every once and a while.
Maybe a strict check option where the identity-public-keys must
optionally match a specific network identifier would be a compromise?
Maybe this is up to the client implementation to decide, so it should
just be suggested in the BIP rather than required?
> # ___authorized-peers___ contains authorized identity-public-keys
Is there an option for a wildcard here? Couldn't there be a case where
the client wants to authenticate, but the bitcoin node does not care who
it's clients are? This would be similar to many of the http based
bitcoin block explorer API services that are out there. The API
operators have built up some reputation, so people use them, but they
don't necessarily care about who their users are.
> === Local identity key management ===
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
What if I have bitcoind listening on multiple IPv4 interfaces? Can I
have a different identity-key for each IPv4 interface?
Also, would it be possible to only allow this authentication on specific
interfaces? In my example above where I have two internet connections,
if you don't agree to loosening the tie between the network identifier
and the identity-public-keys, maybe I would just connect my bitcoin node
to both internet connections, but only allow a few authorized-peers on
the static IP (which would be low bandwidth), and then not authenticate
on the internet connection with the changing IP at all
If you don't want to increase complexity by adding these options, one
could always accomplish the same thing by runing two instances of
bitcoind and pairing the two over a local network, it would just be a
waste of resources.
> == Disadvantages ==
>
> The protocol may be slow if a peer has a large authorized-peers database
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.
Does openssh have this same problem?
I'm assuming this could be parallelized very easily, so it is not a huge
problem?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2016-08-08 17:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 15:00 Jonas Schnelli
2016-08-08 17:09 ` Andy Schroder [this message]
2016-08-08 17:42 ` Gregory Maxwell
2016-08-08 17:54 ` Andy Schroder
2016-08-09 10:02 ` Jonas Schnelli
2016-08-12 12:47 ` Jonas Schnelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57A8BCD9.7050402@AndySchroder.com \
--to=info@andyschroder$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox