P2Pool - zdecentralizowany pool peer-to-peer [4000 TH/s]

YouTube

Użyj pastebina i wklej kilka/naście linijek dookoła tego błędu.

Postautor: **91az** » wtorek, 15 grudnia 2015, 09:25

rav3n_pl pisze:Każdy kto używa P2Pool pod BTC musi jak najszybciej zrobić update.
https://bitcointalk.org/index.php?topic ... sg11723989
Wchodzi softfork wymagający bloków v3 i ForrestV zrobił update.
Mojego forka nie ruszałem jeszcze, ale też będę musiał to wdrożyć u siebie.
Kod na gicie, binarka do pobrania od forresta (linki w poście bitcointalk) albo z mojego OneDrive.

odkopię

Kolejny update do v4 / 15.0.1

Kod: Zaznacz cały

P2Pool release 15.0 - commit hash: 86bbdac7eaaa03438e71ee9dcb11898c7b2b8bdf

HARDFORK - Upgrade URGENTLY required in the next few days.

https://bitcointalk.org/index.php?topic=18313.0

Switchover imminent. Upgraded: 80.636% Threshold: 95.000%

YouTube · Postautor: **rav3n_pl** » wtorek, 15 grudnia 2015, 10:09

Dotyczy oczywiście BTC i wchodzących kolejnych BIPów z blokami wersji v4.

Postautor: **91az** » wtorek, 15 grudnia 2015, 10:19

@rav3n_pl

Miałem nadzieję, że czytujesz jeszcze ten wątek

Czy mam wrażenie, czy też core 0.11.2 (Linux x64) zaczął się zachowywać jakby miał wycieki pamięci. Mam wrażenie, że bez okazjonalnych restartów dedykowanego węzła co 12h wielkość alokowanej pamięci i GBT Latency zaczyna lecieć w kosmos?

http://p2pool2.91az.pro:9332/static/graphs.html?Day

Maszyna z 4 Gb RAM i 4xXeon 5500

Postautor: **hanti** » wtorek, 15 grudnia 2015, 10:45

ja musialem dodac
minrelaytxfee=0.00006
limitfreerelay=5

ale jesli na 0.11 nie miales problemow to pewnie cos innego

Postautor: **91az** » wtorek, 15 grudnia 2015, 11:24

hanti pisze:ja musialem dodac
minrelaytxfee=0.00006
limitfreerelay=5

ale jesli na 0.11 nie miales problemow to pewnie cos innego

Przesiadłem się z core 0.10.x i p2pool v13.3. Nie śledziłem zbyt uważnie zmian p2pool i ominęło mnie 14.x za co słono jak mi się wydaje zapłaciłem :-/

U mnie (obecnie):

Kod: Zaznacz cały

mintxfee=0.0005 
minrelaytxfee=0.0005 
maxconnections=10
limitfreerelay=5

/edit
a jaką stosujesz wartość maxblocksize ?

Postautor: **hanti** » wtorek, 15 grudnia 2015, 11:50

blockmaxsize mam defaultowo ale ja nie uzywam p2pool podalem tylko config swoj na nodzie bitcoind. Ogolnie siec jest spamowana jakimis niepotrzebnymi transakcjami i wlasnie nody sie przez to zapychaja

Coraz wiecej zajmuja pamieci bo ciagle przybywa w mempool roznych smieciowych transakcji. Podobno w wersji 0.12 zostanie to rozwiazane.

Postautor: **91az** » wtorek, 15 grudnia 2015, 11:53

hanti pisze:blockmaxsize mam defaultowo ale ja nie uzywam p2pool podalem tylko config swoj na nodzie bitcoind. Ogolnie siec jest spamowana jakimis niepotrzebnymi transakcjami i wlasnie nody sie przez to zapychaja Podobno w wersji 0.12 zostanie to rozwiazane

Cóż czekamy w takim razie na nowe błędy w 0.12

Na razie podniosłem maxblocksize na 750000 i GBTL wygląda lepiej. Zobaczymy.

YouTube · Postautor: **rav3n_pl** » wtorek, 15 grudnia 2015, 13:56

GBT wynika w prost z mempoola. Jak nie ograniczysz "śmieci" to domowa maszyna nie ma szans.
Możesz poprawić przez zmianę (podniesienie) mintxfee, minrealytxfee i obniżenie maxblocksize, limitfreerelay.
Jak ktoś robi "prawdziwą" kopalnię to demon musi mieć zapas + cache GBT i inne cuda. Na P2Pool w domu trzeba inaczej

Postautor: **powered** » wtorek, 15 grudnia 2015, 21:18

Gdy ja kopie solo (na wersji bitcoin core 0.9.5 bo w nowszej to nie umiem) to po kilkunastu godzinach pożera mi z 3.5 GB ramu.

Postautor: **lerek** » poniedziałek, 1 lutego 2016, 21:32

rav3n_pl pisze:GBT wynika w prost z mempoola. Jak nie ograniczysz "śmieci" to domowa maszyna nie ma szans.
Możesz poprawić przez zmianę (podniesienie) mintxfee, minrealytxfee i obniżenie maxblocksize, limitfreerelay.
Jak ktoś robi "prawdziwą" kopalnię to demon musi mieć zapas + cache GBT i inne cuda. Na P2Pool w domu trzeba inaczej

Możesz rozwinąć w domu trzeba inaczej ?

YouTube

No przecież napisałem. W domowym węźle ograniczasz transakcje w mempoolu przez zwiększenie wymagań.

Odkopię. Ktoś jeszcze korzysta z P2P? Wygląda, że technologia umarła - prawda to?

Lub inaczej - czy kopanie w p2p jest bezpieczne? Taki elizium.name widzę, że funkcjonuje. Nie ma ryzyka z wypłatą? Jakieś forki czy inne duperele wpływają na p2p?

YouTube

Węzeł na którym kopiesz musi być aktualny - widać to łatwo bo ma "normalne" statystyki (ma jakieś share i effie 95+). Łatwo porównać czy kopie ten sam łańcuch patrząc na wykres mocy i porównując z innym węzłem.
Jest to najbezpieczniejsza kopalnia, bo nawet jak padnie/zostanie wyłączony/shakowany/zddosowany węzeł na którym kopiesz to Twój urobek i tak jest w pamięci innych węzłów i możesz spokojnie kopać dalej na innym węźle.

rav3n_pl pisze:Węzeł na którym kopiesz musi być aktualny - widać to łatwo bo ma "normalne" statystyki (ma jakieś share i effie 95+). Łatwo porównać czy kopie ten sam łańcuch patrząc na wykres mocy i porównując z innym węzłem.
Jest to najbezpieczniejsza kopalnia, bo nawet jak padnie/zostanie wyłączony/shakowany/zddosowany węzeł na którym kopiesz to Twój urobek i tak jest w pamięci innych węzłów i możesz spokojnie kopać dalej na innym węźle.

Node p2pool version: 15.0-dirty
Protocol version: 1500
Wartość bloku wyaje się prawidłowa, share przyjmuje, hashrate wygląda na ok. Porównując http://elizium.name:9332/static/ z http://btc.hassocksmining.co.uk/bitpool/ to wygląda na to że hassocks jest nowszy. I tu pojawia się pytanie: czy bezpiecznie jest kopać na elizium (rewelacyjny ping) czy lepiej przejść na hassocks (nowszy mimo, że ping gorszy).

Co ciekawe pokazuje różną wartość kopanego bloku. To prawidłowo? Każdy node kopie inny blok?

ExcaliburPLL pisze: Co ciekawe pokazuje różną wartość kopanego bloku. To prawidłowo? Każdy node kopie inny blok?

Nie może być takiej sytuacji. Wszystkie kopalnie/koparki jednocześnie szukają tego samego rozwiązania. Co do różnicy wartości bloku to raczej są to opóźnione dane, te które są tam wyświetlone. Tutaj dane o wartości bloku powinny być aktualne https://blockchain.info/pl/unconfirmed-transactions

To ja już nic nie rozumiem. Co jak co ale nody p2p powinny być szybkie a tu różnice są na poziomie 0.5BTC - trochę za dużo jak dla mnie.

elizium: 12.76BTC
hassocks: 13.22BTC

Linki do nich dałem wyżej.

Dodano po 49 sekundach:
A co z tą wersją nodów? Lepiej kopać na nowszym czy to nie ma znaczenia?

Postautor: **hanti** » poniedziałek, 25 lipca 2016, 21:05

nie nie, wszystko zalezy od ustawien bitcoind do ktorego podlaczony jest p2pool. Normalna rzecz, ze sie roznia wartosci

Dodano po 1 minucie 41 sekundach:
widac hassocks ma ustawione transakcje z min fee dosyc duzym, dobre dla kopaczy gorsze dla userow btc jesli hassocks trafiaja blok

YouTube

Każdy węzeł kopie inny blok, każdy może ustawić sobie jakie transakcje wciąga do Core i jakiej wielkości będzie blok. Aby przyspieszyć działanie "małe" węzły często mocno ograniczają mempool i tym samym wielkość bloku (a zyskują na opóźnieniu GBT).
Częścią wspólną kopaną przez wszystkie węzły P2Pool jest transakcja generacji która zawiera nagrodę dla wszystkich kopaczy poola.

Dodano po 2 minutach 15 sekundach:
Dopiero doczytałem że ETA bloku w P2Pool to aż 12 dni

Jako, że liczą się ostatnie ~3 dni jak ktoś zacznie kopać to lepiej kopać aż wpadnie blok.

Dodano po 22 sekundach:
TAM JEST TYLDA A NIE MINUS

rav3n_pl pisze: Każdy węzeł kopie inny blok,

Jak to inny blok? Wszyscy naraz starają się trafić i zatwierdzić obecny (jeszcze nie istniejący) blok.
Natomiast rozjaśniłeś sprawę w różnicy w fee jaką blok będzie zawierał. Jeżeli kopalnie wybierają sobie transakcję, to wtedy mają wpływ na wartość bloku. Ale transakcji cały czas przybywa więc ta wartość powinna się zmieniać cały czas. No chyba że w kolejce czeka już dużo transakcji z których można już wcześniej wybrać te najlepsze dopełniając blok do 1MB

I czemu górnicy nie chcą kopać w P2Pool? Kiedy zrozumieją że kopalnie nie dzielą się z nimi opłatą transakcyjną? Jak nagroda za blok i fee będą miały podobną wartość? Obecne opłaty transakcyjne to około 5-10% nagrody.