Add contributions you have delivered and roles you have performed here as new rows in the table below. Role line-items should include an asterisk (*) in the team column.
Our users are still protected because we connect to IpV4 addresses through Tor. This improves connectivity because Bitcoin Core creates an ephemeral onion service on each startup.
bisq: Migrate Socks5SeedOnionDiscovery to BitcoinCoreSeedListDiscovery
Our Socks5SeedOnionDiscovery contains deprecated Tor V2 onion addresses that are not supported anymore. BitcoinCoreSeedListDiscovery contains Tor V3 addresses that are shipped with Bitcoin Core.
The BisqTransactionSigner signs the inputs of a transaction after the given offset using the LocalOffsetTransactionSigner. The LocalOffsetTransactionSigner is identical to BitcoinJ's LocalTransactionSigner. The only difference is that the LocalOffsetTransactionSigner accepts an offset in its constructor. All inputs below this offset are skipped during signing.
This is needed for Bisq's BSQ implementation because the mining fees of BSQ transactions come from Bisq's BTC wallet. BitcoinJ's LocalTransactionSigner expects all inputs to be part of the same wallet.
The bisq.java-integration-tests plugin creates an integrationTest source set that depends on JUnit. The source set inherits the main source set's compile classpath, runtime classpath, and the implementation's source set configuration and runtimeOnly configuration.
First, the sendBsq test creates one BTC and two BSQ wallets. Afterward, it funds the BTC and one BSQ wallet with 1 BTC. Next, the funded BSQ wallet sends 100 BSQ to the second BSQ wallet.
bisq: sendBsq: Throw InsufficientMoneyException when BSQ balance too low
Tor failed to start for some users because their operating system didn't ship Tor's dependencies. This change instructs the package manager to install tor and all its required during the Bisq installation. Furthermore, we don't need to ship the Tor binary and its libraries on Linux anymore leading to package size savings.
The MigrationService allows us to perform necessary migrations when upgrading to a new Bisq version. So far, the only option is to try to perform the migrations on each run. The MigrationService runs the necessary migrations if the data directory version is below the app version.
I tested this PR on:
an instance with a fresh data directory
an instance with a data directory of v2.1.1 (applies migration)
an instance with an already migrated data directory (v2.1.2)
This feature is needed to remove redundant Tor files after merging PR #2938. A follow-up PR will contain the required changes.
PR #2938 unbundles Tor from Bisq on Linux and switches to the OSes Tor binary. If a user updates from a prior version their data directory will contain the old extracted Tor binaries. The migration in this change removes the obsolete files.
bisq2: migration: Write new data directory version if all migrations succeed
Migrations are applied if the app version number is higher than the data directory version number. Currently, the only existing migration writes the new version number to the data directory after applying its migration. Moving the data directory version write to the Migrator makes the code future-proof when we have multiple migrations.
bisq2: migration: Pass migrations to Migrator in constructor
The MigrationService isn't needed anymore after the data directory has been migrated. This change removes the ApplicationService's reference to the MigrationService after it has run.
Summary
8571.43
Contributions delivered
Our users are still protected because we connect to IpV4 addresses
through Tor. This improves connectivity because Bitcoin Core creates an
ephemeral onion service on each startup.
Our Socks5SeedOnionDiscovery contains deprecated Tor V2 onion addresses
that are not supported anymore. BitcoinCoreSeedListDiscovery contains
Tor V3 addresses that are shipped with Bitcoin Core.
We create an array in the getPeers method and throw it away without
using it.
We use the same bitcoind regtest module in Bisq 1 and 2. To avoid
duplicate code I moved the bitcoind module to its own repository.
The BisqTransactionSigner signs the inputs of a transaction after the
given offset using the LocalOffsetTransactionSigner. The
LocalOffsetTransactionSigner is identical to BitcoinJ's
LocalTransactionSigner. The only difference is that the
LocalOffsetTransactionSigner accepts an offset in its constructor. All
inputs below this offset are skipped during signing.
This is needed for Bisq's BSQ implementation because the mining fees of
BSQ transactions come from Bisq's BTC wallet. BitcoinJ's
LocalTransactionSigner expects all inputs to be part of the same wallet.
The addMiningFeesToBsqTx method adds BTC mining fees to a given BSQ
transaction and tx fee amount.
The sendBsq method creates a BSQ transaction, signs the BSQ inputs, and
adds the requires BTC mining fees to the transaction.
utACK
The WalletFactory can create BTC and BSQ wallets.
The bisq.java-integration-tests plugin creates an integrationTest source
set that depends on JUnit. The source set inherits the main source set's
compile classpath, runtime classpath, and the implementation's source
set configuration and runtimeOnly configuration.
The RegtestWalletAppKit sets up BitcoinJ and loads the given wallets.
First, the sendBsq test creates one BTC and two BSQ wallets. Afterward,
it funds the BTC and one BSQ wallet with 1 BTC. Next, the funded BSQ
wallet sends 100 BSQ to the second BSQ wallet.
We should throw an InsufficientMoneyException when the CoinSelection
gathered amount is lower than the amount the user wants to send.
The tests try to send 0 BSQ and the current dust amount in BSQ.
Tor failed to start for some users because their operating system didn't ship Tor's dependencies. This change instructs the package manager to install tor and all its required during the Bisq installation. Furthermore, we don't need to ship the Tor binary and its libraries on Linux anymore leading to package size savings.
Changes:
Fixes #2906
The MigrationService allows us to perform necessary migrations when upgrading to a new Bisq version. So far, the only option is to try to perform the migrations on each run. The MigrationService runs the necessary migrations if the data directory version is below the app version.
I tested this PR on:
This feature is needed to remove redundant Tor files after merging PR #2938. A follow-up PR will contain the required changes.
Changes:
PR #2938 unbundles Tor from Bisq on Linux and switches to the OSes Tor binary. If a user updates from a prior version their data directory will contain the old extracted Tor binaries. The migration in this change removes the obsolete files.
Migrations are applied if the app version number is higher than the data directory version number. Currently, the only existing migration writes the new version number to the data directory after applying its migration. Moving the data directory version write to the Migrator makes the code future-proof when we have multiple migrations.
The migrations are hard-coded in the Migrator making it impossible to add test where some migrations fail.
The MigrationService isn't needed anymore after the data directory has
been migrated. This change removes the ApplicationService's reference to
the MigrationService after it has run.
The CI tasks are failing because macOS 12 isn't supported anymore. See: actions/runner-images#10721
We use the same bitcoind regtest module in Bisq 1 and 2. To avoid
duplicate code I moved the bitcoind module to its own repository.