Replies: 1 comment 2 replies
-
I don't think the current design would require sBTC Signers to trawl any Bitcoin blocks. They must be able to spend Bitcoin outputs, but that's about it. If the deposit flow is:
At no point in time will the Signers have to observe any bitcoin state, beyond having the ability to spend a UTXO. And we don't need to implement any node changes to support this flow. Withdrawals are initiated on Stacks so there's no Bitcoin chain state to observe there either. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
sBTC v1 is meant to be a paired down version of BTC, with a majority if not all of its logic implemented in clarity contracts similar to sBTC mini. The assumption is that we may be able to produce an sBTC design that does not require any stacks node changes.
This would imply that sBTC deposits cannot be purely done on the Bitcoin Blockchain unless we have the sBTC signers trawl the Bitcoin transactions for pending deposits.
If we do not want to make sBTC signers trawl the Bitcoin blocks, we will HAVE to implement some sort of STX transaction in addition to the BTC transaction to reveal it to the signers which introduces a potential extra step (more fees)
If we do not want to make sBTC signers trawl the Bitcoin blocks AND do not want to implement an additional STX transaction/make users create two transactions to deposit, we will HAVE to make changes to the stacks node to auto include these sBTC deposit BTC transactions in the nodes DB similarly to what we had for sBTC mini but that recently got ripped out of the node.
Beta Was this translation helpful? Give feedback.
All reactions