skunk

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.

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.

Konnte ich bisher leider noch nicht testen. Laut beschreibung sieht die Sache so aus. 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. Ja richtig. Das Skript ist optional. Geht notfalls auch erstmal per Hand. 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. 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. 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: 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. 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. Genau dafür hat die Invoice eine alternative Payment Adresse. Der Kunde entscheidet ob er die Rechnung über Lightning oder über "Standard Bitcoin" bezahlt. 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. Siehe oben. Der Pizza Lieferant muss keinen Channel aufmachen. Den werde ich eröffnen. 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. 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. 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) 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. 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.

Danke vielmals

Soweit würde ich derzeit noch nicht gehen. Das wäre etwas zu voreilig. Zumindest fehlt mir aber der Beweis für deine Aussage. Wie kommst du zu der Schlussfolgerung Lightning wäre die komplizierteste und aufwändigste Lösung? Wenn schon auf der untersten Ebene die Erstellung, Bezahlung und Nachverfolgung von Rechnungen möglich sind, wie wird das dann später mit passenden GUIs aussehen? Ich könnte mir bereits heute vorstellen eine Pizza über einen Lightning Payment Channel zu bezahlen. Ohne es genau getestet zu haben sieht die Lage für mich derzeit so aus: 1.) Pizza Lieferant gibt mir den Invoice Hex Code. Ich würde tatsächlich den Hex Code benötigen weil ein QR Code und ein Terminal Fenster sich nicht vertragen. 2.) Ich decodiere den Hex Code. Darin enthalten ist der Betrag, die Ziel Adresse und zwei Zusätzliche Beschreibungs Felder in denen ich die Bestell Nummer erwarten würde. Dieser Schritt ist optional und kann theoretisch auch übersprungen werden. 3.) Ich füge den Hex Code in eine Zahlungsanweisung ein. Alles weitere passiert automatisch. Pizza bezahlt in Sekunden mit einer Transaktionsgebühr von 2-3 sat. 4.) Der Pizza Lieferant kann genau abfragen welche Rechnungen bereits bezahlt wurden und kann sofort mit seiner Arbeit beginnen. 5.) Sollte der Pizza Lieferant die Zahlung aus irgend welchen Gründen nicht zuordnen können (was bei diesem Vorgehen sehr unwahrscheinlich ist), hab ich auf meiner Seite noch einige Funktionen zur Verfügung die ich in den nächsten Tagen noch weiter testen werde.

Mich würden die zu Grunde liegenden Berechnungen interessieren. Wie kommst du auf diese Zahlen. Je genauer um so besser. Keine Angst. Ich beiße nicht. Ich bin nur an den Details interessiert um gegebenenfalls meine eigenen Schlussfolgerungen zu korrigieren.

Öhm ja. Damit sind wir endgültig beim Schwanzvergleich angekommen... Es soll auch normale Menschen geben, die als Entwickler im Bereich Krypto arbeiten. Davon sind auch einige hier im Forum aktiv. Rechne da mal mit 40 Stunden die Woche Arbeitszeit und noch mal 20 Stunden zusätzlich Weiterbildung in der Freizeit. Und dann kommst du mit einem anderen Entwickler in Kontakt der noch mal deutlich mehr Wissen hat als du. Geh also besser davon aus, dass du nur einen Bruchteil verstanden hast und höchstens geringfügig mehr Wissen hast als alle anderen. Hose aufmachen und zum Schwanzvergleich aufrufen kann auch ganz schnell nach hinten losgehen... Bitte bitte mach das nicht. Einen ERC-20 Contract oder eine BTC Blockchain mit bereits vorhandenen Fehlern zu kopieren ist kein Grundstein für ein erfolgreiches Projekt. Beauftrage dafür besser einen Spezialisten und einen zweiten um die Arbeit prüfen zu lassen. Den Rest verkneif ich mir jetzt einfach diplomatisch.

@Christoph Bergmann Ich lasse folgendes einfach mal unkommentiert stehen: # ./lnd/lncli addinvoice --memo 'Lehrgeld' --amt 15000 --expiry 86400 { "r_hash": "217dc421d3445bf27676121a5b87898dd6b2a15ff56d63c9c17ea8af31890c42", "pay_req": "lnbc150u1pdtkdmvpp5y97uggwng3dlyankzgd9hpuf3htt9g2l74kk8jwp06527vvfp3pqdqdf3jksun8v4kxgcqzysxqyz5vqas2700j2kacehfz3xz34ug7cymkwvcrdtcs5hruvq0s9s7klvkxqp3xrnuj2hyva4uta6pu7qrruxvf27cwcrnfuyxe056dgfap57qcqc0de5e" } # ./lnd/lncli decodepayreq lnbc150u1pdtkdmvpp5y97uggwng3dlyankzgd9hpuf3htt9g2l74kk8jwp06527vvfp3pqdqdf3jksun8v4kxgcqzysxqyz5vqas2700j2kacehfz3xz34ug7cymkwvcrdtcs5hruvq0s9s7klvkxqp3xrnuj2hyva4uta6pu7qrruxvf27cwcrnfuyxe056dgfap57qcqc0de5e { "destination": "035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81", "payment_hash": "217dc421d3445bf27676121a5b87898dd6b2a15ff56d63c9c17ea8af31890c42", "num_satoshis": "15000", "timestamp": "1522218860", "expiry": "86400", "description": "Lehrgeld", "description_hash": "", "fallback_addr": "", "cltv_expiry": "144" } # ./lnd/lncli listinvoices { "invoices": [ { "memo": "Lehrgeld", "receipt": null, "r_preimage": "bCp09f55/nBRLB3tOQm147uo/3rNjbbkhdqbQifgmrw=", "r_hash": "IX3EIdNEW/J2dhIaW4eJjdayoV/1bWPJwX6orzGJDEI=", "value": "15000", "settled": false, "creation_date": "1522218860", "settle_date": "0", "payment_request": "lnbc150u1pdtkdmvpp5y97uggwng3dlyankzgd9hpuf3htt9g2l74kk8jwp06527vvfp3pqdqdf3jksun8v4kxgcqzysxqyz5vqas2700j2kacehfz3xz34ug7cymkwvcrdtcs5hruvq0s9s7klvkxqp3xrnuj2hyva4uta6pu7qrruxvf27cwcrnfuyxe056dgfap57qcqc0de5e", "description_hash": null, "expiry": "86400", "fallback_addr": "", "cltv_expiry": "144" } ] }

Das Ziel habe ich mir mehr oder weniger Zufällig ausgesucht. Man kann also davon ausgehen, dass derzeit jedes Ziel nur 2-3 Hops entfernt ist. Ein Hop geht auf mein Konto weil ich bisher nur einen einzigen Channel offen habe was für das Routing einen unnötigen Umweg bedeutet. Maximal kann ich 0,0001 BTC senden sonst findet er keine Route. Es gibt ein Kommando updatechanpolicy mit dem man die Gebühren aller oder gezielt bestimmter Channels anpassen kann. So das war es erstmal von meiner Seite. Noch Fragen?

Hier mal ein Beispiel bei dem ich eine Router für eine 0 Überweisung suche (lncli queryroutes --dest 0347ffcb271ef54fa6103fc6392370ce398d1bc98460829f7046cf64026253a68e --amt 0). Gefunden werden 4 Routen mit unterschiedlichen Gebühren. Hier mal 2 der 4 Routen: { "total_time_lock": 515428, "total_fees": "2", "total_amt": "2", "hops": [ { "chan_id": "566249587943473153", "chan_capacity": "10000", "amt_to_forward": "1", "fee": "1", "expiry": 515284 }, { "chan_id": "566478286372339712", "chan_capacity": "10000", "amt_to_forward": "0", "fee": "1", "expiry": 515270 }, { "chan_id": "565909838810185729", "chan_capacity": "55000", "amt_to_forward": "0", "fee": "0", "expiry": 515270 } ] }, { "total_time_lock": 515442, "total_fees": "3", "total_amt": "3", "hops": [ { "chan_id": "566249587943473153", "chan_capacity": "10000", "amt_to_forward": "2", "fee": "1", "expiry": 515298 }, { "chan_id": "566467291161100288", "chan_capacity": "10000", "amt_to_forward": "1", "fee": "1", "expiry": 515284 }, { "chan_id": "559832838023741440", "chan_capacity": "230000", "amt_to_forward": "0", "fee": "1", "expiry": 515270 }, { "chan_id": "559685503494193152", "chan_capacity": "1100", "amt_to_forward": "0", "fee": "0", "expiry": 515270 } ] },

Ich glaube da muss ich noch ein paar Sache klar stellen. Ich bin von Beruf Test Engineer. Ein gefundener Fehler ist ein Erfolgserlebnis für mich. Wenn ich dabei helfen kann ihn schnell und einfach zu beheben dann steigert das mein Erfolgserlebnis zusätzlich. Mein Ziel ist es die Fehler so früh wie möglich zu finden weil dadurch eine Fehlerbehebung deutlich kostengünstiger ist. Finde ich keine Fehler, ist das eher ein Misserfolg für mich. In dem Fall wird die spätere Fehlerbehebung teurer. Ich stelle mir dann bei den späteren Fehlern die Frage was ich hätte anders machen können um sie früher zu finden. Ich finde selbst in funktionierenden Systemen diverse teilweise gravierende Bugs die normalen Anwendern überhaupt nicht auffallen und nicht stören. Lange Rede kurzer Sinn: Was alles fehlerfrei funktioniert, habe ich nicht aufgezählt. Bitte beachtet das beim Lesen meiner Aussagen. Dann besser selber die Software installieren und ein eigenes Bild von der Lage machen. Ich glaube dabei kann ich eher behilflich sein.

Dazu gibt es bereits zwei Lösungsansätze. Einer Anwender hat Versucht über A eine Route zu finden die am Ende bei C endet. Dann könnte er einfach eine Zahlung an sich selber durchführen um die Channels auszugleichen. Nehmen wir also an vor der Aktion sieht das Netzwerk so aus: A „0“ - - - „2“ B „0“ - - - „4“ C "1" --- "1" A Jetzt sendet B über die Route B->A->C->B 1 and sich selbst. Damit hätten wir den Endstand: A „1“ - - - „1“ B „1“ - - - „3“ C "0" --- "2" A Eine solche Überweisung ist theoretisch möglich wird aber derzeit noch von einigen Fehlerprüfern abgelehnt. Zahlung an sich selber ist nicht erlaubt. Ein Issue wurde dazu erstellt. Soll also irgendwann ermöglicht werden. Mir stellt sich am Ende die Frage ob C den alten Zustand nicht besser fand und eine entsprechende Zahlung in die Gegenrichtung starten würde. Damit hätte man dann ein Netzwerk was ständig versucht mit Micropayments die Channels auszugleichen und keiner Gewinnt das Spiel. Was ich noch testen muss ist die Frage ob die Routing Gebühren pro Node oder pro Channel sind. Es gab da ein Update Channel Command. Eventuell kann man damit nachträglich die Gebühren anpassen. Das würde B ermöglichen die Gebühren kurzfristig zu reduzieren damit eine Route von C->B->A kostengünstiger wird und dann eine normale Zahlung für den Ausgleich der Channels sorgt. Lösung Nummer zwei hört auf den Namen "splicing in/out". Damit soll es möglich sein den Kontostand eines Channels in beide Richtungen zu updaten. Derzeit noch nicht implementiert daher kann ich nicht mehr dazu sagen.

Route und Gebühren werden vor dem versenden Berechnet. Die Option "Gebühren vom Betrag abziehen" gibt es derzeit noch nicht. Ein passender Feature Request ist vorhanden. Ein Limit für die Gebühren gibt es noch nicht. Man sollte sich derzeit die Routen zum Ziel vorher ausgeben lassen. Dabei wird wohl auch die Gebühr mit ausgegeben (muss ich heute Abend mal testen). Macht man das nicht, droht eventuell eine ungewöhnlich hohe Gebühr. Es wird an ein paar Pull Requests gearbeitet um für die Gebühren ein Limit mit auf den Weg zu geben und die zu teuren Routen damit abzulehnen. Das Routing ist derzeit noch Fehleranfällig. Es werden ungültige Routen berechnet. Die Hops verfügen über genug Kapital sind aber auf einem alten Blockheight stehen geblieben. Frisches Kapital werden diese Hops nicht routen können weil die passenden Einzahlungen für sie noch nicht stattgefunden haben. Auch kann ein Hop mit einer anderen timelock Einstellung Probleme machen. Zukünftig soll das beim Routing beachtet werden. Pull Request vorhanden aber noch nicht gemerged.

Nein. A zahlt für das Routing eine Gebühr an B. Vermutlich ist die Gebühr zu gering sodass B beim schließen und neue öffnen der Channels Verluste machen würde. Er kann aber auch einfach die Channels so lassen wie sie sind. Zahlt C Geld an A bekommt B erneut eine kleine Gebühr. Je länger er die Channel offen lässt um so mehr Gebühren bekommt er fürs Routing.

Mal ein kurzer Zwischenstand. Meine Lighning node ist jetzt auf der Map zu sehen. Das ist aber auch schon alles. Aktuell hat die Software noch diverse Bugs. Eine richtige Zahlung ist so noch nicht möglich. Teilweise gibt es Rechenfehler. Sowas geht garnicht. Auch ein Recovery ist derzeit nicht möglich. Das Wallet kommt zwar mit einem Backup Seed und man kann mit diesem Seed auch jederzeit sein Wallet wiederherstellen nur fehlt dann in der Software der Rescan. Privater Schlüsel vorhanden aber Blockchain wird nicht nach alten Guthaben gescannt Resourcen Verbrauch ist akzeptabel. Ich werde meine Lightning node einfach laufen lassen. Wer einen Channel zu mir eröffnen möchte, kann das gern machen. 035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81@84.139.122.35:9735 bzw das passende Kommando ` lncli openchannel --node_key 035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81 --connect 84.139.122.35:9735 --local_amt 1337 ` In diesem Fall ein 1337 sat channel. Bitte kein Geld an mich senden ohne vorherige Absprache. Ich werde es selbstverständlich zurück senden aber ich möchte dafür auch am Platz sein und meine Logdatei überwachen.

Die Frage kann ich jetzt selber beantworten: --private make the channel private, such that it won't be announced to the greater network, and nodes other than the two channel endpoints must be explicitly told about it to be able to route through it Meine Lightning node läuft. Falls jemand Hilfe braucht oder mal ein paar Transaktionen senden möchte, einfach melden. Was ich bisher rausgefunden habe: 1.) Es gibt einen automatik modus bei dem die node einfach selbstständig channels eröffnet und schließt. Per config kann man darauf Einfluss nehmen was sowohl die Anzahl als auch die Menge an BTC angeht. 2.) Routing von Transaktionen kostet eine Gebühr: basefee + (amount * feerate / 1000000)