bitcoin-dev

Combined summary - Graftroot: Private and efficient surrogate scripts under the taproot assumption

Combined summary - Graftroot: Private and efficient surrogate scripts under the taproot assumption

On February 22nd, 2018, a suggestion was made by Jeremy on the Bitcoin-dev list to improve the utility of a construction by introducing functionality that makes a script invalid after a certain time.

This suggestion was discussed in a thread tagged with "nExpiryTime" and users were encouraged to search the archives for more information. The term "fill-or-kill transaction" was also mentioned in a previous discussion on the same list in September 2015. The post was signed off by Sjors.In a recent email conversation on the bitcoin-dev mailing list, Daniel Edgecumbe proposed a method to bind grafts to a specific transaction without requiring aggregation. He suggested signing H(txid, script) instead of H(script), but its impact on aggregation is unknown. This method requires knowing the txid in advance, which can be handled by a graftroot sighash flag. However, in most cases, the txid is not known. Another alternative solution is signing a transaction spending the multisig coin to the graft, but it lacks atomicity, scalability, and privacy. The advantage of the aggregation approach is that it works just in time even on grafts created in advance. A non-interactive schnorr aggregation trick can be used to merge the S values of all graftroots and signatures into a single aggregate, reducing overhead to ~32 bytes, similar to taproot's overhead.The discussion on the Bitcoin-dev mailing list focuses on the case where a delegate is signed conditional on another delegate being signed. Participants suggest the need for something like segwit internally to refer to one side's delegation using a signature-stable identity, but no good solution is currently available. Another point raised in the discussion is the introduction of functionality to make a script invalid after a certain time, allowing exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. This construction enables unilateral key rotation without invalidating the interests of other parties in the existing multisig, requiring only storing the signed delegation.The email thread discusses the introduction of functionality to make a script invalid after a certain time, which can enhance the utility of a construction despite previous re-org behavior. Proposed timelocks would be valid before a certain time or block height and invalid after, allowing for exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. Unilateral key rotation is possible in a multisig setup without invalidating the interests of other parties, as long as all parties agree to add a new key while still allowing the old key to sign.The context suggests the existence of a method that enables unilateral key rotation in a multisig setup without invalidating the interests of other parties. This method does not require any on-chain transactions but involves storing the signed delegation. The Taproot protocol provides only one alternative natively, while the Graftroot protocol allows for an unlimited number of alternatives while maintaining efficiency and privacy. With Graftroot, participants can delegate their ability to sign to a surrogate script by signing just the script with their taproot key and sharing the delegation. When spending the coin, if the signers aren't available, the redeeming party satisfies the script and presents the information along with the signer's signature. Non-interactive schnorr aggregation can be applied to merge the S values of all graftroots and signatures into a single aggregate, lowering overhead to ~32 bytes. However, this approach requires interaction with participants and storage of resulting signatures. Graftroot allows delegation before or after the fact and requires storage. The potential for unexpected surrogate replay and the existence of unused surrogates are considerations to keep in mind.

Discussion History

0
Gregory MaxwellOriginal Post
February 5, 2018 05:58 UTC
1
February 5, 2018 15:56 UTC
2
February 5, 2018 19:58 UTC
3
February 9, 2018 07:29 UTC
4
February 9, 2018 07:42 UTC
5
February 22, 2018 12:19 UTC
6
February 22, 2018 19:44 UTC
7
February 24, 2018 18:58 UTC
8
June 30, 2018 11:49 UTC
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback