The -asmap CLI arg now is given data by default, the first cryptocoin
that I am aware doing this. Bitcoin Core has let asmap stuff languish
on branches and PRs for a very long time, and it indeed has improved,
but people in the streets needs something Right Now.
In Bitcoin Core, -asmap is turned off by default and additionally, it's
quite annoying to generate the file to give to it, which is not included
with Bitcoin Core for either licensing or drama reasons, pick one.
bitcoin-asmap looks promising, but still, will not be enabled by
default, if it ever is merged:
https://github.com/bitcoin/bitcoin/pull/18573
In Hush, we decided to turn it ON BY DEFAULT and additionally,
revolutionarily, we give users the fucking data to use the damn feature,
by default, without them having to do anything. Ignorance is bliss, just
like Extreme Privacy.
Recently SD 1.1.1 learned to do this in it's own inimitable way, so that
release supports this feature without having Hush 3.6.2.
Why is ASN mapping always better than /16 (Class B) Bucketing?
It's just basic math.
* A /16 means 65K "buckets" that a peer can be put into
* Current (Jan 2020) ASN map has 7.4M buckets
That means the ASN bucketing method has over 100000 times more buckets
to put peers into, which means finer-grained filtering of peers
into actual logical networks intead of just IP addresses that are close.
Even an old out of date ASN map will always bucket peers better than a
/16, and all cryptocoins should migrate to doing this by default.
The main reason for this ASN bucketing is to defend against P2P layer
attacks such as the "Erebus Attack"
https://erebus-attack.comp.nus.edu.sg/
There seems to be some build-bug in WolfSSL, such that even though
--enable-harden (HARDEN) is default, it's not set correctly in options.h .
So we define it correctly just after parsing all other config options
BUT BEFORE we load the rest of WolfSSL headers.
These will be defined no matter what options are given to wolfssl ./configure:
ECC_TIMING_RESISTANT
TFM_TIMING_RESISTANT
