|
|
@ -45,20 +45,22 @@ each and are processed efficiently. I feel the defaults are low and |
|
|
|
encourage you to raise them. |
|
|
|
|
|
|
|
MAX_SEND - maximum size of a response message to send over the wire, |
|
|
|
in bytes. Defaults to 350,000 and will treat smaller |
|
|
|
values as the same because standard Electrum protocol |
|
|
|
header chunk requests are nearly that large. |
|
|
|
in bytes. Defaults to 1,000,000 and will treat values |
|
|
|
smaller than 350,000 as 350,000 because standard Electrum |
|
|
|
protocol header chunk requests are almost that large. |
|
|
|
The Electrum protocol has a flaw in that address |
|
|
|
histories must be served all at once or not at all, |
|
|
|
an obvious avenue for abuse. MAX_SEND is a |
|
|
|
stop-gap until the protocol is improved to admit |
|
|
|
incremental history requests. Each history entry |
|
|
|
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 |
|
|
|
users. Increasing by a single-digit factor is |
|
|
|
likely fine but bear in mind one client can request |
|
|
|
history for multiple addresses. |
|
|
|
users. If you increase this bear in mind one client |
|
|
|
can request history for multiple addresses. Also, |
|
|
|
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 |
|
|
|
sessions. Defaults to 250,000. |
|
|
|
MAX_SESSION_SUBS - maximum number of address subscriptions permitted to a |
|
|
|