Allow xpub/zpub import and usage for withdrawals #6726
Replies: 3 comments 10 replies
|
Could really use an xpub or a zpub, here is an example zpub exported from Passport:
|
|
One question around this: is it possible to even use an imported xpub/zpub to send funds directly from trades into? i.e. bypass the Bisq wallet entirely and withdraw directly to xpub/zpub when a trade is completed and funds are sent out of the 2-of-2 multisig escrow. |
|
This is the killer feature for me, It'd save an insane amount of transaction fees over time. |
Not sure if this would be possible or not. But IMHO with the current trade protocol in Bisq it would not be advisable from the perspective of making it harder to provide users with effective support when things go wrong in the trade process. The reason for this is sometimes Bisq users need assistance from a mediator to create manual payout or otherwise interact with their wallet to some degree (this can be due to bug, Tor issue at time of trade, hardware failure etc). For example it might be necessary to the user sign a message to prove ownership of an address in the case of an off Bisq reimbursement being needed. Bisq's bitcoin wallet implementation has the functionality to allow users to interact with it. Users can press 'Ctrl' + 'G' to open the 'Bisq support tool' when running Bisq to access additional wallet functionality. This can be done easily enough if everyone is using the same wallet instance (Bisq). Things like providing support to users signing a message to prove ownership of an address might a problem if the user has to do this on another wallet than Bisq. Especially if you have lots of users all choosing different wallets with different functionalities. |
|
@pazza83 what's the format bisq uses for message signing? I'd like to tinker around with it on passport to see if we can meet all the needs to get this feature working. Is there any other functionality of the bisq wallet I should try to replicate to make this possible? |
|
Bisq uses bitcoinj for it's wallet implementation. Trades are funded by a 2-of-2 multisig which acts as an escrow until the trade paid out. There is also a time lock function that pays out to an addresses created by both buyer and seller at the time of the trade using information provided by the Bisq DAO nodes that ensures the payout addresses are the same for both buyer and seller. Bisq will eventually be replaced by Bisq 2. This is in development and the wallet integration is an open question at the moment. I think efforts to get a feature such as the above to be successful it might be better to look towards Bisq 2 than try and change Bisq 1 which will end up being retired. See here for issues / discussion on the topic: |
|
XPUBs/YPUBs/ZPUBs are not that well suited to being used in applications other than the wallet itself. Address re-use more likely when the same XPUBs are used for different purposes. |
|
I suppose you can't prevent all cases of re-use, but Bisq simply checking the xpub addresses for funds before selecting them would rule out almost every case of re-use, would it not? The other main prevention method would be to recommend using a new account just for Bisq in the external wallet, as we'd recommend anyways on something like Passport. That way you wouldn't be risking address re-use at all as you'd be using it only for Bisq withdrawals. Could also do the same with most software wallets like Sparrow etc. |
|
I don't know the Bisq withdrawal process well enough but I'd prefer to see a dedicated payment "tunnel" as is achieved with BIP47 over using a deposit XPUB for example. Generating fresh addresses is awkward UX but it's preferable to unintentional address re-use. |
|
Separate implementation of BIP 47 for withdrawals would also be fantastic, but would rule out cold storage entirely which is a core point for this discussion. Thoughts on simply using a new account for your Bisq x/y/zpub as I mentioned above? |
|
Having Bisq checking addresses would be necessary but if this is for a deposit XPUB, you risk generating an address on Envoy and due to the asynchronous nature of these processes ending up with deposits to addresses already used by Bisq or, of course, during the time it takes to complete a trade. Not sure why cold storage would be specifically excluded with BIP47 - the tunnel XPUB can be derived from cold if this user flow is required. I don't think a Bisq to cold storage workflow is that important. It's better to encourage receive, mix and spend or save. As for a specific account for Bisq - this is redundant for saving the extra step. The ideal situation here is to have UTXOs that can be brought together in a single transaction with your other deposit XPUB UTXOs. |
|
Good points! For BIP 47 it would definitely be a painful UX flow for HWWs, but is doable. For buy>mix>spend/save that's an excellent point, would be a good reason to use an xpub for the deposit account in Sparrow and then use "mix to" for getting to cold. Definitely understand the risks of address re-use but the changes are extremely small if Bisq just checks for usage of addresses on-chain before using them. Especially if Bisq checked right before sending funds when a trade closes and not when a trade is initiated. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
One feature that would be great to see for Bisq would be enabling users to withdraw directly to a provided xpub or zpub, both removing the need for manually entering a withdrawal address and greatly simplifying withdrawals straight to cold storage devices like Passport.
Ideally this would allow you to import an xpub via either a file, copy + paste, or via a QR code containing the necessary information. Allowing a user to name or describe the xpub account would be excellent as well. Once imported, ideally a user would be able to easily select that xpub when withdrawing funds and have Bisq automatically use the first unused address to withdraw to.
All reactions