Ich laufe Bitcoin Core v0.11.0.0-gd26f951 (64-bit)
zu Hause auf Ubuntu und habe das Bitcoin Wallet for Android
auf meinem Telefon installiert. Ich habe zwei Transaktionen von zu Hause an mein Telefon gesendet: First , Second . Einer hatte eine sehr niedrige Gebühr und dauerte Tage, also schickte ich einen anderen mit einer etwas höheren Gebühr, der nur wenige Minuten dauerte. Beide sind aber angekommen, haben mittlerweile fast zweitausend Bestätigungen und zeigen in der App grün an.
Die Bitcoin-App sagt jetzt (ich habe es heute zum ersten Mal bemerkt und ich glaube nicht, dass sie es anfangs gesagt hat).
This payment was delayed because the sender used an insecure transaction type.
unter beiden Transaktionen. Was bedeutet das?
Ich habe den Ausdruck gegoogelt und genau einen Treffer erhalten, in einem Ressourcenpaket, das Teil des Codes für das Bitcoin-Wallet-Projekt auf github ist, das anscheinend die Android-App ist. Der entsprechende Schlüssel ist transaction_row_message_received_rbf
, der überhaupt keine Treffer generierte.
Kann mir jemand sagen, was dieser „unsichere Transaktionstyp“ sein könnte und warum Bitcoin-Qt ihn verwenden würde? Muss ich das verhindern und wenn ja wie?
Es scheint, dass Transaktionen Bitcoin Wallet for Android
fälschlicherweise als auf einen Fehler in zurückzuführen sind . Das Problem wurde gemeldet . Sie müssen nichts tun.nLockTime
OptInRBF
bitcoinj
Anscheinend hat Bitcoin Wallet für Android Ihre Transaktion als OptInRBF
(wie durch den gefundenen Code angegeben) erkannt. Die Warnung, die Sie sehen, wurde der App erst am 10. März 2016 hinzugefügt .
OptInRBF
ist die Abkürzung für „Opt-in replace-by-fee“, das Bitcoin Core in 0.12.0 hinzugefügt wurde. Die neue Version ermöglicht Bitcoin Core den Empfang und die korrekte Behandlung von Replace-by-Fee-Transaktionen. Bitcoin Core kann jedoch noch keine rbf-Transaktionen erstellen . Wallets müssen sich "anmelden", um sie zu senden.
Replace-by-fee ist ein Flag, das auf Transaktionen gesetzt werden kann, um mitzuteilen, dass man die Transaktion ändern möchte, bevor sie in einen Block aufgenommen wird . Daher sollten solche Transaktionen nicht als zuverlässig angesehen werden, bis sie ihre erste Bestätigung erhalten. Nachdem sie in einen Block aufgenommen wurden, sind sie genauso sicher wie jede andere Transaktion.
Mining-Pools, die rbf unterstützen, erlauben es einer neueren Version der Transaktion, die ältere zu ersetzen, insbesondere wenn die neuere Transaktion eine höhere Gebühr zahlt. Dies ist beispielsweise nützlich, um die Gebühr für eine Transaktion zu erhöhen, wenn sie feststeckt, oder um mehrere Transaktionen zu einer zu kombinieren, wenn Sie sich entscheiden, eine weitere Transaktion zu senden, bevor eine vorherige bestätigt wird.
Wenn man sich die Rohdaten der ersten Transaktion ansieht , stellt sich heraus, dass die Anzahl der Transaktionen sequence
tatsächlich unter dem Maximalwert liegt: Es zeigt, 0xFEFFFFFF
während das Maximum wäre 0xFFFFFFFF
. Die Sequenz mit einem E
an zweiter Stelle ist ein vorzeichenloses Little Endian, lang für "Eins unter dem Maximum". Dies ist der Ablauf einer nLockTime
Transaktion .
OptInRBF
Sequenzen haben, die kleiner als die nLockTime
Sequenz sind, dh sequence < MAX - 1
. Daher scheint entweder bitcoinj
oder Transaktionen fälschlicherweise als zu Bitcoin Wallet for Android
klassifizieren . Das Problem ist, dass seit Bitcoin Core 0.11 alle Transaktionen eine Sequenz haben.nLockTime
OptInRBF
nLockTime
Auf den ersten Blick scheint der bitcoinj
Code , der prüft, ob eine Transaktion in OptInRBF
Ordnung ist:
public boolean isOptInFullRBF() {
return sequence < NO_SEQUENCE - 1;
}
Java verwendet jedoch nativ das Big-Endian-Format anstelle des Little-Endian-Formats.
<speculation>Daher kann es ein Problem geben, bei NO_SEQUENCE - 1
dem sich möglicherweise auflösen lässt, 0xFFFFFFFE
und die als Big Endian gelesene nLockTime
Sequenz 0xFEFFFFFF
würde viel kleiner erscheinen und könnte daher als OptInRBF
.</speculation> 1 bezeichnet werden
Ich habe das Problem gemeldet und versuche, einen Fehler zu beheben .
1 Es stellt sich heraus, dass meine Spekulation falsch war. BitcoinJ
und Bitcoin Wallet for Android
verarbeiten Sie Transaktionen mit der nLockTime
Sequenz fine und parsen Sie sie nach Bedarf im Little-Endian-Format. Bisher konnte der Betreuer das beschriebene Problem mit den bereitgestellten Transaktionen nicht reproduzieren (stattdessen wurden sie ohne Warnung korrekt angezeigt). Daher ist der Grund für das Erscheinen der Warnung noch unbekannt.
Vielen Dank an Pepijn Schmitz, Gregory Sanders, Andreas Schildbach und Wladimir van der Laan für ihre Hilfe bei der Lösung.
Murch
Murch
Pepijn Schmitz
Murch
Pepijn Schmitz
Murch
Andreas
Pepijn Schmitz
Andreas
Pepijn Schmitz
Andreas
Pepijn Schmitz
Andreas
Pepijn Schmitz