Support for Bitcoin Bech32 SegWit addresses

[rex4539]

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

[mrosseel]

bisq depends on bitcoinj for its wallet/bitcoin transactions, and bitcoinj has no segwit/bech32 support as of today. If it's in bitcoinj, we will support it asap!

[sneurlax]

See bitcoinj/bitcoinj#1441 ... so we will get BIP49 (P2SH-P2WKPH, 3...) addresses before BIP173 (P2WKPH, bc1...) addresses

[ManfredKarrer]

I will close for now to keep GH organized with issues which are subject to be implemented in a reasonable time scope. I mark it as deferred.

[sneurlax]

See sipa/bech32#40 (comment)

[ghost]

@mrosseel: segwit support has been merged into bitcoinj master since june 2017: bitcoinj/bitcoinj#1334

[ManfredKarrer]

Thats not full segwit support. See BitcoinJ mailing list....

[ghost]

@mrosseel: thanks for clarifying; I wasn't aware that the current bitcoinj implementation is not complete, but in my understanding the existing code is enough to generate compatible segwit addresses that start with 3 as can be seen in the unit test at https://github.com/bitcoinj/bitcoinj/blob/segwit/core/src/test/java/org/bitcoinj/core/AddressTest.java#L178 (outdated segwit branch). I don't dominate the topic so I apologize in case if my assumptions are wrong... SamouraiWallet apparently relies on bitcoinj for segwit and they provide segwit support in their android wallet: https://github.com/Samourai-Wallet/samourai-wallet-android

[ManfredKarrer]

SamouraiWallet uses its own fork. I have not followed the details but I am pretty sure that BitcoinJ at the current state is not fully supporting SegWit.

[ghost]

SamouraiWallet uses 'compatible' i.e. non-bech32 segwit addresses which start with 3; this is also the format that ledger and trezor currently support. My understanding is that currently bitcoinj does handle this format, at least I was able to generate that type of addresses with the master or release branch. I assume by incomplete support you mean bech32 support, i.e. addresses that start with bc1 and which are still not widely adopted: https://en.bitcoin.it/wiki/Bech32_adoption

[cbeams]

I will close for now to keep GH organized with issues which are subject to be implemented in a reasonable time scope. I mark it as deferred.

@ManfredKarrer, I'm re-opening this issue. SegWit support is our number one requested feature, and this is the only issue we have to track it. Whether it can be implemented in a reasonable time frame is a matter of whether people step up to help implement it. Having this issue open can help potential contributors understand that we're actively looking for this help.

[cbeams]

Note that we should probably create a new, more general issue / epic around "SegWit support" and do our best to break down what we we think users actually want and need.

[ManfredKarrer]

Andreas Schildbach just completed an important part of the SegWit implementation but it is still not fully complete in BitcoinJ.
Once BitcoinJ has full SegWit support we need to bring our changes up to the current master branch which might have some challenges as I am not aware if BIP 44 is now fully supported (i think not).
But before we invest so much time I would prefer to investigate alternative Bitcoin layers like Neutrino or Bitcoin Core in SPV mode.
Either way we need a dedicated developer for that area....

[cbeams]

Andreas Schildbach just completed an important part of the SegWit implementation but it is still not fully complete in BitcoinJ.

Here is a link to the bitcoinj mailing list post that describes this work: https://groups.google.com/forum/#!topic/bitcoinj/_YG1UHJzE9Y

[Talkless]

Either way we need a dedicated developer for that area....

Quite some time have passed. What's current status of supporting SegWit? The lack of it really demotivates to start using Bisq.

[ManfredKarrer]

We depend on BitcoinJ and it is still not implemented there ;-(. We don't have the resources to implement it in BitcoinJ on our own. Any dev welcome to help here

[Talkless]

We depend on BitcoinJ and it is still not implemented there ;-(.

Aww :( . Maybe it would be possible to crow-fund it somehow? I believe there should be quite a few project, maybe even exchanges, using it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Talkless]

Un-stale, still relevant.

[ManfredKarrer]

Sure we would like to have that but there are no dev resources atm to work on that in forseeable future. BitcoinJ needs to get implemented Segwit. They are working on it but still not finished. We want to keep our GH issues list for those tasks where Bisq devs are actually working. We will for sure not forget about it :-).

[Talkless]

They are working on it

That's good news!

[nopara73]

@ManfredKarrer We would like to also help out regarding bech32 sendability in BitcoinJ:
WalletWasabi/WalletWasabi#951

Does "lack of dev resources" mean lack of funding for a developer to work on it or it's rather lack of right people for the job?

[ManfredKarrer]

@nopara73
We have now with @oscarguindzberg a BitcoinJ developer but there are other high prio tasks we need to work on over the next months. Segwit support in BitcoinJ is in development from Andreas Schildbach, I am not sure how far it is and how much is missing.

Does "lack of dev resources" mean lack of funding for a developer to work on it or it's rather lack of right people for the job?

I would say both, beside @oscarguindzberg I am not aware of any available BitcoinJ developer (who knows the library really well) and we cannot afford atm to fund a second dev in that area. Though as soon the DAO is out and BSQ is successful we might try to find a second dev in that area to speed up development.

[Talkless]

Go away bot, no stale! :)

[wiz]

It seems #2772 is almost ready to merge, can we talk about bech32 support on the next dev call?

[v0l]

In the meantime you can just recover your seed in electrum and send directly to bech32 addresses with that.. Useful if you're going to mix in wasabi or something..

[wiz]

As it seems the Bitcoin wallet will be removed from Bisq as part of the v2 trading protocol, this issue seems like a WONTFIX because you'll be able to use any wallet of your choosing with Bisq.

[Talkless]

@wiz could you elaborate how that would look like in practice?

[wiz]

The details are in the Bisq v2 proposal, but basically you can use any external settlement method you want, modern Bitcoin wallets and on-chain transactions or Lightning off-chain: bisq-network/proposals#118

[Talkless]

@wiz it's all a bit too hard to grasp, and a bit too vague. How buying Bitcoin using some external (let's say Electrum) wallet will actually look like? Will we have to create multisig contracts ourselves, or.. how all this will work? Although, this is kind off topic to this issue...

[wiz]

In Bisq v2, security is implemented using bonds. By using long-term bonds instead of short-term bonds (i.e. security deposits) for each trade, this financially incentivizes everyone to stay honest, while allowing everyone to settle the trades however they want, using whatever wallets they want.

[ghost]

People want SegWit unlike bonds of any kind. Better come out from the developer's box.

[Rav3nPL]

Making v2 is lot of work. Updating Bitcoinj to use segwit (p2sh or native) would really help reduce tx fees.
Internally Bisq should use native segwit (cheaper) and allow users to pay in on p2sh (compatible with any wallet).
bitcoinj have full segwit supprot since 0.15

[schildbach]

Note that bitcoinj 0.15 only has limited support for P2SH-P2WPKH; the focus is on native P2WPKH.

[Rav3nPL]

If we use compatible only to pay into Bisq wallet, we can use native for multisig etc.

[chimp1984]

We don't have a BitcoinJ dev atm (hope @oscarguindzberg comes back soon) so that is why the BitcoinJ 0.15 upgrade is on hold and even then it would require another 2-4 months to get full segwit support in Bisq.

[gustavocoding]

No bech32? Oh my...This is really sad...

[ripcurlx]

No bech32? Oh my...This is really sad...

There was an attempt to upgrade to bitcoinj 0.15, but as long as we don't have a dedicated bitcoinj dev it is just too much risk to upgrade.

[gustavocoding]

So the upgrade would fix it? Does bitcoinj already have full segwit support or more work needed on bitcoinj side?

we don't have a dedicated bitcoinj dev

Do you mean someone who understands BitcoinJ or someone from BitcoinJ project?

[ripcurlx]

So the upgrade would fix it? Does bitcoinj already have full segwit support or more work needed on bitcoinj side?

As far as I remember it would allow bech32 addresses to receive and send funds. Using bitcoinJ segwit implementation within the trade protocol had some limitations as far as I remember.

Do you mean someone who understands BitcoinJ or someone from BitcoinJ project?

Someone who understands BitcoinJ properly and takes over the role maintaining our fork of it: https://github.com/bisq-network/bitcoinj

[ripcurlx]

Just in any case: @oscarguindzberg would you be interested taking over this role again? 😄

[gustavocoding]

takes over the role maintaining our fork

Right, now everything makes sense 😄

Why did you fork it, broadly speaking?

[ripcurlx]

@gustavonalle There lots of commits https://github.com/bisq-network/bitcoinj/commits/bisq_0.14.7 added to our branch, but I don't know exactly anymore which were committed to the public bitcoinj repo afterwards and which didn't. The initial reason why we forked the project was a privacy issue (I think it was about some default dns seeds), but I don't remember anymore exactly. That is one of the reasons why we need a dev focused on bitcoinJ 😜 . Maybe @ManfredKarrer still remembers the origins of our fork.

[gustavocoding]

FYI, this is the diff between bitcoinj 0.14.7 and your fork: bitcoinj/bitcoinj@v0.14.7...bisq-network:bisq_0.14.7

[rex4539]

This has been implemented.