SIP-03X: BTC addresses for Stacks transactions #219
Conversation
|
|
||
| ## **Introduction** | ||
|
|
||
| sBTC is designed to make Bitcoin programmable and enable faster transactions, positioning it as a significant component in the growth of decentralized finance and payments on Bitcoin. However, the current Stacks-specific address format presents a barrier to adoption for existing Bitcoin users, who are accustomed to Bitcoin's native address formats. Building wallets to handle both stacks addresses and bitcoin addresses currently requires duplication of user interface components and send/receive user flows. The resulting user interfaces can lead to confusion and a less intuitive user experience. Other Layer 2 solutions have faced similar UX challenges. The core problem this SIP addresses is the user experience friction caused by requiring Bitcoin users to use a non-Bitcoin address format when interacting with sBTC. |
There was a problem hiding this comment.
Formatting: please use consistent capitalization ("bitcoin," "stacks")
|
|
||
| sBTC is designed to make Bitcoin programmable and enable faster transactions, positioning it as a significant component in the growth of decentralized finance and payments on Bitcoin. However, the current Stacks-specific address format presents a barrier to adoption for existing Bitcoin users, who are accustomed to Bitcoin's native address formats. Building wallets to handle both stacks addresses and bitcoin addresses currently requires duplication of user interface components and send/receive user flows. The resulting user interfaces can lead to confusion and a less intuitive user experience. Other Layer 2 solutions have faced similar UX challenges. The core problem this SIP addresses is the user experience friction caused by requiring Bitcoin users to use a non-Bitcoin address format when interacting with sBTC. | ||
|
|
||
| **The proposal is to enable the use of standard Bitcoin addresses (legacy P2PKH and native SegWit P2WPKH) for sending and receiving sBTC and other Stacks-based assets.** This would allow sBTC to look and function more like Bitcoin from a user's perspective, leveraging existing user familiarity and tools, such as bitcoin payment QR codes and payment flows. The goal is to make interacting with sBTC as seamless as interacting with Bitcoin on the base layer, thereby encouraging broader adoption. |
There was a problem hiding this comment.
If Stacks represented its addresses as Bitcoin addresses, wouldn't it be more likely that a user accidentally sends some BTC to a Stacks recipient? I think the counterargument to keeping the status quo is that Stacks has a different address encoding alphabet in order to make this a lot less likely. You can tell on inspection that a Stacks address is not a Bitcoin address (and vice versa), because Bitcoin addresses don't start with S and use base58 instead of Crockford-32.
|
|
||
| This SIP will be considered activated once the following conditions are met: | ||
|
|
||
| 1. **Updated Libraries**: Key Stacks developer libraries (e.g., Stacks.js or its successors) are updated to: |
There was a problem hiding this comment.
We should probably commit to a list of these, so there can be a checklist for activation.
| * Accept P2PKH and P2WPKH Bitcoin addresses as input for transaction recipients. | ||
| * Provide utility functions to convert Stacks addresses to P2WPKH Bitcoin addresses for display purposes. | ||
| * Provide utility functions to resolve P2PKH/P2WPKH Bitcoin addresses back to Stacks addresses. | ||
| 2. **Wallet Adoption**: At least two major Stacks wallets have implemented support for: |
There was a problem hiding this comment.
Can you specify the set from which these two are drawn?
| * Displaying user account addresses in P2WPKH Bitcoin format. | ||
| * Allowing users to send sBTC (and other Stacks assets) to P2PKH and P2WPKH Bitcoin addresses. | ||
| * Implementing a warning mechanism (as described in the Specification section or similar) when sending sBTC to a Bitcoin address if sBTC support by the recipient cannot be confirmed. | ||
| 3. **Explorer Adoption**: At least one major Stacks block explorer is updated to: |
There was a problem hiding this comment.
Is there more than one "major" Stacks block explorer besides the one Hiro runs? Also, can the set of "major" explorers be enumerated?
There was a problem hiding this comment.
One of my favorite fwiw: https://explorer.stxer.xyz/
| 3. **Explorer Adoption**: At least one major Stacks block explorer is updated to: | ||
| * Allow searching by P2PKH/P2WPKH Bitcoin addresses. | ||
| * Display account information using the P2WPKH Bitcoin address format as an option. | ||
| 4. **Community Endorsement**: The proposal receives positive feedback and endorsement from the Stacks developer community and key stakeholders, indicated by discussion on the Stacks forum and other relevant channels. |
There was a problem hiding this comment.
How might we measure this?
|
I believe this SIP is not solving a real problem and is likely to create new problems we do not want. First of all I expect it will lead to confusion. In addition my concern is that it creates work for the a wallet team (or teams) to adopt but it doesn't create enough value compared to other projects a wallet team can choose from. That at least is my impression discussing this with the Leather team and working support there. This is however my personal view. You could also say the burden falls heavily on the wallet team (and perhaps the explorer team) with a very limited advantage for users. I do see that Ken from Xverse is more positive about this but I feel that it won't "improve onboarding UX a lot" as he believes it will. https://forum.stacks.org/t/sip-03x-btc-addresses-for-stacks-transactions-219/17910/7 I believe quite the opposite. The problems it creates.
Another way to look at it: I think the problem is that Stacks addresses are not yet recognized by users as being "bitcoin addresses", there are currently four types of common bitcoin address, legacy, wrapped segwit, native segwit and taproot. "Bitcoin addresses" that support Stacks assets start with SP.../SM... and are encoded differently compared to the better known types. What about a BIP process to get Stacks addresses recognized as "Bitcoin (L2) addresses"? I understand that this is meant as a stepping stone to all Stacks addresses being bitcoin address at their core and only that. Instead of the optionality about which address encoding to show/use as proposed by this SIP. I think the real value comes from having a single address as suggested by Friedger here https://forum.stacks.org/t/sip-03x-btc-addresses-for-stacks-transactions-219/17910/18 and this initial idea by Ken https://forum.stacks.org/t/rfc-standardizing-on-bitcoin-derivation-paths/13394. |
4 participants
This PR adds a SIP that: