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!
See https://github.com/bitcoinj/bitcoinj/pull/1441 ... so we will get BIP49 (P2SH-P2WKPH, 3...) addresses before BIP173 (P2WKPH, bc1...) addresses
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.
See https://github.com/sipa/bech32/pull/40#issuecomment-365921271
@mrosseel: segwit support has been merged into bitcoinj master since june 2017: https://github.com/bitcoinj/bitcoinj/pull/1334
Thats not full segwit support. See BitcoinJ mailing list....
@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
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.
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
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.
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.
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....
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
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.
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
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.
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.
Un-stale, still relevant.
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 :-).
They are working on it
That's good news!
@ManfredKarrer We would like to also help out regarding bech32 sendability in BitcoinJ:
https://github.com/zkSNACKs/WalletWasabi/issues/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?
@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.
Just to let you know we are happy to contribute with funds and developers (me, @lontivero and @molnard) towards bech32 sendability if it can be broken away from the fully featured segwit integration work.
Unfortunately we are not Java devs, although we all worked in Java here and there and we are well-skilled in Bitcoin development, but I'm afraid we would still need a bit of babysitting to get started. If you are willing to lead us in this work then we're here, or if you can find somebody to do it, then I'd fund it from my own pocket.
@ManfredKarrer I offered @schildbach help with bech32 sendability and he updated me that " The "send to bech32" is in there, [bitcoinj master branch] since over a year now." So I tested Bisq, but it cannot send to bech32. I am confused. What is going on here?

@nopara73 Thanks for your support and offer!
It would be BitcoinJ work, I am not expert in that either but @oscarguindzberg is. We are using the latest release which is quite old (2 years). As master is not production ready and not tested we did not want to take the risk to move to master. But it is on our roadmap, but I fear it will take a few months until we get there as many other high prio tasks need to be completed first.
Hey guys, you might be interested in this PR: https://github.com/bitcoinj/bitcoinj/pull/1563
If you help testing, I'll be able to merge sooner and release bitcoinj 0.15 after that.
@schildbach I would like to help with the test/review. I downloaded the PR and run the tests but I get 5889 failing tests (I get a similar number if I run the test suite in the master branch).
Here is the terminal output (gradle build --stacktrace)
org.bitcoinj.utils.MonetaryFormatTest test results
21534 tests completed, 5889 failed, 18 skipped
:core:test FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':core:test'.
> There were failing tests. See the report at: file:///home/lontivero/GitHub/bitcoinj/core/build/reports/tests/test/index.html
* Try:
Run with --info or --debug option to get more log output.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':core:test'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:84)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:113)
at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
at org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:256)
at org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:253)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:175)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:119)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:102)
at org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:71)
at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:31)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:47)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
Caused by: org.gradle.api.GradleException: There were failing tests. See the report at: file:///home/lontivero/GitHub/bitcoinj/core/build/reports/tests/test/index.html
at org.gradle.api.tasks.testing.Test.handleTestFailures(Test.java:1252)
at org.gradle.api.tasks.testing.Test.executeTests(Test.java:664)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.doExecute(DefaultTaskClassInfoStore.java:141)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:134)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:123)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:632)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:615)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:95)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:76)
... 70 more
BUILD FAILED
Total time: 1 mins 32.446 secs
Here is one of the failing tests results:
org.bitcoinj.utils.MonetaryFormatTest test results
<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="org.bitcoinj.utils.MonetaryFormatTest" tests="27" skipped="0" failures="1" errors="0" timestamp="2019-02-02T23:00:14" hostname="lontivero-MAX-G5" time="0.006">
<properties/>
<testcase name="testDecimalMark" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="standardCodes" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="customCode" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="mBtcRounding" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="testSigns" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="noCode" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidMultipleDecimalMarks" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidPositiveSign" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidNegativeSign" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="codeOrientation" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="uBtcRounding" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="codeSeparator" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="fiat" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidWhitespaceSign" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parse" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.003"/>
<testcase name="btcRounding" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.001"/>
<testcase name="repeatOptionalDecimals" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidHugeNegativeNumber" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidDecimalMark" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidWhitespaceAfter" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidHugeNumber" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="testGrouping" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="testDigits" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="missingCode" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="withLocale" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0">
<failure message="org.junit.ComparisonFailure: expected:<-[啷оエ.啷┼オ啷ガ啷ギ啷ウ]> but was:<-[12.34567890]>" type="org.junit.ComparisonFailure">org.junit.ComparisonFailure: expected:<-[啷оエ.啷┼オ啷ガ啷ギ啷ウ]> but was:<-[12.34567890]>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.bitcoinj.utils.MonetaryFormatTest.withLocale(MonetaryFormatTest.java:254)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy3.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:129)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
</failure>
</testcase>
<testcase name="parseInvalidEmpty" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<testcase name="parseInvalidWhitespaceBefore" classname="org.bitcoinj.utils.MonetaryFormatTest" time="0.0"/>
<system-out><![CDATA[]]></system-out>
<system-err><![CDATA[]]></system-err>
</testsuite>
It is clearly something that happens only in my machine. Could you give me a clue? I am not java developer.
@lontivero The one test you posted details about is a test for Devanagari. Seems lke your JDK doesn't have all locales. Can you post the output of java -version?
Generally please report bugs on bitcoinj on our bugtracker at https://github.com/bitcoinj/bitcoinj
Hey guys, you might be interested in this PR: bitcoinj/bitcoinj#1563
Have just seen a few minutes before! Great news!
If you help testing, I'll be able to merge sooner and release bitcoinj 0.15 after that.
I will ask @oscarguindzberg to partizipate. His wife gave birth recently so he is not 100% available atm...
$ java -version
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode)
If this is not the right version please let me know how it should look like. I can see in the travis.yml that the oraclejdk is used, should I use that one or the openjdk is okay? Thx.
@lontivero I think you use wrong Java version. From bitcoinj Readme.md:
Java 7 for the core modules, Java 8 for everything else
Mine:
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
I did not install 7, because that seemed to be taken down from oracle website, but it still works only with 8.
I just fixed this by ignoring locale-sensitive tests. Please update your branches.
That's a lot of tests:

Actually just 9 tests. Multiplied by the number of locales installed in your JDK.
Hey, happy this is moving forward.
@lontivero I suggest you to use jdk8 to build bitcoinj. Very long discussion about it here: https://github.com/bisq-network/bitcoinj/issues/17
Created a PR for using bitcoinj 0.15 in bisq https://github.com/bisq-network/bisq/pull/2772.
Once that is merged, we can work on this issue.
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.
Go away bot, no stale! :)
It seems #2772 is almost ready to merge, can we talk about bech32 support on the next dev call?
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..
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.
@wiz could you elaborate how that would look like in practice?
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: https://github.com/bisq-network/proposals/issues/118
@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...
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.
People want SegWit unlike bonds of any kind. Better come out from the developer's box.
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
Note that bitcoinj 0.15 only has limited support for P2SH-P2WPKH; the focus is on native P2WPKH.
If we use compatible only to pay into Bisq wallet, we can use native for multisig etc.
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.
No bech32? Oh my...This is really sad...
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.
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?
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
Just in any case: @oscarguindzberg would you be interested taking over this role again? 馃槃
takes over the role maintaining our fork
Right, now everything makes sense :smile:
Why did you fork it, broadly speaking?
@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.
FYI, this is the diff between bitcoinj 0.14.7 and your fork: https://github.com/bitcoinj/bitcoinj/compare/v0.14.7...bisq-network:bisq_0.14.7
Most helpful comment
Created a PR for using bitcoinj 0.15 in bisq https://github.com/bisq-network/bisq/pull/2772.
Once that is merged, we can work on this issue.