CKpool selbst gehostet auf umbrelOS

[duckAxe]

Moin die Runde.

Für diejenigen von euch, die ein Ƀ-Node auf umbrelOS betreiben und Lust haben, CKpool ebenfalls drauf laufen zu lassen, möchte ich mein neues Projekt vorstellen: https://github.com/duckAxe/bassin

Auf GitHub stehen Schritte, die für die Installation notwendig sind. Community Apps sind leider auf umbrelOS ein wenig versteckt. An sich ist es nur ein Klick

Das Projekt ist sehr jung. Mein Ziel ist es, - sollte es Anklang finden - Bassin im offiziellen umbrelOS App Store einzureichen. Damit Public Pool ein wenig Konkurrenz bekommt
Doch bis es soweit ist, sollte es hier in kleiner Runde ausprobiert werden. Später größer.

Der Plan ist, ein simples, überschaubares CKpool-Live-Dashboard für umbrelOS zu schaffen.

Danke für Feedback.

[Stargazer-132]

Klasse! Schau ich mir gerne mal an. Bin mit dem PublicPool nicht so wirklich zufrieden, es sind halt paar Kinderkrankheiten drin und es hat sich schon länger nix mehr getan. CK-Pool finde ich persönlich auch hübscher von den Statistiken her, ist aber Ansichtssache.

Viel mehr stört mich, dass das B-Node seit dem Update auf die neue UI ständig nach paar Stunden / Tagen abschmiert und dann alle Apps wie Electrs, Solopool etc. quasi mit in der Luft hängen.

[willi9974]

Eigentlich eine coole Idee. Aber je mehr man auf einen Node packt desto mehr Angriffsfläche und Fehler entstehen.
Wenn ich einen stabilen Mining Pool Node erstellen würde, dann würde ich den so "schlank" wie möglich halten wollen.
Aber meine Sicht muss ja nicht für jeden gelten, daher cool das du das versuchst.

Ich drücke die Daumen!

Viele Grüße
Willi

[Stargazer-132]

Habs zum Rennen bekommen, dank der beschriebenen Schritte im Link oben auch kein Problem. Wusste gar nicht, dass das so einfach ist ;-)

Schaut schon recht gut aus, schlank, kein BlingBling, CK-Pool ähnliche GUI, mehr brauchts eigentlich auch nicht fürs eigene Solomining.

Blocks found + Odds und eine Skala am Graphen wäre da noch etwas für den Kontrolletti in mir.

Mir gefällt der untere Fortschrittsbalken 60s und die automatische Seitenaktualisierung. Ich werde das mal einige Zeit beobachten, habe da gerade zwei meiner Nano3 ins "Bassin" geschubst. Die ich eh etwas umstellen muss, die haben sporadisch immer mal wieder WLAN Probleme, immer ein anderer meiner insgesamt 4. Der neue Stellplatz im Regal ist wohl nicht so gut in der Kellerecke :-(

[duckAxe]

Bin mit dem PublicPool nicht so wirklich zufrieden, es sind halt paar Kinderkrankheiten drin und es hat sich schon länger nix mehr getan. CK-Pool finde ich persönlich auch hübscher von den Statistiken her, ist aber Ansichtssache.

Geht mir ähnlich. Ich hatte auch schon Code-Änderungen für Public Pool UI auf GitHub eingereicht. Für mich sieht das Projekt - zum aktuellen Zeitpunkt - tot aus. Hoffentlich ändert sich das.

Viel mehr stört mich, dass das B-Node seit dem Update auf die neue UI ständig nach paar Stunden / Tagen abschmiert und dann alle Apps wie Electrs, Solopool etc. quasi mit in der Luft hängen.

Das aktuellste Update hab ich gleich weggeworfen, weil es einfach zu viel RAM zieht. Ich habe dazu was zusammengetragen: https://gist.github.com/duckAxe/cd2da3bf8e98be067028c7ff59cbe558

Klasse! Schau ich mir gerne mal an.

Danke dir.

Eigentlich eine coole Idee. Aber je mehr man auf einen Node packt desto mehr Angriffsfläche und Fehler entstehen.

An sich ja, allerdings laufen alle Apps als Docker-Container. Und wenn man mit der Anzahl der Apps nicht übertreibt, dann ist es eine feine Sache. Bei mir laufen auch nur die beiden: Node und Pool.

Ich drücke die Daumen!

Danke auch dir.

[Stargazer-132]

Dafür direkt ein Merit (hab ich das 1. Mal genutzt). Besten Dank fürs Teilen der Downgrade Anleitung!!!

Wenn das B-Node das nächste Mal abschmiert, die Hoffnung auf ein schnelles Update stirbt zuletzt, werde ich Deine Liste mal abarbeiten und ein Downgrade durchführen. Hoffentlich gibts da keine Autoupdatefunktion, die das danach direkt wieder drüberbügelt. Ist derzeit leider kein Zustand was da gerade läuft. Mal läuft es paar Stunden, auch mal paar Tage, habe aufgehört zu zählen wie oft ich die App neugestartet hab und die Miner komplett sinnlos Strom verbraten haben wenn die nicht automatisch woanders hin gewechselt sind. Anfangs immer den Pi5 rebootet, aber App neustarten reicht ja auch.

Ja, beim PublicPool sind auf Github auch einige Issues reingekommen, ohne Antwort vom Entwickler wie es ausschaut, da kam Deine Idee und Umsetzung gerade recht :-) Funktionieren tut PublicPool @umbrel aber, zumindest gabs da mal nen Blockfund.

Ein Nano3 hat direkt nach der kurzen Laufzeit ein 6.38G Share abgegriffen @Low Mode mit 2TH/s   Ich leite mal einen Teil vom S19er ins Schwimmbecken.

[duckAxe]

Hoffentlich gibts da keine Autoupdatefunktion, die das danach direkt wieder drüberbügelt.

Nein, kein Auto-Update. Wenn ich dazu komme, will ich die Ƀ Node 28.1.0 ebenfalls in eine eigenständige App auslagern, dann ist man sich sicher, dass sie auch so bleibt.

Ja, beim PublicPool sind auf Github auch einige Issues reingekommen, ohne Antwort vom Entwickler wie es ausschaut, da kam Deine Idee und Umsetzung gerade recht :-) Funktionieren tut PublicPool @umbrel aber, zumindest gabs da mal nen Blockfund.

Das stimmt. Allerdings gab es doch dafür nie einen Beweis außer, dass jemand es zugegeben hat?

[Stargazer-132]

Danke erneut, das beruhigt etwas.  

Ich beziehe mich auf diesen Fall: https://www.blocktrainer.de/blog/solo-miner-findet-bitcoin-block-mit-eigenem-mining-pool

Dass der Glückspilz sich mit einigen Details erklärt hat, ist die eine Sache, dass es Public Pool on umbrel war, steht ja dagegen angeblich im Header.

[duckAxe]

Danke erneut, das beruhigt etwas.  

Ich beziehe mich auf diesen Fall: https://www.blocktrainer.de/blog/solo-miner-findet-bitcoin-block-mit-eigenem-mining-pool

Dass der Glückspilz sich mit einigen Details erklärt hat, ist die eine Sache, dass es Public Pool on umbrel war, steht ja dagegen angeblich im Header.

Danke für den Hinweis. In der Tat, steht so im Block "Public-Pool", "Public Pool on Umbrel" https://mempool.space/de/block/00000000000000000000a517d87e63ea04c7ec3dd51d20926e82cca5466dccaf

[willi9974]

Auf welcher Hardware hast du das Laufen?
Wie ist deine Internetverbindung daheim?

Ich hab halt einen DSL und wenn ich da meinen eigenen SoloCK Mining Pool aufbaue und alles funktioniert. Erstmal alles fein.
Meine kleinen Miner finden wirklich einen Block und ich bin gerade dann im DSL Reconnect alle 24h (und bekommen eine neue IP) und erzeuge damit einen ungültigen Block, dann würde ich mich in den Arsch..... beißen.

Das ist ein Punkt weswegen ich das immer wieder verworfen habe, obwohl der Spieltrieb natürlich da ist 

Viele Grüße
Willi

[Stargazer-132]

Hab einen Pi5 mit 8GB, da läuft dann Umbrel OS drauf mit dem B-Node, Lighning-Node, Electrs und eben dem Pool. Anbindung via LAN an einer Fritzbox 7590. Erst mit VDSL250 unterwegs, dann seit Anfang des Jahres hängt an der 7590 ein Glasfasermodem am WAN-Anschluss. Geschwindigkeit um die 280 MBit/s, ein Upgrade habe ich erstmal sein lassen. Möglich wäre noch bis 1 GBit/s hier an meiner Adresse, aber wozu?

Das mit dem DSL-Reconnect hast du halt auch beim normalen öffentlichen CKPool, die Miner Zuhause hängen dann im WorstCase ebenso am Fliegenfänger. Aber man hat ja 2 Backen zum Reinbeissen ;-)
Das Node ist dann im ext. Reconnectfall immer noch mit dem Pool und der Miner mit dem Pool verbunden (bis die fehlende I-Net Verbindung irgendwann alles lahmlegt), ist ja lokal, nur der Sync der Nodes untereinander bei einem Blockfund und wiederhergestellter I-Netverbindung ist dann fraglich. Kann dir aber halt auch so passieren meiner Meinung nach. Da bin ich aber technisch nicht so tief drin in der Blockchain wie dann sowas gehändelt wird. Glaube die Chancen einen Block zu finden sind höher, als einen Block zu finden bei genau diesem einen Reconnect-Zeitfenster. Das wäre dann wirklich das Gegenteil von Glückspilz = Pechpilz? Oder einfach nur Murphy´s Law.

Bei Glasfaser und auch bei DOCSIS Kabel ist das (fast) wie bei DSL, da gibts auch Reconnects, sonst würde das Standleitung heißen.

@duckAxe Auffälligkeiten:

1. Anzahl der Worker, bei 2*Nano 3 ist noch OK, bei einem weiteren Miner (insgesamt 3) steht dann 4 da?

2. Anzeige der 5m Hashrate: unten unter den Minern die Zusammenfassung stimmt bei allen Werten mit denen oben im Kopf überein, außer bei 5m Hashrate. Unten steht dann mehr als oben.

Update: ca. 4h nachdem der S19 (3. Miner) seinen letzten Share abgeliefert hat, steht bei Worker wieder eine 3. Der S19 verbleibt in der Liste mit 0 in der 5m Hashrate Spalte.

Super, beim Public Pool fliegen immer alle komplett raus wenn die offline sind und fangen wieder bei 0 an. Gut, dass das hier wie beim bormalen ckpool ist wie man es kennt.

Update 2: hab heute zwei weitere Miner mit reingenommen, nun insgesamt 5, Trommelwirbel: Anzeige 4

[duckAxe]

1. Anzahl der Worker, bei 2*Nano 3 ist noch OK, bei einem weiteren Miner (insgesamt 3) steht dann 4 da?

Die Anzeige gebe ich eins zu eins an die UI weiter. Das sind alles Werte, die aus der CKpool-API kommen. Ich kalkuliere nichts.

2. Anzeige der 5m Hashrate: unten unter den Minern die Zusammenfassung stimmt bei allen Werten mit denen oben im Kopf überein, außer bei 5m Hashrate. Unten steht dann mehr als oben.

Auch das liefert die API so. Ich summiere nichts. Die API liefert die Einzelwerte pro Worker und auch für den User (das ist der Wert unter der Linie). Scheinbar hat CKpool da eine Differenz der Berechnung. Oder einfach nur Rundungsfehler

Update: ca. 4h nachdem der S19 (3. Miner) seinen letzten Share abgeliefert hat, steht bei Worker wieder eine 3. Der S19 verbleibt in der Liste mit 0 in der 5m Hashrate Spalte.

Super, beim Public Pool fliegen immer alle komplett raus wenn die offline sind und fangen wieder bei 0 an. Gut, dass das hier wie beim bormalen ckpool ist wie man es kennt.

Update 2: hab heute zwei weitere Miner mit reingenommen, nun insgesamt 5, Trommelwirbel: Anzeige 4

Man kann sicherlich im Quellcode von CKpool nachschauen, wie sie es ermitteln, welche Worker wann als aktiv gelten. Aber das wird nichts ändern

[Stargazer-132]

Danke für die Erklärungen 

[MagicDude4Eva]

Ich habe so was ähnliches auf meiner Synology in Docker gebaut (https://github.com/magicdude4eva/btc-fullnode-stack). Obwohl alles super-stabil läuft, ich Glasfaser zu Hause habe und einiges an Redundanz (UPS, PV + Speicher) habe ich mit selbst-gehosteten Pool und Bitcoin-Node die Sorge das sollten meine Miner einen Block finden, die Bestätigung über Nodes nicht schnell genug geht und ich dann verliere.

In meinen Stack habe ich keine Verzögerung festgestellt und über ZMQ wird auch schnell auf CKPool gepushed. Im Testnet laufen zu lassen konnte ich schon alles verifizieren, aber ist dann doch nicht ein gleichartiger Vergleich.

Was mich verwundert hat: Ich habe zwei NerdQAxe++ parallel am Laufen. Der erste lief gegen meinen lokalen CKSolo Pool. Hatte in einer Woche dann Best Difficulty von 300M erreicht und ca 300M shares gemacht. Im Vergleich (und vlt reines Glück) hat der zweite NerdQAxe++ (mit eusolo.ckpool.org verbunden) schon knapp nach dem Einschalten (ca 8h) die Best Difficulty von 558M erreicht und nach 1d 7h 118M shares gemacht. Gefühlt funktioniert der 2. Miner auf ckpool.org "schneller".

Ich lasse beide parallel laufen und hoffe das wenn einer was findet, das es richtig bestätigt wird ;-)

[Stargazer-132]

Das ist aber sehr dem Zufall geschuldet, wenn ich meine Miner ab und zu mal reboote, finden die auch mal nach ein paar Stunden eine recht hohe Schwierigkeit, meistens aber gefühlt dümpeln die ewig lang rum bis mal etwas hohes kommt. Das zieht sich durch von Nerdaxe bis zum S19, siehe hier mein erster Test im "Bassin" mit dem Nano 3 da hats ja auch direkt nen hohen Share gegeben, aber nur bei einem. Der andere immer gleich eingestellte Nano 3 hat immer noch nur 70,98M anstatt wie 6,38G vom anderen mit gleicher Laufzeit und nach 4d10h Pool-Uptime. Beide Miner haben in dieser Zeit ca. 240M Shares absolviert. Funfact: mein BTC-Node ist seitdem nicht noch mal abgestürzt. Die App vom Public Pool @ umbrel habe ich derzeit gestoppt/deaktiviert.

[duckAxe]

Ich würde auch sagen, es ist Zufall. Es gibt auf Reddit sehr viele Nutzer, die berichten, dass nach dem Reboot neue Rekorde erreicht werden. Aber nicht reproduzierbar.

[MagicDude4Eva]

Ich würde auch sagen, es ist Zufall. Es gibt auf Reddit sehr viele Nutzer, die berichten, dass nach dem Reboot neue Rekorde erreicht werden. Aber nicht reproduzierbar.

Vlt Zufall, aber gestern einen neuen NerdQAxe++ auf meinen lokalen CKpool verbunden und best difficulty war nach 12 Stunden noch immer 100M, dann am Abend auf eusolo umgestellt und rebooted und um Mitternacht war dieser auch schon auf 600M. Ich würde jetzt nicht unnötig rebooten wollen aber schon ungewöhnlich.

[o_solo_miner]

Ich hab halt einen DSL und wenn ich da meinen eigenen SoloCK Mining Pool aufbaue und alles funktioniert. Erstmal alles fein.

Meine kleinen Miner finden wirklich einen Block und ich bin gerade dann im DSL Reconnect alle 24h (und bekommen eine neue IP) und erzeuge damit einen ungültigen Block, dann würde ich mich in den Arsch..... beißen.
Das ist ein Punkt weswegen ich das immer wieder verworfen habe, obwohl der Spieltrieb natürlich da ist 
Willi

Solange du mit -zmq die Blockupdates schnell bekommst, ist die chance gering einen Block zu verlieren.
ABER: compiliert die Node selber und last die Wallet funktion raus! (--without-wallet)
Hintergrund ist die deutlich erhöhte Verarbeitungsgeschwindigkeit und erhöhte Sicherheit. Ein Pool benötigt keine Walletfunktion um einen Block zu minen.
Und schön wäre es zwei Nodes zu betreiben um bei einem hänger der ersten Node, weiterhin auf dem richtigen Block zu bleiben.

[duckAxe]

Vlt Zufall, aber gestern einen neuen NerdQAxe++ auf meinen lokalen CKpool verbunden und best difficulty war nach 12 Stunden noch immer 100M, dann am Abend auf eusolo umgestellt und rebooted und um Mitternacht war dieser auch schon auf 600M. Ich würde jetzt nicht unnötig rebooten wollen aber schon ungewöhnlich.

Japp. Wie gesagt, auf Reddit liest man haufenweise solche Berichte. Es gab mal jemanden, der es ausgewertet hat. Er hatte mehrere Devices, die einen hatte er täglich rebootet, die anderen nicht. Am Ende gab es nachweislich keinen Unterschied, was Rekorde angeht. Was ich damit sagen will: Du kannst zwei Mal neu starten und neue Höhen erreichen. Aber du kannst täglich monatelang neu starten und es wird sich nichts rühren.

[SN347]

Das ist keine Einbildung und hat Unterschiedliche Gründe.

Nach dem Neustart erhält der Miner ein frisches Block-Template inklusive neuer Nonce-Bereiche. Das bedeutet -> Er startet mit einem komplett neuen Suchraum..

Viele Mining Soft- und Firmwares starten nach einem Reboot mit vordefinierten Optimierungen = ein sogenanntes Prefetching, initialisierte Threads mit optimiertem Scheduling oder spezielle aggressivere Algorithmen -> das alles kann die Hashleistung kurzfristig verbessern!

Direkt nach dem Reboot sind die Chips kühler = weniger thermisches throttling.. das verbessert die elektrische Stabilität, was wiederum kurzzeitig die Hashrate oder Effizienz erhöht, bis sie wieder warm werden..

Wahrscheinlich ist es das Zusammenspiel aus neuem Template, aggressiver Start-Soft- und Firmware und optimierter Hardwarekühlung.. das führt dazu, dass Miner direkt nach einem Neustart häufiger höhere „Best-Diff“-Werte erreichen, was sich aber mittelfristig bis langfristig wieder normalisiert.