skunk

Das sieht mir so aus als wäre da noch einige Fehler verborgen. Bei mir wird die Rechnung auch weiterhin nur einmal angezeigt. Für eine Spenden Rechnung komplett unbrauchbar. Da erwarte ich eine Auflistung aller Zahlungen. Viel schlimmer ist aber folgendes: 2018-05-04 19:04:35.770 [ERR] HSWC: ChannelPoint(a12e77885380fdd66cb40ea2d226756a3767a1fcca20b5dffd55e181d87952fc:1): recieved error from peer: commit_sig with no changes 2018-05-05 07:34:22.296 [ERR] HSWC: ChannelPoint(e3342ee4cc5c28cf6856a0d66720385f17207d55e9303dbc9d86bd8354dc6a9a:0): recieved error from peer: commit_sig with no changes Danach ist meine Node Amok gelaufen und hat beide Channels irgendwann geschlossen. Nicht das was man von einem Channel erwarten würde. Ich bin mir jetzt nicht mal sicher ob das Geld bei mir überhaupt eingegangen. Werde da erstmal noch etwas Nachforschen müssen.

Sonst versuch es mal mit sendpayment. Das hat noch ein paar weitere Optionen. --final_cltv_delta steht default auf 0. Keine Ahnung was das macht aber es könnte bedeutsam sein^^

Nein. Ich will doch kein Geld verschenken. Wäre auch witzlos der Gegenseite erst 5000 sat zu schenken um dann eine Zahlung in gleicher Höhe zu erhalten. Damit wäre nach der ersten Zahlung der Channel in exakt dem Zustand der dir eventuell Probleme macht. Ich erwarte eigentlich, dass das beim Routing automatisch geregelt wird. Soll er halt die nächste Route probieren. Irgendwann sollte er eine gültige Route finden. Ich habe 24 eingehende Channels. Die haben natürlich 0 Guthaben auf meiner Seite und volles Guthaben auf der Gegenseite. Klingt also eher nach einem Problem an einem der Zwischenstationen.

Kann losgehen. Meine invoice ist: "pay_req": "lnbc1pdwcv7mpp59myp7hk67yt3gvwj28vtmr8637kfwssnwn87yn29y3z68wmyyr2qdq8w3jhxaqcqpwxq9unsuqezeyrqjr6u7ketx4qw47uenpmp4c7q8jkvzpgm90g4ee4ansckh36e4gfy8yt2gr02veqagzqx58jjrcfae6wqtq6amlqvuu340s08gqjzwd5s" Den Betrag musst du selber wählen. Beim bezahlen also --amt nicht vergessen sonst gibt es eine Fehlermeldung. Du hast maximal 347 Tage Zeit um die Rechnung zu bezahlen (----expiry 30000000). Maximum scheint 1 Jahr zu sein. Mich würde auch interessieren ob der Zahlungscode nur exakt einmal genutzt werden kann oder mehrfach. Das kann ich testen wenn ich dir das Geld zurück sende.

Sorry bei uns waren am WE Überstunden angesagt. Ich komme leider erst jetzt dazu mich wieder mit dem Ligthning Netzwerk zu beschäftigen. Ja die Router zeigt mir ebenfalls 2-3 sat Gebühren an. Wenn du noch Interesse hast, können wir gern weiter testen.

Die Option "Alle Käufe nach Tag gruppieren" ist daran Schuld. Diese Option muss deaktiviert werden damit er Trades am gleichen Tag zuordnen kann. Eigentlich ist es ein Bug, dass diese Option jedesmal Standardmäßig aktiviert ist. Ich verstehe wofür sie da ist. Damit kann man Probleme bei der Zeitrumrechnung aus dem Weg gehen. Angesichts der Folgen sollte das aber eine Option sein, die standardmäßig deaktiviert ist. Dann ist man sich als User auch bewusst welche Folgen diese Option haben kann.

Stimmt soweit alles allerdings können wir auch erst mal ein paar Trockenübungen machen. $lncli queryroutes --dest 035e3662cd71e0596daf5b150d86a990bc25cb1f73467950e0b08be5c73bf89a81 --amt 5000 Sollte dir anzeigen welche Routen es zu mir gibt und wie teuer diese wären.

Ja ich. Hier!

Gib mir einen Moment dann frag ich meine Lightning node nach der Kapazität des Netzwerkes. Das kann wie gesagt jeder abfragen. Was tatsächlich über die Channels geht ist dagegen nicht von Außen einsehbar. Eine Kapazität von 1 BTC bedeutet, dass alle vorhandenen Channels zusammen eine Größe von 1 BTC haben. Es können in der selben Millisekunde nicht mehr als dieser 1 BTC bewegt werden. Eine Millisekunde später kann der 1 BTC nochmal in die Gegenrichtung bewegt werden. Das ganze Spiel immer wieder hin und her. So hat man ein Netzwerk mit einer Gesamtkapazität von 1 BTC was aber bereits 2 BTC bewegt hat. Transaktionen werden derzeit nicht in eine Warteschlange geschoben. Sie werden sofort ausgeführt und melden innerhalb von Sekunden eine Fehlermeldung zurück. Sorry ich wurde etwas aufgehalten und aus dem Moment wurden Stunden. Hier die aktuellen Zahlen root@bitcoin:~# ./lnd/lncli getnetworkinfo { "graph_diameter": 0, "avg_out_degree": 3.001557632398754, "max_out_degree": 373, "num_nodes": 1926, "num_channels": 5781, "total_network_capacity": "1695796275", "avg_channel_size": 293339.60819927347, "min_channel_size": "1050", "max_channel_size": "16777216" } Demnach sind es fast 17 BTC. Weiter rapide ansteigend.

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.

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.

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.

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.

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.

Das ist jetzt ein Wiederspruch. Bekommt der Beschenkte die Coins zum Tageskurs oder muss er sie ein Jahr halten? 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.

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.

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?

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.