Ich habe eine JavaWebApp, die bitcoinj 0.13.2 verwendet, um Bitcoins von einer Brieftasche an eine bestimmte Adresse in einer TimerTask
. Wenn der Job beginnt, schicke ich jede Minute 10000 Satoshis an die Adresse. Die Transaktionsgebühr beträgt 1000 Satoshis. Transaktionsbestätigungen sind 0.
Das Problem ist, dass ich nach dem Zufallsprinzip bekomme InsufficientMoneyException
, obwohl viel mehr Geld als 11000 in der Brieftasche verfügbar sind, die für die Transaktionen benötigt werden.
Zum Beispiel habe ich 1 Job für 30 Minuten erfolgreich abgeschlossen, danach starte ich einen anderen an einer anderen Adresse und bei der dritten Transaktion habe ich die Ausnahme bekommen. Selbst wenn die Gebühr mehr als 1000 beträgt oder Bestätigungen > 0 eingestellt sind, kann ich nicht verstehen, wie ein Guthaben wie: 0,10720419 BTC (10720419 Satoshis) mit zwei Transaktionen für 10000 Satoshis erschöpft werden kann (ich habe es sogar mit einer Brieftasche versucht, die ein Guthaben von 9,43673481 BTC hat (943673481 satoshis) und es wurde auch mit mehreren Transaktionen erschöpft)?
Wenn die Transaktion abgeschlossen ist, ist alles normal und das verfügbare Guthaben ist korrekt, sodass ich eine weitere Transaktion starten kann, aber das kann viel länger als eine Minute dauern. Ich kann den Grund nicht verstehen, warum so viele Münzen reserviert sind (nicht verfügbar).
Wenn es sich um fällige Bestätigungen oder Gebühren handelt, gibt es eine Problemumgehung, damit das Ziel der Transaktion pro Minute erreicht werden kann?
Ich benutze TestNet3 zum Testen
Ich benutze walletKit.wallet().sendCoins(walletKit.peerGroup(), to, Coin.valueOf(amount))
zum Versenden von Coins.
Vor der Transaktion, die die Ausnahme auslöst, befindet sich die vorherige in einer Art festgefahrenem Zustand – sie erscheint nur im Sendeverlauf des Absenders und bleibt etwa 1-2 Stunden lang bei 0-Benachrichtigungen hängen. Wenn es 1 Bestätigung erhält, erscheint es im Tx-Verlauf der Empfänger-Brieftasche mit 0 Bestätigung und mit einem anderen Erstellungsdatum (Uhrzeit). Tx.ID ist gleich. Ich kann den Grund für dieses Verhalten nicht verstehen!? Im Moment in Wallets TX History habe ich:
Absender: Datum - 27.10.2015 11:35 Betrag - 0,0001 Gebühr - 0,00001 conf - 3 tx.id:8eee2f5e92edc0ba8ab656e9364646507158fa91f74364815c7b36ecac7fdd69;
Empfänger: 27.10.2015 13:52 Betrag - 0,0001 Gebühr - 0,00001 Konf - 0 tx.id:8eee2f5e92edc0ba8ab656e9364646507158fa91f74364815c7b36ecac7fdd69.
Ich bin neu in Bitcoin und Bitcoins, aber das scheint sehr ungewöhnlich zu sein, und ich möchte wirklich den Grund für dieses Verhalten herausfinden!?
Es liegt an den Bestätigungszeiten und Sie können nichts dagegen tun. Bis eine Zahlung bestätigt wird, können ihre Ausgaben nicht ausgegeben werden, da Sie nicht sicher sein können, dass die Zahlung tatsächlich bestätigt wird. Dies schließt die "Änderungs"-Ausgaben einer Transaktion ein. Sie könnten versuchen, einen großen Pool verfügbarer, nicht ausgegebener Ausgaben verfügbar zu halten.
Update: Das von Ihnen beschriebene Verhalten ist nicht ungewöhnlich. Bis eine Transaktion in einen Block aufgenommen wird, bleibt sie bei null Bestätigungen hängen. Jede Zahlung, die Sie tätigen, nimmt eine oder mehrere Ihrer nicht ausgegebenen Ausgaben und verbraucht sie, wodurch eine neue nicht ausgegebene Ausgabe für das "Wechselgeld" an Sie zurückgesendet wird.
Angenommen, Sie haben zwei nicht ausgegebene Ausgaben, eine für 1 Bitcoin und eine für 0,4 Bitcoins, und Sie müssen eine Zahlung von 1,2 Bitcoins an jemanden leisten. Sie leisten eine Zahlung, die Ihre beiden nicht ausgegebenen Ausgaben einbezieht, 1,2 Bitcoins an den Empfänger sendet und die restlichen 0,2 Bitcoins an Sie zurücksendet. Im Moment sind die einzigen Bitcoins, die Sie haben, diese 0,2 Bitcoin „Change“-Ausgabe, und es ist noch nicht bestätigt.
NafetzD
David Schwarz
NafetzD
David Schwarz