Ogromna większość węzłów za NAT (bez przekierowania portów) - Stan sieci jest kiepski

[McGravier]

Jakiś czas temu dyskutowałem z LukeJr na reddicie,


i z naszej wymiany zdań dowiedziałem się czegoś bardzo niepokojącego:

UPnP was disabled by default after a number of security vulnerabilities in the UPnP code in v0.12 (2015). Furthermore, there is no real need for more listening nodes - the important part is that people run full nodes at all, not whether they are listening.

UPnP jest ważnym mechanizmem automatycznej konfiguracji, która zajmuje się między innymi przekierowaniem portów. Węzeł który nie posiada przekierowanych portów, jest w stanie nawiązać połączenie z węzłem z otwartymi portami, ale nie może połączyć się z drugim węzłem który ma zamknięte porty. Efektywnie węzeł z zamkniętymi portami musi być obsłużony przez węzeł z otwartymi.

Pogrzebałem w necie, i znalazłem dwie metody zliczania ilości węzłów
- pierwsza opierająca się crawlerze łączącym się aktywnie z węzłami pozwala na wykrywanie węzłów posiadających przekierowane porty
przykład:
https://bitnodes.21.co/dashboard/
https://coin.dance/nodes/all

- druga (pasywna) zlicza wszystkie węzły, które łączą się z crawlerem - narzędzie napisał zresztą sam LukeJr


Statystyki są dosyć brzydkie.
Wedle coindance, pod koniec marca 2017 było około 6750 węzłów z otwartymi portami.

W tym samym czasie ogólna ilość węzłów wynosiła (wg pasywnego crawlera) ok. 57000 węzłów

Oznacza to efektywnie że te 6750 węzłów musi obsługiwać pozostałe 50 000!!!

Mimo iż mamy zaledwie 1MB bloki = 4,3GB miesięcznie (plus jakiś tam overhead), niektórzy użytkownicy raportują że ich węzły BTC muszą wysłać nawet 200GB danych na miesiąc. SegWit czy jakie kolwiek inne zwiększenie rozmiaru bloku, wywinduje te wymagania jeszcze wyżej.

Nie wiem czym kieruje się Core, prowadząc politykę domyślnego wyłączenia UPnP - moim zdaniem bugi powinny zostać załatane i funkcja domyślnie włączona. Inaczej nadal otwarte węzły (które muszą być konfigurowane ręcznie) będą musiały obsługiwać masę pasożytów, a zwiększenie bloku tylko pogorszy sprawę. Co gorsza to tak pracuje już od dwóch lat - taki stan rzeczy zakrawa na niekompetencję...

[rav3n_pl]

Gros ludzi ma zmienne IP, więc ta liczba może być znacznie zawyżona.
Aż z ciekawości zdejmę limit połączeń przychodzących i zobaczę ile uda mi się uzyskać

Dodano po 56 sekundach:

będą musiały obsługiwać masę pasożytów

Ojtam, to tylko pijawki... ;]

[McGravier]

Gros ludzi ma zmienne IP, więc ta liczba może być znacznie zawyżona.

To prawda - zwłaszcza jeśli pomiar był wykonywany w długim okresie czasu (powyżej 24h)

Ale nawet jeśli mamy 20-30% przekłamania, to i tak sytuację można mocno poprawić.

[baggins]

nie wiem czy to jest realny problem... ja mam prehistoryczne łącze 1Mb i około 60 nawiązanych połączeń (kiedyś na szybszym dobijało do 100) - i jeszcze youtube chodzi więc mogę obsługiwać tych bez otwartych portów bez bólu

[rav3n_pl]

W sumie nie przesadzajmy. 2MB blok (4MB danych w segwit) na 10 minut to ciągły strumień 6kb/s, łącze 1MB zatkamy dopiero 20 klientami którzy ciągną tylko od nas, a klient ma co najmniej 6 połączeń. Czyli dopiero ok 120 połączeń może nas wysycić.

[powered]

A jakie są wnioski? Z czego to wynika?
Wszystkie nowe routery domyślnie mają wyłączone UPnP?
Czy to bitcoin nie umie współpracować z UPnP?
Czy większość administratorów sieci celowo wyłącza UPnP?

[McGravier]

A jakie są wnioski? Z czego to wynika?
Wszystkie nowe routery domyślnie mają wyłączone UPnP?
Czy to bitcoin nie umie współpracować z UPnP?
Czy większość administratorów sieci celowo wyłącza UPnP?

- Praktycznie wszystkie routery mają domyślnie włączone UPnP
- Klient bitcoin Core posiada zdolność do współpracy z UPnP ale jest ona domyślnie wyłączona
- Sądzę że większość administratorów sieci pozostawia UPnP włączone (wedle ustawień domyślnych)

Niestety o przyczyny wyłączenia UPnP w kliencie Core, musisz pytać deweloperów tego klienta - ja nie widzę uzasadnienia innego jak zwykła niedbałość

[rav3n_pl]

UPnP w Core zostało wyłączone ze względu na masę routerów które mając aktywne i działające przekierowanie UPnP stawały się podatne na ataki z zewnątrz ORAZ błąd w bibliotece używanej przez core: https://bitcoin.org/en/alert/2015-10-12 ... nerability (do wersji 0.11).

Nie wiem, czy sytuacja z routerami się poprawiła w ostatnim czasie, ale bez ustawienia w kliencie włączenia UPnP (klient domyślnie kompilowany jest z modułem UPnP ale jest on wyłączony w domyślnej konfiguracji) Core musi polegać na userze, że ten łaskawie otworzy odpowiedni port.

Włączenie UPnP w QT to ptaszek w konfiguracji, a w każdym dodatnie "upnp=1" w bitcoin.conf załatwia temat.

[powered]

W Core w tym samym czasie pewnie zostało wyłączone dużo więcej funkcji. Teraz kojarzę że od pewnej wersji nie mogłem kopać solo gdy core był na innym komputerze w sieci lokalnej i nie umiałem znaleźć powodu w czym problem.

[McGravier]

UPnP w Core zostało wyłączone ze względu na masę routerów które mając aktywne i działające przekierowanie UPnP stawały się podatne na ataki z zewnątrz

To ciekawe, pamiętam problem z wadliwym kodem w Core, ale o tym że na rynku jest masa dziurawych routerów nie wiedziałem - masz jakieś linki z dodatkowymi informacjami na ten temat?

I jak to się ma do innych projektów (zarówno kryptowalutowych jak i pozostałych) które mają domyślnie włączone UPnP?

[rav3n_pl]

Paczaj tu: http://www.upnp-hacks.org/