Kontext: Ich erstelle einen Beispielcode, der einen atomaren Austausch zwischen Elements und Bitcoin demonstrieren würde, mit dem Ziel, dass die Austauschtransaktionen nicht trivial verknüpft werden können, wie dies bei einfachem HTLC der Fall wäre, in dem Sie nach demselben Hash / Preimage suchen können beide Ketten. Dies liegt daran, dass der offenzulegende Schlüssel tatsächlich eine Summe von Schlüsseln (A + B) ist und um die andere Seite des Swaps zu beanspruchen, ein anderer Summenschlüssel (A + C) verwendet wird. A, B und C sind nur (einem oder beiden) Teilnehmern bekannt.
Ich verwende CHECKSIGFROMSTACK auf der Elementseite, um die Gegenpartei zu zwingen, eine Signatur mit festem R-Wert zu erstellen (das k wäre bekannt, und somit kann die andere Partei den Schlüssel wiederherstellen).
Ich wurde auf https://bitcointalk.org/index.php?topic=321228.msg13072047#msg13072047 verwiesen , wo gmaxwell mitteilt, dass Sie den gleichen Effekt erzielen können, indem Sie die Offenlegung von Privatschlüsseln für nicht modifizierte Bitcoin erzwingen.
Er sagt, dass er zwei Wege kennt, um dies bei unmodifiziertem Bitcoin zu erreichen, einer davon ist:
OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY <P> OP_CHECKSIGVERIFY
Meine Fragen:
In dem oben aufgeführten Skript wird die Signatur gezwungen, die Länge kleiner oder gleich 57 zu haben. Dies scheint auf einem bekannten kleinen R-Wert und der Annahme zu beruhen, dass andere R-Werte gleicher oder kleinerer Größe für ein bekanntes k rechnerisch nicht möglich sind finden.
in diesem Beitrag https://crypto.stackexchange.com/questions/60420/what-does-the-special-form-of-the-base-point-of-secp256k1-allow wird ein R-Wert mit 90 führenden Nullbits angegeben . S müsste <= 29 Byte groß sein mit einer R-Länge von 21 Byte (166 Bit), damit die Signatur in die 57-Byte-Grenze (29 + 21 + 6 + 1 = 57) passt. Um dieses Skript mit diesem bekannten kleinen R zu erfüllen, müsste der Ersteller der Signatur nach der zu signierenden Nachricht suchen, die zu einer Signatur mit len(S) <= 29 führen würde. Wird diese enge Grenze gewählt, um den „Spielraum“ zu verringern? für Brute-Forcing R ?
Was ist die zweite Methode, um dies bei unmodifiziertem Bitcoin zu erreichen?
Wenn diese Methoden funktionieren, warum wurden sie nicht häufig anstelle von HTLC-Konstrukten verwendet, da diese Methoden (oder zumindest die vorgestellte) nicht viel komplexer in Bezug auf die Implementierung sind, aber privater (weil es keinen öffentlich geteilten Hash gibt). /Vorbild) ? Was sind die Nachteile dieser Methoden gegenüber HTLC?
(Anmerkung: Die obigen Fragen sind eher aus intellektueller Neugier als aus konkretem praktischem Zweck, denn wenn Schnorr-Signaturen auf Bitcoin aktiviert werden (ich hoffe, das wird nicht zu lange dauern), Adapter-Signaturen https://github.com/apoelstra /scriptless-scripts/blob/master/md/atomic-swap.md wäre ein viel besserer Weg, um atomare Swaps ohne triviale Verknüpfung zwischen Transaktionen zu erstellen)
Ich habe einige Suchen und Recherchen durchgeführt, und ich habe auch Input zum Kanal #elements auf Bitcoincore Slack erhalten, also habe ich das Gefühl, dass ich diese jetzt beantworten kann (BEARBEITEN: Zuerst war ich verwirrt über die CODESEPARATOR-Methode, aber nach einiger Zeit habe ich fragte Anthony Towns und er stellte die Links zu seinen Nachrichten in der Liste der Beleuchtungsentwickler zur Verfügung, um dies zu erklären.)
Ich denke, dass die Größe 57 für eine erhöhte Garantie gegen die Möglichkeit gewählt wird, dass andere kleine R-Werte gefunden werden, die größer als 21 Bytes sind, aber klein genug, dass das Schleifen für kleinere S es ermöglichen könnte, die Größenbeschränkung zu überwinden. Ich habe auch ein anderes Beispiel dafür gesehen, wie diese Technik verwendet werden könnte ( https://gist.github.com/nothingmuch/683042343c48a4ef07efd3d438e7ee56 ), aber es setzt 60 für die Größenbeschränkung. Es könnte angenommen werden, dass ein R-Wert, der mit 72 Null-Bits beginnt, auch nicht gefunden werden kann. Es kann auch sein, dass die 57-Byte-Grenze unnötig klein ist. Beachten Sie, dass das Schleifen für len(S) <= 29 auf Allzweckcomputern möglich ist. Dies könnte durch Ändern anderer Eingaben/Ausgaben der Transaktion erfolgen, so dass sich Sighash ändert. Relevant:https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
Der zweite Weg, dies bei unmodifiziertem Bitcoin zu erreichen, kann irgendwie die Verwendung von OP_CODESEPARATOR beinhalten. Es gäbe zwei Signaturen eines Pubkeys, aber die zweite Signatur würde einen anderen Sighash verwenden, da diese Signatur überprüft wird, nachdem CODESEPARATOR ausgeführt wurde, und Sighash nur unter Verwendung des Teils des Skripts nach CODESEPARATOR berechnet wird. Aber während Sie zwei verschiedene Signaturen (für verschiedene Nachrichten) für einen Pubkey haben können, ist mir nicht klar, wie ich hier die Wiederverwendung von Nonce erzwingen kann, wenn nicht mit dem gleichen Größentrick wie zuvor beschrieben oder mit den deaktivierten Opcodes.
BEARBEITEN: Anthony Towns danach gefragt, Antwort erhalten. Es gibt eine Technik, die zwei Codeseparatoren und drei Checkmultisigs verwendet, so dass die Wiederverwendung von R erzwungen wird. Siehe https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html und https:// listen.linuxfoundation.org/pipermail/lightning-dev/2015-November/000363.html
Weitere relevante Links: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016594.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016592.html Meine experimentellen Skripte: https://gist.github.com/dgpv/7818a4009f4e90868c0920cc1e238653
Beachten Sie, dass CODESEPARATOR kein Standard für Nicht-Segwit-Eingaben in Bitcoin ist, aber für Segwit-Eingaben in Ordnung sein sollte. Aber immer noch nicht ohne Kontroversen: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016732.html (es gab einen Vorschlag, CODESEPARATOR ganz zu entfernen oder Sighash immer mit dem Anfangsskript zu berechnen, ungeachtet Auswirkungen von CODESEPARATOR)
HTLC ist einfacher zu implementieren, und das Programm, das HTLCs erstellt, muss nicht in der Lage sein, mit Bignums zu arbeiten, zusammen mit der Funktion, die modulare Inverse auf Bignums implementiert. HTLCs würden im Allgemeinen auch kleiner sein. Sie sind auch bekannter und daher beliebter.
Dmitri Petuchow