-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Research]: Deposit API Service (formerly Revealer API) #18
Comments
I think it's really important to prioritize not having the signer binary be publicly reachable. Even though we'll almost certainly need the signer to expose some HTTP endpoint, we do not have to have the signer's IP be publicly known. It just adds too much security risk. I understand the pushback of a third-party service being potentially seen as "more centralization", but it's functionally the same as a signer developing their own proxy and then making that publicly known. |
Scrapped this per #37 |
To help conclude this topic, I'll mention the discussed points and my potentially inaccurate assumptions here again: If we only have the Deposit API:+ We can avoid extra contract calls - faster and no fees If we only support deposits through contract calls:+ Decentralized Any other strong opinions for not having the API and only going with making deposits through contract calls (similar to withdrawal)? My impression was that we really want to avoid the latency/cost. UPDATE: I'm leaning more towards the contract route now given that maybe we could reuse more of sBTC mini. Additionally, I think the API can be added anytime later, or developed asynchronously but it doesn't have to be the initial promise to users for how to interact with sBTC for deposits. |
That makes a lot of sense to me as a promise. Though I'm losing track of what sBTC ops come from where.
|
For Deposit, the contract call approach was mentioned in this discussion (Deposit -> proof of deposit -> first point) and was part of this initial diagram (left flow from user to sbtc contract) |
We discussed how having access to stx before making a deposit (for the contract call route) could be a downer for users. Some sponsorship model from the past was brought up. New discussion made: #38 |
It's not clear to me what the advantage of using contract calls for revealing deposits is. It's not more censorship resistant (at least in terms of getting your deposit finalized), as it's still up to the signers to approve each deposit. From my perspective, the overhead of requiring two transactions (one on BTC and one on Stacks) is a huge downside. Especially if we require proving your deposit on Stacks - that means you have to wait 2 Bitcoin blocks just to get your deposit "pending" (one block to confirm the BTC tx, then 1 block to prove tx inclusion on Stacks). |
Since the extra fee and wait overhead is a bigger "con" from the user experience, then maybe it's safe to conclude this ticket with the "Deposit API" route. |
Gained consensus for the Deposit API option. Next step is to design the Deposit API calls and API call flows. |
Research - Deposit API Service (formerly Revealer API)
This ticket holds the research relating to the sBTC revealer API service and how it impacts sBTC-v1.
Details here: #1
1. Summary
This discussion finalized the need for an external API, referred to as "Signer API", for allowing deposits in sBTC. The implementation details have not been concluded yet.
2. Context & Relevance
The need for a two-phase commit-reveal scheme for sBTC transactions arose to accommodate users to peg-in their BTC from custodial wallets. In the designs and documents that followed this decision, the "Revealer" component acts as an intermediary service for its API to be called by external user-facing applications to accept deposit requests and for stackers/signers to poll for pending addresses and tapscript data.
This discussion revisited this component to redefine and clarify its necessity/purpose for sBTC V1.
3. Research
3.1 Proposed Research Conclusions
For sBTC V1, we want to proceed with an API-only approach for accepting deposits so this service is definitely needed.
To not confuse it with previous commit-reveal discussions, we call this the "Signer API".
We have different options for the design/implementation aspect of this service:
3.1. Having a hosted service maintained by a non-consensus/centralized party
Pros:
Cons:
3.2. Having the ability to register a Signer API on the Stacks chain
Pros:
Cons:
The general agreement is that we don't want the signers to expose public endpoints so we want the external facing API to be separate from the signer binary.
3.2 External Resources
3.3 Areas of Ambiguity
Closing Checklist
The text was updated successfully, but these errors were encountered: