Jump to content

RaspiBolt mit Elektrum Personal Server - lokale tx


 Share

Recommended Posts

Hallo zusammen,

ich mache hier mal ein Thema für mein Problem auf.

Bei mir läuft eps 0.15 mit bitcoind 0.17.0 und lnd 0.5 auf einem Raspberry Pi, installiert nach Stadicus' Anleitung https://github.com/Stadicus/guides

Wenn ich jetzt mein Elektrum-Wallet auf dem PC mit meinem eps verbinde, dann wird eine der Transaktionen als "Status: local" angezeigt. Diese tx ist schon Monate alt und wird von allen Blockexplorern und öffentlichen Elektrum-Servern als korrekt und bestätigt mit dem richtigen Datum angezeigt.

Das bitcoind update auf 0.17.0 hat schon einen blockchain reindex ausgeführt, Neustarts gab es mehr als genug...  Fällt euch sonst noch etwas ein, was ich probieren könnte um das Problem einzugrenzen?

Den Raspi hatte ich neu aufgesetzt, in einer früheren Inkarnation (eps 0.12 und bitcoind 0.16.0) gab's dieses Problem noch nicht.

Link to comment
Share on other sites

  • 3 months later...

Hallo,

hier mal ein Update: auch nach meinem jüngsten Update auf eps 0.16 (mit blockchain-rescan bis 2 Jahre vor der ersten tx in diesem Wallet)  , bitcoind 0.17.1 und ln 0.5.1 habe ich immer noch dasselbe Problem mit derselben tx. Die ist vom Mai 2017, mitten zwischen normal angezeigten tx, und wird nach wie vor von allen Blockexplorern und öffentlichen Elektrum-Servern als korrekt und bestätigt mit dem richtigen Datum angezeigt. War auch kein dust, sondern etwa 6 mBTC.

Hat wirklich niemand eine Idee was ich noch checken könnte?

Mit google finde ich nur Fälle, wo die tx tatsächlich nicht ausgeführt wurde, nicht lange genug gewartet, Null fees oder so...

Link to comment
Share on other sites

  • 4 months later...

Hallo, ich probiere es ein letztes Mal, ob jemandem was dazu einfällt. Inzwischen läuft eps 0.1.7 mit bitcoind 0.18.0 auf dem raspibolt. Aus anderen Gründen wurde die komplette Blockchain in der Zwischenzeit neu heruntergeladen, tx-indiziert und dann von eps 0.1.7 gescannt.

Immer noch dasselbe Problem: eine einzige, auf der blockchain korrekte, tx zeigt eps als "local only" an. Immerhin meldet die neueste Version von eps den Umsatz an den Client, so dass jetzt wenigstens der Kontostand stimmt...

Link to comment
Share on other sites

$ bitcoin-cli getaddressinfo <deine Adresse> schon versucht?
Falls mit deiner Node alles in Ordnung ist, auf github mal ein Issue erstellen.
Oder mit einem Public Server verbinden und deine Coins auf eine neue Adresse transferieren.

Link to comment
Share on other sites

@triumvirat

wie ganz oben geschrieben ist auf der blockchain ja alles in Ordnung, also kein Grund Coins zu transferieren.

Mir geht#s ja nur drum ob das ein Bug in eps oder ein Problem mit meiner Node/okalen blockchain-Kopie ist. Inzwischen glaube ich an Ersteres, und zwar erst nach Version 0.12

oder sieht das für dich verdächtig aus?

$ biitcoin-cli getaddressinfo 19...
{
  "address": "19...",
  "scriptPubKey": "76...",
  "ismine": false,
  "solvable": false,
  "iswatchonly": true,
  "isscript": false,
  "iswitness": false,
  "label": "electrum-watchonly-addresses",
  "ischange": false,
  "timestamp": 0,
  "labels": [
    {
      "name": "electrum-watchonly-addresses",
      "purpose": "receive"
    }
  ]
}

 

Link to comment
Share on other sites

@triumvirat

ich weiss ja nicht, von welchen Adressen du bei dir redest, aber so funktioniert jeder Electrum Server. Dem gibt man nur public keys. Damit kann er die dazugehörenden Adressen auf Blockchain beobachten ("watch only") und dem Client auf Anfrage erzählen, was er dort sieht.

Die privaten keys, und damit die Möglichkeit, tx auszulösen, bleiben ausschließlich beim lokalen Client.

Link to comment
Share on other sites

@wwurst
So wie ich es verstanden habe, importiert eps die Electrum-publickeys in die bitcoind(core) wallet, darum bekommst du die Adresse als watchonly angezeigt. Ein ElectrumX-Server macht das nicht.

 


Versuch mal, falls noch nicht durchgeführt,
$ bitcoin-cli rescanblockchain ( start_height stop_height )
Musst den Block finden, in dem die Transaktion steckt und diesen bei start_height eintragen. Sonst mal mit
$ bitcoin-cli help
schauen, ob du unter == Wallet == noch irgendwelche Funktionen findest, die dir weiterhelfen.

Edited by triumvirat
Link to comment
Share on other sites

@triumvirat

danke für's Gedanken machen, aber das war alles schon (teilweise mehrfach) passiert.

Was meinem Verständnis, bzw. der Suche nach der Ursache, evt. helfen könnte: wie kommt die Einstufung einer tx als "local only" zustande? Macht das der bitcoind oder der eps? Anhand welcher Kriterien? Ich wüsste nicht mal wo ich im sourcecode anfangen sollte zu suchen...

Link to comment
Share on other sites

@wwurst

1.) nimm ein paar Euros in die Hand und schaffe dir eine vernünftige Hardware an, installiere eine Bitcoin-Full-Node + ElectrumX-Server + usw.

2.) Issue auf github erstellen.

3.) eps nochmals zurücksetzen.
  in bitcoin.config debug=rpc sezten, bitcoind neustarten.
  tail -f .bitcoin/debug.log überwachen
  ~/.local/bin/electrum-personal-server-rescan -c config.cfg
  ~/.local/bin/electrum-personal-server -c config.cfg
und dann electrumpersonalserver.log und debug.log auswerten.
 

Link to comment
Share on other sites

  • 7 months later...

So, als ich meinen RaspiBolt heute auf eps 0.2.0 ugedated habe ist mir auch die Ursache dieses Fehlers klar geworden.

Ich hatte in der config.cfg vergessen, die Zieladresse (war ein lightning wallet) der "lokalen" tx einzutragen. Jetzt steht sie drin und alles klappt.

Ist auch logisch so. Warum das mit eps 0.1.2 noch ohne diesen Eintrag ging, will ich gar nicht mehr wissen....

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.