skunk

1.) Nein das ist nicht möglich. Test Nodes können keine Channels zu anderen Mainnet Nodes aufmachen. Wenn du auf der Übersicht Channels siehst, müssen das Mainnet Nodes sein.

2.) Gesamtkapazität. Die Transaktionen selber können von Außen nicht eingesehen werden. Du weiß wie viel BTC du selber routest aber nicht was deine Nachbarn so machen.

vor 13 Stunden schrieb o0Julia0o:

Wenn alle Leute links und rechts sehen, dass der Bitcoin so safe wie das Sparkassen-Logo ist, dann wird es von immer mehr Leuten genutzt & somit langfristig wertiger.

Das spielt eher keine Rolle. Siehe DAO. Selbst wenn bekannt ist, dass es Sicherheitslücken gibt, investieren die Leute wie blöde. Bei IOTA und diversen anderen neuen Coins auch gleich noch Geld investieren ohne sich Sorgen über die Sicherheit zu machen. Das ist die Realität am Markt. Wichtigste Regel nicht vergessen. Coins unbedingt alle auf einem Exchange lagern. Das erhöht noch das Risiko....

Ich hab nicht selber gebaut. Ich habe die fertigen Binaries von Github installiert und mir den Spaß mit dem Go Compiler erspart.

Was mich immer noch wundert ist warum er deine Config nicht findet. Wie wäre es mit folgenden Plan. Das .lnd Verzeichnis löschen und lnd starten in der Hoffnung es legt das Verzeichnis an mit allem was dazu gehört. Dann lnd stoppen und prüfen ob das Verzeichnis da ist. Config rein und nochmal probieren.

vor 14 Minuten schrieb Christoph Bergmann:

[lncli] unable to generate seed: rpc error: code = Internal desc = connection error: desc = "transport: authentication handshake failed: remote error: tls: handshake failure"

Bitte mal die Rechte des .lnd Verzeichnis prüfen. Das würde auch zu dem Config Problem passen. Eigentlich sollte er beim Starten automatisch eine tls.key und tls.cert Datei in diesem Verzeichnis anlegen.

Ebenfalls eine mögliche Ursache könnte das home Verzeichnis sein. Ich arbeite mit einem LXC Container und bin in diesem Container als root unterwegs. Bei mir liegt das dann alles unter /root/.lnd/ Eventuell ist das Verzeichnis ja Default. In dem Fall sollte --lnddir helfen.

vor 1 Minute schrieb leblitzdick:

--bitcoind.rpcuser=skunk --bitcoind.rpcpass=MySuperSecretPassword

sollten schon sinnvolle Zugangsdaten sein, du willst doch nicht zu skunk's bitcoin node connecten, oder ??

 

Ist im Grunde egal weil von Außen nicht erreichbar. Wäre mit der aktuellen Config nur von localhost ansprechbar.

Unabhängig davon legt er das notwendige Fachwissen an den Tag um mit Linux klar zu kommen. Ich gehe daher davon aus er hat seine Passwort einfach nur durch ein besser lesbares Passwort ersetzt bevor er es hier gepostet hat. Genau so bin ich auch vorgegangen. Das ist weder mein User noch mein Passwort. Ich habe es einfach nur zum besseren Verständnis gewählt.

Klingt so als ob er die Config nicht richtig geladen hat. Eigentlich steht exakt dieser Eintrag auf der Config Datei.

Edit: Steht irgendwas in der Logdatei? ~/.lnd/logs/bitcoin/mainnet/lnd.log

Die aktuelle Version ist recht stabil. https://github.com/lightningnetwork/lnd/releases/tag/v0.4.1-beta

Für Ubuntu dürfte es lnd-linux-amd64-v0.4.1-beta.tar.gz sein.

vor 3 Stunden schrieb Christoph Bergmann:

@skunk

was müsste ich denn machen, damit wir anfangen können?

Für den Anfang Bitcoin core und lnd installieren. Als Vorlage schlage ich folgende Configs vor:

Bitcoin.conf

# bitcoin.conf
listen=0
txindex=1
server=1
daemon=1
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28332

rpcuser=skunk
rpcpassword=MySuperSecretPassword

mintxfee=0.00000001
minrelaytxfee=0.00000001

lnd.conf

[Application Options]
listen=0.0.0.0:9735
externalip=Hier die externe IP oder DynDNS Namen eintragen.
debuglevel=info
debughtlc=true
alias=BitcoinBlog.de
color=#CD1076

[Bitcoin]
bitcoin.active=1
bitcoin.mainnet=1
bitcoin.node=bitcoind

[Bitcoind]
bitcoind.rpchost=localhost
bitcoind.rpcuser=skunk
bitcoind.rpcpass=MySuperSecretPassword
bitcoind.zmqpath=tcp://127.0.0.1:28332

[autopilot]
autopilot.active=0

Der txindex wird bitcoin core einige Stunden beschäftigen. Wenn alles soweit läuft mache ich einen Channel zu dir auf und das sollte es dann schon gewesen sein. Ich habe inzwischen 20 eingehende Channels mit ausreichend Kapazität. Es sollte für mich also kein Problem sein Zahlungen zu routen.

Im Raum Berlin mach ich auch Hausbesuche.

Edit: Eine Portweiterleitung für 9735. Der Rest kann geschlossen bleiben.

Ja. Der QR-Code ist solange gültig bis du auf der Seite einen neuen generierst oder 2FA deaktivierst.

Am 14.4.2018 um 16:00 schrieb o0Julia0o:

Wie lange hälst du den -> über 1 Jahr, dann zahlt Niemand Steuern beim Verkauf.

Am 12.4.2018 um 21:08 schrieb o0Julia0o:

Es zählt der Kurs an dem Tag, wo du sie verschenkst. Der Zufluss ist ja dann.

Das ist jetzt ein Wiederspruch. Bekommt der Beschenkte die Coins zum Tageskurs oder muss er sie ein Jahr halten?

Am 14.4.2018 um 16:00 schrieb o0Julia0o:

Aber wie machste das? Wenn du den einzigen Private-Key hast, auf nen Ledger/Trezor. Gilt es dann vorm Richter als Geschenk? Oder musste tatsächlich auf eine andere Adresse überweisen?

Ein Trezor hat unendlich viele private Schlüssel. Sende die Coins einfach auf die nächste Adresse. Was vorm Richter als Steuerhinterziehung durchgeht und was erlaubt ist, kann ich dir nicht beantworten. Dazu besser einen Anwalt fragen.

Interessanter ist eher die Frage wie du dem Beschenkten später Zugriff auf seine Coins geben willst ohne ihm dabei die Schlüssel für deine Coins ebenfalls in die Hand zu drücken.

vor 15 Stunden schrieb o0Julia0o:

Bei Geschenken sind 20.000€ an Fremde möglich pro Jahr steuerfrei. Das wird bei bitcon dann genauso sein. Ob du ein Pferd, Euros oder bitcoin verschenkst wird ja egal sein. Es zählt der Kurs an dem Tag, wo du sie verschenkst. Der Zufluss ist ja dann.

Da kann jetzt was nicht stimmen.

Beispiel:

Ich kaufe einen BTC für 2.000€ und halte ihn bis der Kurs bei 5.000€ steht. Jetzt verschenke ich den einen BTC an dich und du verkaufst ihn für 5.000€.

Wer zahlt jetzt die Steuern für die 3.000€ Gewinn?

Und das ist erst der Anfang. Die letzte Version läuft über Tage stabil aber es fehlt noch an der notwendigen Kompatibilität zu anderen Implementierungen. Das heißt ich kann nicht mit allen nodes im Netzwerk einen Channel aufmachen. Einige mögen meine Einstellungen nicht oder andersrum meine node mag deren Einstellungen nicht. Da fehlt noch ein Abgleich was alles erlaubt und nicht erlaubt ist. Es ist also noch Potential nach oben.

Am ‎06‎.‎04‎.‎2018 um 17:49 schrieb Kiwianer:

Für das Binance-Konto habe ich bei Kontoname einfach Binance eingegeben, und den 16-stelligen Key verwendet. Zack - funktioniert

Für das Coinbase-Konto habe ich bei Kontoname auch einfach Coinbase eingegeben, und wieder denselben 16-stelligen Key verwendet. Dödöööm - leider funktioniert es hier nicht

Ich muss nochmal so blöd fragen. Denselben Key? Ich hätte unterschiedliche Keys erwartet. Hast du in deinen Unterlagen eventuell noch ein Backup vom Coinbase Key?

vor 8 Stunden schrieb Watesmo:

Gemeinschaftskonto also von daher werde ich es auch sicher nicht zurückzahlen.

Gemeinschaftskonto heißt nicht automatisch, dass die Haftung aufgeteilt wird. Je nach Gesellschaftsform musst du den kompletten Betrag aus deinem Privat Kapital begleichen und darfst alles weitere intern mit deiner Gemeinschaft klären. Dein Anwalt kann dir erklären was rechtlich hinter dem Gemeinschaftskonto steckt.

Bei Einzahlungen gebe ich dir Recht. Die findet man relativ einfach auf der Blockchain. Bei den Auszahlungen wird es dagegen schwierig. Dazu muss man schon genau wissen wohin man die Coins gesendet hat damit man sie auf der Blockchain auch findet.

Meine Lösung für das Problem. Nach größeren Trades bei Cointracking sofort alles buchen bzw die automatischens Jobs dafür nutzen. Ab und zu ein Backup und CSV Export erstellen. Auch Cointracking kann gehackt werden und geht dann eventuell offline.

Ein Verlust zu verbuchen ist in diesem Fall tatsächlich unlogisch. Es war die Rede von der Trading History. Wo die Coins zum Zeitpunkt der Schließung lagen, wurde nicht genannt.

Folgendes Scenario:

Ich kaufe 1 BTC von einer Börse und betreibe ein paar Jahre Daytrading. Am Ende bringe ich es auf 2 BTC. Diese 2 BTC lasse ich jetzt 1 Jahr liegen und kann damit auch die Steuern auf das Daytrading umgehen? Das wird nicht funktionieren.

mehr als ein Jahr zwischen Anschaffung und Veräußerung liegt.

Na dann versuch dem Finanzamt mal die Anschaffung zu erklären wenn dazu die Unterlagen fehlen.

Nein. Du musst den Erwerb nachweisen. Du kannst nicht einfach lustig Daytrading betreiben, keine Steuern bezahlen und die Coins dann 1 Jahr liegen lassen in der Hoffnung sie später steuerfrei verkaufen zu können. Kannst du den Erwerb nicht belegen, wird der Verkauf auch nach mehr als einem Jahr beim Finanzamt so nicht durchgehen.

Am WE etwas Zeit zum Testen des Routings gehabt. Das scheint mir sehr gut zu funktionieren. Die Routen werden nach Gebühren sortiert. Die billigste Route gewinnt selbst wenn sie mehr hops benötigt. Die Gebühren werden immer abgerundet. Das heißt 0,9 sat geht noch als kostenlos durch aber ab 1,0 muss dann bezahlt werden.

Es wurden bereits ca 10 Zahlungen über meine node geroutet allerdings derzeit noch kostenlos. Jetzt wo das funktioniert, habe ich meine Gebühren angepasst und mal sehen ob dabei ein paar sat abfallen.

Einfach mal im Freundeskreis rum fragen. Ein altes Smartphone hat jeder im Schrank. Das darf auch gern 10 Jahre alt sein. Sim Karte ist nicht notwendig.

Update: Hab zwei Channels zu zwei Freunden aufgebaut und kann jetzt auch den Rest testen.

Rechnungen ohne Betrag sind möglich. Beim Bezahlen einer solchen Rechnung bin ich gezwungen selber einen Betrag anzugeben. Mache ich das nicht, bekomme ich eine Fehlermeldung angezeigt. Derzeit noch mit falschen Text. Dazu werde ich später noch ein Issue eröffnen.

Die bezahlte Rechnung wird auf beiden Seiten vermerkt. Zahlungsbelege so wie man sich das wünscht.

Als nächstes testen wir noch das Routing. 2 von 3 bauen eine Route zu irgend einer node auf und der dritte fragt die Routen ab. Dann können wir die Gebühren der zwei Channels anpassen und jeweils sehen welche Route gewinnen würde. Dauert aber noch ein paar Tage bis wir soweit sind.

Zitat

D.h. es ist möglich, als Zahlender den Betrag frei auszuwählen? Die Info hat mir bisher gefehlt ...

Zitat

Invoices without an amount can be created by not supplying any
parameters or providing an amount of 0. These invoices allow the payee
to specify the amount of satoshis they wish to send.

Konnte ich bisher leider noch nicht testen. Laut beschreibung sieht die Sache so aus.

Zitat

Darüber habe ich auch schon relativ viel nachgedacht. Es ist irgendwie möglich, aber ich finde es ziemlich unbefriedigend. Die Leute sollen ja nicht jedesmal, wenn sie mir etwas zahlen, einen Payment-Channel zu mir aufmachen. Außerdem wird das Volumen der Zahlungen ja durch den einen Channel begrenzt, und solange ich keinen neuen Channel irgendwohin eröffne, wird der immer einseitig bleiben. Nicht unlösbar, aber wie ich ja gemeint habe, es macht die Sache eher komplizierter als einfacher.

Du machst einfach nichts und wartest darauf, dass ich den Channel eröffne und am Leben halte. Ich werde die Situation ausnutzen und deinen Kunden eine Routing Gebühr von bis zu 50sat in Rechnung stellen. Je nach Marktlage vielleicht auch mehr. Bevor der Channel leer läuft, werde ich ihn mit frischen Kapital auffüllen. Bei der Routing Gebühr wäre es fast schon sträflich wenn ich nicht vorausschauend plane. Ich werde dabei relative Hohe Summen in den Payment Channel legen um meine Kosten gering zu halten. Das bekommen wir auf jeden Fall hin.

Zitat

Wenn ich B richtig verstehe, führt das wieder einen Mittelsmann ein (und macht die Voraussetzungen komplexer). Aber auch das können wir einmal ausprobieren, das wäre wie A, nur dass die Leute, die mir Spenden geben, nicht das Skript laufen lassen, sondern du, richtig?

Ja richtig. Das Skript ist optional. Geht notfalls auch erstmal per Hand.

Zitat

Mein eigentliches Problem war, dass man die Channels einseitig leeren kann, was natürlich harmlos ist, bei Spenden, aber ernst wird, wenn sich das ganze verkettet. Wenn ich dann regelmäßig-unregelmäßig Spenden bekomme, reicht es nicht mehr, einmal die Woche online zu sein, weil ja in jedem Moment eine N=144 Frist auslaufen könnte (oder habe ich hier wieder einen Gedankenfehler?)

Kann ich derzeit noch nicht beantworten. Die 144 scheint mir konfigurierbar zu sein. Was eine Erhöhung oder Verringerung für Auswirkungen hat und in welchen Fällen das überhaupt möglich ist, weiß ich noch nicht.

Zitat

Naja, aber d.h. dass der Pizza-Lieferant zunächst darauf angewiesen ist, dass jmd einen Channel mit ihm eröffnet, der erstmal einseitig ist, und dann ist seine Kapazität auf die des Channels beschränkt. Ist alles möglich, aber eben erneut eine Verkomplizierung der Sache.

Siehe oben. Ich warte nur darauf, dass der Pizza-Lieferant das macht. 1000€ in den Channel gelegt das sollte für den Anfang genug Kapazität sein. Alles weitere ergibt sich dann von selbst. Ich werde vorausschauend planen.

Das ist keine Raketen Wissenschaft. Ich rechne pro Channel mit Gesamt Kosten von ~300 sat. Diese 300 sat will ich wieder einnehmen. Pizza Lieferant und Blog Spenden sind dafür eigentlich perfekt. Viele kleine Zahlungen. Alles weitere ist am Ende nur eine Frage der Routing Gebühren.

Zitat

Aber wenn du mir dabei hilfst, einen LN einzurichten, mit dem ich Spenden empfangen kann, wäre das geil, und wir sollten es auf jeden Fall ausprobieren. Vielleicht wird das ja auch einige meiner Bedenken durch Praxis ausräumen.

Gerne. Noch ein paar Versionen abwarten oder gleich loslegen? Gibt noch ein paar Bugs die du vielleicht nicht ausprobieren willst

Vermutlich zwei verschiedene Vorfälle mit dem selben Resultat.

Machen wir das Stück für Stück:

Zitat

- man kann den Betrag nicht wählen oder braucht eine App, die das macht, -- anstatt dass ich einfach eine Adresse poste

Du kannst eine Invoice mit Wert 0 erstellen. Der Anwender gibt dann die Betrag an und kann die Rechnung auf den Weg schicken. Alles weitere wie gehabt. Ob du nun eine Adresse oder eine Invoice postest, ist am Ende Hoch wie Breit. Sobald die Wallets das neue Format unterstützen ist es nur noch ein klick auf deine Spenden Aufforderung.

Zitat

um Geld empfangen zu können, muss ich erstmal Geld in einen Channel pumpen und dann irgendetwas zu bezahlen (sagen wir, einen Amazon-Gutschein). Danach kann ich MAXIMAL Spenden im Wert des Amazon-Gutscheins annehmen. Mit einer Bitcoin-Adresse kann ich ohne jede Vorleistung endlos viel empfangen. Wer weiß, wie die Spendenökonomie funktioniert (sehr wenige große Spenden machen den Großteil der Einnahmen aus), wird das als No-Go erkennen.

Ein Channel eröffnen müssen die Personen die Geld versenden möchten. Du willst nur Geld empfangen und musst dafür keinen einzigen Channel eröffnen. Jemand anderes wird das netterweise machen. In deinen speziellen Fall würde ich das gern übernehmen wenn du Interesse hast. Ich bekomme für das Weiterleiten der Spenden ja eine kleine Gebühr. Also eine Win Win Situation für alle Beteiligten.

Das ist kein Theoretische Annahme sondern ist in meinem Fall exakt so gelaufen. Noch bevor ich einen Channel offen hatte, hat jemand anderes einen Channel zu mir eröffnet. Damit war ich zu diesem Zeitpunkt in der Lage Geld zu empfangen aber nicht welches zu senden.

Hinweis: Beim Eröffnen eines Channels kann man auch gleich für die Gegenseite ein Guthaben einzahlen. So könnte ein Exchange für jeden Neukunden ein Channel eröffnen mit 10€ Startguthaben. Ob Sinnvoll oder nicht sei mal dahin gestellt. Es ist zumindest technisch möglich.

Zitat

schließlich beschränkt ein LN-Invoice die potenziellen Spender auf jene Leser, die einen LN-Node haben. Ich sehe auf absehbare Zeit nicht, dass diese Menge ähnlich groß ist wie die Leser, die irgendeine Art von Bitcoin-Wallet benutzen. Da die meisten Wallets es bis jetzt noch nicht mal geschafft haben, SegWit zu implementieren, sehe ich auch nicht, wie LN in absehbarer Zeit die bestehende Arbeit an Wallets nutzen können wird.

Genau dafür hat die Invoice eine alternative Payment Adresse. Der Kunde entscheidet ob er die Rechnung über Lightning oder über "Standard Bitcoin" bezahlt.

Zitat

ich muss bei einem fortlaufenden Strom von Spenden einen LN-Node betreiben, oder einen Mittelsmann (Watchtower) benutzen.

Zur Zeit ja aber auch hier zeichnet sich mehrere Lösungen ab. Nehmen wir mal an du bist nur eine Stunde pro Tag online und am WE auch mal zwei Stunden. Selbes Spiel bei mir.

A: Jetzt klicke ich auf deinen Spenden Link. Mein Wallet öffnet sich und bietet mir eine Zahlung per Lightning an mit dem Hinweis, dass du derzeit offline bist oder eine direkte Überweisung. Da mir völlig egal ist wann du die Spende bekommst, wähle ich die Variante mit den günstigeren Gebühren. Mein Wallet speichert die Invoice ab und versucht im Abstand von 10 Minuten eine Route zu dir zu finden. Erst am WE schaffen wir es beide zeitgleich online zu sein und die Zahlung wird erfolgreich geroutet.

B: Meine Lösung für das Problem würde allerdings noch etwas anders aussehen. Ich würde zwei nodes laufen lassen. Eine node auf meinem Rechner zum senden von Zahlungen. Eine node auf einem Mittelsmann zum Empfangen von Zahlungen. Damit kann ich die Vorteile beider Varianten kombinieren. Ich kann jederzeit Geld erhalten, kann es beim nächsten Start auf meine node sofort kostenlos umbuchen und der Mittelsmann hat nur kurzzeitig Zugriff auf das bisschen Geld.

Diesen Service könnte ich dir ebenfalls anbieten. Können wir gern für ein paar Monate ausprobieren und uns dann eine dauerhafte Lösung überlegen.

C: Die dritte und letzte Möglichkeit beruht auf der Tatsache, dass der Start der node und das Entschlüsseln der Wallet Datei zwei verschiedene Befehle sind. Das lässt mich vermuten, dass es später wie bei bitcoin core laufen soll. In diesem Fall könnte ich die node laufen lassen aber mehr nicht. Nur du hast das wallet Passwort was für bestimmte Aktivitäten notwendig wäre.

Lösung A wäre derzeit nur über Scripte möglich. Ich kenne noch kein Wallet was das automatisch machen würde. Allerdings habe ich auch nicht danach gesucht...

Lösung B ist kein Thema und kann sofort umgesetzt werden. Alle notwendigen Tools sind bereits vorhanden.

Lösung C wird noch ein paar Entwicklungs Zyklen benötigen und es ist fraglich ob meine Vermutung überhaupt richtig ist. Wir werden sehen.

Zitat

0.) der Pizza Lieferant braucht einen Lightning-Channel, d.h. er muss nach dem derzeitigen Modell so viel Geld über LN ausgeben, wie er vorhat, einzunehmen.

Siehe oben. Der Pizza Lieferant muss keinen Channel aufmachen. Den werde ich eröffnen.

Zitat

4.) Da 0-confs bei Pizzas absolut ausreichend sicher sind, hat LN hier keinen Vorteil für den Pizzabäcker.

Ja in dieser Hinsicht ist mein Beispiel schlecht gewählt. Meine Schmerzgrenze wäre derzeit 1000€. Pizza Lieferant habe ich nur gewählt weil ich da mein Essen so schnell wie möglich haben möchte ohne mich noch mit dem mempool rumschlagen zu müssen. Das will ich auf einen Freitag Abend im Halbschlaf nicht machen müssen. Daher nutze ich als Kunde derzeit noch Paypal würde aber auf Lightning umsteigen wenn es möglich ist.

Zitat

5.) Was für eine Seite?

Meine "Seite" des Vertrags. Will der Pizza Lieferant nicht liefern, muss ich von meiner Seite beweisen, dass ich meinen Teil des Vertrages eingehalten habe. Ich benötige also einen passenden Beleg. Das scheint bei der Rechnungs Funktionalität beachtet worden zu sein aber ich konnte es noch nicht testen.

Zitat

Vorteile LN für den Pizzabäcker im Vergleich zu Bitcoin? Mir fällt keiner ein, außer der abstrakten Gewissheit, das Bitcoin-Netzwerk nicht zu missbrauchen. Ich weiß, dass dieser Vorteil für viele - darunter mich selbst - gigantisch ist, aber für einen normalen Pizzabäcker spielt er keine Rolle. Welche Nachteile hat er dagegen?
- geringere Reichweite (Netzwerkeffekt)
- er muss Geld vorschießen
- er muss einen LN-Node offenhalten bzw. einen Mittelsmann beauftragen

Siehe oben. Kurzfassung:

Fallback über Bitcoin Transaktion im Rechnugs Format

Channel nicht notwendig. Den eröffne ich.

Es düfte ausreichend sein die node zu den Öffnungszeiten laufen zu lassen. (Im Gegensatz zu deinen Spenden. Da wäre eine der anderen oben stehenden Lösungen notwendig)

Zitat

Ich bin sicher, es gibt noch mehr Nachteile, wenn ich gründlich nachdenke.

Interessante Grundhaltung. Dazu kann ich selber nicht viel Sagen. Ich bin als Test Engineer alles andere als objektiv, bin mir dessen voll und ganz bewusst und halte mich daher absichtlich zurück. Ich versuche dann eher meinen Gegenüber Lücken in seiner Argumentation aufzuzeigen. Mit anderen Worten mein Testobjekt bist jetzt du und nicht mehr Lightning Ein Urteil über das Lightning Netzwerk erlaube ich mir erst wenn meine Tests abgeschlossen sind.

Zitat

Ich hoffe, das alles wird mir jetzt nicht als "Christoph ist gegen Lightning" ausgelegt.

Ja das lege ich dir genau so aus aber das ist im Grunde völlig egal. Ein Forum ist doch genau dafür da. Zum Austausch von Meinungen. Grundsätzlich finde ich dein Feedback sehr hilfreich.

Ein Problem habe ich nur mit dem Blog Post. Ich finde es schade, dass wir die aktuelle Diskussion nicht vor dem Blog Post geführt haben. Ich habe meine Hilfe angeboten und biete sie auch weiterhin an. Ich helfe euch beim Einrichten euer nodes, eröffne einen Channel auf meine Kosten, wir können ein wenig kostenlos Zahlungen hin und her senden und alle Funktionalitäten testen. Mehr als Anbieten kann ich es nicht.