Selbst gehosteter BTCPay Server auf einem VPS: Bitcoin und Lightning akzeptieren ohne Zahlungsabwickler

Was BTCPay Server tatsächlich ist, und was es ersetzt

BTCPay Server ist keine Wallet und kein Zahlungsunternehmen. Es ist die Softwareschicht, die zwischen Ihrer Website und Ihrem eigenen Bitcoin-Node sitzt und die langweilige, notwendige Arbeit erledigt, die sonst ein Zahlungsabwickler für Sie übernimmt: Es erzeugt pro Bestellung eine frische Adresse oder Lightning-Rechnung, gibt einen Fiat-Betrag zu einem Kurs an, den es für die Lebensdauer der Rechnung festschreibt, beobachtet die Chain auf die Zahlung hin, entscheidet, wann die Zahlung als abgewickelt gilt, und meldet es Ihrem Shop. Das Geld läuft auf seinem Weg zu Ihnen durch kein einziges fremdes Konto, weil es kein Konto gibt — die Adressen gehören zu einer Wallet, die Sie kontrollieren, und die Software beobachtet sie nur.

Genau dieser architektonische Unterschied ist der ganze Grund, es zu betreiben. Ein gehosteter Zahlungsabwickler ist ein Unternehmen mit einer Compliance-Abteilung, einer Bank und einem Nutzungsbedingungen-Dokument, das sich das Recht vorbehält, Ihre Auszahlung zurückzuhalten, während es Sie überprüft. Er wird Identitätsdokumente verlangen, weil er in Ihrem Namen Geld bewegt und sein eigener Regulator von ihm verlangt zu wissen, wessen Geld er bewegt. Self-Hosting entfernt den Intermediär, statt mit ihm zu verhandeln: Es gibt kein Onboarding, keine monatliche Volumenprüfung, keinen Auszahlungsplan, und nichts, das ein Dritter einfrieren könnte, weil zu keinem Zeitpunkt ein Dritter die Gelder hält.

Was Sie im Gegenzug für die Arbeit bekommen, ist ein wirklich vollständiger Checkout. Rechnungen mit Ablaufzeit und festgeschriebenem Wechselkurs. On-Chain und Lightning in derselben Rechnung, sodass ein Kunde, der zwei Dollar zahlt, nicht gebeten wird, eine Netzwerkgebühr von drei Dollar zu zahlen. Eine Point-of-Sale-Seite, ein Spenden-Button, eine Crowdfunding-Seite, ein Zahlungs-Button, den Sie in beliebiges HTML einfügen können. Plugins für die gängigen Shop-Plattformen, und eine vollständige REST-API, falls Ihr Shop etwas ist, das Sie selbst geschrieben haben. Rückerstattungen, Pull Payments, Auszahlungen. Payjoin, falls Ihnen daran liegt, die Common-Input-Ownership-Heuristik auf der Empfängerseite zu brechen.

Es lohnt sich, genau zu sein, was nicht enthalten ist, denn die meiste Enttäuschung bei selbst gehosteten Zahlungen entsteht, weil man ein Produkt erwartet, wo es nur ein Protokoll gibt. Niemand wandelt Ihr Bitcoin in Euro um und überweist es auf eine Bank; wenn Sie das brauchen, benötigen Sie weiterhin eine Börse, und die Börse wird weiterhin fragen, wer Sie sind. Niemand übernimmt die Haftung für Chargebacks, auch wenn es hier keine gibt, für die man haften müsste. Niemand geht um zwei Uhr morgens ans Telefon, wenn der Node aufhört, der Chain zu folgen — das ist jetzt Ihr Job, und es ist der Teil dieses Leitfadens, den die Leute überspringen.

Die Maschine: was sie wirklich braucht, und wo der günstige Plan aufhört

Die Anwendung selbst ist klein. Der Stack darunter ist es nicht. Eine Standard-Bereitstellung betreibt Bitcoin Core, einen Adress-Indexer namens NBXplorer, eine PostgreSQL-Datenbank, die BTCPay-Webanwendung, einen Reverse-Proxy, der die Zertifikate verwaltet, und — wenn Sie ihn aktivieren — einen Lightning-Node, jeweils in einem eigenen Container. Die Webanwendung wäre auf einem Raspberry Pi glücklich. Bitcoin Core nicht.

Arbeitsspeicher ist das Erste, wo Leute zu knapp kalkulieren. Zwei Gigabyte starten den Stack technisch und verbringen die anfängliche Synchronisierung mit Swapping, was auf einem geteilten NVMe eine gute Methode ist, aus einem Tag drei zu machen. Vier Gigabyte sind eine vernünftige Untergrenze für reines On-Chain. Acht sind die realistische Untergrenze, sobald Lightning ins Spiel kommt, weil Sie jetzt einen zweiten Daemon betreiben, der seine eigene Datenbank und seine eigene Sicht auf den Graphen führt, und weil bitcoind während des anfänglichen Downloads enorm besser läuft, wenn Sie ihm einen großen dbcache geben können statt der konservativen Vorgabe. Die reduce-memory-Hinweise in Bitcoin Core sind die Referenz dafür, welche Stellschrauben RAM gegen Zeit eintauschen.

Die Festplatte ist der zweite Faktor, und er ist es, der Ihren Plan bestimmt. Die unbeschnittene Chain liegt inzwischen über siebenhundert Gigabyte und wächst um etwa sechzig pro Jahr, sodass ein Archiv-Node auf keiner VPS-Stufe mehr passt, die wir verkaufen, und auf eine dedizierte Maschine gehört, wo Ihnen ein gespiegeltes Paar immer noch ein Terabyte übriglässt. Pruning ändert das vollständig — der Node behält ein rollierendes Fenster aktueller Blöcke und verwirft den Rest, und für einen Zahlungs-Endpunkt ist das überhaupt kein Kompromiss, weil ein Händler niemals historische Blöcke an irgendjemanden ausliefern muss. Rechnen Sie die Datenbank des Indexers, PostgreSQL, die Docker-Images und -Volumes, den eigenen Speicher des Lightning-Nodes und die Logs hinzu, und eine beschnittene Bereitstellung landet komfortabel innerhalb einer Hundert-Gigabyte-Klasse von Maschine, mit Raum zum Wachsen.

Die CPU zählt vor allem für eine Woche Ihres Lebens. Die Signaturvalidierung während des Initial Block Download ist das Schwerste, was dieser Server jemals tun wird; danach ist die Prüfung eines Blocks alle zehn Minuten und die Beantwortung einer Handvoll Rechnungsanfragen nahezu Leerlauf. Kaufen Sie Kerne für die Synchronisierung, nicht für den Dauerbetrieb — oder kaufen Sie den kleineren Plan und akzeptieren Sie, dass die Synchronisierung länger dauert, was ein völlig vernünftiger Tausch ist, wenn Sie es nicht eilig haben.

Pruning spart Festplatte, nicht Zeit — und die Synchronisierung ist der Flaschenhals

Das mit Abstand häufigste Missverständnis beim Betrieb eines Nodes ist, dass Pruning ihn schnell macht. Das stimmt nicht. Ein beschnittener Node lädt jeden Block vom Genesis-Block an herunter und validiert jede Signatur in jedem einzelnen davon, exakt wie ein Archiv-Node; der einzige Unterschied ist, dass ein Block, sobald er validiert und nicht mehr benötigt wird, gelöscht statt behalten wird. Sie sparen Festplatte. Sie sparen nichts bei der Bandbreite und nichts bei der Zeit. Wer erwartet, dass ein beschnittener Node in einer Stunde fertig ist, wird diese Stunde damit verbringen, überzeugt zu sein, dass etwas kaputt ist.

Wie lange es tatsächlich dauert, hängt fast ausschließlich davon ab, wie viel Cache Sie ihm gegeben haben und wie schnell die Festplatte ist. Auf NVMe mit mehreren Gigabyte dbcache und vier nicht geteilten Kernen ist ein Tag eine realistische Erwartung. Bei einem kleinen Plan mit der Standard-Cache-Größe und einem lauten Nachbarn sind zwei bis drei Tage normal, und der Prozess verbringt die meiste dieser Zeit damit, das UTXO-Set immer wieder auf die Festplatte zu schreiben, weil er es nicht im Speicher halten kann. Das ist der eine Moment, in dem ein vorübergehend größerer Plan echtes Geld wert ist: für die Synchronisierung hochskalieren, danach wieder herunter. Monatliche Abrechnung ohne Vertragsbindung ist genau das, was dieses Manöver billig macht.

Nachdem die Chain synchronisiert ist, gibt es dann eine zweite Wartezeit, mit der fast niemand plant. Wenn Sie eine Wallet verbinden, die bereits Historie hat — einen Extended Public Key von einer Hardware-Wallet, die Sie seit einem Jahr benutzen —, muss der Indexer die Chain nach Adressen durchsuchen, die daraus abgeleitet sind. Bei einem beschnittenen Node ist dieser Scan durch das begrenzt, was noch auf der Festplatte liegt, weshalb die Reihenfolge bei der Installation wichtig ist: Richten Sie die Wallet auf den Node, bevor alte Blöcke verworfen werden, falls historische Transaktionen erscheinen sollen, oder akzeptieren Sie, dass der Store bei null anfängt, und behandeln Sie das als den sauberen Neuanfang, der es meistens auch ist.

Die praktische Terminregel lautet, dass die Maschine, lange bevor der Shop sie braucht, im Dienst sein und synchronisieren muss. Bereitstellen, den Download starten, und die dazwischenliegende Zeit mit den Teilen verbringen, die nicht von der Chain abhängen: DNS, Zertifikate, das Shop-Plugin, die Wallet, die Backup-Routine. Wenn Sie den Node bis zuletzt liegen lassen, werden Sie feststellen, dass Sie sich auf ein Startdatum festgelegt haben, das von einem Prozess bestimmt wird, den niemand beschleunigen kann.

Schlüssel: die Architekturentscheidung, die Sie ein einziges Mal treffen

Die Frage, die bestimmt, wie schlimm Ihr schlechtester Tag werden kann, ist einfach: Kann der Server das Geld ausgeben? Für On-Chain-Zahlungen sollte die Antwort Nein lauten, und BTCPay ist darauf ausgelegt, Ihnen dieses Nein zu erlauben. Sie importieren einen Extended Public Key — einen xpub oder seine modernen Äquivalente — abgeleitet von einer Hardware-Wallet oder einem Offline-Signierer. Der Server leitet aus diesem Schlüssel pro Rechnung eine frische Empfangsadresse ab, beobachtet die Chain auf Zahlungen an diese Adressen und meldet sie. Er kann keine gültige Ausgabe konstruieren, weil er nie einen privaten Schlüssel gesehen hat. Eine vollständige Kompromittierung der Maschine kostet Sie dann die Maschine und die Bestelldaten Ihrer Kunden, was schlimm ist, aber sie kostet Sie nicht die Einnahmen.

Die Alternative — BTCPay der Bequemlichkeit halber eine Hot Wallet erzeugen und halten zu lassen — wird angeboten, ist gelegentlich für sehr kleine Volumina die richtige Entscheidung, und sollte eine bewusste Entscheidung sein statt die Sache, die passiert ist, weil es der Standard-Button war. Wenn Sie sich dafür entscheiden, behandeln Sie das Guthaben auf diesem Server so, wie Sie Bargeld in einer Ladenkasse behandeln würden: räumen Sie es nach Zeitplan ab, behalten Sie nur, was der Handel eines Tages braucht, und seien Sie sich bewusst, dass der Seed auf einer Festplatte in einem Rechenzentrum liegt.

Lightning ist die Ausnahme, die sich nicht vermeiden lässt. Ein Lightning-Node muss Transaktionen in Echtzeit signieren, um den Kanalzustand zu aktualisieren, daher sind seine Schlüssel zwangsläufig heiß, und es gibt keinen Watch-only-Modus, der Ihnen trotzdem das Empfangen erlaubt. Das ist kein Mangel von BTCPay; es ist das, was das Protokoll verlangt. Die richtige Antwort ist, das Lightning-Guthaben nach Bedarf zu dimensionieren — genug Inbound, um einen Tag oder eine Woche an Bestellungen zu empfangen, nicht Ihre gesamte Kriegskasse — und angesammelte Eingänge regelmäßig in Cold Storage zu verschieben, dieselbe Disziplin, die jeder Laden auf seine Kasse anwendet.

Zu dieser Entscheidung gehört noch etwas, weil es der Teil ist, den man bis nach dem Vorfall aufschiebt: Schreiben Sie auf, wo der Seed liegt, in einer Form, mit der Ihr Nachfolger etwas anfangen könnte, und bewahren Sie es an einem Ort auf, der nicht der Server und nicht dasselbe Gebäude wie der Server ist. Full-Disk-Encryption auf dem VPS schützt die Festplatte im Ruhezustand gegen eine Offline-Kopie; für eine laufende Maschine bringt sie nichts, und sie hilft ganz sicher nicht, wenn die einzige Kopie Ihres Seeds darauf lag.

Lightning ist ein Liquiditätsproblem im Software-Kostüm

Einen Lightning-Node zu installieren ist leicht. Die erste Zahlung darauf zu empfangen ist es nicht, und der Grund dafür erwischt fast jeden. Ein Lightning-Kanal ist ein zweiseitiges Guthaben: Wenn Sie einen Kanal öffnen und finanzieren, liegt die gesamte Kapazität auf Ihrer Seite, was bedeutet, dass Sie andere bezahlen können, aber niemand Sie. Empfangen erfordert Inbound-Kapazität — Gelder, die auf der anderen Seite eines Kanals liegen, bereit, sich zu Ihnen zu bewegen. Ein frisch installierter Node mit drei gut finanzierten Outbound-Kanälen kann trotzdem nicht ein einziges Satoshi von einem Kunden annehmen, und der Checkout wird Lightning schlicht nicht als Option anbieten.

Es gibt drei ehrliche Wege, das zu beheben. Sie können Inbound-Kapazität von einem Liquiditätsanbieter kaufen, was am schnellsten geht und eine Gebühr proportional zu Betrag und Dauer kostet. Sie können einen Submarine Swap durchführen — über Lightning auszahlen und on-chain empfangen, wodurch sich Ihr eigenes Guthaben auf die andere Seite Ihrer Kanäle verschiebt und Outbound in Inbound umwandelt, zum Preis der Swap-Gebühr. Oder Sie bitten einen gut vernetzten Peer, einen Kanal zu Ihnen zu öffnen, was kostenlos ist, wenn Sie die Beziehung haben, und langsam, wenn nicht. Wofür Sie sich auch entscheiden: Planen Sie es vor dem Start ein, und bemessen Sie es an Ihrem erwarteten Bestellaufkommen statt eine runde Zahl zu wählen.

Kanäle brauchen außerdem Wartung, auf eine Art, wie On-Chain sie nicht braucht. Inbound-Kapazität wird verbraucht, während Kunden Sie bezahlen: Jede empfangene Zahlung verschiebt Guthaben von deren Seite eines Kanals auf Ihre, sodass ein Shop, der nur empfängt, seine Fähigkeit zu empfangen stetig aufbraucht und irgendwann rebalancen oder swappen muss. Kanäle schließen, manchmal einseitig, wenn ein Peer verschwindet, und ein Force-Close sperrt Ihre Gelder für eine Weile hinter einem Timelock und kostet eine On-Chain-Gebühr. Nodes müssen online sein, um Zahlungen anzunehmen und um nach betrügerischen Gegenparteien Ausschau zu halten. Nichts davon ist schwierig, aber all das ist fortlaufend, und das ist der Grund, warum viele Shops Lightning für kleine Bestellungen nutzen und alles oberhalb einer Schwelle still und leise on-chain abwickeln.

Die Belohnung für den Aufwand ist real. On-Chain-Gebühren sind gegenüber der Höhe der Zahlung gleichgültig, was eine Fünf-Dollar-Bestellung wirtschaftlich absurd macht, wenn der Mempool voll ist, und völlig in Ordnung, wenn nicht — und Sie haben keinen Einfluss darauf, welches von beidem am Tag Ihres Starts zutrifft. Lightning-Zahlungen werden in unter einer Sekunde für einen Bruchteil eines Cents abgewickelt, unabhängig von der Auslastung, und bei allem, was wie ein Kaffee, ein Download, ein API-Guthaben-Aufladen oder ein monatliches Abonnement bepreist ist, ist das der Unterschied zwischen einem Checkout, der funktioniert, und einem, der still und leise den Verkauf verliert.

Das Backup, das Sie ruiniert: einen Lightning-Node niemals zurückrollen

Dieser Abschnitt ist der Grund, den Leitfaden zu lesen, selbst wenn Sie bereits alles andere darin wissen. Einen Lightning-Node aus einer alten Kopie seiner Daten wiederherzustellen ist keine neutrale Handlung, und unter den falschen Umständen zerstört es Ihre Kanalguthaben. Der gewöhnliche Systemadministrations-Instinkt — einen Snapshot machen, den Snapshot wiederherstellen, wenn etwas kaputtgeht — ist genau der Instinkt, der den Verlust verursacht.

Der Mechanismus dahinter ist die Betrugsstrafe des Protokolls. Jedes Kanal-Update ersetzt das vorherige, und jede Seite gibt der anderen die Mittel in die Hand, sie zu bestrafen, falls sie jemals einen überholten Zustand veröffentlicht. Das ist es, was einen Kanal zwischen zwei Parteien sicher macht, ohne einen Schiedsrichter zu brauchen. Es bedeutet aber auch, dass ein Node, der aus der Kopie von gestern wiederhergestellt wurde, tatsächlich glaubt, ein alter Zustand sei aktuell, und wenn er nach diesem Glauben handelt — durch einen Force-Close, oder schlicht weil er dazu aufgefordert wird —, ist die Gegenpartei berechtigt, das gesamte Kanalguthaben zu nehmen, und deren Software wird das automatisch tun. Sie hatten nicht die Absicht zu betrügen. Das Protokoll kann den Unterschied nicht erkennen, und es ist auch nicht dafür ausgelegt.

Die Regel ist also absolut und es lohnt sich, sie an die Wand zu schreiben: Stellen Sie einen Lightning-Node niemals auf einen früheren Zustand zurück. Nicht aus einem Dateisystem-Snapshot, nicht aus einem Datenbank-Dump, nicht aus einer Kopie des Datenverzeichnisses, die Sie letzte Woche gemacht haben, und nicht aus den stündlichen Snapshots, die mit dem Server mitgeliefert werden. Snapshots sind hervorragend für den Rest der Maschine und gefährlich für genau dieses Verzeichnis, und die Gefahr ist lautlos — der Node startet, sieht gesund aus, und kostet Sie später Geld.

Was Sie stattdessen aufbewahren, ist ein statisches Kanal-Backup: eine kleine Datei, aktualisiert bei jedem Öffnen oder Schließen eines Kanals, die gerade genug Informationen enthält, um jede Gegenpartei zu bitten, kooperativ zu schließen und Ihre Gelder zurückzugeben. LND nennt es channel.backup und dokumentiert die Semantik in seinem Recovery-Guide; Core Lightning bietet ein Äquivalent zusammen mit einem Plugin, das eine fortlaufend replizierte Kopie der Datenbank pflegt. Eines davon wiederherzustellen setzt Ihre Kanäle nicht fort — es zwingt sie alle zum Force-Close und stellt das Guthaben wieder her, was das korrekte und einzig sichere Ergebnis nach einem Totalverlust ist. Bewahren Sie es abseits der Maschine auf, halten Sie es aktuell, und verstehen Sie es als Versicherungspolice, nicht als Fortsetzen-Knopf.

Für alles andere: sichern Sie normal und großzügig. Die BTCPay-Bereitstellung liefert ein eigenes Backup-Skript mit, das den Stack stoppt, Datenbank und Konfiguration konsistent dumpt und ihn wieder startet; führen Sie es nach Zeitplan aus und kopieren Sie die Ausgabe woanders hin, idealerweise auf einen zweiten Server in einer anderen Rechtsordnung. Die Datenbank enthält Ihre Rechnungen, Stores, Nutzer, API-Keys und Einstellungen — nicht Ihr Geld, aber Ihre gesamte Historie, und die werden Sie tatsächlich vermissen.

Wo der Server steht, ist Teil des Zahlungs-Stacks

Es liegt nahe, Hosting als Massenware unterhalb des eigentlich interessanten Teils zu betrachten. Für einen Zahlungs-Endpunkt stimmt das nicht, weil der Checkout die eine Komponente ist, deren Verfügbarkeit direkt gleich Umsatz ist, und weil ein Server ein physisches Objekt in einer Rechtsordnung ist, mit einem Anbieter, der dazu kontaktiert werden kann. Wenn Ihre Zahlungsinfrastruktur ein gehosteter Zahlungsabwickler ist, ist dessen Compliance-Haltung Ihre Compliance-Haltung. Wenn Sie selbst hosten, übernimmt die Haltung Ihres Hosting-Anbieters diese Rolle — und wenn Sie speziell deshalb selbst gehostet haben, um dem Ermessen eines Zahlungsunternehmens zu entkommen, wäre es unachtsam, genau dieses Ermessen dem Unternehmen zu übergeben, das die Maschine betreibt.

Es gibt drei Eigenschaften, bei denen es sich lohnt, bewusst zu entscheiden. Die erste ist, welche Identität der Host hält: Ein Konto, das mit einer E-Mail-Adresse eröffnet und in Kryptowährung bezahlt wurde, hat nichts herauszugeben und nichts einzufrieren — dieselbe Überlegung, die Sie überhaupt erst zum Self-Hosting gebracht hat. No-KYC-Hosting erklärt, was das in der Praxis bedeutet und was nicht, einschließlich seiner unbequemen Kehrseite — ein Anbieter, der nie erfahren hat, wer Sie sind, kann Ihnen Ihr Konto nicht zurückgeben, wenn Sie den Zugriff darauf verlieren.

Die zweite ist die Rechtsordnung. Ein Checkout-Endpunkt, der Kunden in vielen Ländern bedient, steht in genau einem, und das Recht dieses einen bestimmt, wer den Anbieter wozu verpflichten kann, auf welcher Grundlage, und wie schnell. Unsere vier Regionen — Island, die Niederlande, Rumänien und die Schweiz — unterscheiden sich in dieser Hinsicht spürbar, ebenso in der Latenz zu unterschiedlichen Kundenkreisen, und die Wahl der Rechtsordnung arbeitet die Abwägungen sauber durch. Es gibt auch einen schlicht operativen Aspekt: Platzieren Sie den Node nahe an Ihren Kunden, wenn Checkout-Latenz wichtig ist, und nahe an Ihrer übrigen Infrastruktur, wenn nicht.

Die dritte ist die Bezahlung des Hostings selbst, und das ist die Lücke, die die meisten Leute offen lassen. Einen anonymen, nicht-verwahrenden Checkout auf einem Server zu betreiben, der auf eine Kreditkarte in Ihrem eigenen Namen abgerechnet wird, schafft genau die Verbindung, die Sie mit dem Rest des Stacks vermeiden wollten. Die Maschine in Monero oder Bitcoin zu bezahlen schließt sie — dieselbe Überlegung, eine Schicht tiefer angewendet. Es bedeutet außerdem, dass die Infrastrukturrechnung nicht vom eigenen Risikomodell eines Kartenausstellers unterbrochen werden kann, ein Fehlermodus, der Shops schon ganz real offline genommen hat.

Zu guter Letzt sind die langweiligen Zuverlässigkeitsanforderungen hier strenger als bei einem Blog. Ein Lightning-Node, der offline ist, kann nicht empfangen, kann nicht nach einer betrügerischen Gegenpartei Ausschau halten, und kann von Peers, die ihn nicht erreichen, zwangsweise geschlossen werden. Ein Bitcoin-Node, der hinter die Chain zurückfällt, zeigt Kunden Rechnungen, die er nicht abwickeln kann. Ungemessene Bandbreite zählt mehr, als es aussieht, weil ein Node, der wirklich am Netzwerk teilnimmt, Blöcke an Peers ausliefert, und ein Plan mit Datenlimit Ihnen eine Rechnung präsentiert, die nichts mit dem Traffic Ihres Shops zu tun hat.

Die Installationsreihenfolge, die eine zweite Synchronisierung vermeidet

Die Bereitstellung, die alle verwenden, ist die offizielle Docker-Distribution: ein Repository, das Sie auf einen frischen Server klonen, ein Satz Umgebungsvariablen, der beschreibt, was Sie wollen, und ein Setup-Skript, das eine Compose-Datei erzeugt und den gesamten Stack hochfährt. Sie ist wirklich schlüsselfertig, und der Grund, warum Installationen schiefgehen, ist fast nie das Skript — es ist, die Dinge in einer Reihenfolge zu tun, die Sie zwingt, den teuren Schritt zu wiederholen.

Beginnen Sie mit einer sauberen Maschine und dem DNS-Eintrag. Der Installer fordert für den Hostnamen, den Sie ihm geben, ein Zertifikat an, und diese Anfrage geht an eine Zertifizierungsstelle hinaus, die über Port 80 zu Ihrer Adresse zurückverbindet. Wenn der Eintrag noch nicht auflöst, oder die Ports geschlossen sind, kommt der Stack ohne TLS hoch, und Sie dürfen herausfinden, welches von drei Dingen fehlgeschlagen ist. Legen Sie den A-Eintrag an, bestätigen Sie, dass er von irgendwo antwortet, das nicht Ihr eigener Laptop ist, öffnen Sie 80 und 443, und führen Sie erst dann den Installer aus.

Entscheiden Sie die Fragments vor dem ersten Lauf, nicht danach. Die Umgebung sagt dem Generator, welche Chains aktiviert werden, welche Lightning-Implementierung verwendet wird, ob Pruning aktiviert wird und wie aggressiv, ob neben dem Clearnet-Host ein Onion-Dienst exponiert wird, und welcher Reverse-Proxy konfiguriert wird. Einige davon sind später billig zu ändern; die, die den Node berühren — eine Chain aktivieren, Pruning ein- oder ausschalten, die Lightning-Implementierung wechseln — bedeuten, dass irgendetwas neu heruntergeladen oder neu indiziert werden muss, und etwas neu herunterzuladen ist das, was einen Tag kostet. Lesen Sie die Fragment-Liste einmal durch, entscheiden Sie bewusst, und führen Sie sie dann aus.

Während die Chain herunterlädt, erledigen Sie den Rest. Legen Sie Ihren Store an und setzen Sie dessen Währung, die Ablaufzeit der Rechnungen und wie viele Bestätigungen Sie wollen, bevor eine Rechnung als abgewickelt gilt — eine Entscheidung, die es wert ist, bewusst getroffen zu werden, denn die Annahme mit null Bestätigungen ist schnell und gelegentlich falsch, und sechs Bestätigungen sind sicher und dauern eine Stunde. Importieren Sie die Watch-only-Wallet. Installieren Sie das Shop-Plugin und richten Sie es mit einem eingeschränkten API-Key statt dem Admin-Konto auf den Server aus. Konfigurieren Sie die Kursquelle. Schicken Sie sich selbst eine Testrechnung über einen trivialen Betrag und bezahlen Sie sie, on-chain und über Lightning, von einer Wallet, die nicht auf derselben Maschine liegt — die Zahl der Bereitstellungen, die noch nie mit echtem Geld getestet wurden, ist höher, als es irgendjemandem lieb wäre.

Schreiben Sie dann den Update-Vorgang auf, denn es gibt ihn, und er besteht aus einem einzigen Befehl. Die Distribution liefert einen eigenen Updater mit, der neue Images zieht und den Stack in der richtigen Reihenfolge neu startet, und ein Zahlungs-Endpunkt, auf dem eine ein Jahr alte Version läuft, trägt jeden Bug mit sich, der seither behoben wurde. Tragen Sie es in einen Kalender ein, lesen Sie die Release Notes, bevor Sie es ausführen, und machen Sie zuerst das Backup.

Eine Maschine härten, die Geld hält

Die generischen Ratschläge gelten uneingeschränkt und sind in der Härtungs-Checkliste ausgeschrieben: Schlüssel statt Passwörter, kein Root-Login über SSH, eine Default-Deny-Firewall, unbeaufsichtigte Sicherheitsupdates, und ein Log, das Sie tatsächlich lesen. Was folgt, ist der Teil, der spezifisch für diese Maschine ist, und das Thema ist, dass die Angriffsfläche eines Zahlungs-Endpunkts nicht dieselbe Form hat wie die eines Webservers.

Halten Sie die administrative Oberfläche vom öffentlichen Internet fern, wenn Sie können. BTCPays Dashboard ist die Steuerungsebene für Ihr Geld — es kann Pull Payments erstellen, Wallets wechseln und API-Keys ausstellen — und es muss nicht für die ganze Welt erreichbar sein, nur weil die Rechnungsseiten es sein müssen. Den Admin-Pfad hinter ein VPN oder einen Onion-Dienst zu legen, oder hinter eine Allowlist, entfernt eine ganze Kategorie von Risiko zum Preis eines zusätzlichen Schritts in Ihrem eigenen Arbeitsablauf. Ein WireGuard-Tunnel zum Server ist die am wenigsten aufdringliche Variante davon.

Behandeln Sie API-Keys als primäre Zugangsdaten statt als nachträglichen Einfall, denn in der Praxis sind sie es, womit der Shop mit dem Checkout spricht — und womit ein Angreifer es ebenfalls täte. Stellen Sie einen Key pro Integration aus, beschränken Sie ihn auf den Store und die Berechtigung, die tatsächlich gebraucht wird, bewahren Sie ihn in der geheimen Konfiguration des Shops auf statt in einem Repository, und rotieren Sie ihn, wenn jemand das Team verlässt. Ein nicht eingeschränkter Key auf einem kompromittierten Webhost ist funktional dasselbe wie das Dashboard zu übergeben.

Achten Sie auf die zwei Fehlerzustände, die für diesen Stack einzigartig sind, denn keiner von beiden sieht wie ein Ausfall aus. Ein Node, der aufgehört hat, der Chain zu folgen, wird die Seite weiter bedienen und Kunden weiter Rechnungen zeigen, die sich nie abwickeln lassen. Ein Lightning-Node, der die Verbindung zu seinen Peers verloren hat, wird weiter Bestellungen on-chain annehmen, während er still und leise jede Lightning-Zahlung ablehnt. Überwachen Sie die Blockhöhe gegen eine öffentliche Referenz, überwachen Sie Kanalanzahl und Inbound-Guthaben, und alarmieren Sie bei beidem — das ist das Monitoring, das niemand einrichtet, bis es ihn das erste Mal einen Tag an Bestellungen kostet.

Halten Sie die Maschine in jeder anderen Hinsicht langweilig. Ein Zahlungs-Endpunkt ist ein schlechter Ort, um daneben auch noch Ihren Mailserver, Ihre Entwicklungs-Sandbox und einen Gameserver für Ihre Freunde zu betreiben — nicht weil die Software kollidiert, sondern weil jeder zusätzliche Dienst ein weiterer Weg hinein ist und eine weitere Sache, deren Upgrade den Checkout lahmlegen kann. Wenn Sie den Rest auch wollen: ein zweiter kleiner Server kostet weniger als die Transaktionsgebühren, die Sie sich damit sparen.

Monero und die Coins, die BTCPay nicht von sich aus spricht

Bitcoin und Lightning sind in BTCPay erstklassig unterstützt, und eine Handvoll Bitcoin-naher Chains wird direkt unterstützt. Alles andere kommt über das Plugin-System, das mit der zweiten Hauptversion eingeführt wurde, und es lohnt sich, den Unterschied in der Reife zu verstehen, bevor Sie eine Zahlungsmethode auf Ihrer Checkout-Seite versprechen.

Monero ist die Chain, nach der am häufigsten gefragt wird, und sie funktioniert tatsächlich — über ein Plugin, das auf Ihrem eigenen monerod und einem Wallet-RPC-Daemon aufbaut und neben dem Bitcoin-Stack läuft. Das Design ist in den Punkten, die zählen, dasselbe wie bei Bitcoin: Sie betreiben den Node, Sie halten die Schlüssel, die Software beobachtet auf Zahlungen hin. Was sich unterscheidet, sind die Betriebskosten. Es ist eine zweite Blockchain, die heruntergeladen und synchron gehalten werden muss, es ist ein zweiter Daemon, der überwacht und aktualisiert werden muss, und das Plugin wird von der Community statt vom Kernteam gepflegt, was bedeutet, dass sein Release-Rhythmus sein eigener ist. Wenn Monero nur ein Nice-to-have ist, wägen Sie das ehrlich ab; wenn Privatsphäre am Point of Sale der ganze Grund ist, warum Ihre Kunden gekommen sind, ist es den Aufwand wert, und der Vergleich zwischen den beiden Chains legt dar, was jede der beiden tatsächlich verbirgt.

Die allgemeine Regel für jede zusätzliche Chain lautet, zu fragen, was sie Sie kostet, wenn sie ausfällt. Jede Chain, die Sie aktivieren, ist ein Node, der zurückfallen kann, eine Wallet, die gesichert werden muss, eine Kursquelle, die veralten kann, und ein Support-Gespräch mit einem Kunden, dessen Zahlung feststeckt. Zwei gut betriebene Zahlungsmethoden schlagen sechs vernachlässigte, und ein Checkout, der eine Münze anbietet, deren Node seit einer Woche nicht mehr synchron ist, ist schlechter als einer, der sie nie angeboten hat.

Es gibt außerdem einen legitimen Mittelweg, den man leicht vergisst: Sie müssen nicht jede Chain selbst betreiben, um sie zu akzeptieren. Nichts hindert Sie daran, für eine Chain, die Sie bei geringem Volumen manuell abwickeln, eine statische Adresse zu listen, oder die zweite Chain auf einer separaten Maschine zu betreiben, sodass ihr Ressourcenprofil und ihre Ausfälle vom eigentlich wichtigen Checkout isoliert sind. Self-Hosting ist keine Alles-oder-Nichts-Verpflichtung, und die pragmatischen Setups haben meist eine Chain, die richtig gemacht ist, und einen manuellen Fallback für den Rest.

Was es kostet, gegen das, was ein Zahlungsabwickler verlangt

Die Rechnung ist ungewöhnlich einfach, weil ein selbst gehosteter Checkout feste Kosten hat und keinen Prozentsatz. Ein beschnittener Bitcoin-Node mit Lightning passt auf einen Plan im niedrigen zweistelligen Dollarbereich pro Monat; ein geschäftigerer Shop, der Luft nach oben will, sitzt eine Stufe oder zwei darüber. On-Chain-Zahlungen kosten die Netzwerkgebühr, die der Kunde zahlt, und Lightning-Zahlungen kosten eine Routing-Gebühr, gemessen in Bruchteilen eines Cents. Es gibt keinen Anteil pro Transaktion, kein Monatsminimum, keine Abwicklungsverzögerung und keine Volumenstufe.

Dem gegenüber verlangt ein gehosteter Krypto-Zahlungsabwickler typischerweise rund ein Prozent jeder Transaktion, und ein Kartenzahlungsabwickler verlangt etwa zweieinhalb bis drei Prozent plus einen festen Betrag pro Transaktion. Bei tausend Dollar Umsatz im Monat ist ein Prozent zehn Dollar — wirklich vergleichbar mit dem Server, und Self-Hosting ist dann ein Nullsummenspiel, das Sie eher aus Prinzip als aus wirtschaftlichen Gründen machen. Bei zwanzigtausend im Monat verlangt der Abwickler zweihundert Dollar, und der Server kostet immer noch dieselben zwanzig, und die Entscheidung trifft sich von selbst. Der Umschlagpunkt liegt für die meisten Shops irgendwo im niedrigen vierstelligen Bereich, und alles darüber ist Marge.

Die Kosten, die auf keiner Rechnung erscheinen, sind Ihre Aufmerksamkeit. Nennen Sie es einen Nachmittag zur Installation, einen Tag Warten auf die Chain, und danach so etwas wie eine Stunde im Monat für Updates, Backups und einen Blick aufs Monitoring — plus einen unangenehmen Nachmittag im Jahr, wenn zur Unzeit etwas kaputtgeht. Wenn Ihr Stundensatz das teurer macht als die Gebühren, lautet die ehrliche Antwort, die Gebühren zu zahlen. Niemand sollte einen Zahlungs-Stack aus Prinzip selbst hosten, während das eigentliche Geschäft darauf wartet.

Ein Vorbehalt gehört neben diese Tabelle, denn ihn wegzulassen wäre unehrlich. Der Vergleich setzt voraus, dass Sie gerne halten, was Sie empfangen. Wenn jede Zahlung noch am selben Tag zu Fiatgeld auf einem Bankkonto werden muss, haben Sie eine Börse wieder in den Ablauf eingeführt, und die Börse hat ihre eigenen Gebühren, ihre eigenen Identitätsanforderungen und ihr eigenes Ermessen. Das Self-Hosting des Checkouts entfernt den Zahlungsabwickler. Es entfernt nicht die Bank, und die Shops, die davon am meisten profitieren, sind die, die zumindest einen Teil ihrer Einnahmen in der Währung behalten, in der sie bezahlt wurden.

Wann Sie das nicht selbst hosten sollten

Es gibt Situationen, in denen die richtige Antwort ist, nichts von alldem zu tun, und ein Leitfaden, der das nie sagt, verkauft Ihnen etwas. Wenn Ihr monatliches Volumen klein genug ist, dass der Prozentsatz eines Zahlungsabwicklers unter den Serverkosten liegt, geht die Rechnung nicht auf — beginnen Sie gehostet, und wechseln Sie, wenn sich die Zahlen kreuzen. Wenn niemand in Ihrem Team sich an einem Shell-Prompt wohlfühlt, machen Sie den Checkout nicht zu dem Ort, an dem diese Fähigkeit erworben wird; ein Zahlungs-Endpunkt, den Sie nicht debuggen können, ist schlimmer als eine Gebühr, die Sie ärgert.

Wenn Sie wirklich eine taggleiche Fiat-Auszahlung auf ein Bankkonto brauchen, löst Self-Hosting die falsche Hälfte Ihres Problems. Der Zahlungsabwickler, den Sie loswerden wollen, ist auch das, was die Umwandlung und die Banküberweisung erledigt, und ihn zu ersetzen bedeutet, eine Börse hinzuzufügen, die genau die Identitätsdokumente verlangt, die Sie vermeiden wollten. Das kann wegen der Verwahrungsgarantien trotzdem lohnend sein, aber machen Sie sich klar, dass das KYC sich verschoben hat, statt verschwunden zu sein.

Und wenn Ihre Auslastung auf eine Weise sprunghaft ist, die Ausfallzeit katastrophal macht — ein Launch, ein Drop, eine Spendenaktion mit Deadline —, überlegen Sie genau, ob Sie Ihre erste selbst gehostete Bereitstellung ausgerechnet gegen diese Deadline durchführen wollen. Betreiben Sie sie für einen Zyklus parallel zu etwas anderem, nehmen Sie damit bei geringem Volumen echte Zahlungen entgegen, und lassen Sie sie sich beweisen, bevor sie den Tag trägt, auf den es ankommt. Sie später umzuziehen ist ein gelöstes Problem; ihre Fehlermodi ausgerechnet in Ihrer geschäftigsten Stunde zu entdecken ist es nicht.

Für alle anderen — einen Shop mit stetigem Umsatz, einen Betreiber, der mit einem Terminal zurechtkommt, ein Unternehmen, das lieber seine eigenen Schlüssel hält, als sich mit einer Risikoabteilung zu streiten — ist das eines der wenigen Stücke selbst gehosteter Infrastruktur, die sich in barer Münze auszahlen statt nur im Prinzip. Der Stack ist ausgereift, die Bereitstellung ist ein Skript, die Fehlermodi sind bekannt und aufgeschrieben, und der einzige wirklich unversöhnliche davon ist die Lightning-Rollback-Regel oben auf dieser Seite. Bringen Sie die richtig hin, und der Rest ist gewöhnliche Systemadministration.

Wenn Sie starten wollen: ein Server ist in etwa einer Minute bereitgestellt, und die Chain wird beschäftigt sein zu synchronisieren, während Sie den Rest der Dokumentation lesen. Wählen Sie einen Plan mit acht Gigabyte Arbeitsspeicher, wenn Lightning zu Ihren Plänen gehört, platzieren Sie ihn in der Rechtsordnung, in der Sie ihn tatsächlich haben wollen würden, wenn jemand unangenehme Fragen stellt, und bezahlen Sie ihn mit derselben Münze, die Sie gleich zu akzeptieren beginnen.