Ich bin also dabei, ein BTC-basiertes Zahlungsmodul zu implementieren, bei dem für jede Transaktion auf ein Nicht-Wallet-Konto ein Bruchteil des Betrags auf einem Wohltätigkeitskonto in einem externen Wallet landet, das nicht von diesem Modul kontrolliert wird.
Eine typische Runde dafür wäre:
Auf einer niedrigeren Ebene, das System:
TxFromUservom Benutzer mit einem XBTC -BetragTxToMerchantum die Zahlung an den Händler weiterzuleitenTxToCharity, um die Spende an die Wohltätigkeitsorganisation weiterzuleitenEtwas tiefer gehen:
TxToHändler:
TxFromUserMerchant's address, Betrag: 0,9 * TxFromUser.AmountModule's own wallet address, Betrag: 0,1 * TxFromUser.AmountTxToMerchant.IdTxToCharity:
TxToMerchant(dies ist die Änderung, um die wir oben gebeten haben)Charity's address, Betrag: TxToMerchant.Amount = 0.1 * TxFromUser.AmountTxToCharity.IdMir ist bewusst, dass ich diese beiden Transaktionen (TxToMerchant und TxToCharity) zu einer einzigen Transaktion zusammenführen könnte, aber aus verschiedenen Gründen (Geschäftsanforderungen) sagen wir einfach, dass dies im Moment nicht möglich ist.
Das Problem, das ich bei der obigen Implementierung habe, ist folgendes: Das Warten auf die TxToMerchantBestätigung führt zu einer Verzögerung, da ich die Zahlung nicht an die Wohltätigkeitsorganisation weiterleiten kann, TxToCharitybis TxToMerchantsie bestätigt ist (oder kann ich das, ohne mir Gedanken über die Verformbarkeit der Transaktion usw. machen zu müssen?).
Darüber hinaus TxToCharitymuss ich, wenn es an der Zeit ist, die Eingabe von hinzuzufügen, nachverfolgen, wie die Änderung zurückgegeben wurde, TxToMerchantund dann die richtige nicht ausgegebene Transaktion erhalten (wobei listunspent.txid = TxToMerchant.Id), gibt es eine effizientere und weniger fehleranfälliger Weg, dies zu tun?
Nehmen wir an, der Benutzer möchte die Zahlung zwischen 2 Händlern aufteilen (oder einem Händler und einem Frachtdienst, was sinnvoller ist), also gäbe es im obigen Beispiel 1 weitere Transaktion wie TxToMerchant, nennen wir sie TxToFreightService. Sagen wir jetzt, TxToMerchantdas läuft gut und wird bestätigt, schlägt aber TxToFreightServicefehl und wird nie bestätigt, weil die dafür verwendete Eingabe eine doppelte Ausgabe war, unabhängig von den 6 Bestätigungen, die wir (für seine Eingabe) vor der Verarbeitung erhalten haben. TxToCharityhängt von ab, TxToFreightServiceda die angeforderte Änderung in TxToFreightServiceals Eingabe für dient TxToCharity. Wie gehe ich programmgesteuert mit diesem Szenario um, ohne jedes Mal Korrekturen von Hand vornehmen zu müssen, wenn dies passiert?
Ich denke, Ihr Geschäftsprozess verwirrt das Problem. Ich gehe davon aus, dass die "Geschäftsseite" auch einen Teil der Transaktion nehmen oder die Zahlung der Wohltätigkeit verzögern möchte, und deshalb ist dies komplizierter geworden.
Es gibt eine Reihe von Überlegungen, nicht zuletzt die Tatsache, dass Sie eine Eingabe verwenden, um den Händler zu bezahlen, und das Wechselgeld, um die Fracht zu bezahlen, und das Wechselgeld, um die Wohltätigkeitsorganisation zu bezahlen.
Worüber Sie sich Sorgen machen, ist die Unfähigkeit , die Sie eingebaut haben, um die eine Partei aufgrund einer vorangegangenen Transaktion zu bezahlen, aber das ist Ihr Geschäftsprozess, der dafür verantwortlich ist, nicht das Bitcoin-Protokoll.
Sie sollten auch den Mindestzahlungsbetrag und die eventuelle Netzwerkgebühr berücksichtigen, die beide nicht prozentual sind.
Diese werden nicht erwähnt, und tatsächlich entstehen Ihnen durch zwei (oder möglicherweise vier) Transaktionen bis zu 4x die Transaktionsgebühren des Bitcoin-Netzwerks.
Dies ist einer der Hauptgründe, warum Sie (aus geschäftlicher Sicht) die Transaktionen nicht aufteilen sollten, dh es ist teurer und wer trägt die Kosten? Die Wohlfahrt? der Händler? die Fracht? Du?
Kann ich auch vorschlagen, dass Sie die "Bestätigungen" als etwas anderes missverstanden haben, als dass Ihre Transaktion in einen Block aufgenommen wurde? Wenn eine Transaktion von einem Peer angefordert wird, bevor sie in einen Block aufgenommen wird, validiert der Peer die Transaktion unabhängig, und wenn sie aus irgendeinem Grund nicht gut ist, wird sie abgelehnt. Dies ist NICHT der Prozess der „Bestätigung“.
Alle effektiven Peers führen dieselbe Validierung Ihrer Transaktion durch, während sie sich durch das Netzwerk ausbreitet (was übrigens extrem schnell ist).
Die Bestätigung hingegen erfolgt, wenn die Transaktion in einen Block aufgenommen wurde, und das wird nur dann zu einem Problem, wenn es einen Fork in der Blockchain gibt. Aber selbst dann können Sie eine Transaktion erneut übertragen, wenn die „andere Gabelung“ die endgültige wird, vorausgesetzt, die Grundlage, auf der sie erstellt wurde, ist gut.
Der Punkt, den ich machen möchte, ist, dass Sie zu viel Wert auf Bestätigungen für Transaktionen legen, die Sie selbst erstellt haben, und dann warten, bis jemand anderes bestätigt, was Sie bereits als wahr kennen, und das scheint völlig sinnlos.
Vielleicht können Sie Ihre Frage erweitern, um die "geschäftlichen Gründe" zu erläutern?
Doug Peters
Doug Peters
T9b
Doug Peters