Add BTC wallet support - Githubissues

markmhendrickson commented 3 years ago

Allow users can access the BTC stored with the same Secret Key.

This was requested by the PlanBetter team, which currently sends BTC to the key's underlying address but has to direct users to Electrum to withdraw the funds.

This could be helpful for Stacking applications in general for the creation of a consolidated UX around BTC, STX and Stacks-based apps. This doesn't have to be a separate wallet in the UX per se but rather an additional assets balance alongside chain-native assets.

andresgalante commented 3 years ago

Do we have anyone asking for this feature?

2snEM6 commented 3 years ago

In my opinion, there are many ways on why this feature is positive for the Stacks Wallet Web and also for the Stacks Ecosystem.

It helps bring STX and BTC tokens even closer, under the same interface. Users could have BTC within the same wallet classified as an additional asset. (And maybe in the future even swap them using @friedger new decentralized btc-stx swaps)
Stacking pools that reencode STX addresses into BTC addresses and send stacking payouts to those, would mean stackers would see BTC payouts directly in their wallets, without having to use external explorers, or wallets, making the user experience smoother and also contained within the same domain.

friedger commented 3 years ago

Is this about read-only access to BTC wallets or also to create and sign txs? I would imagine that a full-fledged BTC wallet is out of scope.

markmhendrickson commented 3 years ago

The PlanBetter team requested this when we met with them recently, and I believe @xanbots has requested this in the past (though my impression is that it's less relevant to Daemon plans these days).

My impression in both cases as well was that a full-fledge BTC wallet was desired so users – either Stacking pool users or mining pool users in these respective cases – could manage STX and BTC with sends and receives with one holistic solution / in one place with the same underlying key.

pors commented 2 years ago

My impression in both cases as well was that a full-fledge BTC wallet was desired so users – either Stacking pool users or mining pool users in these respective cases – could manage STX and BTC with sends and receives with one holistic solution / in one place with the same underlying key.

What is meant here with the same underlying key? To use the same HD wallet phrase for both STX and BTC?

markmhendrickson commented 2 years ago

What is meant here with the same underlying key? To use the same HD wallet phrase for both STX and BTC?

@pors Yep the same phrase for both types of holdings

markmhendrickson commented 2 years ago

@xanbots indicated yesterday that this is still indeed relevant to their plans at Daemon

markmhendrickson commented 2 years ago

@beguene want to post a consolidated version of your tech spec here as a comment, migrating it from Notion for greater transparency and easier reference as we start work on this?

landitus commented 2 years ago

Last week we had an initial project kick-off where we brainstormed around the most basic ways to integrate Bitcoin into the wallet. During the session we touched upon displaying BTC/STX addresses, viewing balances/activity, sending and receiving BTC and how to handle network selection for both Bitcoin and Stacks networks. The network part seems the more tricky, since there are 2 networks to choose from and there could be some confusion around combining testnet and mainnet networks from both blockchains at the same time.

There will be mockups coming exploring these ideas soon:

Figma

2snEM6 commented 2 years ago

This is great news! One thing that would be interesting to consider is the capability for a client application to interact with the wallet via Stacks.js, in order to trigger a bitcoin transaction programatically.

I foresee two different ways:

The client application uses a programmatic interface to signal the Stacks Web Wallet to spend BTC => the Stacks Web Wallet opens the Send Bitcoin screen with pre-filled details (address, amount, etc).
The client application uses a programmatic interface to signal the Stacks Web Wallet to spend BTC => the Stacks Web Wallet opens the Send Bitcoin application but it is up to the user to choose the amount, the recipient address, etc.

The client application uses a programmatic interface to signal the Stacks Web Wallet to spend BTC => the Stacks Web Wallet opens the Send Bitcoin screen with pre-filled details (address, amount, etc).

This approach opens up many possibilities, for instance to stacking pools that encode Bitcoin addresses from Stacks addresses and are already aware of the constraints users might have when building a Bitcoin transaction since they handle it in app: address, amount, or even fees. However the Stacks Web Wallet would need to verify this data before prompting the user to sign the transaction.

The client application uses a programmatic interface to signal the Stacks Web Wallet to spend BTC => the Stacks Web Wallet opens the Send Bitcoin application but it is up to the user to choose the amount, the recipient address, etc.

This other approach is simpler and more constrained, since the Stacks Web Wallet would be the only responsible of allowing the user to select amount, address, etc. As it is more constrained, use cases such as the above would cause worse UX, IMO.

markmhendrickson commented 2 years ago

Some exploratory designs are now available here in a Figma prototype.