Hallo,

Ich hab einen Lightning node am Laufen und muss gestehen dass ich mir nur von Zeit zu Zeit
im Detail ansehe was da passiert.

Jetzt habe ich gesehen dass zwischen dem 3. und 6.Mai ein Großteil meiner offenen Channels geschlossen worden ist.

Außerdem sehe ich dass seit dem 20.April das Kommando 'lncli describegraph' nur noch einen Bruchteil der Knoten sieht:

vorher:  20047
nachher: 2198

Weiß jemand ob zu diesen Terminen irgendwas passiert ist was das erklären kann ?

I am running a lightning node (LND) for a long time.
But I didn't look too much into details of its operation
but I actually would like to do that if it does not take too much effort.

Are there any tools available to diagnose the performance of an LND node in some detail ?
(usage history of channels etc.)
Probably there are. Can anybody provide any info on that ?

Thanks in advance, A.

Auch danke für die Info.

Ich hatte mein OB2-Wallet gemäß dem oben angegebenen Link  https://www.reddit.com/r/OpenBazaar/comments/kw52s3/repairing_ob_wallet/ repariert.
Das hat bis vor kurzem funktioniert geht aber jetzt nicht mehr.
Weiß jemand ob es da noch eine andere Konfiguration gibt ?

Ein gutes neues Jahr für alle!
Und herzlichen Glückwunsch an die Gewinner auf dem Treppchen!

Da haben die alten Hasen ja mächtig abgesahnt.

Herzlichen Glückwunsch!

weitere 0.002btc sind unterwegs.

Ich wünsche allen einen guten Rutsch!

Hallo 1miau,

Dieses Spiel gab ja wieder viel Gelegenheit zum Analysieren.

Die zu erwartende Blocknummer folgt einer Poisson-Verteilung deren
Mittelwert E und Standardabweichung S gegeben ist durch:

E = b0 + (t - t0) / l

S = sqrt((t - t0) / l)

mit: t0 = aktuelle Zeit
     b0 = aktuelle Blockhöhe
     t  = Zeit (1.1.2020 00:00CET)
     l  = mittlere Zeit zwischen 2 Blöcken (soll: 10min)

Wenn ich die Zeiten in Unix-Epoch Sekunden angebe komme ich mit den
Daten von gestern Abend (Mi 4. Dez 22:21:42 CET 2019) auf folgende
Werte:

  t0 = 1575494498
  t  = 1577833200
  l  =        600
  b0 =     606675

  E  =     610573
  S  =         62

Aufgrund dieser Lage wäre also die Vorhersage : Block 610573 +- 62

Die Standardabweichung beschreibt die rein statistische
Unsicherheit. Je näher man dem Zielzeitpunkt kommt, desdo geringer
wird sie.

Viel größer als die statistische Unsicherheit ist jedoch die
systematische Abweichung aufgrund der Änderung der Hashrate.  Die
Anpassung der Difficulty hinkt immer etwas hinterher so dass eine
etwas längere oder kürzere Blockzeit zu erwarten ist je nachdem ob die
Hasrate aktuell fällt oder steigt. Die Erwartungswerte für abweichende Blockzeiten
von 9.5 oder 10.5 Minuten wären:

  l  =        630
  E  =     610387

  l  =        570
  E  =     610779

Das nachfolgende Bild gibt die Tipps (Balken) gestern 22:30 sowie die 3 verschiedenen Verteilungen
für Blockzeiten von 9.5 10 und 10.5 Minuten wieder:

jetzt kommen die Nachzügler.

Ich hätte gerne:

610480
610750

und ich gebe noch 2.5mBTC für einen 3.Platz

Jetzt hat es mich doch noch einmal interessiert was passiert wäre wenn wir die ursprünglichen Spielregen beibehalten hätten.
Unten der Hash vom Block 604950. Blaue Ziffern wären verwendet worden, rote Ziffern übersprungen da nicht getippt.
Die 0 hätte einen Gewinn nur knapp verfehlt und die 73 hätte doppelt gewonnen.

0000000000000000000787afcdc7dadf3f80ffaa1cec54585e5383307e342c46

Ja, genau so.
Dort ist ein BTC-Wallet integriert zu dem man selbst den Schlüssel besitzt.
Dort liegen bei mir ein paar BTC herum die ich dann umtausche wenn die Debit-Karte mal wieder leer ist.
So ein Umtausch dauert vielleicht 1/2 Stunde.
Dann kann man die Kreditkarte ganz normal verwenden, oder auch vom Konto SEPA-Überweisungen machen.
Funktioniert soweit reibungslos.

Die Frage was passiert wenn man Bitcoins in ein schwarzes Loch wirft lässt sich experimentell klären:

1SgrAmp8dTo2XtPvMe2m95THoWREDNQCZ

Da es hier ja im Moment keinen Bitcoin zu gewinnen gibt.

Seht doch mal dort nach:  https://bitcointalk.org/index.php?topic=5200141.0

Eigentlich war ich zu faul, aber jetzt muss ich doch mal rechnen.

Um es vorwegzunehmen, ich komme auf dasselbe Ergebnis wie trantute2, allerdings relativiert sich das Ergebnis dramatisch wenn deutlich unter 100 Tipps abgegeben werden.

Annahme (wie bei trantute2): die ersten 19 Stellen der Hashfunktion sind Nullen.  Dann verbleiben 45 Stellen mit gleicher Wahrscheinlichkeit für die "hexadezimalen" Ziffern 0...f .

(a) Wir müssen jetzt berechnen wie hoch die Wahrscheinlichkeit ist, dass in diesen 45 Stellen mindestens 20 mal eine der Ziffern 0..9 auftritt. In diesem Fall ist die Wahrscheinlichkeit für das Auftreten von 00 genau so groß wie für alle anderen zweistelligen Ziffernkombinationen, nämlich 1% .

(b) Interessant ist auch, wie häufig in diesen 45 Stellen genau 19 mal die die Ziffern 0..9 gewürfelt werden. Dann hat man nänlich die Gewinnkombination 0x, mit x=0...9 . Das bedeutet alle die einen einstelligen Tip abgegeben haben sind bevorzugt.

(c) Und letztendlich, wie häufig tritt in den ersten 45 Stellen höchstens 18 mal eine Ziffer 0...9 auf? Das sind die Fälle in denen dann die 00 sicher gewinnt.

------

Die obigen Wahrscheinlichkeiten werden durch die Binominalverteilung B(k,p,n) für n=45 Versuche, und k=19 Erfolgsfälle bei einer Wahrscheinlichkeit von p=10/16=0.625 für das Würfeln der Ziffern 0...9 beschrieben. Das kann man sich irgendwo im Netz ausrechnen lassen. Ich gebe hier nur mal die Wahrscheinlichkeiten an:

    (a) B(k>19,p,n) = 0.99547
    (b) B(k=19,p,n) = 0.00271
    (c) B(k<19,p,n) = 0.00181

Damit wären dann die relativen Häufigkeiten für das Würfeln von:

  P(xx) = 0.99547 * 10 * 0.01 + 0.00271 * 9 * 0.01 + 0.00181 * 9 * 0.01 = 0.09995
  P(0x) = P(xx)               + 0.00271 * 1 * 0.1                       = 0.09995 + 0.00027           = 0.10022
  P(00) = P(0x)                                    + 0.00181            = 0.09995 + 0.00027 + 0.00181 = 0.10203

wobei x hier für eine der Ziffern 1...9 steht.

Damit wäre
die Häufigkeit von "00" um 2%   größer (10203/09995=1.0208) als für "xx". (dasselbe Ergebnis wie trantute2)
die Häufigkeit von "0x" um 0.3% größer (10022/09995=1.0027) als für "xx".

An dieser Stelle ist nicht berücksichtigt, dass sich für k<18 der Wert für P(xx) weiter marginal reduziert.

------

Eine 2% höhere Wahrscheinlichkeit für 00 ist nicht dramatisch und 0.3% für 0x ist wirklich marginal. Das sieht jedoch anders aus, wenn man die von 1miau vorgeschlagene Regelung eintritt:

    - Wenn eine Zahl nicht belegt wurde und diese gewonnen hätte, wird im
      Block-Hash die 11. bzw. 12. Zahl in Betracht gezogen.

Gegenwärtig sind ca 30% der Zahlen belegt. Ich gehe für folgende Rechnung mal davon aus, dass am Ende 50% der Zahlen belegt sind. Dann wird jede zweite der erfolgreich gewürfelten Kombinationen mit Ziffern von 0..9 verworfen, da sie nicht getippt wurde. Ich wiederhole deshalb die obige Rechnung einmal für die doppelte Zahl k=38 (2x19) von erfolgreich gewürfelten Dezimalziffern:

    (a) B(k>38,p,n) = 0.000325
    (b) B(k=38,p,n) = 0.000829
    (c) B(k<38,p,n) = 0.998846

Damit wären dann die relativen Häufigkeiten für das Würfeln von:

    P(xx) = 0.000325 * 10 * 0.01 + 0.000829 * 9 * 0.01 + 0.998846 * 9 * 0.01 = 0.09000325
    P(0x) = P(xx)                + 0.000829 * 1 * 0.1                        = 0.09000325 + 0.0000829            = 0.09008615
    P(00) = P(0x)                                      + 0.998846            = 0.09000325 + 0.0000829 + 0.998846 = 1.08893215

Damit wäre die Häufigkeit von "00" ca. 12 mal größer (1.08893215/0.09000325) als für "xx".

An dieser Stelle müsste man dringend für die Fälle für k<38 noch weiter differenzieren, das heißt berücksichtigen ob 9x 8x oder weniger oft zweistellige Dezimalkombinationen gewürfelt werden. Dadurch erhöht sich die berechnete relative Häufigkeit für das Auftreten von 00 noch weiter.

Fazit: wenn deutlich weniger als 100% der verfügbaren Kombinationen getippt werden, tendiert die Wahrscheinlichkeit für das Auftreten von 00 gegen 100%. Dies wird durch den Term (c) festgelegt, den ich hier mal für verschiedene Beteiligungen abgeschätzt habe:

    Beteiligung  K   B(k<K,p,n)

    100%         19  0.0018
     90%         21  0.0104
     80%         24  0.0786
     70%         27  0.3052
     60%         32  0.8509
     50%         38  0.9988

Man kann auch abschätzen dass sich die Häufigkeit für das Auftreten von 0x für geringe Beteiligungen etwa verdoppelt.

-----

Ich plädiere nicht dafür dass die Regeln so modifiziert werden dass jeder die gleichen Gewinnchancen hat, das ist langweilig. Das Interessante ist ja gerade zu Überlegen wie man tippen soll um diese zu optimieren, und die Diskussionen darum herum.

Wichtig wäre noch dass 1miau festlegt wie verfahren wird, wenn dieselbe Zahlenkombination mehrfach auftritt.  Wird der Betrag dann mehrfach an denselben Gewinner ausgezahlt, verfällt er oder wird dann auch die 11. bzw. 12. Zahl in Betracht gezogen.

Ja
Ja
Wenn der Anbieter seinen Kanal schließt werden die 500.000 Sats gemäß der aktuellen Balance auf dich und ihn aufgeteilt, jeder kriegt dann
seinen Anteil auf seine BTC-Adresse transferiert. In deinem Beispiel also 300.000 für dich und 200.000 für ihn. Die ihm "fehlenden" an dich transferierten
300.000 BTC hat er ja bereits von anderen erhalten.

Tippe auf 1BTC=10123$

und 0.002BTC in den pool.

Hallo Eric,

Herzlichen Glückwunsch !

https://blockchair.com/bitcoin/transaction/10a42ca8e4e7b4961bedb3e9499efc6a59c397cf55f9f1eebc57e27582c5368d

Die Leute die sich für Bitcoin interessiert haben waren in der Regel technikaffine Spinner aber keine Betrüger.
Vieles hat dann natürlich nicht so geklappt.

Ja, Bitcoins waren eben nicht soviel Wert (womit wir wieder beim Thema wären).

Ja, stimmt.
Aber im Unterschied zu heute waren in der Vergangenheit 80% der Gegenüber vertrauenswürdige Menschen.
Da hat sich was geändert.

Yes, the routing is done by the sender, so he can decide to exclude
certain nodes, or nodes with more than nmax open channels. But this
requires some programming and struggling with the command line
interfaces of the lightning clients, I have not done that so far.

I do something similar when opening channels. I do not use the
'autopilot' feature of lnd but wrote my own algorithm to select
destination nodes: choose the nodes so that the number of hubs
required to enable me to send a certain amount of btc to every node in
the network is minimized, excluding routing through hubs with more
than 30 open channels.

By doing this one would set up a network that is more
decentralized. But I cannot claim that my node is excessivly used. (I
think the acceptance of lightning is still very poor).

If you want to have a look at my node and have any comments, its called
'node1'.

wette auf 21345 $

gebe 0.002 BTC in den pool