SIP 021: Trustless Two-way Peg to Bitcoin #113
Conversation
| rewards are repurposed to fulfill peg-out requests in the event that Stackers | ||
| temporarily fail in their duties. | ||
|
|
||
| Two high-level summaries of this SIP and what is would mean for the Stacks blockchain can be found here: |
|
|
||
| Sign-off: | ||
|
|
||
| Discussions-To: |
There was a problem hiding this comment.
Missing link
Suggestions:
|
|
||
| Alice converts her BTC to sBTC by doing the following: | ||
|
|
||
| 1. Her wallet queries the `.pox` contract for Bob's, Charlie's, Dannielle's, |
There was a problem hiding this comment.
Line breaks can be added in this paragraph so that the ordered list is rendered correctly in markdown; currently only the 1. is displayed
|
Nice job on the SIP! Is there a place to discuss the lower-level mechanics of peg-in and peg-out? For peg-in, I'd want to suggest mechanisms other than Anyways, not sure if this is the right place for discussion, but I'm just signaling:
|
|
Would also be interested in what Hank said. 👍 |
|
The |
|
|
||
| * **Data** | ||
|
|
||
| * **Bytes 3-80**: c32-encoded Stacks |
There was a problem hiding this comment.
This should be any valid Stacks address (principal or smart contract), and moreover, the address part does not need to be c32-encoded. Encoding it as a 21-byte string is fine.
There was a problem hiding this comment.
Do you mean it should be the byte encoded principal, using Clarity serialization?
There was a problem hiding this comment.
I mean:
- byte 3: address version
- bytes 4-23: address hash bytes
- bytes 24-64: address name, if this is a smart contract
|
Is |
Yep! Here's a tx from the Magic protocol - the input includes edit: forgot the link 😛 https://mempool.space/tx/39b1019ec7b76cf852dad9440babbb8eea6d42d8f9825faaae7d5604338dfe1a |
|
If we wanted to crudely "translate" this SIP's wire format for peg-ins to something using |
|
Interesting! I'll have to think about that. I confirmed by looking at How much easier is it to create a custom
I'd like to know more about this, if you have any links or resources handy. I'm currently under the impression that any attempt to embed extra data into a Bitcoin transaction is going to be iffy at best, since either way we're expecting wallets to offer users a way to paste some additional data into the transaction. I'd be keen to know how well Trezors and Ledgers support this, too, since these systems are expected to decode a given
The sBTC signers are already going to be running a custom daemon that interacts with a Stacks node to learn about peg-ins and peg-out requests. |
You can already do that with the |
|
Something interesting came up in a working group call today that I want to field here. What if sBTC holders got a PoX yield? We can do this without affecting the current PoX yield for STX holders. Right now, between ~75 and ~325 reward slots per PoX reward phase are burnt. This is a consequence of how the stacking minimum is calculated -- unless 100% of STX are stacking, there will be some unclaimed reward slots. What if, instead of burning BTC for those slots, the system diverted PoX payouts to sBTC holders? It would be used to incentivize people to move BTC into sBTC, and keep it there. The protocol wouldn't require you to lock your sBTC per se; instead, it could do something like use your lowest-ever sBTC balance in the prior reward cycle to determine how many of these leftover slots you'd qualify for, and distribute them similar to how they're distributed to Stackers today. There'd be a "sBTC balance minimum" that your lowest-ever balance must exceed in order to receive one or more reward slots. Stackers would continue to receive PoX rewards as-is, and would thus be prioritized for PoX rewards over sBTC holders (which I think is fair, because STX has higher price risk than BTC). But there's no reason to burn the excess BTC in a reward phase when we could instead use it to help incentivize people to use sBTC. What do you all think? |
In general I like the idea of doing some more useful with the BTC that currently gets burnt. What about a generalization where we decouple the actual usage: basically never burn any BTC; any BTC that would have been burnt gets locked up in a contract. And then you could have optionality in what happens to this BTC: as incentives for sBTC early adopters or for other "swim lanes" as @muneeb-ali calls them. Thoughts? |
Any BTC is untenable, which is why I specifically referred to the unused slots in the reward phase. In particular, the prepare phase must burn, for two reasons:
The unused slots could go to an arbitrary address. But if we want to redirect unused reward slots to sBTC holders in order to given them a yield, then I think the sBTC user experience would be best served by directing the rewards to them automatically instead of requiring users to go and claim them. As we learned with PoX, part of the "magic" of the UX is that you can watch BTC materialize in the Bitcoin wallet of your choice. |
|
Hi everyone, I would like to point to some issues and concerns about the draft proposal. First issue is about the Recovery Mode. Indeed peg-outs are theoretically processed in a finite period of time. However presumably the amount of sBTC would be high compared to the PoX rewards. At this moment there are $111 M of value stacked, and assuming a 200% collateralization ratio we could have up to $55 M in sBTC. In Recovery Mode, we can roughly process $14 million in a year ($0.27 per STX * 1,000 of subsidy * 52,500 blocks). If a lot of users want to peg-out in such case they would need to wait for even more than a year. However if Stacks reputation was affected by this and price dropped with the uncertainty then it would take longer and longer to process the peg-outs, which is a negative feedback loop causing the peg to never be processed (less PoX rewards -> slower peg-outs -> less value of STX -> less PoX...) and the loss of value of sBTC. Another issue is what happens if the collateralization limit is exceed. It's mentioned that no peg-ins are allowed, but the system needs to incentive somehow that people get their sBTC out so that the collateralization ratio is considered safe. If STX falls enough against BTC then we will reach under-collateralization. If peg-outs aren't sufficient we could perhaps burn sBTC to increase the collateralization ratio. Finally, and most important, the mentioned oracle mechanism doesn't seem reliable. As mentioned in the draft, we need to pick the mining data for long periods of time to increase the cost of manipulating the oracle price. However this basically means that the oracle price doesn't reflect the current STX price but the mean price over the last N blocks. If we choose N to be low the oracle can be cheaply manipulated, and if we choose N to be high it's expensive to manipulate but it doesn't reflect the current price. Taking into account that price movements can be very sharp, it's risky to rely on such oracle. |
The alternative is that a peg failure means that sBTC holders get nothing. Even if the Stacks chain takes years to pay back sBTC holders, or stops running PoX due to a lack of interest, that's still a preferable outcome.
Please see this thread: stacks-network/stacks#469 (comment). The TL;DR is that the negative consequence of an undercollateralized peg -- i.e. theft of funds by Stackers -- is both unlikely in practice and easy to mitigate because (1) that would require that fewer than 30% of the stacked STX holders are honest, and (2) stackers can do many things to render themselves trustworthy, such as disclose their identities and operate in jurisdictions where theft of the BTC will result in criminal charges and jail time. Also, please see the list of things that I'm actually worried will threaten the peg at the end of the thread. Banal concerns like security vunlerabilities in the implementation scare me a lot more than peg undercollateralization.
This is a non-starter. We're not going to burn sBTC, since that's protocol-level theft.
The alternative is to use an off-chain oracle, which can simply be hacked to return garbage data. Yes, using the behaviors of on-chain actors like miners and Stackers to derive the STX/BTC price means that there is a finite BTC expenditure by which these actors can change the derived STX/BTC price by an arbitrary amount. But, keep in mind that this behavior is visible on the Bitcoin chain, so anyone who would be negatively impacted by this behavior would be alerted well beforehand and can take appropriate action. Hacking an off-chain oracle, by contrast, is an invisible act, in which case affected parties would not be able to proactively protect themselves. Also, the cost of hacking an off-chain oracle is effectively unknowable and could be as low as $0. Making the oracle part of the consensus protocol at least gives us a lower bound on how costly it is to attack the system, which is pertinent information to would-be sBTC users. |
I think the same. More than 70% of dishonest stackers doesn't seem realistic, but if the back-up script lowers that threshold (which seems necessary to prevent the loss of peg funds) then under-collateralization may become a more serious concern.
Yes, but the issue I was mentioning is that the oracle is not sensitive to sudden market movements, because the price returned is a mean of the price of last N blocks. If STX price crashes against BTC, then it will take some time for the oracle to reflect this. This would allow processing peg-ins in a moment where it shouldn't be allowed. There's a tradeoff between sensitivity of price and cost of manipulating it.
What would be the specific actions that users could take in case miners spend too much? |
In the case of Magic, the This is why the sBTC signers would need to be notified of the peg-in. Because, the transaction just looks like a regular payment to an address, unless you know what the You can see Magic working here: https://testnet.magic.fun/ |
Right, that's one way a security vulnerability could slip in. In this specific case, the vulnerability is mitigated by a lengthy voting process by which a backup script is chosen, so there would be plenty of time to voice concerns and even peg-out if the upcoming peg wallet is not trustworthy.
I don't think it will be the average of N blocks. I think it will be a non-linear function of the last N blocks, and would take into account multiple parameters such as the distribution of STX/BTC spends per block (e.g. perhaps taking the median), how old the block is, whether or not the block is a flashblock, how many miners participated, and so on.
I think the system will err on the side of being expensive to manipulate. The reason is that it's very apparent to sBTC holders what the USD prices of STX and BTC are, so if there's a sudden drop in the price of STX to BTC, they would be more inclined to peg-out regardless of what the oracle calculated. The oracle's primary purpose here is to warn users not to put too much BTC in that Stacker incentives could be warped. The calculation would also low-ball the true STX/BTC price.
If evil miners (who could also be evil Stackers) are deliberately mining at a loss for a prolonged period of time, ostensibly to manipulate the oracle, then the following actions could be taken:
|
So I don't really know what is the point of the on-chain oracle. The oracle is not used to limit the collateralization ratio, since the only thing perhaps enforced is pausing peg-ins, which is not enough if STX price keeps falling against BTC. Not even pausing peg-ins can actually be enforced (without consensus changes) if the oracle is manipulated. And anyway, if it's manipulated, users can see the real STX and BTC price, and use that information to peg-out and not peg-in if necessary. In other words the oracle is not reliable and we instead rely on users and wallets self-verifying the actual STX and BTC prices, and pegging-out if the collateral ratio seems risky to them. But it's likely that most users do not peg-out (perhaps because they are using smart contracts that lock their funds, they lost their private keys, or other reasons) even when the collateralization ratio is way too low. This damages the Stacker incentives. |
|
@hstove @FriendsFerdinand I think in this case embedding the Stacks destination data inside the Bitcoin peg-in address is not suitable because the actual data is only revealed on-chain after spending from that address (by revealing the redeem script). The Stacks network needs, however, to agree on these destination addresses soon after the transaction is made to enforce and verify the peg-ins. By using OP_RETURNs it's guaranteed that we are in consensus about Stacks destinations, since peg-in transactions record it. But if we just commit to the data in the Bitcoin peg-in address, reaching consensus is non-trivial (and if the data is missing we cannot identify the peg-in transaction) which may open up potential network attacks. |
|
|
||
| * **Output 2**: a dust output with the recipient Bitcoin | ||
| scriptPubKey | ||
|
|
There was a problem hiding this comment.
Reminder: We need an Output 3 which sends a dust amount to the peg wallet to fund the fulfillment transaction fee, as discussed in yesterdays [sBTC meeting].(https://docs.google.com/document/d/1m4ROTYvgZhTJxbMY7NaI8N2sk5chbEm9SWEIE_Ewuy0/edit)
Related thought: If we want to be able to link fulfillment transactions and peg-out requests, should we also add a reference to the peg out request txid in the fulfillment transaction data? Because a single peg-out request might have multiple fulfillment transactions.
|
|
||
| * We increase the | ||
| economic cost to produce forks after a short time horizon. To produce a fork | ||
| of at least 7 blocks deep, the miner must have the explicit support of a |
There was a problem hiding this comment.
Would it be possible to further reduce the possible fork length? So that even the creation of a 'sibling' would get punished by Stackers? (to further reduce the 51% mining formation risk)
What is the reason for 7 blocks? Why not 5, 1 or 11?
There was a problem hiding this comment.
I recall that 7 came from the general people consensus that 6 Bitcoin confirmations is considered as Bitcoin finality.
There was a problem hiding this comment.
We could make the mining field more efficient and fair, if stackers immediately bless the first block in the event of a sibling? What speaks against it?
This would further decrease orphaned blocks produced by bad actors?
There was a problem hiding this comment.
I don't understand the Bitcoin confirmation argument because a fork on Stacks is different to a fork on Bitcoin. Stack forks happens on network delays or on bad actors. Bitcoin reorgs happens if two blocks are mined at the same time. This is not possible in Stacks.
There was a problem hiding this comment.
Stackers will be able to vote on thawing blocks with [6,150] confirmations to steer, but not completely control, block production.
We are retiring the "blessing" terminology and replacing it with freezing and thawing.
There was a problem hiding this comment.
Unfortunately, this doesn´t solve the problem with siblings and forks <6 blocks like we see them right now. E.g. Stacks block 95283/95284?
There was a problem hiding this comment.
The economic profit on 1 block forks can be high enough to encourage miners to do it.
I understand that stackers should not control block production, however, indicating their preferred fork as soon as possible could be integrated more into the consensus algorithm.
There was a problem hiding this comment.
Correct. If our goal is to further decentralize the network - wouldn't that be the next necessary step?
Otherwise, larger miners would be able to "bleed out" smaller ones by initiating forks/siblings on purpose?
There was a problem hiding this comment.
The economic profit on 1 block forks can be high enough to encourage miners to do it.
Right, the reason why this doesn't happen on Bitcoin (at least in theory) is because miners have a long term commitment with the Bitcoin network i.e. they purchased ASICs whose only way to monetize is mining Bitcoin for years. They are discouraged to damage the trust in the system that allows them to get a profit on their capital expenditure.
But Stacks is mainly operational expenditure, so miners don't have such commitment. They don't have an up-front cost that forces them to stay mining for long periods of time in order to get a profit.
There was a problem hiding this comment.
Could the text be extended to explain the calculations of the economical costs for a fork? Will get only frozen blocks the block reward?
| * **Bytes 11-76**: A 65-byte recoverable secp256k1 low-S | ||
| signature from the sBTC owner's private key(s), over the SHA512/256 hash of the | ||
| bytes consisting of | ||
|
|
||
| * the number of sBTC (bytes 3-11 above) | ||
|
|
||
| * Output 2's | ||
| scriptPubKey |
There was a problem hiding this comment.
Observation from @MarvinJanssen. Is there anything in this design preventing replay attacks? It seems like anyone could replay a peg out request, and force an sBTC holder to peg out again if they have already done it once.
There was a problem hiding this comment.
For Clarity: this is not about repeating the transaction itself but just the payload, as the signature is only over the amount of BTC being pegged out and the output scriptPubKey. It needs another differentiator or a nonce at the bare minimum.
The section also needs to be updated right? I was told the signature is now inside the unlock script instead of OP_RETURN.
There was a problem hiding this comment.
The section also needs to be updated right? I was told the signature is now inside the unlock script instead of OP_RETURN.
We're keeping the original OP_RETURN format, but we're also extending the protocol to allow for the same data to be submitted in the witness using the commit-reveal format.
At least that's how I have defined it in the proposed design. This is very much up for discussion, but I don't see any reason not to keep supporting the original OP_RETURN format since it is simpler and more secure for any user who can leverage it.
Link to design draft for supporting commit-reveal ops: https://github.com/Trust-Machines/core-eng/pull/268
| * Requires HSMs on a majority of Bitcoin miners (brittle; | ||
| closed-membership) |
There was a problem hiding this comment.
The Powpeg protocol does not require that a majority of bitcoin miners run PowHSM nodes, or even that the PowHSM operators be miners at all. See existing PowHSM operator list here: https://rootstock.io/powpeg/
There was a problem hiding this comment.
That actually makes them more brittle and less secure. It does not matter what attestations a non-miner or a minority of miners make with PowHSM, because the non-miner / minority coalition is not guaranteed to see the true state of the canonical fork with 100% certainty. Non-miners / minority coalitions only sees the blocks that the majority of miners and next-hop peers allow them to see. The PowHSM is reduced to security theater.
There was a problem hiding this comment.
My comment wasn't contesting any sort of security analysis on PowHSMs, more just pointing out that, contrary to what the bulletpoint I quoted says, Powpeg does not require a majority of bitcoin miners to run HSMs. Just want to make sure this is corrected before this section is finalized.
The PowHSM is reduced to security theater.
The PowHSM is not security theater, like anything it has tradeoffs. Here the tradeoff is: assuming the private keys cannot be extracted from a quorum of HSMs, a quorum of PowHSM operators cannot steal the BTC locked in the Powpeg, but a majority of Rootstock hashpower can. The majority of Rootstock hashpower can steal by mining a block with a valid header but an invalid withdrawal transaction inside that sends all of the BTC to themselves, and burying this block under a sufficient number of confirmations -- currently 4000 Rootstock confirmations are required before a withdrawal is signed by the PowHSM nodes. During the 4000 block confirmation window, the PowHSM operators could notice what's happening and unplug their PowHSM nodes until the valid chain takes over as the most difficult chain again for some sufficiently deep number of confirmations. If the valid chain never overtakes the invalid chain in block depth, then the network could hard fork to get away from the attacking miners, or wait until the emergency multisig kicks in.
Depending on how much of the bitcoin hashrate is mining Rootstock, the Powpeg protocol may be considered strictly superior to a "vanilla" multisig, since bitcoin miners are a highly decentralized group (this will be improved even more with widespread Stratum v2 adoption). Thus the security of the Powpeg approaches that of a hashrate escrow. Whether or not a hashrate escrow actually is more secure than a vanilla multisig can be debated, but at least some people (including the Rootstock community and others such as the drivechain community) feel that way. So to them the Powpeg is a meaningful improvement (not "theater") compared to a vanilla multisig.
| * Has a token with coinbases to incentivize validator | ||
| liveness regardless of tx volume (good!) |
There was a problem hiding this comment.
PowHSM operators do not receive any sort of coinbase subsidy.
There was a problem hiding this comment.
They don't receive RIF? News to me.
That makes their position weaker, then. Why should validators care to stay online in periods of low activity, when there are other more-profitable things they could be doing at the same time? That's the problem that a protocol-level coinbase solves (or some other minimum but fixed reward for just showing up, such as PoX payouts in our case).
There was a problem hiding this comment.
They don't receive RIF?
Right. RIF is an application-layer asset. It's not used at all in the consensus layer.
Why should validators care to stay online in periods of low activity, when there are other more-profitable things they could be doing at the same time?
The effort to merge-mine Rootstock is marginal: run a Rootstock node and set generate to true (exaggerating slightly but not far off from that level of simplicity). So the activity would have to be really low for a long period of time to make it worth it to stop merge-mining.
| * No incentive for validators to | ||
| process transactions, outside of miniscule tx fees |
There was a problem hiding this comment.
Calling the fees "miniscule" is conjecture.
There was a problem hiding this comment.
Is there a live sidechain somewhere I can look at to get a feel for what the reward is to validators for processing peg-ins and peg-outs?
I personally almost didn't bother including sidechains/drivechains in this section because AFAIK there aren't any live ones. I don't have very much patience for paper systems whose designs are still in-flight (by the same token, I wouldn't expect any of them to cite sBTC as related work before it was live).
| * Probably the closest system to what | ||
| we're building |
There was a problem hiding this comment.
Nomic is much more similar to sBTC than Powpeg:
See also Interlay and tBTC v1, which are both based on the XCLAIM protocol:
There was a problem hiding this comment.
Thanks for the links. Will take a look when I have more time.
There was a problem hiding this comment.
"Nomic is much more similar to sBTC than Powpeg:"
Nomic was used as inspiration for the initial sBTC design discussions last year.
| * No compelling answer for | ||
| dealing with sidechain reorgs (Bitcoin miners have to fully validate, which | ||
| does not scale) |
There was a problem hiding this comment.
- No compelling answer for dealing with sidechain reorgs (Bitcoin miners have to fully validate, which does not scale)
It's worth separating out these two claims. Although adequately dealing with re-orgs does require the bitcoin miners (who are also the custodians of BTC locked in the hashrate escrow) to fully validate the chain so they know which pegout requests to process, the issue of scaling full validation would still exist even if the question of how to handle re-orgs was adequately addressed. So I will address each claim separately:
Bitcoin miners have to fully validate, which does not scale
Using "proof-sync" clients such as Zerosync, the marginal effort of validating an extra chain would be minimal, enabling the trustless scaling of full validation.
No compelling answer for dealing with sidechain reorgs
The general solution here is to wait some number of confirmations before processing peg-outs. If there is a re-org after said number of confirmations then yes, the peg-outs could be double-spent, causing the sidechain to become undercollateralized.
One simple way to deal with this possibility is to require that re-orgs are not allowed at a block depth equal to or greater than the block depth at which peg-outs will be processed. IIUC Stacks/sBTC does something like this:
If Stackers have received their peg-wallet hand-off for this reward cycle and fail to fulfill a request within 50 Bitcoin blocks of the request being finalized (i.e. at most 150 Bitcoin blocks after the request is submitted), then the system transitions to Recovery mode and PoX payouts are repurposed for fulfilling pending peg-out requests.
I don't know if these answers meet the author's bar for "compelling" but I find them reasonable given the inherent tradeoffs of the sidechain approach.
There was a problem hiding this comment.
Using "proof-sync" clients such as Zerosync, the marginal effort of validating an extra chain would be minimal, enabling the trustless scaling of full validation.
A few questions:
- Is Zerosync live yet? If not, then our point stands at least until it's live.
- If Zerosync is live, does it apply to sidechains with computation models that are at least as expressive as Clarity? If not, then Bitcoin's ability to scale through STARK proofs for sidechains does not help users achieve expressive smart contracts for Bitcoin (meaning, zerosync's existence does not invalidate the novelty of our work).
- Is Zerosync proof generation open-membership? As in, can multiple prover coalitions exist? If so, can two coalitions of provers submit conflicting proofs on the state of the sidechain? If so, then can Bitcoin determine which proof represents the majority coalition? If the answer to any of these three criteria is "no," then it's also strictly worse than our work. A sidechain whose state is decided by a fixed set of provers has all the problems that PoS does (for example, it's impossible to dislodge or overpower malicious provers in-band, and a 33% or larger malicious coalition can halt the sidechain).
One simple way to deal with this possibility is to require that re-orgs are not allowed at a block depth equal to or greater than the block depth at which peg-outs will be processed. IIUC Stacks/sBTC does something like this:
If the sBTC wallet is ever undercollateralized, then Recovery Mode engages and PoX payouts are repurposed to restore the missing BTC. No sidechain does this that I at least am aware of.
There was a problem hiding this comment.
- Is Zerosync live yet? If not, then our point stands at least until it's live.
- If Zerosync is live, does it apply to sidechains with computation models that are at least as expressive as Clarity? If not, then Bitcoin's ability to scale through STARK proofs for sidechains does not help users achieve expressive smart contracts for Bitcoin (meaning, zerosync's existence does not invalidate the novelty of our work).
There are no production-grade proof-sync clients for bitcoin-like chains yet. However, there are proof-sync clients for fully-expressive EVM and Cairo chains. These are implemented as smart contracts and used for verifying the state of validity rollups built with those computation models. Some example include:
- EVM: Polygon zkEVM, zkSync Era
- Cairo: Starknet
Is Zerosync proof generation open-membership? As in, can multiple prover coalitions exist?
Yes
If so, can two coalitions of provers submit conflicting proofs on the state of the sidechain?
Yes, but...
If so, then can Bitcoin determine which proof represents the majority coalition?
Short answer: bitcoin consensus does not verify the proof. Only the miners need to verify the proof, so they know which drivechain blocks to build on and which withdrawals (what you called "redemptions" in another comment) to upvote (or downvote). It doesn't matter how many proofs get thrown at them by how many different "coalitions" of provers, the miners can use the proofs to figure out what they need to know so that they only allow valid withdrawals to go through.
If the sBTC wallet is ever undercollateralized, then Recovery Mode engages and PoX payouts are repurposed to restore the missing BTC. No sidechain does this that I at least am aware of.
Yes but AFAICT the block finality mechanism I cited in my previous comments prevents the sBTC wallet from becoming undercollateralized due to a Stacks re-org. The failure scenario that the Recovery Mode you cite is designed to deal with is the case where a sufficient quorum of signers are compromised such that their private keys are used to transfer BTC out of the reserve wallet. Right?
| * Merged mining | ||
|
|
||
| * Requires majority Bitcoin miner | ||
|
|
||
| participation (risky without 100% participation -- one Bitcoin miner could have | ||
| majority merged-mining power, like with Namecoin) | ||
|
|
||
| * Bitcoin miners must | ||
| validate merged-mined chain (does not scale) | ||
|
|
||
| None of the above can recover from a peg failure. |
There was a problem hiding this comment.
Merged-mining is orthogonal to BTC bridge protocols, no? I mean, the techniques can be combined (as with Rootstock, which is both merge-mined and has a BTC bridge) but on its own merged-mining is just a block production Sybil-resistance mechanism that piggy-backs off the mining power of an existing blockchain -- closer in comparison to PoX than it is to sBTC.
There was a problem hiding this comment.
Right -- this bulleted collection speaks more to the limits of merged mining as a useful protocol for building a BTC bridge. This will be clarified when this section is fully written.
| * Probably the closest system to what | ||
| we're building | ||
|
|
||
| * Sidechains / drivechains |
There was a problem hiding this comment.
While we're considering options that require a soft fork such as Drivechain, perhaps worth adding rollups and validia chains to the list for comparison?
There was a problem hiding this comment.
Does there exist a live system in which the wrapped BTC can be redeemed for BTC by an open-membership set of validators who ensure that the redeemer followed all of the protocol rules for claiming the BTC?
There was a problem hiding this comment.
@jcnelson in rollups (and validia chains, but I will use rollups in the example below for simplicity) there are two paths to redeeming "wrapped" BTC (or L2 BTC, however you want to call it) for L1 BTC:
- Happy path: users submit a withdrawal transaction on the rollup chain specifying an amount and withdrawal address. The rollup block producer will submit a rollup state update transaction to the rollup smart contract on L1 that also withdraws the specified amount of funds from the rollup contract and transfers them to the specified withdrawal address. If the rollup is a validity rollup, then the block producer will also include in their L1 transaction a cryptographic validity proof that proves the withdrawal is valid according to the rules of the rollup. If this state update transaction is confirmed, the user will receive their funds at the specified address. If the rollup is an optimistic rollup, there is also a challenge period where the user must wait some period of time after the withdrawal transaction is confirmed before their withdrawal is processed. If the state transition is invalid according to the rules of the protocol, then anyone can submit a fault proof on L1 during the challenge period and cancel the withdrawal. This prevents invalid withdrawals from going through.
- Unhappy path: users submit a withdrawal transaction on the rollup chain specifying an amount and withdrawal address. The block producer is uncooperative for whatever reason and doesn't include the withdrawal transaction in the blocks that are submitted to the L1 rollup contract. The user can then go to the L1 contract and submit their own withdrawal transaction directly to the L1 contract. This is known as a "unilateral exit" aka "escape hatch" or "self-propose" (the details about how unilateral exit capabilities are implemented differ between rollup implementations). If the user gets their unilateral exit transaction confirmed (and in optimistic rollups, goes the whole challenge period without a successful challenge) then the withdrawal will be processed by the rollup contract and the user will receive their funds back on L1.
There are multiple rollup protocols in production that demonstrate these capabilities, see the list here showing "escape hatch" or "self-propose" under the "proposer failure" column. No one has implemented this yet on bitcoin or a bitcoin-like chain but there's no technical reason why it couldn't be.
This SIP proposes a trustless two-way peg for Bitcoin, backed by Stackers and PoX.
For more background, see the following: