-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
26 changed files
with
572 additions
and
111 deletions.
There are no files selected for viewing
29 changes: 29 additions & 0 deletions
29
...-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks</title> | ||
| <updated>2024-12-01T02:54:58.537936+00:00</updated> | ||
| <author> | ||
| <name>jeremy 2024-11-30 18:29:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Erik Aronesty 2024-11-30 17:19:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>jeremy 2024-11-27 03:05:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Nov_2024/m8423420dacdd1cb73ef8cdf320e3a0351fbd427a_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Nov_2024/m28457287069e8273057ef1b1d0d8b8ca641e7f05_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Nov_2024/mdf4d5c5017c77c10dd14fa387208cbdf0b59dace_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml" rel="alternate"/> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>2</id> | ||
| <title>Combined summary - Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks</title> | ||
| <updated>2024-12-01T02:54:58.537987+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#m8423420dacdd1cb73ef8cdf320e3a0351fbd427a" rel="alternate"/> | ||
| <summary>The email introduces a novel methodology for the implementation of Bitcoin covenants that cleverly circumvents the need for alterations to the Bitcoin protocol itself. This is achieved through an inventive use of covenant emulators alongside signing servers, setting it apart from prior methods aimed at simulating covenants. A pivotal aspect of this strategy is the imposition of a requirement for oracle signers to place bonds with BitVM auditors. These bonds are subjected to a risk of forfeiture under a specific BITVM style fraud proof regime, where any act of authorizing transactions in contravention of the established covenant rules could result in the loss of these funds. This serves as a deterrent against violations of covenant conditions by introducing a financial repercussion for non-compliance. | ||
|
|
||
| This approach is detailed further in a paper that elucidates the framework necessary for enforcing Bitcoin covenants without necessitating direct modifications to the blockchain's underlying protocol. The paper presents a comprehensive exploration of the mechanics behind this innovative solution, offering valuable insights into its potential application within the Bitcoin ecosystem. Interested parties can delve into the specifics of this proposal by accessing the document provided online, which promises an extensive analysis of the operational aspects of the proposed system. The discussed mechanism highlights a significant advancement in the realm of Bitcoin technology, proposing a viable solution for the implementation of covenants that preserves the integrity of the existing protocol. The full details of this approach, including theoretical underpinnings and practical implications, are available in the paper accessible via [this link](https://rubin.io/bitcoin/2024/11/26/unfed-covenants/), inviting further scrutiny and discussion among Bitcoin developers and enthusiasts alike.</summary> | ||
| <published>2024-11-30T18:29:00+00:00</published> | ||
| </entry> | ||
| </feed> |
22 changes: 22 additions & 0 deletions
22
...-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks</title> | ||
| <updated>2024-12-01T02:54:49.477648+00:00</updated> | ||
| <author> | ||
| <name>Erik Aronesty 2024-11-30 17:19:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks</title> | ||
| <updated>2024-12-01T02:54:49.477680+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#m28457287069e8273057ef1b1d0d8b8ca641e7f05" rel="alternate"/> | ||
| <summary>The discussion revolves around the concept of implementing Bitcoin covenants through an innovative approach that does not necessitate changes to the native protocol. This method involves the use of covenant emulators and signing servers, where oracle signers are required to post bonds to BitVM auditors. These bonds are subject to a BITVM style fraud proof system, allowing for the seizure of funds if an emulator oracle signs a transaction that breaches the covenant rules. This mechanism aims to secure the system by ensuring that the value locked in the bonds exceeds the value locked in the covenants, which is deemed a feasible restriction for various Layer 2 (L2) applications. Specifically, it targets enabling low-valued transactions, referred to as "vtxo's", that facilitate the emulation of self-custody for small amounts, which would be prohibitively costly to move on-chain otherwise. | ||
|
|
||
| The proposal underscores the necessity of analyzing the relationship between the bond lock value and the maximum safe covenant value, alongside the fees paid to oracles versus the potential loss of liquidity. Such analysis is crucial for driving incentives for both potential oracles and users, suggesting that while this model may not be suitable for vaulting use cases, it holds promise for protocols like ark2 and enigma-network, which are designed to support small-value transactions at scale. | ||
|
|
||
| For those interested in exploring this concept further, Jeremy provides a link to the paper detailing the proposed approach to unfed covenants, available at [https://rubin.io/bitcoin/2024/11/26/unfed-covenants/](https://rubin.io/bitcoin/2024/11/26/unfed-covenants/). This initiative represents a significant contribution to the ongoing conversation among Bitcoin developers about enhancing the flexibility and efficiency of Bitcoin transactions without altering the core protocol.</summary> | ||
| <published>2024-11-30T17:19:00+00:00</published> | ||
| </entry> | ||
| </feed> |
22 changes: 22 additions & 0 deletions
22
...-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks</title> | ||
| <updated>2024-12-01T02:54:38.541962+00:00</updated> | ||
| <author> | ||
| <name>jeremy 2024-11-30 18:29:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks</title> | ||
| <updated>2024-12-01T02:54:38.541996+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#m8423420dacdd1cb73ef8cdf320e3a0351fbd427a" rel="alternate"/> | ||
| <summary>In the discussion of enhancing security and incentivizing honesty in the context of vaults compared to systems like Ark, a novel approach is proposed focusing on the mechanics of signing oracles. The idea revolves around setting up a system where signing oracles receive payment over time for their services, promoting the operation of long-lasting, honest oracles due to the continuous revenue stream. This contrasts with the potential one-time gain from dishonest actions, thus encouraging the maintenance of integrity. | ||
|
|
||
| The method employs a key generation mechanism that operates privately, without the oracle's knowledge of the specific unspent transaction outputs (UTXOs) they might interact with. This setup ensures that oracles can't preemptively target UTXOs for malicious purposes, as they remain unaware of their existence until a signature request is submitted. An additional layer of security could be introduced by modifying the oracle to either blind sign transactions without learning their specifics or utilize homomorphic computations. These techniques allow for the verification of transactions without exposing sensitive details to the oracles or enabling them to broadcast transactions independently. | ||
|
|
||
| In a single-party vault scenario, this framework would not only deter misbehavior through the threat of punishment but also inherently limit the oracle's ability to steal coins directly. It suggests a model where a user might employ a 2-of-2 multisignature setup with their own key in tandem with the oracle, enforcing the agreed-upon ruleset collaboratively. However, the issue of ensuring continuous operation or "liveness" remains, which the author suggests addressing through mechanisms such as employing multiple "ultra cold" keys in combination with timelocks to secure the system further.</summary> | ||
| <published>2024-11-30T18:29:00+00:00</published> | ||
| </entry> | ||
| </feed> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.