I get your point, but there’s a reason other Bitcoin L2s like Liquid (LBTC) and Rootstock (RBTC) - not to mention wrapped Bitcoin (WBTC) - use identifiers with their token tickers, and that’s to prevent confusion when looking at coins on exchanges or apps like CoinMarketCap etc.
Beyond just the label, at the root of such confusion would be the address system itself. Each chain uses completely different addressing systems. Now, if Stacks was able to somehow enable Segwit Bitcoin address format - for funds both in and out - then that would certainly help.
That doesn’t prevent confusion, it increases it by increasing cognitive load.
Users have to know what these different tokens are. If they all are 100% interchangable/swappable assets then it would be more simple to call them all the same thing (same name). All exchanges and apps should endeavor to hide complexities that do not matter to users.
BTC on the Rootstock network (RBTC) and BTC on the Ethereum network (WBTC) or BTC on the Stacks network (sBTC)… they are all BTC and only the network where they reside is the difference. It would be easier for users to only have to understand and distiguish WHERE the BTC is going-to/came-from/resides-on… which network/blockchain. This is how USDT is handled and it seems it could be a good way to handle BTC “flavors” as well.
I see your point. So I guess the difference between these versions of bitcoin would be obvious when you came to deposit or withdraw, and were asked to choose which blockchain you want or need to use - as it is with USDt.
Thanks to everyone who joined the panel to discuss, give feedback, ask questions, and learn more about this SIP proposal.
-Thanks Haddy for being the coordinator “SIP Deputy” to help make it happen.
-Thanks Larry for taking his valuable time to creating this proposal to make Stacks even better, and feels more like operating on Bitcoin.
Next Step:
-Please continue to feedback & discuss about this proposal.
-Haddy will work with SIP author Larry to understand how he’d like to move the idea forward and provide support where possible.
Just wanted to post a quick status update for the community.
I’ve reached out to the wallets and some of the core team to directly gauge their interest, support and initial thoughts on this proposal. Everyone is generally interested in at least exploring this change. Directionally, it seems that it makes sense start with a initial proposal that is limited in scope such that it is something can be shipped without depending on getting changing into stacks-core.
As a next step, I’ll put together a draft SIP and then loop in authors from the ecosystem wallets and anyone else who is interested in contributing. I’ll post more in this thread when we have something.
Thanks so much for @Haddy for his support in moving this initiative forward!
Awesome! Excited to see this develop. I think it makes a LOT of sense to utilize Bitcoin addresses for Stacks. It aligns Stacks more directly with Bitcoin and helps abstract away the perception of being on different chains.
This seems like a step in the right direction, reminds me of a recent experience getting sBTC via bitflow in which the whole transaction and experience were neither straightforward or simple, it felt a bit misleading actually, nothing like using btc, and if regular users such as myself are to feel excited about sBTC and use it frequently then we definitely need smooth, effortless transactions that give a native-like feeling
Hi Larry, got some questions from today’s SIP call as we were talking about your SIP proposal, would you be able to share with the community some thoughts around this?
I totally support this proposal, however, I am wondering if there is an even lower hanging fruit which could pay some dividends immediately.
Based on your proof of concept, can I get the Stacks address that will be used in the same account for Xverse/Leather for an existing bc1p or bc1q address?
I see that we can go from STX to Segwit, but I am not sure if 1) can do the reverse and 2) if we do will they actually match in the current wallets.
Could you clarify this?
Goal is to identify most active Ordinals Enjoyoors through on-chain data then airdrop them an Ordinal that tells them they have a claim on STX. Or otherwise just airdrop them something on STX they will see in the same account on those wallets.
We can convert in both directions: Stacks address to Native Segwit address and Native Segwit to Stacks address.
If you take a bitcoin address from leather or xverse and convert it to a stacks address, it will only match the stacks address in current wallets if the wallets used the same derivation path to derive the stacks address as it used to derive the bitcoin address.
I believe that both xverse and leather use the bitcoin cointype derivation path for bitcoin addresses and the stacks cointype derivation path for stacks address.
If this is still the case, then without changes to the wallets, users won’t be able to automatically access them.
With small software changes, wallets could access such an airdrop. The main challenge (from what I’ve heard from wallet makers) is that Ledger prevents Ledger apps from accessing derivation paths for other coins. If one had such a wallet secured by ledger, the stacks ledger update would need to be updated so that it access the bitcoin coin type derivation path.
Correct.
Coordination is challenging but I don’t think we need every wallet onboard at all. I suspect many of the challenges can be mitigated unilaterally through wallet-side UI/UX. Working on a prototype that I hope will demonstrate this. Looking to have something to share around Bitcoin Asia (this coming week).
Initially not at all. Even if stacks were to totally switch to bitcoin address across the stack (ha!) and ecosystem including stacks-core, data aggregators and indexers could still get the same information separately for the stacks ecosystem by only including data collected from stacks nodes and apis. This data wouldn’t have any information about activity using the same bitcoin address on different layers or networks.
tripnmonkey: “How will impact backend infrastructure like Chainhooks?”
The initally wallet-only shouldn’t affect chainhooks, those such services could choose to also accept bitcoin addresses in their apis anywhere they accept stacks addresses. If that would lead to any confusion as to which layer (BTC L1 or STX L2) they should be interacting with, they could add a parameter to clarify that.
tripnmonkey: “How will this change impact existing apps that may be built around STX Addresses? Sites like Bitflow, Velar, Hiro Explorer,
Hermetica, Zest, etc?”
It depends on how they interact with users and addresses. If all of their addresses come via programmatic wallet interactions, wallets could automatically provide them with legacy stx addresses so that no changes are need. If they are asking for users to manually input addresses by typing or copy and pasting, they could either do nothing and expect users to continue to provide stx addresses or they could update their input fields to accept both and translate back to stx address under the hood.
If sBTC adopts Bitcoin native SegWit addresses, how can we prevent confusion or accidental loss when users send sBTC to a Bitcoin wallet that doesn’t yet support sBTC? Would wallet-level safeguards (like BIP-21 extensions) be enough?
