In Bitcoin hat jede Transaktion eine nLockTimeGanzzahl, um die früheste zulässige Blocknummer/Zeit anzugeben, zu der die Transaktion der Blockchain hinzugefügt werden kann. Darüber hinaus hat jede Transaktionseingabe eine nSequenceGanzzahl, die theoretisch verwendet werden könnte, um Transaktionen zu aktualisieren und zu wissen, welche die neueste ist (obwohl diese Funktionalität derzeit deaktiviert ist).
Aber gibt es eine Möglichkeit, eine Transaktion zu senden, die endgültig ist und sofort zur Blockchain hinzugefügt werden kann, aber auch so zu gestalten, dass ihre Ausgaben nicht bis zu einer bestimmten Blocknummer/Zeit ausgegeben werden können? Es scheint, als wäre dies eine nützliche Funktion. Wenn ich beispielsweise mein Erbe zur Verfügung stellen möchte, wenn mein Enkel / meine Enkelin 18 Jahre alt wird, gibt es meiner Meinung nach keine Möglichkeit, dies in Bitcoin zu tun, außer dass jemand die Gelder hält und sie ihnen gibt die Zeit. Oder wenn ich jemandem eine Zulage geben wollte, konnte ich einfach Gelder auf einmal für etwa 3 Monate schicken, und sie tauchten wöchentlich im Portemonnaie des Sohnes/der Tochter auf.
Also, nur um es noch einmal zu überprüfen, es gibt keine Möglichkeit, so etwas in Bitcoin zu tun, oder? Gibt es Sicherheitsrisiken, wenn solche Transaktionen zugelassen werden? Wenn es wirklich keine Möglichkeit gibt, dies zu tun, dann ist es vielleicht etwas, das man der Hard Fork-Wunschliste hinzufügen kann .
Wenn es derzeit keine Möglichkeit gibt, dies mit Bitcoin zu tun, liegt es daran, dass ein solches System einen schwerwiegenden Fehler aufweist, bei dem ein UTXO zur Blockchain hinzugefügt werden könnte, das NOCH nicht ausgegeben werden kann ?
Ich kann mir zwei Möglichkeiten vorstellen, wie so etwas implementiert werden könnte.
OP_BLOCKINDEXund - OP_BLOCKTIMEOpcodes, die einfach den entsprechenden Wert auf den Stack schieben. Diese Werte müssten jedoch von dem Block stammen, der den UTXO ausgibt, und nicht von dem Block, der die Transaktion enthält, die den UTXO erstellt hat. Dies würde bedeuten, dass alle Transaktionsausgaben mit diesen OP-Codes nicht mit 0-Bestätigungen ausgegeben werden könnten, da diese OPs in diesem Zusammenhang keine Bedeutung hätten. (Diese Methode fügt der Situation möglicherweise zu viel Komplexität hinzu)nSequenceFeld, jeder Ausgabe ein paar zusätzliche Bytes hinzufügen, um anzugeben, wann eine Ausgabe ausgegeben werden kann (Blocknummer/Zeit). Wenn nicht angegeben, kann davon ausgegangen werden, dass es 0 ist.Nein, es gibt derzeit keine Möglichkeit, das zu tun, was Sie beschreiben, ohne ein Drittanbieter-Orakel zu verwenden.
Ja, möglicherweise können Sie dies relativ bald tun. Ein Soft Fork wurde vorgeschlagen, um einen OP_CHECKLOCKTIMEVERIFYOp Code (CLTV) einzuführen, und was ich sagen kann, hat starke Unterstützung vom Kern-Entwicklerteam (aber beachten Sie, dass Soft Forks Miner-Unterstützung für die Implementierung benötigen).
Wie Nick sagt, wurden frühere Versuche abgelehnt, weil sie vorschlugen, die Höhe oder Zeit des aktuellen Blocks wie folgt auf den Stapel zu verschieben:
<pubkey> checksigverify block <data> equalverify
<your pubkey> compare to sig current height 1000000 Only spend in block 1,000,000
Nochmals, um auf das einzugehen, was Nick gesagt hat, wäre die obige Beispieltransaktion in Block 1.000.000 gültig – aber wenn es eine Kettenreorganisation gäbe, wäre sie möglicherweise nicht in den neuen Block 1.000.000 eingeschlossen und daher wären alle davon abhängigen Transaktionen ungültig.
Der CLTV-Operationscode vermeidet dies auf zwei Arten. Erstens verwendet es den nLockTime- Wert aus der Ausgabentransaktion und nicht die Blockhöhe oder den Zeitwert des Blockheaders. Da eine Transaktion nur dann in einen Block aufgenommen werden kann, wenn ihre nLockTime gleich oder größer als die aktuelle Blockhöhe/-zeit ist, wird damit das primäre Ziel erreicht, UTXOs zuzulassen, die bis zu einer bestimmten Zeit nicht ausgegeben werden können.
Die andere Sache, die CLTV macht, ist, Werte direkt zu prüfen, anstatt Daten auf den Stack zu schieben. Dadurch kann nur eine Größer-als-gleich-Prüfung implementiert werden, sodass die Transaktion nach der angegebenen Höhe/Zeit immer ausgegeben werden kann.
Meine Vermutung ist, dass der Soft-Fork-Prozess zur Einführung von CLTV mit Bitcoin Core 0.11 beginnen wird, möglicherweise irgendwann im Juli 2015. (Aber wirklich, die Core-Entwickler werden wahrscheinlich nicht viel Zeit mit CLTV verbringen, bis 0.10 im Januar veröffentlicht wird, also nicht. zähle nicht darauf.)
Ich kann das Bitcointalk-Thread/Github-Problem nicht finden, in dem dies diskutiert wird, aber ein Blockindex-Opcode wurde in Betracht gezogen und abgelehnt.
Der Grund (IIRC) ist, dass es wichtig ist, dass eine Transaktion, wenn sie nicht in einen Block gelangt, immer noch in einen anderen Block aufgenommen werden kann. Es wäre sehr überraschend, wenn eine Transaktion rückgängig gemacht würde, weil der Block, in dem sie sich befand, ausgestorben ist und der Block, der sie ersetzt hat, einen Zeitstempel von zehn Sekunden später hatte.
Natürlich könnten Sie dies abmildern, indem Sie erkennen, wenn eine eingehende Zahlung einen der zeit-/blockabhängigen Opcodes enthält. Das nächste Problem, das Sie lösen müssen, ist, dass jemand eine zeitabhängige Transaktion durchführen und dann eine dieser Ausgaben mit einer normalen Transaktion ausgeben könnte. Es würde für die Person, an die Sie es gesendet haben, wie eine normale Transaktion aussehen, aber es würde tatsächlich von einer Transaktion abhängen, die ungültig werden könnte, wenn sie in einen anderen Block aufgenommen würde.
Keines dieser Probleme ist unlösbar, aber ohne einen überzeugenden Anwendungsfall sind sie die Komplexität nicht wert. In dem Beispiel, das Sie geben, könnte dasselbe erreicht werden, indem Sie Ihren privaten Schlüssel in ein Schließfach legen und seinen Inhalt Ihrem Enkel überlassen.
Außerdem kann Ihr Problem mit nLockTime gelöst werden. Sie können eine Transaktion erstellen, die Ihre Bitcoins an eine Adresse sendet, die von Ihrem Enkel kontrolliert wird; Stellen Sie die nLockTime so ein, dass sie an einem bestimmten Datum abläuft; und den privaten Schlüssel zerstören, der diese Transaktion signiert. Das Problem dabei ist, dass die Transaktion nicht auf der Blockchain gehalten wird. Außerdem sollte Ihr Enkel diesen privaten Schlüssel besser nicht verlieren. :)
Kommentatoren, bitte melden Sie sich, wenn Sie herausfinden können, wo dies besprochen wurde.
if you could send to a Multisig, you could eliminate thatWAHR. What do you meanSorry, das war nicht ganz klar. Ist es jetzt besser?x > 0wird erst x blocksnach der Blockhöhe des Txn verarbeitet, obwohl in der Praxis offenbar 2 Stunden (12 Blöcke) die ideale Cutoff-Zeit sind. Dies liegt daran, dass, wenn Sie die Transaktion rückgängig machen möchten, ein neuer Tx gebildet werden muss, um die Bitcoins von der zeitgesperrten Ausgangsadresse zu einem neuen Ausgang umzuleiten (d. h. wenn ntimelock abläuft, schlägt der Tx fehl, weil die Eingaben ausgegeben werden. Dies ist alles aus dem Gedächtnis, also bin ich noch nicht zuversichtlich genug, um darauf eine Antwort zu gebenDie anderen Antworten hier sind derzeit veraltet, da OP_CSV und OP_CHECKLOCKTIMEVERIFY vom Netzwerk übernommen wurden, die beide Möglichkeiten bieten, gesperrte Ausgaben zu erstellen.
Nick Odell
Morsecoder
nLockTimees sowohl zur Bestimmung des frühesten Zeitpunkts verwendet werden, an dem eine Transaktion zur Blockchain hinzugefügt werden kann, als auch zur Bestimmung der frühesten Zeit, in der sie ausgegeben werden kann? VerliertnLockTimeseine alte Funktionalität und wird durch die neue ersetzt? Es kann nicht zwei Werte gleichzeitig annehmen...David A. Harding
Morsecoder
nLockTimegrößer als eine im scriptPubKey angegebene Anzahl sind, und die aktuelle Funktionalität von Bitcoin macht es bereits so, dass Transaktionen nicht enthalten sein können in der Blockchain vor demnLockTimeBlock/der Zeit. Vielen Dank!