Published on: 2019-08-13T14:15:32+00:00
The email thread discusses various covenant proposals, such as CHECKSIGFROMSTACK, SECURETHEBAG, and CHECKOUTPUTVERIFY, that could address the issue at hand. Bishop's proposal is highlighted, along with previous works on the subject that he recently became aware of. Links to related works, including a 2018 proposal on the bitcoin-dev mailing list, a blog post on SegWit's security improvements, a YouTube video, and a Bitcointalk thread, are shared.Re-vaulting transactions and their limitations are also discussed in the email thread. These transactions are signed during the setup of the delayed-spend transaction for the parent vault, preventing coin withdrawals during the public observation delay period. However, there may be practical limits on the number of times a vault can be used for re-vaulting, as the transactions need to be signed in reverse order. The discussion also covers whether the same keys or new ones should be used for revaulting, depending on individual vault users' preferences.The conversation delves into various techniques and proposals for securing Bitcoin transactions, particularly in the context of implementing vaults without the need for soft-forks. Topics covered include delete-the-key pre-signed transactions, multisig gated by ECDSA pubkey recovery, alternative fee rates, fail-deadly mechanisms, key rotation, single-use seals, paid defection, financial privacy for custody and segregated vaults, and more. Multiple individuals contribute to the conversation, and links to related works are shared throughout.The article presents a proposal called "pre-signed vaults" as a method for implementing bitcoin vaults without relying on soft-forks or software upgrades. This method involves a public observation and delay period before a weakly-secured hot key can spend coins. The concept of "delete-the-key" pre-signed transactions plays a crucial role, where the key is deleted after a single transaction is pre-signed. Vaults are particularly useful for cold storage security as they allow for a publicly observable delay period during which a watchtower can alert the user if their coins are being stolen. The security of the scheme is enforced through pre-signed transactions and deleting private keys.The article also explores using pre-signed transactions to emulate covenants in Bitcoin, where a condition must be fulfilled for a transaction to occur. This can be achieved by using a series of pre-signed transactions with relative locktimes. Managing fees for pre-signed transactions is discussed, as well as the introduction of the "delete-the-key" trick. However, this trick does not work for multisig scenarios due to a lack of trust. An alternative technique using provably-unknown ECDSA keys in a multisig scheme is proposed. The article suggests a construction that allows for scripts exceeding size limits and explains how multi-party multisig bitcoin vaults can enforce a covenant.To improve financial privacy and security using vault constructions, the article suggests using a script template with different parameters instead of self-referential values to avoid dependency loops. The final transaction is created first and then used as input to the script template function. An early nuclear abort option and different multisig variations are proposed to enhance security. Key rotation and single-use seals are suggested for better financial privacy. The article emphasizes the importance of funding the vault only once and with the configured amount during setup.The author acknowledges the contributions of various individuals, including Jeremy Rubin, Bob McElrath, Andrew Poelstra, Joe Rayhawk, and Tadge Dryja. The article concludes by providing references to related works and acknowledging sources of inspiration for the proposal.
Updated on: 2023-08-02T01:15:25.991008+00:00