Replies: 10 comments 21 replies
-
|
Under Nakamoto Stacks forks with Bitcoin, so if there's Bitcoin fork the Stacks chain would get rewritten starting at the point of the fork. The TX to mint sBTC would then be on an invalid Stacks block and the signers would refuse to build upon it. Is this post only relevant if there's 1-1 transaction replay? This exact concern is why it's not included in SIP-021 but I'm wondering if I'm missing something. |
Beta Was this translation helpful? Give feedback.
-
The signers strictly do NOT preserve transaction ordering because the Bitcoin fork changes the Bitcoin chainstate. This is actually why we had to go back and forth with the economics CAB. There was a strong preference for transaction replay to avoid reordering of the Stacks chain but there's no way to do that without "taint analysis" (an unfortunate term) to effectively sort between transaction that become "tainted" by a Bitcoin reorg and those that are safe to replay. Muneeb had a twitter response on this: https://twitter.com/muneeb/status/1752009319569072139 |
Beta Was this translation helpful? Give feedback.
-
|
I suspect the takeaway is that this isn't a concern because:
|
Beta Was this translation helpful? Give feedback.
-
|
Seems like for withdrawal there might need to be a 3 block delay to make sure the Withdrawal is final? |
Beta Was this translation helpful? Give feedback.
-
|
Would it be feasible for there to be a "staging" contract where any sBTC would live and if it's been in there for more than 3 Bitcoin blocks the peg out can be confirmed in 1 Bitcoin block? The staging contract would not be dependent on the Bitcoin blockchain so there's no potential for taint, which is the crux of this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Then that staging contract could be the regular flow, and for anyone who isn't immediately trying to pull their sBTC out after making complex contract calls wouldn't even need to know that there was a staging step |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if I fully understand the proposed staging mechanism, but if all we're doing is buying us time we're still vulnerable to deep forks as illustrated in my comment below. |
Beta Was this translation helpful? Give feedback.
-
|
But my comment does not solve the problem either, so we're probably stuck with having to delay withdrawals in either case. Unless we do initiate withdrawals on Bitcoin, but that would entail a very different design. |
Beta Was this translation helpful? Give feedback.
-
|
EDIT: This proposal has been proven wrong and do not solve the issue. I believe we can make double spending impossible thanks to Nakamoto block finality. This is achievable if we only create withdrawal accept transaction on bitcoin which consume a sBTC UTXO in a bitcoin block that confirms the stacks history containing the withdraw request. For example, consider the following unsafe scenario Here, the withdraw request is fulfilled by a withdraw accept transaction in block N+5a, three bitcoin blocks after the withdraw request happened. However, the withdraw accept transaction consumes a very old sBTC UTXO from block N+1. Thus it is entirely possible for a Bitcoin fork happening from block N+1, in which the withdraw request never happens but the withdraw accept transaction is included. However, if the withdraw accept consumes a UTXO from block N+4a as in this scenario Then, double spending the requested sBTC becomes impossible. This is because any Bitcoin fork that includes the withdraw accept transaction will have a corresponding Stacks fork which must include the withdraw request. |
Beta Was this translation helpful? Give feedback.
-
|
I'll admit that I'm not totally following this, but I'd love to have a chat with you to get a better understanding. Regardless of which UTXO we consume in a withdrawal accept TX, we can't control whether our already broadcast BTC TX gets included in a forked block or not. I also don't follow how it makes a difference whether we make a withdrawal accept in a BTC block that is part of Stack's history. But again, let's chat about this! |
Beta Was this translation helpful? Give feedback.
-
That is exactly what we can do. The BTC TX can never be included in a fork which doesn't contain all UTXOs it consume. By ensuring we consume a UTXO which exists in a block that confirms the withdraw request, the withdraw accept bitcoin transaction can not be included in a fork unless that fork already contains the block that confirms the withdraw request which means that any stacks chain built on that fork must also include the withdraw request. But yeah, I also find this hard to think about and it is entirely possible I'm overlooking something. Let's have a chat to iron out this. |
Beta Was this translation helpful? Give feedback.
-
|
@hstove helped me realize that there is nothing preventing the parent UTXO to also be materialized on a fork, so this proposal do not solve the problem. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Thinking out loud about the constraints of this, once a Bitcoin transaction is created for a withdrawal there's nothing we can do to guarantee that we take it back. The singular constraint should be this: There must be a valid confirmed sBTC withdrawal on Stacks for there to be a withdrawal on Bitcoin. I see no way for a Bitcoin transaction's validity to be conditional on the chain instance that it lives in. As far as I see, transactions have no way to access any part of the overall Bitcoin chain that differentiates one fork from another except in the transactions that came before it, and those transactions are also incapable of accessing fork related data, so the issue cascades. @netrome It sounds like you are suggesting a way around this but I'll admit I'm also not following it entirely. My above reasoning makes me think that it's information-theoretically impossible to impose any kind of restriction on when a transaction is valid once it has been sent because the act of expecting transactions to come before doesn't impose a greater restriction. The problem then is this: Signers can make a withdrawal on Bitcoin before the withdrawal on Stacks is sufficiently final. This is where we need to determine some of comfort in finality that sBTC should be comfortable with. I believe it's possible to maintain a contract that we can guarantee isn't conditional on any aspect of the Bitcoin blockchain so on any Bitcoin fork it's guaranteed to be valid, and the Signers can then only accept withdrawals from sBTC tokens that have "lived" in a verifiably un-Bitcoin-impacted state for the last Under a scheme like this the withdrawal will be a single Bitcoin block if the sBTC tokens have been living in that contract for the last several blocks, but will take I'm making some assertions about what it means for a SIP-10 token to "live" in a certain state, so I defer to you two on whether this makes any sense. I believe there's a path here where sBTC Bootstrap Signers can just reject any transactions that could be invalidated by the act of Bitcoin forking, and instead of doing some complex taint analysis the sBTC signers just verify that the tokens went through what is effectively a "cleaning procedure" ahead of time. Note on Bitcoin FinalityThe Stacks Blockchain has Bitcoin finality because each tenure is meant to have a valid sortition on the bitcoin blockchain. Tenures can be extended without a valid sortition. This means that if there are three tenure extends because there were three Bitcoin blocks that for whatever reason didn't have a valid sortition winner those Bitcoin blocks would have no impact on the finality of the Stacks Blockchain. For precision we may want to talk about finality in terms of tenure changes as opposed to Bitcoin blocks, because a tenure change needs a Bitcoin block and is the mechanism for finality, but a Bitcoin block does not need a tenure change. Waiting |
Beta Was this translation helpful? Give feedback.
-
There's no way to deterministically know which withdraws are verifiably "immune" to Bitcoin forks. If I'm missing something here, please let me know! You could theoretically say "you can only make a withdrawal if you call our contract directly, and not via a different contract". This would prevent the "coin flip" example. But then you have a different problem - the attacker can simply make two transactions. The first would be a coin flip that transfers their sBTC, and the second would be the withdraw request. So then you have to try and solve "what is the total state tree above this transaction that could have effected this withdraw". And even then, if we said "you can't have made any transactions within X blocks of your withdrawals" (which is infeasible from a UX perspective), the attack vector comes from transferring funds from A to B after a coin flip, and then withdrawing from B. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure there is unfortunately. I've been thinking about variations on what I've proposed where we instead require the signers to consume one or more leader block commit UTXOs (requiring PoX payouts to go through the sBTC wallet), but even in that scenario there is no guarantee that the leader block commits we consume are the sortition winners on another fork. I have looked at bitcoin opcodes and not found anything enforcing that a transaction is only valid on a particular fork, and finally I've even asked GPT-4 about this problem further confirming that transactions on Bitcoin are fundamentally unaware of how they are organized in blocks. Unless we want to revisit the old design where withdrawals are initiated on Bitcoin, I don't see how we can avoid the fork risk. |
Beta Was this translation helpful? Give feedback.
-
|
This would be a very useful primitive to have on Bitcoin. I'm wondering if this is something we'd even like to consider pushing for in the base layer long term. |
Beta Was this translation helpful? Give feedback.
-
|
I kind of think we have to initiate withdrawal on Bitcoin. This issue has nothing to do with Signer incentives so it'll persist in sBTC-v2; we would be better off addressing it now and having the same guarantees across implementations. |
Beta Was this translation helpful? Give feedback.
-
Access to the Bitcoin block header is only really useful for interesting and code-like transaction behavior; I bet preventing transactions from having access to any non-transaction data is a very deliberate choice to abstract the system away from the behavior. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah would likely only be useful for Bitcoin layers. I don't see any scenario where I as a Bitcoin holder would ever care about that. From that perspective it might be a hard sell to some maxis. |
Beta Was this translation helpful? Give feedback.
-
|
We need to revisit the discussion on the Withdrawal script because I think there's no way to avoid initiating it on Bitcoin: #17 |
Beta Was this translation helpful? Give feedback.
-
|
I think I only digested 30% of this ticket, but it's sort of related to bitcoin finality. Can’t the Clarity dataspace + stacks chain be our source of truth? (especially since we won’t have forks post-Nakamoto) |
Beta Was this translation helpful? Give feedback.
-
|
"Stacks doesn't fork" is technically true but is a little misleading. There's only one valid instance of the Stacks blockchain BUT if Bitcoin forks and the stacks chain was following a Bitcoin tip that turns out to be sub-optimal the Stacks chain that was following the sub-optimal Bitcoin fork instantly dies and then picks up on the new better Bitcoin chain tip. "There are never two valid Stacks forks" is better wording. |
Beta Was this translation helpful? Give feedback.
-
|
But what this means is a valid withdrawal could happen on the Stacks blockchain and the Signers make a withdrawal transaction on the bitcoin blockchain. THEN it turns out that that withdrawal happened on the Stacks blockchain when the Stacks chain was following a Bitcoin tip that later becomes sub-optimal. The Bitcoin withdrawal still lives and pays the Bitcoin out to some user BUT the original withdrawal could end up being invalid |
Beta Was this translation helpful? Give feedback.
-
You are more familiar with Clarity than I am at this point @8marz8, but updating the Clarity map still requires a valid action on the Stacks chain and if history on the Stacks chain can get re-written without the Bitcoin withdrawal request becoming invalid on the Bitcoin blockchain then it comes out to the same issue (I believe). |
Beta Was this translation helpful? Give feedback.
-
|
Two different options
It sounds like 6 Bitcoin blocks would be a better option because it's an industry standard. We need to finalize this aspect as soon as possible. If we think the two transaction approach could be faster to implement lets look otherwise lets commit to the 6 block approach. |
Beta Was this translation helpful? Give feedback.
-
|
Committing to the 6 block approach. Now we want a description of how the 6 block approach would look from a systems perspective. |
Beta Was this translation helpful? Give feedback.
-
|
I'm closing this discussion because we've solidified that sBTC-v1 will handle forks by ensuring the withdrawal is on a block in the Stacks blockchain that is sufficiently final. We will want to revisit this for sBTC-v2 and beyond; perhaps there's a BitVM procedure that can tie a transaction to a specific Bitcoin Chainstate. The next steps is to include the following information into #16.
|
Beta Was this translation helpful? Give feedback.
-
A stated high-level goal is to process both deposits and withdraws as soon as possible. Ideally, this could have a 1-block gap. As I've been thinking about v1 and how we can build it without being consensus-critical, I think there are few unresolved questions we need to figure out regarding this time.
As background for this issue, I'm working under the assumption that Signers will maintain strict transaction ordering, even in the case of Bitcoin forks.
To demonstrate the potential issues, let me outline an "attack scenario", along with potential mitigations:
Deposits
NN+1N, such as via replace-by-fee. A miner would be able to easily trigger this scenario (a "Finney attack").I think the solution here is that our sBTC
mintfunction must include a reference to the known latest Bitcoin(block-hash, height)tuple as part of the contract call payload. Inside the function, the contract checks that(get-burn-block-info? header-hash height)is equal to the signer-provided block hash. If this check fails, the whole mint function fails, thus preventing a double spend.While this prevents a double spent deposit, it means the signers would have to re-submit mint transactions in the case of Bitcoin forks. This adds a decent amount of complexity, because in the "happy path" we've already consumed the deposit UTXO, but we need to re-process the mint transaction.
In sBTC v2, where these mechanisms are consensus-critical, the sBTC mint would never occur, because it would be part of Stacks nodes' internal processing of sBTC deposits.
Withdraws
An attack scenario for withdraws is:
u128::MAX / 2. 50% of the time, this check will be "heads".Then, Bitcoin forks, and the Stacks signers preserve transaction ordering while re-executing each transaction. This time the result is "heads", so the sBTC withdraw request is not made. But Alice has already received her BTC withdraw. Thus, Alice has "double spent".
This attack isn't costly other than in transaction fees - in both cases Alice keeps control of her funds (in either sBTC or BTC).
I still need to think through this more, but my current thought is that the only way to handle this in sBTC v1 is to mandate a delay between withdraw requests and sending BTC withdraws. A typical delay that exchanges use is 6 blocks, but I'm sure there is good research out there about the occurrence of re-orgs. 2 blocks is relatively common, and more than that is rare.
Beta Was this translation helpful? Give feedback.
All reactions