delvingbitcoin

Transitory Soft Forks for Consensus Cleanup Forks

Transitory Soft Forks for Consensus Cleanup Forks

Original Postby harding

Posted on: January 3, 2025 21:22 UTC

The discussion revolves around the innovative "covenant-less Ark," highlighted through two primary sources, which can be explored further at https://ark-protocol.org/intro/clark/index.html and https://arkdev.info/blog/ark-release-v0.2covenant-less-ark.

This concept aligns closely with a proposed definition by incorporating a pseudo-covenant mechanism that achieves security through just a single successful interaction and the involvement of an honest third party. The unique approach taken by clArk leverages a system where multiple third parties form a multisignature setup ready to endorse transactions, thereby streamlining the process without significantly increasing costs.

The operational details of this system are meticulously outlined, beginning with the utilization of signing oracles, which are abundant and can include any relaying full node as a potential signer. In an illustrative scenario, a user named Alice seeks to execute a transaction benefiting Bob and Carol using a precommitted transaction tree, akin to capabilities offered by CTV (CheckTemplateVerify). She collects a list of oracles from Bob and Carol and obtains ephemeral public keys from each, for which the oracles confirm ownership. Alice then amalgamates these public keys to craft a transaction directed to the combined public key address in a P2TR output, forming a Partially Signed Bitcoin Transaction (PSBT) without finalizing it with her signature.

This PSBT is then provided to the oracles, who construct a presigned transaction that reallocates funds according to the original transaction tree intended for Bob and Carol. Upon Alice completing the transaction with her signature and ensuring its confirmation on the blockchain, she distributes the presigned transactions alongside attestations to Bob and Carol. The architecture guarantees security as long as one oracle remains honest and disposes of their private key post-signature, highlighting an effective safeguard against malfeasance.

Comparatively, when assessed against base CTV functionalities, this method incurs an overhead of 111 vbytes for a standard 1-input-1-output transaction, with an additional 18 vbytes required per precommitted transaction to cater to signature and miscellaneous data. While it may not offer the cost-effectiveness of CTV's tapleaf constructs, this strategy presents a viable alternative for several use cases traditionally served by CTV, such as congestion control, channel factories, and coin pools, suggesting a meaningful advancement in blockchain transaction protocols.

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