Zum Inhalt springen

Transferierte BTCs tauchen im Masterwallet nicht auf


James Hodlen

Empfohlene Beiträge

Ich hab ein paar Testbeträge von bitcoin.de auf eine eigene Wallet geschickt. Zuerst an eine von Electrum generierte Adresse, alles ok. Dann an die erste Adresse die iancoleman mir gibt, auch ok. Die Adresse zeigt die erfolgreiche Transaktion.

Allerdings wird mir diese zweite Transaktion nicht im Masterwallet angezeigt. Dort ist nur der erste Betrag zu sehen.

Address Gap? 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 29 Minuten schrieb James Hodlen:

Ich hab ein paar Testbeträge von bitcoin.de auf eine eigene Wallet geschickt. Zuerst an eine von Electrum generierte Adresse, alles ok. Dann an die erste Adresse die iancoleman mir gibt, auch ok. Die Adresse zeigt die erfolgreiche Transaktion.

Allerdings wird mir diese zweite Transaktion nicht im Masterwallet angezeigt. Dort ist nur der erste Betrag zu sehen.

Address Gap? 

Haben beide Wallets denselben Seed?

Dann werden die sowohl bei Electrum als auch bei iancoleman die identischen Adressen angezeigt.

Wenn das unterschiedliche Adressen trotz desselben Seeds sind, dann hast du unterschiedliche Derivation-Paths benutzt.

Legacy: m/44'/0'/0' ... BIP 44 ... Adresse beginnt mit "1"
p2sh-segwit: m/49'/0'/0' ... BIP49 ... Adresse beginnt mit "3"
native segwit: m/84'/0'/0' ... BIP 84 ... Adresse beginnt mit "bc"

Deine beiden Adressen werden sich vermutlich in der ersten Stelle unterscheiden.

 

Bearbeitet von Jokin
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja, selber Seed. Aber Electrum gibt einem doch "irgendeine" Adresse aus der Mitte oder? Beim zweiten Transfer hab ich einfach die erste m/44'/0'/0'/0/0 aus den Derived Addresses genommen. Das ist egal? Dachte da kommt dann der Address Gap.

Habs aber jetzt: Electrum hatte mir eine bc1 Adresse gegeben. Von iancoleman hab ich eine 3... BIP141 genommen. Damit ist auch der extended pub key ein anderer. zpub und ypub. 

D.h. für den "Gesamtkontostand" des Seeds muss ich den Seed oder der Root Key nehmen und nicht den Public, richtig? Bzw. alle verschiedenen Public Keys. Oder ich benutze nur noch 3.. Adressen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 40 Minuten schrieb James Hodlen:

Ja, selber Seed. Aber Electrum gibt einem doch "irgendeine" Adresse aus der Mitte oder?

Nein, immer nur die "nächste".

vor 41 Minuten schrieb James Hodlen:

Habs aber jetzt: Electrum hatte mir eine bc1 Adresse gegeben. Von iancoleman hab ich eine 3... BIP141 genommen. Damit ist auch der extended pub key ein anderer. zpub und ypub. 

Fein, dann konnte ich ja helfen 🙂

vor 41 Minuten schrieb James Hodlen:

D.h. für den "Gesamtkontostand" des Seeds muss ich den Seed oder der Root Key nehmen und nicht den Public, richtig? Bzw. alle verschiedenen Public Keys. Oder ich benutze nur noch 3.. Adressen.

Nein, so einfach geht das nicht. Blockexplorer können damit nichts anfangen.

vor 33 Minuten schrieb James Hodlen:

Gibts einen aktuellen Standard den man _immer_ nimmt?

Die Wörter "immer" und "nie" sind "immer falsch" und "nie richtig" ;) 

Ich versuche diese beiden Wörter zu vermeiden.

Mit Legacy-Adressen "1..." machste nix falsch, mit "3.."-Adressen sparste Transaktionskosten (wird nun meistens verwendet) und mit den "bc..."-Adressen kannste auch das Lightning-Network benutzen und sparst noch mehr Transaktionskosten.

 

Hier ein paar weitere Infos: 
https://coinfinity.co/1bc-oder-doch-lieber-1-oder-3-bitcoin-adressformate-und-wie-sie-erstellt-werden/
https://en.bitcoin.it/wiki/Bech32_adoption

 

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Für den Post würd ich mich immer bedanken und niemals beschweren 😄

Ja du lagst richtig. Ich hatte nicht gesehen dass der Extended Public Key auch "derived" ist. Der Root Private Key ist ja immer der gleiche, aber den trag ich ja höchstens mal offline ein.

Zu den Electrum Adressen, starten die denn bei m/44'/0'/0'/0/0 und dann fortlaufend? Ich hatte die mit iancoleman verglichen und es waren andere. Denkfehler?

Die Transaktionskosten bei bitcoin.de werden vorgeschlagen und sind unabhängig vom Protokoll der Zieladresse. Sollte ich das bei segwt Adressen dann runterrechnen? So nach Bauchgefühl was wohl wie schnell durchgeht?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb James Hodlen:

Zu den Electrum Adressen, starten die denn bei m/44'/0'/0'/0/0 und dann fortlaufend? Ich hatte die mit iancoleman verglichen und es waren andere. Denkfehler?

Das sollten definitiv dieselben sein.

vor einer Stunde schrieb James Hodlen:

Die Transaktionskosten bei bitcoin.de werden vorgeschlagen und sind unabhängig vom Protokoll der Zieladresse. Sollte ich das bei segwt Adressen dann runterrechnen? So nach Bauchgefühl was wohl wie schnell durchgeht?

Ignorier das. Bei Exchanges werden die Auszahlungen der User gebündelt. Sind zu wenig da, dann wird die Transaktion später rausgeschickt. Die ist in der Regel direkt im nächsten Block was meistens jedoch nicht wirklich wichtig ist.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb James Hodlen:

Zu den Electrum Adressen, starten die denn bei m/44'/0'/0'/0/0 und dann fortlaufend?

Ja, Electrum fängt beim Adress-Index auch stets bei Null an zu zählen, wenn die Ableitung eine leere HD-Wallet ergibt.

vor 2 Stunden schrieb James Hodlen:

Ich hatte die mit iancoleman verglichen und es waren andere. Denkfehler?

Hast du bei Electrum eingestellt, daß der Seed als ein BIP-39 Seed verwendet werden soll? Wobei ein BIP-39 Mnemonic Seed nicht als Electrum Seed durchgeht und umgekehrt ein Electrum Seed nicht als BIP-39 angenommen wird. (Hab' nur laut gedacht...)

Test mit folgendem Mnemonic Seed (BIP-39): iron split viable glow property asthma brief river erosion cat tumble way
Derivation Path: m/44'/0'/0'
Electrum — Skripttype: p2pkh — Wallet type: Standard:
.../0/0    1LehDUTHcY3EejtxvcFxhgNqicMkRES6Ui
.../0/1    1CxqgHisFearriEXZTfS56ybSM88KpwwzH
.../0/2    14yXjM2TFDHwyMb3RRy1XeFwDHqboahdBD
...

iancoleman.io:
.../0/0   1LehDUTHcY3EejtxvcFxhgNqicMkRES6Ui
.../0/1   1CxqgHisFearriEXZTfS56ybSM88KpwwzH
.../0/2   14yXjM2TFDHwyMb3RRy1XeFwDHqboahdBD
...

In der absichtlich für den Test unverschlüsselt gespeicherten Electrum-Wallet-Datei steht dann der bei iancoleman.io im Tab BIP44 bezeichnete Account Extended Private/Public Key oder im Tab BIP32 als bezeichnete BIP32 Extended Private/Public Key

    "keystore": {
        "derivation": "m/44'/0'/0'",
        "pw_hash_version": 1,
        "root_fingerprint": "32335b64",
        "type": "bip32",
        "xprv": "xprv9yUuKRHPwcdQN1pBfsN5owk8tsDZV9A2ArcrqaMNiw1qMqmMXsGvasjEsfWw3mdQRd1dvvLz76onccyBqCKjChDPB6zXoTgz5npM5tG8Nmy",
        "xpub": "xpub6CUFivpHmzBhaVtemtu6B5gsSu43tbssY5YTdxkzHGYpEe6W5QbB8g3iix4hNrnqScS8bNywLgtCjnVDcR1Bey4cmWiVPNgA76qWdq97Acx"
    },

 

Bearbeitet von Cricktor
  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 15 Minuten schrieb Cricktor:

Ja, Electrum fängt beim Adress-Index auch stets bei Null an zu zählen, wenn die Ableitung eine leere HD-Wallet ergibt.

Hast du bei Electrum eingestellt, daß der Seed als ein BIP-39 Seed verwendet werden soll?

Test mit folgendem Mnemonic Seed (BIP-39): iron split viable glow property asthma brief river erosion cat tumble way
Derivation Path: m/44'/0'/0'
Electrum — Skripttype: p2pkh — Wallet type: Standard:
.../0/0    1LehDUTHcY3EejtxvcFxhgNqicMkRES6Ui
.../0/1    1CxqgHisFearriEXZTfS56ybSM88KpwwzH
.../0/2    14yXjM2TFDHwyMb3RRy1XeFwDHqboahdBD
...

iancoleman.io:
.../0/0   1LehDUTHcY3EejtxvcFxhgNqicMkRES6Ui
.../0/1   1CxqgHisFearriEXZTfS56ybSM88KpwwzH
.../0/2   14yXjM2TFDHwyMb3RRy1XeFwDHqboahdBD
...

In der absichtlich für den Test unverschlüsselt gespeicherten Electrum-Wallet-Datei steht dann der bei iancoleman.io bezeichnete Account Extended Private/Public Key

    "keystore": {
        "derivation": "m/44'/0'/0'",
        "pw_hash_version": 1,
        "root_fingerprint": "32335b64",
        "type": "bip32",
        "xprv": "xprv9yUuKRHPwcdQN1pBfsN5owk8tsDZV9A2ArcrqaMNiw1qMqmMXsGvasjEsfWw3mdQRd1dvvLz76onccyBqCKjChDPB6zXoTgz5npM5tG8Nmy",
        "xpub": "xpub6CUFivpHmzBhaVtemtu6B5gsSu43tbssY5YTdxkzHGYpEe6W5QbB8g3iix4hNrnqScS8bNywLgtCjnVDcR1Bey4cmWiVPNgA76qWdq97Acx"
    },

 

Ja ich hab Electrum mit dem BIP39 Seed von iancoleman angelegt. Dann ein paar mal auf die Knöpfe gedrückt ums zu testen. Bei "Receive" nimmt er immer ab der ersten Adresse? Ist definitiv nicht in der iancoleman Liste. Beides bc1 Adressen. Seed passt, Transaktionen alle erfolgreich und angekommen.

Aber egal, wahrscheinlich nur irgendwo wieder was übersehen. Es klappt ja.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb Jokin:

 

Ignorier das. Bei Exchanges werden die Auszahlungen der User gebündelt. Sind zu wenig da, dann wird die Transaktion später rausgeschickt. Die ist in der Regel direkt im nächsten Block was meistens jedoch nicht wirklich wichtig ist.

D.h. ich nehme für bitcoin.de>coldwallet im Standardfall die bc1 Adressen und nur wenn irgendwas mal nicht kompatibel ist die 1er? Das meinte ich mit "immer". Oder will ich Lightning vermeiden wegen Zentralisierungsproblemen und nehme die 3er? So einfach isses nicht oder?

Gibts ne gute Seite für angemessene Gebührenberechnung? Eilig hab ich es ja meistens nicht. 

Bearbeitet von James Hodlen
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb Cricktor:

Mit bc1-Adressen bekomme ich auch identische Adressen Electrum<->iancoleman.io

Vielleicht hast du beim Rumklickern 'was verstellt und dann haut's nicht mehr hin. Da muss man gut aufpassen.

Ne eigetlich nur ein paar mal auf Receive geklickt und geguckt was passiert. Guck ich mir morgen nochmal an.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 9 Stunden schrieb James Hodlen:

Ne eigetlich nur ein paar mal auf Receive geklickt und geguckt was passiert. Guck ich mir morgen nochmal an.

Schau dir doch direkt die Adressen an - den Reiter Adressen muss man manchmal erst einblenden ... klick dich durch die Einstellungen.

vor 11 Stunden schrieb James Hodlen:

D.h. ich nehme für bitcoin.de>coldwallet im Standardfall die bc1 Adressen und nur wenn irgendwas mal nicht kompatibel ist die 1er? Das meinte ich mit "immer". Oder will ich Lightning vermeiden wegen Zentralisierungsproblemen und nehme die 3er? So einfach isses nicht oder?

Gibts ne gute Seite für angemessene Gebührenberechnung? Eilig hab ich es ja meistens nicht. 

Was'n Durcheinander.

Du kannst nicht einfach hin und her switschen und das ist auch völliger Unsinn. Nimm einfach native Segwit (bc1...) und gut ist.

Warum solltest du Lightning vermeiden? ... was für eine Zentralisierung? Glaub doch bitte nicht jeden Unsinn, den du irgendwo aufschnappst. Das Lightning-Network ist und bleibt ein dezentrales Netzwerk. Jeder kann mit einem Raspberry Pi einen Lightning Node aufsetzen und Channels zu anderen Nodes öffnen. Nur weil Exchanges mehr Channels und mehr Liquidität im Netz haben entsteht noch lange keine "Zentralisierung". Und ein Problem ist das auch nicht.

Gebühren sind auch einfach zu ermitteln: Schieber bei Electrum auf "minimum" stellen und kurz nachrechnen wieviel Gebühren das sind ... überlegen ob das ok für dich ist ... wenn nicht, dann den Wert manuell eingeben und reduzieren. In der Regel werden auch auch Transaktionen mit geringen Gebühren an Wochenenden nachts in die Blockchain aufgenommen.

Schau hier: https://jochen-hoenicke.de/queue/#BTC,24h,weight

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 33 Minuten schrieb QQQ:

Ist das nicht mehr Korrekt?

Nicht zuverlässig, aber dafür zentralisiert
https://bitcoinblog.de/2020/07/02/nicht-zuverlaessig-aber-dafuer-zentralisiert/

"Zentralisierung" meint im Normalfall, dass eine zentrale Stelle bestimmt wie die Regeln des Netzwerks aussehen.

Und das ist bei Lightning eben nicht der Fall. Es gibt dort schlichtweg keine Konsensus-Regeln.

Und vollkommen klar, dass Exchanges und Payment-Provider wie Paypal, Visa, die Sparkassen und andere zu "Superhubs" werden deren Kunden einen direkten Channel zu diesen Hubs haben werden. Dadurch entsteht aber noch lange keine "Zentralisierung".

Und dass Zahlungen mit 10 USD in einem experimentellen Netzwerk Probleme haben durchzukommen, ist doch auch klar. Ich selber hab nur ein paar wenige USD in meinen Channels. 

Aktuell müssen immer noch Bugs in der Software und im gesamten Konzept gefunden werden. Ich weiß selber noch nicht wie ich meine Fundings sichern soll wenn mein Node mal längere Zeit offline ist, das ist noch ein Problem. (vielleicht auch nur meines aufgrund von Unwissenheit)

  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 16 Stunden schrieb James Hodlen:

Ich hatte die mit iancoleman verglichen und es waren andere. Denkfehler?

vor 14 Stunden schrieb James Hodlen:

Ne eigetlich nur ein paar mal auf Receive geklickt und geguckt was passiert. Guck ich mir morgen nochmal an.

Ich könnte mir vorstellen, was bei dir ggf. schiefgelaufen ist, was die bc1q Adressen unterschiedlich hat werden lassen. Wenn du bei Electrum für die Wallet folgende Auswahl nimmst: New/Restore wallet: Standard Wallet; vorhandener Seed (BIP39); für bc1q... wählst du "native segwit (p2wpkh)" --> Deriv.Path: m/84'/0'/0' ist vorgegeben (kannst hier natürlich auch nehmen, was du möchtest, aber m/84'/0'/0' wäre zunächst mal der Standard!)

Auf der iancoleman.io Seite musst du dann bei Derivation Path entweder den BIP84-Reiter auswählen, dann sind die Adressen von Electrum und der Seite sofort identisch.

Du warst aber, wie ich annehme, auf dem BIP141-Reiter beim Abschnitt Derivation Path und da ist dann erst noch folgendes anzupassen, damit Electrum und iancoleman.io diesselben bc1q... Adressen generieren:

BIP32 Derivation Path:  m/0 (Vorgabe) --> m/84'/0'/0'/0 (für Receive addresses, für Change addresses nimmt man m/84'/0'/0'/1)
Script Semantics:          P2WPKH nested in P2SH --> P2WPKH

 

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich hab mit hardened addresses rumgespielt. Daher die "falschen" Adressen. 😄

Danke für Eure Hilfe. Die Ding sind zwar nachlesbar, aber das hilft nicht beim auf dem Schlauch stehen.

Kann es sein, das Electrum nicht mit hardened addresses klarkommt? Finde nur ganz wenig dazu. 

Edit: und mit BIP141 auch nicht?!

Bearbeitet von James Hodlen
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 9 Stunden schrieb James Hodlen:

Ich hab mit hardened addresses rumgespielt. Daher die "falschen" Adressen. 😄

Danke für Eure Hilfe. Die Ding sind zwar nachlesbar, aber das hilft nicht beim auf dem Schlauch stehen.

Kann es sein, das Electrum nicht mit hardened addresses klarkommt? Finde nur ganz wenig dazu. 

Edit: und mit BIP141 auch nicht?!

Lass solche Spielereien einfach beiseite - das Risiko nicht mehr an die eigenen Coins zu kommen ist schlichtweg zu groß.

Oder lies dich in das Thema tiefer ein: https://bitcoin.stackexchange.com/questions/61891/electrum-how-to-generate-hardened-public-addresses-with-hd-bip32-wallet

https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671

Das ist mir aber auch zu abgefahren ....

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb James Hodlen:

Welche wallet kann denn hardened und BIP141 Adressen, damit ichs wieder weiterschicken kann?

Warum willst du denn "hardened Adressen" benutzen?

Was genau versprichst du dir davon?

Schau mal hier: https://docs.keys.casa/wealth-security-protocol/rejected-features/hardened-addresses

Da ist der Widerspruch ganz gut beschrieben und wieso es gar nicht so sinnvoll ist diese hardened Adressen zu benutzen.

Bearbeitet von Jokin
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb James Hodlen:

Welche wallet kann denn hardened und BIP141 Adressen, damit ichs wieder weiterschicken kann?

Abgesehen davon, was @Jokin schreibt, sehe ich auch keine höhere Sicherheit, wenn "fully hardened" Adressen verwendet werden. Der Derivation Path, den die meisten Wallets verwenden, ist doch schon an allen sinnvollen Stellen mit "hardened" Keys ausgestaltet, von denen weiter abgeleitet würde:

m/84'/0'/0'  — 84' hardened für bc1q... Adressen — 0' hardened für Bitcoin — 0' hardened für den allerersten Account
                \__ von diesem hardened extended "Account" Key werden die non-hardened Receive-Adr. 0/0, 0/1, 0/2, ... bzw. Change-Adr. 1/0, 1/1, 1/2, ... abgeleitet
(aber eben nicht mehr weitere extended Keys ausgehend von den non-hardened Adressen abgeleitet, so daß keine Kompromitierung weiterer Enkel-Keys passieren kann)

m/84'/0'/0'/0/n --> (n+1)te Receive-Key: von hier wird nicht weiter abgeleitet, auch wenn es möglich wäre
                     \__ 0: Receive / 1: Change

Ich wüsste nicht, welche Wallet bis ins letzte hardened Adressen nutzen kann. Aber ich kenne nicht alle. Wenn du aus Spieltrieb hardened Adressen mit Coins beladen hast, dann würde ich mir mit iancoleman.io die privaten Schlüssel aller beladenen hardened Adressen zusammen sammeln, in eine temporäre Wallet (Import priv. Keys; das kann auch Electrum) werfen und die Coins auf eine "normale" Wallet zurück schubsen.

Die optionale Verschlüsselung nach BIP38 sähe ich höchstens für Paperwallets als eine vielleicht sinnvolle Sicherungsstufe. Aber viel Spaß bei der sicheren und nachvollziehbaren Dokumentation solcher Spezialfälle.

Bearbeitet von Cricktor
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Minuten schrieb Cricktor:

 

Ich wüsste nicht, welche Wallet bis ins letzte hardened Adressen nutzen kann. Aber ich kenne nicht alle. Wenn du aus Spieltrieb hardened Adressen mit Coins beladen hast, dann würde ich mir mit iancoleman.io die privaten Schlüssel aller beladenen Adressen zusammen sammeln, in eine temporäre Wallet werfen und die Coins auf eine "normale" Wallet packen.

 

Das scheint nicht zu gehen. Electrum erkennt den privaten Schlüssel als nicht hardened address eines anderen Seeds und dort ist natürlich nichts drauf.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.