Proposing Bitcoin Addresses for Stacks

Community
#1

Hey Stacks friends!

Like the rest of you, I’m very excited about sBTC and the potential it has to revolutionize both decentralized finance and payments. sBTC makes bitcoin programmable and super fast (like Lightning but without the liquidity problems and complexity). This past week at the Consensus HK event, I had the opportunity to chat with a number of OGs in our community including a couple of our wallets about our bitcoin payments UX and how we present sBTC to users.

There are many challenges in both the bitcoin payments and the bitcoin defi space. Bitcoiners in general have a strong bias against spending or moving their bitcoin. Because of this, it’s important to nail the UX and communications so that it is as low friction and close to what they expect as possible. Other layer 2 payment projects have struggled with UX and we have a real opportunity with sBTC to deliver something game changing for the Bitcoin community.

In my mind, there are three areas around sBTC that still need work to really optimize the experience:

  1. Address format
  2. Payment of transaction fees in sBTC
  3. Communication/UI

In this post, I plan to tackle #1, address format.

Right now, a user that wants to send or receive sBTC is forced to use a Stacks address that looks like something like SP2V0G568F20Q1XCRT43XX8Q32V2DPMMYFHHBD8PP. This is fine if you are an OG Stacks user but confusing to a Bitcoin user who comes to sBTC for the faster blocktimes, access to Bitcoin DeFi and generally a better overall, happier life.

sBTC is layer 2 Bitcoin. It should look and function like Bitcoin, only with more features and better UX and faster because it’s on layer 2. By look and function like Bitcoin I mean sBTC should work with bitcoin addresses and bitcoin QR codes. We shouldn’t make the same mistake Lightning made by trying to push a new set of standards on users.

I propose Stacks return to bitcoin addresses as the standard address format for our network. This would enable wallets to use the same payment/checkout flow, QR code, address, etc as they use to accept base layer bitcoin to accept layer 2 bitcoin (sBTC). All they would need to do is update their backend to check for sBTC at the address.

Large exchanges already support the assumption that an asset can be transferred via multiple networks

How can we do this?

Stacks addresses encode the HASH160 of a public key just the same as both legacy P2KH addresses (start with “1”) and native SegWit P2WPKH addresses (start with “bc1”).

I put together a quick rust proof of concept that does this.

What changes are needed to Stacks?

This can be done at the developer tool/library/application level without consensus changes.

  • All user-facing Stacks addresses can be displayed as bitcoin native segwit (P2WPKH) addresses.
  • Developer tools can be updated to accept either stacks addresses or supported Bitcoin addresses (P2PKH and P2WPKH) and “resolve” Bitcoin addresses back to their corresponding Stacks addresses before building transactions, interacting with contracts, etc.

What happens when a user sends sBTC to an address of a user whose wallet doesn’t (yet) support sBTC? How can we prevent this?

We could do something like add an extension to the Bitcoin URI standard (BIP-21) (perhaps via the extensibility mechanism in BIP-70 that indicates that a payment QR code supports receiving sBTC (and other assets) via the Stacks network. If a QR code doesn’t have this flag, wallets could warn users that the receiving party might not be able to receive the sBTC.

What about derivation paths?

I’m intentionally ignoring this in this discussion because I see it as an implementation detail.

What are the next steps?

I’m really curious about what everyone thinks. If there’s interest, we can put together a SIP.

6 Likes
#2

As an aside, I’m in the slightly embarrassing situation of being one of the people who advocated for a different Stacks address format in the first place. And now I’m advocating for the opposite position. You can read the original discussion here:

At the time, there was a desire to have different address types for different asset types. The idea was that it would prevent users from accidentally sending assets of one type to an address where they might not be able to retrieve them.

The industry led by the rise of Ethereum and other multi-token chains, moved in another direction and now it’s common practice for a single address type to be able to hold any asset type. We see this now too on Bitcoin with ordinals and runes.

2 Likes
#3

I like your idea and what you suggest was exactly what came to my mind too when I read the title.

If I send someone sBTC and it does not show up in their pure Bitcoin wallet app, all they would need to do is connect their hardware device to an “sBTC-aware” wallet app.

2 Likes
#4

I’m a Bitcoiner since 2011 and fit the “profile” of such as described here. I’m also new to Stacks - just one month in fact - and was drawn into it precisely because of the sBTC launch (I converted some bitcoin to sBTC in the first minting).

I don’t understand the technicalities of what’s being suggested or how feasible it is, but the idea certainly appeals to my “bitcoin-centric” brain.

3 Likes
#5

Ya, I see this making sense because of the public key in the Stacks address that could be used in a Bitcoin address (I believe for P2PKH, but I wonder if it’s possible to wrap into a Taproot compatible one). A lot of the heavy work would be on the side of the wallet and make sure they’re aware of it I believe.

3 Likes
#6

Concept ACK (in the Bitcoin core repo, to ACK is to agree with the proposal), from users perspective.

If a user only needs to interact with a BTC address, will reduce massive frictions. Cannot see much downside tbh.

2 Likes
#7

Thanks for writing this up! This is a great proposal. It would improve wallet and onboarding UX a lot.

I think this would require some changes to the Clarity side of things. The principal type will need to support Bitcoin addresses as well. Maybe one of the core devs can chime in on this.

5 Likes
#8

Having the same address type for different asset types prevents accidentally losing assets. This removes friction, “merges” ecosystems, and potentially equips Bitcoin addresses with BNS?

#9

I personally really like this idea very much, but what happens to Stacks in that case? Can the asset be used for gas fees? Or only sBTC be used?

Apologies if this second part doesn’t quite fit here, but it’s on my mind.

I see the benefit unlocking the Bitcoin Economy, perhaps this is due to my limited understanding sBTC will be used for DeFI not so much for purchases as many view it as NGU tech/asset. I can certainly see STX being the spendable asset though, how do we promote this part of the offering?

1 Like
#10

I made a prototype wallet app that allows you to use sBTC with native segwit bitcoin addresses instead of Stacks addresses. I posted a video demonstrating its usage on X:

https://x.com/larrysalibra/status/1895787738877841638 (or alternatively on youtube)

Source code is available on github
You can try out the app here (desktop chrome with xverse or leather extensions only): https://sbtc-with-btc-addresses.vercel.app/

One way to approach this in the short term is to make stacks addresses an implementation detail. Show users native segwit bitcoin addresses and convert them to stacks addresses “under the hood” when making layer 2 transactions.

Exactly. The world we want to end up in is that every bitcoin wallet checks addresses in its wallet for assets on both layer 1 and layer 2.

Yes! The bitcoin ecosystem is one of layers.

There’s a more detailed thread about this. Personally I think fees will need to be paid in sBTC to make the user experience ideal. There are a number of ways to do this. One way is to transparently convert the sBTC to STX “under the hood” in some form seems to be the way to do it.

1 Like
#11

Think we can add this proposal to the product roadmap

#12

so if i understand the intent here - rather than ask wallet (etc) maintainers to provide this address translation, you’re suggesting this be a native feature of the stacks blockchain?

it’s an interesting idea to be sure, but the devil is in the details - there are a lot of codepaths/rpc endpoints that are predicated on the current stx address format (i remember the original suggestion, so lol that we’re here now!).

from a code standpoint, i don’t see this as something difficult to achieve - but it might break existing third party applications that rely on the rpc responding specifically.
maybe the code changes could determine first if the address format is stx or btc, and then respond accordingly?

i’m thinking of something like this specifically: stacks-core/docs/rpc/openapi.yaml at master · stacks-network/stacks-core · GitHub

where if you want the balance of stx tokens, but you supply a btc address it may not return the value you’re expecting.

i like the idea though - i’d be in favor of starting a SIP sooner rather than later, particularly since it’s not consensus breaking.

1 Like
#14

This is a fantastic initiative from Larry.

From a user’s perspective, the fewer steps I need to take and understand, the easier it is for me to use a product—Larry’s proposal directly addresses this. Everyone already has a Bitcoin address, so let’s look at some key facts:

:small_blue_diamond: Bitcoin Owners: 106 million
:small_blue_diamond: Daily Bitcoin Users: 400,000
:small_blue_diamond: Bitcoin Wallets: 200 million
:small_blue_diamond: Bitcoin Traders: 53 million
:small_blue_diamond: Daily Bitcoin Transactions: 270,000
:small_blue_diamond: Americans aware of Bitcoin: 89%
:small_blue_diamond: Americans who own Bitcoin: 22%

Now, imagine the impact if we enable Bitcoin-native SegWit addresses (bc1) for sBTC—transactions would feel seamless and familiar.

And if we talk about market potential for STX… well, I’ll leave that to your imagination.

#15

Great proposal @larry, efforts working towards better interoperability are important.

I am concerned about the non-standard derivation path usage this would entail, though. These bitcoin addresses belong to the m/44'/5757' chain.

Hardware wallets—at least Ledger—lock down their apps to only sign on the respective SLIP-0044 defined paths. This proposal would either need to accept that limitation, or find ways around it. Whether that’s lobbying hw wallet manufacturers to make exceptions, or publishing new apps that handle multi-chain concerns etc

1 Like
#16

Technically, it is just a different encoding. We don’t need the public key. All addresses can be converted. However, stacks only has two types singlesig and multisig. While bitcoin has legacy, segwit, etc . So we need to agree whichbbitcoin address type should be map to the single sig stacks address.

With stacking pool, we had the confusing that some pools used legacy, some used segwit.

Currently, it makes sense to use native segwit. However, bitcoin users with legacy addresses are left out.

With the mapping, we are loosing a portion of the verifiability of the transactions and smart contracts if we rely on tools that transcode addresses in transactions and contracts for us. Next step from transcoding would be compilers.

We are also creating some confusion about utxo models and account models. While my bitcoin address has been replaced by a change address on bitcoin, my bitcoin address on stacks is still the same. A solution could be to use smart wallets/account abstraction on stacks (some WIP here Add sponsored sbtc transfer by friedger · Pull Request #25 · friedger/Smart-Wallet · GitHub).
Users would need to learn what bc1234.. .amm-dao mean, what smart contracts on bitcoin L2 are.

1 Like