You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Title
Team
USD
Link
Notes
bisq2: Only bind servers to all interfaces on Whonix
Users have to manually update Bisq and to support auto-updates we need to ship msi files. We can't use the existing exe file because it requires user interaction during installation or updating.
bisq2: bitcoind: Download and verify SHA256SUMS file
The hash verification task looks up the expected hash and verifies that the provided file has that hash. To look up the expected hash, the Gradle task parses the input hash list file of the format ' filename.tar.gz' (per line). Most projects use this format.
We send a stop RPC call and wait for the subprocess after receiving a success/ok message. This is unnecessary because we received a success reply already.
We parse stdout and wait for the "init message: Done loading" line to detect when bitcoind is ready. After seeing this line, we stop reading stdout causing the stdout buffer to fill up. When the stdout buffer fills up, bitcoind waits until its parent process reads from it but this unfortunately never happens leading to a deadlock.
bisq2: BitcoindProcess: Reuse BitcoinDaemon class instance in stop call
The test mines blocks and waits until it sees the block hashes of the mined blocks over ZMQ. Unfortunately, ZMQ publishers are stateless and can't re-transmit lost messages [1]. Consequently, the test was wrong. The fixed test subscribes to the publisher, starts mining blocks, and waits until it observes a new block hash.
The tests use the installed bitcoind binary. To make the test failures reproducible it's better to run the tests with the officially supported Bitcoin Core version.
bisq2: Move JUnit 5 BitcoindExtension to wallets.regtest module
The wallets.regtest can't depend on any Bisq 2 API to be able to re-use the bitcoind regtest module in Bisq 1. I migrated our BitcoinJ fork to the upstream version but Bisq 1 uses deprecated/removed BitcoinJ APIs, and it's too risky to update critical code without testing the changes. Bisq 1 doesn't have any bitcoind-based integration testing code and quicker to re-use Bisq 2 bitcoind integration test infrastructure.
bisq2: Move DaemonProcess to wallets.regtest module
Summary
7500.00
Contributions delivered
The Bisq P2P ports are exposed to the local network even when Tor is the only selected network. This is only needed on Whonix.
Users have to manually update Bisq and to support auto-updates we need to ship msi files. We can't use the existing exe file because it requires user interaction during installation or updating.
We send a
stop
RPC call and wait for the subprocess after receiving asuccess/ok
message. This is unnecessary because we received asuccess
reply already.We parse stdout and wait for the "init message: Done loading" line to
detect when bitcoind is ready. After seeing this line, we stop reading
stdout causing the stdout buffer to fill up. When the stdout buffer
fills up, bitcoind waits until its parent process reads from it but this
unfortunately never happens leading to a deadlock.
The assumptions and expectations of the tests are wrong.
The test mines blocks and waits until it sees the block hashes of the
mined blocks over ZMQ. Unfortunately, ZMQ publishers are stateless and
can't re-transmit lost messages [1]. Consequently, the test was wrong.
The fixed test subscribes to the publisher, starts mining blocks, and
waits until it observes a new block hash.
The assumptions and expectations of the tests are wrong.
The implementation is wrong.
The test is wrong.
Both fields were added in Bitcoin Core 24.0.1.
warning
string was replaced by awarnings
JSON array in Bitcoin Core 25.0.The tests use the installed bitcoind binary. To make the test failures
reproducible it's better to run the tests with the officially supported
Bitcoin Core version.
The wallets.regtest can't depend on any Bisq 2 API to be able to re-use
the bitcoind regtest module in Bisq 1. I migrated our BitcoinJ fork to
the upstream version but Bisq 1 uses deprecated/removed BitcoinJ APIs,
and it's too risky to update critical code without testing the changes.
Bisq 1 doesn't have any bitcoind-based integration testing code and
quicker to re-use Bisq 2 bitcoind integration test infrastructure.
The text was updated successfully, but these errors were encountered: