RanchiMall/electrumx
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Accept IPv6 addresses in DAEMON_URL

Browse Source 
Fixes #126
This commit is contained in:
Neil Booth 2017-02-16 08:00:08 +09:00
parent 60ad792179
commit 82d57dc90f
2 changed files with 74 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
docs/PEER_DISCOVERY.rst
View File

@ -49,13 +49,21 @@ This RPC call is used by Electrum clients to get a list of peer
servers, in preference to a hard-coded list of peer servers in the servers, in preference to a hard-coded list of peer servers in the
client, which it will fall back to if necessary. client, which it will fall back to if necessary.
The response should only include peers it has successfully connected The server should craft its response in a way that reduces the
to recently. If Tor routing is not available to the server, so it effectiveness of sybil attacks and peer spamming.
cannot connect to them, it should return a random limited number of
onion peers it is aware of.
In ElectrumX, "recently" is taken to be the last 24 hours, and it will The response should only include peers it has successfully connected
serve up to 3 onion peers if onion routing is not available. to recently. If Tor routing is not available, so their existence
cannot be verified, the response should include some hard-coded onion
peers so that clients always have a choice of onion servers.
Only reporting recent good peers ensures that those that have gone
offline will not be passed around for long (ignoring for hard-coded
onion peer exception).
In ElectrumX, "recently" is taken to be the last 24 hours. Only one
peer from each IPv4/16 netmask is returned, and the number of onion
peers is limited.
Maintaining the Peer Database Maintaining the Peer Database
@ -63,46 +71,64 @@ Maintaining the Peer Database
In order to keep its peer database up-to-date and fresh, if some time In order to keep its peer database up-to-date and fresh, if some time
has passed since the last successful connection to a peer, an Electrum has passed since the last successful connection to a peer, an Electrum
server should make an attempt to connect, choosing the TCP or SSL port server should make an attempt to connect, choosing either the TCP or
at random if both are available. On connecting it should issue SSL port. On connecting it should issue **server.peers.subscribe**
**server.peers.subscribe** and **server.features** RPC calls to and **server.features** RPC calls to collect information about the
collect information about the server and its peers, and issue a server and its peers, and if it is the first time connecting to this
**server.add_peer** call to advertise itself. Once this is done and peer, a **server.add_peer** call to advertise itself. Once this is
replies received it should terminate the connection. done and replies received it should terminate the connection.
The peer database should prefer information obtained from the peer The peer database should view information obtained from an outgoing
itself over information obtained from any other source. connection as authoritative, and prefer it to information obtained
from any other source.
If a connection attempt fails, reconnection should follow some kind of On connecting, a server should confirm the peer is serving the same
exponential backoff. If a long period of time has elapsed since the network, ideally via the genesis block hash of the **server.features**
successful connection attempt, the peer entry should be removed from RPC call below. If the peer does not implement that call, perhaps
the database. instead check the **blockchain.headers.subscribe** RPC call returns a
peer block height within a small number of the expected value. If a
peer is on the wrong network it should never be advertised to clients
or other peers. Such invalid peers should perhaps be remembered for a
short time to prevent redundant revalidation if other peers persist in
advertising them, and later forgotten.
ElectrumX will choose the SSL port most of the time if both ports are If a connection attempt fails, subsequent reconnection attempts should
available. It tries to reconnect to each peer once every 24 hours and follow some kind of exponential backoff.
drops peers if two weeks have passed since a successful connection.
If a long period of time has elapsed since the last successful
connection attempt, the peer entry should be removed from the
database. This ensures that all peers that have gone offline will
eventually be forgotten by the network entirely.
ElectrumX will connect to the SSL port if both ports are available.
If that fails it will fall back to the TCP port. It tries to
reconnect to a good peer at least once every 24 hours, and a failing
after 5 minutes but with exponential backoff. It forgets a peer
entirely if two weeks have passed since a successful connection.
ElectrumX attempts to connect to onion peers through a Tor proxy that
can be configured or that it will try to autodetect.
server.features RPC call server.features RPC call
------------------------ ------------------------
This is a new RPC call that a server can use to advertise what This is a new RPC call that a server can use to advertise what
services and features it offers. It is intended for use by Electrum services and features it offers. It is intended for eventual use by
clients as well as peer servers. In the case of servers it is useful Electrum clients as well as other peers. Peers will use it to gather
in order to have database peer information sourced from the peer peer information from the peer itself.
itself.
The call takes no arguments and returns a dictionary keyed by feature The call takes no arguments and returns a dictionary keyed by feature
name whose value gives details about the feature where appropriate. name whose value gives details about the feature where appropriate.
If a key is missing the feature is presumed not to be offered. If a key is missing the feature is presumed not to be offered.
Currently ElectrumX understands and returns the following keys: Currently ElectrumX understands and returns the following keys.
Unknown keys should be silently ignored.
* **hosts** * **hosts**
An dictionary, keyed by host name, that this server can be reached An dictionary, keyed by host name, that this server can be reached
at. Normally this will only have a single entry; other entries can at. Normally this will only have a single entry; other entries can
be used in case there are other connection routes (e.g. ToR). be used in case there are other connection routes (e.g. Tor).
The value for a host is itself a dictionary, with the following The value for a host is itself a dictionary, with the following
optional keys: optional keys:
@ -120,21 +146,28 @@ Currently ElectrumX understands and returns the following keys:
A server should ignore information provided about any host other A server should ignore information provided about any host other
than the one it connected to. than the one it connected to.
* **genesis_hash**
The hash of the genesis block. This is used to detect if a peer is
connected to one serving a different network.
* **server_version** * **server_version**
A string that identifies the server software. Should be the same as A string that identifies the server software. Should be the same as
the response to **server.version** RPC call. the response to **server.version** RPC call.
* **protocol_version** * **protocol_max**
* **protocol_min**
A string that is the Electrum protcol version. Should be the same Strings that are the minimum and maximum Electrum protcol versions
as what would suffix the letter 'v' in the IRC real name. this server speaks. Should be the same as what would suffix the
letter **v** in the IRC real name. Example: "1.1".
* **pruning** * **pruning**
An integer, the pruning limit. Omit or set to *null* if there is no An integer, the pruning limit. Omit or set to *null* if there is no
pruning limit. Should be the same as what would suffix the letter pruning limit. Should be the same as what would suffix the letter
'p' in the IRC real name. **p** in the IRC real name.
server.add_peer RPC call server.add_peer RPC call
@ -151,8 +184,10 @@ A server receiving a **server.add_peer** call should not replace
existing information about the host(s) given, but instead schedule a existing information about the host(s) given, but instead schedule a
separate connection to verify the information for itself. separate connection to verify the information for itself.
To prevent abuse a server may want to ignore excessive calls to this To prevent abuse a server may do nothing with second and subsequent
function. calls to this method from a single connection.
The result should be True if accepted and False otherwise.
IRC IRC
@ -160,6 +195,8 @@ IRC
Other server implementations may not have implemented the peer Other server implementations may not have implemented the peer
discovery protocol yet. Whilst we transition away from IRC, in order discovery protocol yet. Whilst we transition away from IRC, in order
to keep these servers in the connected peer set, software implementing to keep these servers in the connected peer set, having one or two in
this protocol should provide a way to occasionally connect to IRC to the hard-coded peer list used to seed this process should suffice.
pick up stragglers only advertising themselves there. Any peer on IRC will report other peers on IRC, and so if any one of
them is known to any single peer implementing this protocol, they will
all become known to all peers quite rapidly.

2
lib/coins.py
View File

@ -34,7 +34,7 @@ class Coin(object):
REORG_LIMIT = 200 REORG_LIMIT = 200
# Not sure if these are coin-specific # Not sure if these are coin-specific
RPC_URL_REGEX = re.compile('.+@[^:]+(:[0-9]+)?') RPC_URL_REGEX = re.compile('.+@(\[[0-9:]+\]|[^:]+)(:[0-9]+)?')
VALUE_PER_COIN = 100000000 VALUE_PER_COIN = 100000000
CHUNK_SIZE = 2016 CHUNK_SIZE = 2016
IRC_SERVER = "irc.freenode.net" IRC_SERVER = "irc.freenode.net"