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

Bump default value of MAX_SEND to 1m bytes.

Browse Source 
Otherwise historic large txs could not be served to clients.
This commit is contained in:
Neil Booth 2016-11-26 14:51:31 +09:00
parent 95a2de6dae
commit 4e26e0fe96
3 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
RELEASE-NOTES
View File

@ -1,3 +1,11 @@
version 0.7.11
--------------
- increased MAX_SEND default value to 1 million bytes so as to be able
to serve large historical transactions of up to 500K in size. The
MAX_SEND floor remains at 350,000 bytes so you can reduct it if you
wish.
version 0.7.10 version 0.7.10
-------------- --------------

16
docs/ENV-NOTES
View File

@ -45,20 +45,22 @@ each and are processed efficiently. I feel the defaults are low and
encourage you to raise them. encourage you to raise them.
MAX_SEND - maximum size of a response message to send over the wire, MAX_SEND - maximum size of a response message to send over the wire,
in bytes. Defaults to 350,000 and will treat smaller in bytes. Defaults to 1,000,000 and will treat values
values as the same because standard Electrum protocol smaller than 350,000 as 350,000 because standard Electrum
header chunk requests are nearly that large. protocol header chunk requests are almost that large.
The Electrum protocol has a flaw in that address The Electrum protocol has a flaw in that address
histories must be served all at once or not at all, histories must be served all at once or not at all,
an obvious avenue for abuse. MAX_SEND is a an obvious avenue for abuse. MAX_SEND is a
stop-gap until the protocol is improved to admit stop-gap until the protocol is improved to admit
incremental history requests. Each history entry incremental history requests. Each history entry
is appoximately 100 bytes so the default is is appoximately 100 bytes so the default is
equivalent to a history limit of around 3,500 equivalent to a history limit of around 10,000
entries, which should be ample for most legitimate entries, which should be ample for most legitimate
users. Increasing by a single-digit factor is users. If you increase this bear in mind one client
likely fine but bear in mind one client can request can request history for multiple addresses. Also,
history for multiple addresses. the largest raw transaction you will be able to serve
to a client is just under half of MAX_SEND, as each raw
byte becomes 2 hexadecimal ASCII characters on the wire.
MAX_SUBS - maximum number of address subscriptions across all MAX_SUBS - maximum number of address subscriptions across all
sessions. Defaults to 250,000. sessions. Defaults to 250,000.
MAX_SESSION_SUBS - maximum number of address subscriptions permitted to a MAX_SESSION_SUBS - maximum number of address subscriptions permitted to a

2
server/env.py
View File

@ -45,7 +45,7 @@ class Env(LoggedClass):
self.donation_address = self.default('DONATION_ADDRESS', '') self.donation_address = self.default('DONATION_ADDRESS', '')
self.db_engine = self.default('DB_ENGINE', 'leveldb') self.db_engine = self.default('DB_ENGINE', 'leveldb')
# Server limits to help prevent DoS # Server limits to help prevent DoS
self.max_send = self.integer('MAX_SEND', 250000) self.max_send = self.integer('MAX_SEND', 1000000)
self.max_subs = self.integer('MAX_SUBS', 250000) self.max_subs = self.integer('MAX_SUBS', 250000)
self.max_session_subs = self.integer('MAX_SESSION_SUBS', 50000) self.max_session_subs = self.integer('MAX_SESSION_SUBS', 50000)
# IRC # IRC