Bitcoin Project Release Tracker

BlueWallet/BlueWallet: v6.0.8

Published: 2021-04-06 08:28:57 UTC


New

  • RTL language support
  • Allow send MAX and BATCH for all wallet types
  • ANG and AWG currencies
  • Show fingerprint and derivation path for HD wallets

Fixed

  • Aezeed onchain correct zpub
  • Address input QRcode denomination reset
  • Currency rates loader, add LPB new rate source
  • Import procedure improvements

Languages updates

French, Chinese (Simplified), Chinese (Traditional), Finnish, German, Dutch, Portuguese Brazilian, Greek, Indonesian, Italian, Japanese, Turkish, Polish, Persian, Romanian, Spanish and Czech . Join us here → https://www.transifex.com/bluewallet/bluewallet

Download

Appstore

Playstore

Go to Repo Go to Release

zkSNACKs/WalletWasabi: v1.1.12.8

Published: 2021-04-02 08:10:11 UTC


Summary

This is a trivial fix for letting our users be able to recover from 12, 15, 18, 21, 24 Recovery Words.

Newbie Guide

While setting up Wasabi is straightforward, even a Linux wizard with the longest beard can get stuck on the most basic tasks. Consider taking a look at the Installation Instructions guide.

Advanced Guide

If you want to build Wasabi from source code or update the source code check out these instructions.

From version 1.1.3 Wasabi also introduces reproducible builds: Deterministic Build Guide

Build with .NET Core 3.1.407-win-x64.

FAQ

  • Frequently asked questions here.
  • Requirements? x64, Linux, >Win10, >macOS 10.13.

Release Notes

Go to Repo Go to Release

bisq-network/bisq: v1.6.2

Published: 2021-04-01 08:33:36 UTC


This is a hotfix release that fixes an issue with SPV resync introduced in v1.6.0 and fixes a minor bug in the portfolio view when price nodes aren't available.

For more details please see https://github.com/bisq-network/bisq/milestone/56?closed=1

Here are the release notes from v1.6.0:

Release notes

This release ships the official beta release for the Bisq API! It has been tested on mainnet, but is still in beta, so please be careful.

Other highlights: absolute minimum deposits have now been lowered from 0.006 BTC to 0.001 BTC. Maker and taker fee transactions are now verified via mempool.space to reduce trade issues, and mediation and arbitration were improved as well. And as always, there are many bug fixes and refinements.

Also important: this release ships part of 1 of 2 for BSQ SegWit implementation. It prepares the network for handling SegWit BSQ transactions (activation block is 680300, around 2021/04/25 -- all full nodes should update to 1.6.0+ before that time). Shortly after this activation point, the wallet code (https://github.com/bisq-network/bisq/pull/5109) will be merged into master for testing so that the full BSQ SegWit update is shipped in the following release.

DAO

UI

Trading

Wallet

Reliability

Privacy

Mediation/Arbitration

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.6.2.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.6.2.jar The output need to match the value from the Bisq-1.6.2.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.6.2.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @BtcContributor
  • @cd2357
  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @huey735
  • @JaredBoone
  • @jmacxx
  • @wallclockbuilder
  • @sqrrm
  • @stejbac

A special thanks to our first time contributor:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.7.2

Published: 2021-04-01 03:17:19 UTC


Small release fixing bugs introduced in 1.0.7.1:

Bug fixes:

  • The date in invoice page were not showing anymore the browser date time, but the server date time. (@NicolasDorier)
  • Apps on root where not working anymore, redirecting to login page rather than showing the app (see #2414) (@bolatovumar)

Go to Repo Go to Release

ElementsProject/lightning: v0.10.0

Published: 2021-03-31 20:14:56 UTC


We're pleased to announce the 0.10.0 release of c-lightning, named by @jsarenik.

This is a major release, consolidating a number of features, fixes and experimental extensions.

Highlights for Users

  • pay has been refined and much improved across various less-common scenarios.
  • listpeers shows the current feerate and unilateral close fee.
  • listforwards can now filter by channel status, and in or out channel.
  • fundpsbt and utxopsbt have a new excess_as_change parameter if you don't want to add it yourself.
  • connect returns the address we actually connected to (and direction tells you if they actually connected to us instead).
  • fundchannel_complete takes a PSBT, removing a common cause of tragic opening failures: txprepare and withdraw now provide a PSBT for convenience too.
  • In regtest mode, we don't care that bitcoind doesn't give any fee estimates, but use the minimum.

Highlights for the Network

  • We now send warning messages if an error condition is possibly recoverable, rather than closing the channel and sending error.
  • We now implement sync_complete for gossip_range queries as per latest spec, with backwards compatibility for older nodes.
  • experimental-dual-fund config option enables the draft dual funding option for compatible nodes, which includes RBF upgrades for opening transactions.

Highlights for Developers

  • All hooks are now registerable by multiple plugins at once.
  • experimental-shutdown-wrong-funding allows remote nodes to close incorrectly opened channels using the new wrong_funding option to close.

More details can be found in the changelog.

Thanks to everyone for their contributions and bug reports; please keep them coming.

Since 0.9.3, we've had 339 commits from 14 different authors over 69 days.

A special thanks goes to the 3 first time contributors:

  • Matthias Debernardini
  • Luke Childs
  • Alexey Zagarin

Cheers, Rusty, Lisa, Christian, ZmnSCPxj

Go to Repo Go to Release

zkSNACKs/WalletWasabi: v1.1.12.7

Published: 2021-03-31 10:39:06 UTC


Summary

Trezor T's firmware (v2.3.5) breaks the compatibility with Wasabi, this release fixes this. I also added some minor updates and fixes.

  • Update HWI to v2.0.1
  • Update Tor to v0.4.5.7

Newbie Guide

While setting up Wasabi is straightforward, even a Linux wizard with the longest beard can get stuck on the most basic tasks. Consider taking a look at the Installation Instructions guide.

Advanced Guide

If you want to build Wasabi from source code or update the source code check out these instructions.

From version 1.1.3 Wasabi also introduces reproducible builds: Deterministic Build Guide

Build with .NET Core 3.1.407-win-x64.

FAQ

  • Frequently asked questions here.
  • Requirements? x64, Linux, >Win10, >macOS 10.13.

Release Notes

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.7.1

Published: 2021-03-30 15:16:32 UTC


This is a security release that patches one critical and several low-impact vulnerabilities that affected BTCPay Server versions 1.0.7.0 and older.

The critical vulnerability (CVE-2021-29251) impacts users who:

  • Use Docker Deployment, have a configured email server and enabled registration for users in Server Settings > Policies

We strongly recommend affected users to update their instances to mitigate the risk. We will release a full public disclosure of vulnerabilities with the next major version of the BTCPay Server.

We want to thank @teslamotors for filing a responsible disclosure, helping us with remediation, and handling the situation professionally.
We also want to thank Qaiser Abbas, an independent web-security researcher, for an additional responsible vulnerability disclosure that was handled in this release.

Thank you for keeping our users safe.

Improvements:

  • Add user email search/sort @bolatovumar
  • Fix pay button link preview (see #2396) @bumbummen99
  • Change display date format on view pull payments (see #2339) @AlexGidge
  • Update form required input styling (see #2373) @bolatovumar
  • Order file uploaded list by descending timestamp (#2273) @bolatovumar
  • Remove misleading title from hint icon @dennisreimann
  • Make dates/timespan swagger docs more clear (#2399) @Kukks
  • Add rate limiter for forgotpassword @NicolasDorier
  • Upgrade Boostrap to v4.6 and jquery to 3.6.0 @dennisreimann
  • Use better PRNG for payjoin input selection @NicolasDorier
  • Decrease authentication cookie timeout after password change from 30min to 5min @NicolasDorier
  • Use secure/http-only cookies for preferences @NicolasDorier

Bug fixes:

  • Ensure submitting empty currency does not break update PoS page (#2376) @bolatovumar
  • Fix point of sale item newline break (#2366) @Kukks
  • Validate filename in file upload endpoints @NicolasDorier
  • Turn off autocomplete for BIP39 Seed or HD private key inputs @nosovk
  • Fix payment request template body/page height and footer style @Patrick

Go to Repo Go to Release

ElementsProject/elements: elements-0.18.1.11

Published: 2021-03-29 18:37:42 UTC


Changelog for v0.18.1.11:

  • Specify the dynafed epoch length for liquidv1.

Changelog for v0.18.1.10

  • Add SIGHASH_RANGEPROOF support
  • Add two missing dynafed fields to getblockchaininfo
  • Support changing mainnet dynafed activation
  • Only verify proposed dynafed parameters if they differ from current

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.3.0

Published: 2021-03-29 17:27:24 UTC


Binaries

There are two types of binaries:

Specter Desktop

It's a windowed GUI application with Specter server included. Supported platforms: Windows, MacOS, Linux (x86_64)

Note on Linux: you need to set up udev rules (included in the archive). Check out readme.

Note on macOS: The current build supports only macOS Catalina (10.15) or higher. If you'd like to run Specter on an older macOS version, you can install Specter from Pip.

specterd

It's a command-line program that only runs Specter server. Supported platforms: Windows, MacOS, Linux (x86_64)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @ben-kaufman's GPG key. You can get the public key from here: https://benkaufman.info/ben-kaufman.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 5DF6 A760 1DB8 B78E BDEC 18DB 5D27 DE56 4153 F2BD, short id: 5d27de564153f2bd

Release notes

Bugfix: bump embit version, add secp binary #1031 (Stepan Snigirev) - Bugfix: consolidations issue #1034 (benk10) - Bugfix: Default bitcoind timeout to 60s for all platforms #1044 (kdmukai) - Bugfix: Raspberry Pi check; fixing breaking changes when not using built-in Tor #1037 (kdmukai) - Bugfix: Remove potentially non-final txid #1011 (benk10) - Bugfix: auto-escaping of wallet.accountmap json in pdf backup #976 (djpnewton) - Bugfix: typo #1008 (Jan Rothen) - Bugfix: HWI2 integration issues #1045 (benk10) - Bugfix: misc Fixes for pre-release, mainly proper tor shutdown (#1048) (benk10) - Bugfix: fix fillpsbt #1050 (Stepan Snigirev) - Bugfix: exit cleanup #1053 (benk10) - Bugfix: Fix Windows pyinstaller typo #1064 (benk10) - Bugfix: Pre release minor fixes #1055 (benk10) - Bugfix: Remove scientific notations #1067 (benk10) - Bugfix: Update Bitcoin Core data dir even when installed and update Cobo Vault instructions #1056 (benk10) - Bugfix: Remove download attribute from link #1061 (Taylor Helsper) - Chore: Bump jinja2 from 2.11.2 to 2.11.3 #1033 (dependabot[bot]) - Chore: Some more Cypress tests #970 (benk10) - Chore: Re-applying config change to pass Black formatting #1003 (kdmukai) - Chore: Cypress travis #997 (Kim Neunert) - Chore: Bump HWI to 2.0.1 #1060 (benk10) - Chore: Refactor node setup state and timeout #1058 (benk10) - Docs: added signature-verification to FAQ #1042 (Kim Neunert) - Docs: Update DEVELOPMENT.md for Raspi #1032 (kdmukai) - Docs: update to specify correct docker tag #971 (kdmukai) - Docs: Fixed typos in faq.md #1004 (Dimitris Tsapakidis) - Docs: Add link to RaspiBlitz connection guide #1041 (d11n) - Feature: Add "Abandon transaction" option for low fee txs that have been purged from the mempool #991 (kdmukai) - Feature: Add full edit transaction for RBF #998 (benk10) - Feature: Add mempool.space as an option for fee estimation and block explorer #1020 (benk10) - Feature: many more currencies to the price provider #1021 (benk10) - Feature: Move wallets loading process to background #1017 (benk10) - Feature: Setup Bitcoin Core from Specter #1007 (benk10) - Feature: Show wallets overview for / , resolves #1018 #1019 (benk10) - Feature: improved the description of the CLI arguments/options #984 (8go) - Feature: Logging improvements #1043 (Kim Neunert) - Feature: Move to HWI v2 #1001 (benk10) - Feature: Specter-DIY: add sd card support #1047 (Stepan Snigirev) - Feature: Adding regular logs to core-settings-page #1065 (Kim Neunert) - Feature: Call the checker more often if IBD #1059 (benk10) - Feature: Pre download core and tor binaries #1062 (benk10) - UIUX: changing the background color of that input/output (using colors based on the send/receive svg icons) #989 (djpnewton) - UIUX: HWI Bridge design improvement #1015 (benk10) - UIUX: Timeout management and other improvements #1057 (Kim Neunert) - UIUX: Only tor quicksync warning #1054 (Kim Neunert)

Go to Repo Go to Release

bisq-network/bisq: v1.6.1

Published: 2021-03-29 14:04:50 UTC


A newer version is already available! Please don’t use this version anymore.

This is a follow-up release that allows default fee values in leniency checks, fixes an issue in the the new portfolio history popup and upgrades to the latest Tor version v0.4.5.7 that fixes two important denial-of-service bugs in earlier versions of Tor.

For more details please see https://github.com/bisq-network/bisq/milestone/54?closed=1

Here are the release notes from v1.6.0:

Release notes

This release ships the official beta release for the Bisq API! It has been tested on mainnet, but is still in beta, so please be careful.

Other highlights: absolute minimum deposits have now been lowered from 0.006 BTC to 0.001 BTC. Maker and taker fee transactions are now verified via mempool.space to reduce trade issues, and mediation and arbitration were improved as well. And as always, there are many bug fixes and refinements.

Also important: this release ships part of 1 of 2 for BSQ SegWit implementation. It prepares the network for handling SegWit BSQ transactions (activation block is 680300, around 2021/04/25 -- all full nodes should update to 1.6.0+ before that time). Shortly after this activation point, the wallet code (https://github.com/bisq-network/bisq/pull/5109) will be merged into master for testing so that the full BSQ SegWit update is shipped in the following release.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.6.1.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.6.1.jar The output need to match the value from the Bisq-1.6.1.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.6.1.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @BtcContributor
  • @cd2357
  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @huey735
  • @JaredBoone
  • @jmacxx
  • @wallclockbuilder
  • @sqrrm
  • @stejbac

A special thanks to our first time contributor:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

bitcoin-core/HWI: 2.0.1

Published: 2021-03-27 17:55:57 UTC


Also available on PyPi and can be installed with pip install -U hwi

Fixed

  • Fixed Trezor T on device passphrase entry
  • Fixed hwi-qt Linux binary crashing when using keyboard shortcuts

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.3.0-pre6

Published: 2021-03-26 18:46:17 UTC


v1.3.0-pre6 - This is a pre-release (i.e. beta software).

Use this with caution!!!

Main changes to test:

  • Bitcoin Core and Tor setup: Specter now has a new setup wizard, accessible from the main screen, which allows setting up Bitcoin Core and Tor directly from Specter. You can also setup Tor separately from the Tor settings tab. The Tor and Bitcoin Core will automatically start and stop with Specter launch/ close. (Warning: If you're already using Bitcoin Core on the machine you're testing the setup on, Specter by default will use and override existing files in the default location of Bitcoin Core - since we assume users who need Bitcoin Core installation from Specter don't have a node there already. If that is a concern for you, make sure to specify a custom path to Bitcoin Core data folder so Specter will use that instead, this can be done from the advanced section of the wizard).
  • Full RBF editing option: You can now fully edit an RBF transaction - i.e. change recipient address, add inputs, edit amounts etc.
  • HWI v2.0.0: New version of HWI with major changes, meaning all USB-connected hardware wallets should be tested to ensure the new version did not break any integration.
  • BitBox02 Multisig support: With HWI v2.0.0, Specter now supports using BitBox02 in multisig setups.
  • Async wallets loading: The process of loading existing wallets into Specter on startup has been moved to the background. Specter should now start up much faster, and you may see loading indication at first for the wallets.
  • Abandon transaction: If you sent a transaction that has been purged from the mempool, it is now possible to make your wallet forget it so that the funds are spendable again.
  • Mempool.space fee estimation: The default fee estimation source is now mempool.space. It's also possible to configure in the general settings to use either Bitcoin Core, or a self-hosted instance of mempool.space.
  • Block explorer default options: We now have default options for block explorers instead of only free text. It's still possible to use as free text by choosing custom.
  • HWI Bridge Redesign: The process and design of configuring Specter used on a remote machine to allow USB connections has been simplified and redesigned.
  • More currencies and precious metals in price bar: More currencies are now available for automated price pulling, also precious metals, with multiple weight unit options, are now available too.
  • Fix escaping of JSON wallet backup: Avoid escaping the JSON file downloaded on wallet backup.
  • Fix Bitcoin Core v0.21 UTXO consolidation issue: Previous version had a bug where UTXO consolidation transactions were would always show up as unconfirmed if Bitcoin Core v0.21 is used.
  • Fix Signet Nested SegWit: Nested SegWit addresses on Signet were previously generated incorrectly.

Planned release-notes:

  • Bugfix: bump embit version, add secp binary #1031 (Stepan Snigirev)
  • Bugfix: consolidations issue #1034 (benk10)
  • Bugfix: Default bitcoind timeout to 60s for all platforms #1044 (kdmukai)
  • Bugfix: Raspberry Pi check; fixing breaking changes when not using built-in Tor #1037 (kdmukai)
  • Bugfix: Remove potentially non-final txid #1011 (benk10)
  • Bugfix: auto-escaping of wallet.account_map json in pdf backup #976 (djpnewton)
  • Bugfix: typo #1008 (Jan Rothen)
  • Bugfix: HWI2 integration issues #1045 (benk10)
  • Chore: Bump jinja2 from 2.11.2 to 2.11.3 #1033 (dependabot[bot])
  • Chore: Some more Cypress tests #970 (benk10)
  • Chore: Re-applying config change to pass Black formatting #1003 (kdmukai)
  • Chore: Cypress travis #997 (Kim Neunert)
  • Docs: added signature-verification to FAQ #1042 (Kim Neunert)
  • Docs: Update DEVELOPMENT.md for Raspi #1032 (kdmukai)
  • Docs: update to specify correct docker tag #971 (kdmukai)
  • Docs: Fixed typos in faq.md #1004 (Dimitris Tsapakidis)
  • Docs: Add link to RaspiBlitz connection guide #1041 (d11n)
  • Feature: Add "Abandon transaction" option for low fee txs that have been purged from the mempool #991 (kdmukai)
  • Feature: Add full edit transaction for RBF #998 (benk10)
  • Feature: Add mempool.space as an option for fee estimation and block explorer #1020 (benk10)
  • Feature: many more currencies to the price provider #1021 (benk10)
  • Feature: Move wallets loading process to background #1017 (benk10)
  • Feature: Setup Bitcoin Core from Specter #1007 (benk10)
  • Feature: Show wallets overview for / , resolves #1018 #1019 (benk10)
  • Feature: improved the description of the CLI arguments/options #984 (8go)
  • Feature: Logging improvements #1043 (Kim Neunert)
  • Feature: Move to HWI v2 #1001 (benk10)
  • Feature: Specter-DIY: add sd card support #1047 (Stepan Snigirev)
  • UIUX: changing the background color of that input/output (using colors based on the send/receive svg icons) #989 (djpnewton)
  • UIUX: HWI Bridge design improvement #1015 (benk10)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @ben-kaufman's GPG key. You can get the public key from here: https://benkaufman.info/ben-kaufman.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 5DF6 A760 1DB8 B78E BDEC 18DB 5D27 DE56 4153 F2BD, short id: 5d27de564153f2bd

Go to Repo Go to Release

bisq-network/bisq: v1.6.0

Published: 2021-03-26 15:44:15 UTC


A newer version is already available! Please don’t use this version anymore.

Release notes

This release ships the official beta release for the Bisq API! It has been tested on mainnet, but is still in beta, so please be careful.

Other highlights: absolute minimum deposits have now been lowered from 0.006 BTC to 0.001 BTC. Maker and taker fee transactions are now verified via mempool.space to reduce trade issues, and mediation and arbitration were improved as well. And as always, there are many bug fixes and refinements.

Also important: this release ships part of 1 of 2 for BSQ SegWit implementation. It prepares the network for handling SegWit BSQ transactions (activation block is 680300, around 2021/04/25 -- all full nodes should update to 1.6.0 before that time). Shortly after this activation point, the wallet code (https://github.com/bisq-network/bisq/pull/5109) will be merged into master for testing so that the full BSQ SegWit update is shipped in the following release.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.6.0.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.6.0.jar The output need to match the value from the Bisq-1.6.0.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.6.0.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @BtcContributor
  • @cd2357
  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @huey735
  • @JaredBoone
  • @jmacxx
  • @wallclockbuilder
  • @sqrrm
  • @stejbac

A special thanks to our first time contributor:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

getumbrel/umbrel: v0.3.8

Published: 2021-03-26 12:53:40 UTC


Umbrel v0.3.8 brings the following apps up to their latest versions:

  • Thunderhub
  • RTL
  • BTCPay
  • Lightning Terminal
  • Specter Desktop
  • Sphinx Relay
  • Samourai Server

If you face any difficulties while updating, please message us on Telegram: https://t.me/getumbrel

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.7...v0.3.8

Go to Repo Go to Release

BlueWallet/BlueWallet: v6.0.7

Published: 2021-03-25 11:02:37 UTC


New

  • Encrypted Message sign/verify
  • Main SCAN button can import wallets
  • Card colors
  • Romanian language
  • TZS currency

Fixed

  • Improved accessibility
  • Show XPUB for AEZEED wallets
  • Wallet selection was not visible
  • Coin Control handle 0 conf output correctly
  • Decrease animated QR codes density
  • Send MAX can be used with regular outputs

Languages updates

French, Chinese (Simplified), Chinese (Traditional), Finnish, German, Dutch, Portuguese Brazilian and Slovenian. Join us here → https://www.transifex.com/bluewallet/bluewallet

Download

Appstore

Playstore

Go to Repo Go to Release

bwt-dev/bwt: v0.2.4

Published: 2021-03-24 23:50:08 UTC


Changelog

  • Allow specifying an explicit script type for xpubs using -x <xpub>:wpkh, -x <xpub>:shwpkh or -x <xpub>:pkh.

  • Fix blockchain.block.headers sending wrong number of headers (#87, thanks @stevenroose!)

  • Check testmempoolaccept prior to custom broadcast (#80)

  • Dependency updates and various small enhancements


Also see the v0.2.4 releases for bwt-electrum-plugin, libbwt, libbwt-nodejs and libbwt-jni.

Installation

Installation instructions are available on the README.

Verifying signatures

The releases are signed by Nadav Ivgi (@shesek). The public key can be verified on the PGP WoT, github, twitter, keybase, hacker news and this video presentation.

```bash

Download (change x86_64-linux to your platform)

$ wget https://github.com/bwt-dev/bwt/releases/download/v0.2.4/bwt-0.2.4-x86_64-linux.tar.gz

Fetch public key

$ gpg --keyserver keyserver.ubuntu.com --recv-keys FCF19B67866562F08A43AAD681F6104CD0F150FC

Verify signature

$ wget -qO - https://github.com/bwt-dev/bwt/releases/download/v0.2.4/SHA256SUMS.asc \ | gpg --decrypt - | grep ' bwt-0.2.4-x86_64-linux.tar.gz$' | sha256sum -c -

$ tar zxvf bwt-0.2.4-x8664-linux.tar.gz $ ./bwt-0.1.5-x8664-linux/bwt --xpub ... ```

The signature verification should show Good signature from "Nadav Ivgi <nadav@shesek.info>" ... Primary key fingerprint: FCF1 9B67 ... and bwt-0.2.4-x86_64-linux.tar.gz: OK.

Reproducible builds

The builds are fully reproducible.

You can verify the checksums against the v0.2.4 builds on Travis CI: https://travis-ci.org/github/bwt-dev/bwt/builds/764306060

See more details here.

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.3.0-pre4

Published: 2021-03-24 20:46:48 UTC


v1.3.0-pre4 - This is a pre-release (i.e. beta software).

Use this with caution!!!

Main changes to test:

  • Bitcoin Core and Tor setup: Specter now has a new setup wizard, accessible from the main screen, which allows setting up Bitcoin Core and Tor directly from Specter. You can also setup Tor separately from the Tor settings tab. The Tor and Bitcoin Core will automatically start and stop with Specter launch/ close. (Warning: If you're already using Bitcoin Core on the machine you're testing the setup on, Specter by default will use and override existing files in the default location of Bitcoin Core - since we assume users who need Bitcoin Core installation from Specter don't have a node there already. If that is a concern for you, make sure to specify a custom path to Bitcoin Core data folder so Specter will use that instead, this can be done from the advanced section of the wizard).
  • Full RBF editing option: You can now fully edit an RBF transaction - i.e. change recipient address, add inputs, edit amounts etc.
  • HWI v2.0.0: New version of HWI with major changes, meaning all USB-connected hardware wallets should be tested to ensure the new version did not break any integration.
  • BitBox02 Multisig support: With HWI v2.0.0, Specter now supports using BitBox02 in multisig setups.
  • Async wallets loading: The process of loading existing wallets into Specter on startup has been moved to the background. Specter should now start up much faster, and you may see loading indication at first for the wallets.
  • Abandon transaction: If you sent a transaction that has been purged from the mempool, it is now possible to make your wallet forget it so that the funds are spendable again.
  • Mempool.space fee estimation: The default fee estimation source is now mempool.space. It's also possible to configure in the general settings to use either Bitcoin Core, or a self-hosted instance of mempool.space.
  • Block explorer default options: We now have default options for block explorers instead of only free text. It's still possible to use as free text by choosing custom.
  • HWI Bridge Redesign: The process and design of configuring Specter used on a remote machine to allow USB connections has been simplified and redesigned.
  • More currencies and precious metals in price bar: More currencies are now available for automated price pulling, also precious metals, with multiple weight unit options, are now available too.
  • Fix escaping of JSON wallet backup: Avoid escaping the JSON file downloaded on wallet backup.
  • Fix Bitcoin Core v0.21 UTXO consolidation issue: Previous version had a bug where UTXO consolidation transactions were would always show up as unconfirmed if Bitcoin Core v0.21 is used.
  • Fix Signet Nested SegWit: Nested SegWit addresses on Signet were previously generated incorrectly.

Planned release-notes:

  • Bugfix: bump embit version, add secp binary #1031 (Stepan Snigirev)
  • Bugfix: consolidations issue #1034 (benk10)
  • Bugfix: Default bitcoind timeout to 60s for all platforms #1044 (kdmukai)
  • Bugfix: Raspberry Pi check; fixing breaking changes when not using built-in Tor #1037 (kdmukai)
  • Bugfix: Remove potentially non-final txid #1011 (benk10)
  • Bugfix: auto-escaping of wallet.account_map json in pdf backup #976 (djpnewton)
  • Bugfix: typo #1008 (Jan Rothen)
  • Bugfix: HWI2 integration issues #1045 (benk10)
  • Chore: Bump jinja2 from 2.11.2 to 2.11.3 #1033 (dependabot[bot])
  • Chore: Some more Cypress tests #970 (benk10)
  • Chore: Re-applying config change to pass Black formatting #1003 (kdmukai)
  • Chore: Cypress travis #997 (Kim Neunert)
  • Docs: added signature-verification to FAQ #1042 (Kim Neunert)
  • Docs: Update DEVELOPMENT.md for Raspi #1032 (kdmukai)
  • Docs: update to specify correct docker tag #971 (kdmukai)
  • Docs: Fixed typos in faq.md #1004 (Dimitris Tsapakidis)
  • Docs: Add link to RaspiBlitz connection guide #1041 (d11n)
  • Feature: Add "Abandon transaction" option for low fee txs that have been purged from the mempool #991 (kdmukai)
  • Feature: Add full edit transaction for RBF #998 (benk10)
  • Feature: Add mempool.space as an option for fee estimation and block explorer #1020 (benk10)
  • Feature: many more currencies to the price provider #1021 (benk10)
  • Feature: Move wallets loading process to background #1017 (benk10)
  • Feature: Setup Bitcoin Core from Specter #1007 (benk10)
  • Feature: Show wallets overview for / , resolves #1018 #1019 (benk10)
  • Feature: improved the description of the CLI arguments/options #984 (8go)
  • Feature: Logging improvements #1043 (Kim Neunert)
  • Feature: Move to HWI v2 #1001 (benk10)
  • Feature: Specter-DIY: add sd card support #1047 (Stepan Snigirev)
  • UIUX: changing the background color of that input/output (using colors based on the send/receive svg icons) #989 (djpnewton)
  • UIUX: HWI Bridge design improvement #1015 (benk10)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @ben-kaufman's GPG key. You can get the public key from here: https://benkaufman.info/ben-kaufman.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 5DF6 A760 1DB8 B78E BDEC 18DB 5D27 DE56 4153 F2BD, short id: 5d27de564153f2bd

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.3.0-pre3

Published: 2021-03-23 16:58:56 UTC


v1.3.0-pre3 - This is a pre-release (i.e. beta software).

Use this with caution!!!

Main changes to test:

  • Bitcoin Core and Tor setup: Specter now has a new setup wizard, accessible from the main screen, which allows setting up Bitcoin Core and Tor directly from Specter. You can also setup Tor separately from the Tor settings tab. The Tor and Bitcoin Core will automatically start and stop with Specter launch/ close. (Warning: If you're already using Bitcoin Core on the machine you're testing the setup on, Specter by default will use and override existing files in the default location of Bitcoin Core - since we assume users who need Bitcoin Core installation from Specter don't have a node there already. If that is a concern for you, make sure to specify a custom path to Bitcoin Core data folder so Specter will use that instead, this can be done from the advanced section of the wizard).
  • Full RBF editing option: You can now fully edit an RBF transaction - i.e. change recipient address, add inputs, edit amounts etc.
  • HWI v2.0.0: New version of HWI with major changes, meaning all USB-connected hardware wallets should be tested to ensure the new version did not break any integration.
  • BitBox02 Multisig support: With HWI v2.0.0, Specter now supports using BitBox02 in multisig setups.
  • Async wallets loading: The process of loading existing wallets into Specter on startup has been moved to the background. Specter should now start up much faster, and you may see loading indication at first for the wallets.
  • Abandon transaction: If you sent a transaction that has been purged from the mempool, it is now possible to make your wallet forget it so that the funds are spendable again.
  • Mempool.space fee estimation: The default fee estimation source is now mempool.space. It's also possible to configure in the general settings to use either Bitcoin Core, or a self-hosted instance of mempool.space.
  • Block explorer default options: We now have default options for block explorers instead of only free text. It's still possible to use as free text by choosing custom.
  • HWI Bridge Redesign: The process and design of configuring Specter used on a remote machine to allow USB connections has been simplified and redesigned.
  • More currencies and precious metals in price bar: More currencies are now available for automated price pulling, also precious metals, with multiple weight unit options, are now available too.
  • Fix escaping of JSON wallet backup: Avoid escaping the JSON file downloaded on wallet backup.
  • Fix Bitcoin Core v0.21 UTXO consolidation issue: Previous version had a bug where UTXO consolidation transactions were would always show up as unconfirmed if Bitcoin Core v0.21 is used.
  • Fix Signet Nested SegWit: Nested SegWit addresses on Signet were previously generated incorrectly.

Planned release-notes:

  • Bugfix: bump embit version, add secp binary #1031 (Stepan Snigirev)
  • Bugfix: consolidations issue #1034 (benk10)
  • Bugfix: Default bitcoind timeout to 60s for all platforms #1044 (kdmukai)
  • Bugfix: Raspberry Pi check; fixing breaking changes when not using built-in Tor #1037 (kdmukai)
  • Bugfix: Remove potentially non-final txid #1011 (benk10)
  • Bugfix: auto-escaping of wallet.account_map json in pdf backup #976 (djpnewton)
  • Bugfix: typo #1008 (Jan Rothen)
  • Bugfix: HWI2 integration issues #1045 (benk10)
  • Chore: Bump jinja2 from 2.11.2 to 2.11.3 #1033 (dependabot[bot])
  • Chore: Some more Cypress tests #970 (benk10)
  • Chore: Re-applying config change to pass Black formatting #1003 (kdmukai)
  • Chore: Cypress travis #997 (Kim Neunert)
  • Docs: added signature-verification to FAQ #1042 (Kim Neunert)
  • Docs: Update DEVELOPMENT.md for Raspi #1032 (kdmukai)
  • Docs: update to specify correct docker tag #971 (kdmukai)
  • Docs: Fixed typos in faq.md #1004 (Dimitris Tsapakidis)
  • Docs: Add link to RaspiBlitz connection guide #1041 (d11n)
  • Feature: Add "Abandon transaction" option for low fee txs that have been purged from the mempool #991 (kdmukai)
  • Feature: Add full edit transaction for RBF #998 (benk10)
  • Feature: Add mempool.space as an option for fee estimation and block explorer #1020 (benk10)
  • Feature: many more currencies to the price provider #1021 (benk10)
  • Feature: Move wallets loading process to background #1017 (benk10)
  • Feature: Setup Bitcoin Core from Specter #1007 (benk10)
  • Feature: Show wallets overview for / , resolves #1018 #1019 (benk10)
  • Feature: improved the description of the CLI arguments/options #984 (8go)
  • Feature: Logging improvements #1043 (Kim Neunert)
  • Feature: Move to HWI v2 #1001 (benk10)
  • Feature: Specter-DIY: add sd card support #1047 (Stepan Snigirev)
  • UIUX: changing the background color of that input/output (using colors based on the send/receive svg icons) #989 (djpnewton)
  • UIUX: HWI Bridge design improvement #1015 (benk10)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @ben-kaufman's GPG key. You can get the public key from here: https://benkaufman.info/ben-kaufman.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 5DF6 A760 1DB8 B78E BDEC 18DB 5D27 DE56 4153 F2BD, short id: 5d27de564153f2bd

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.3.0-pre2

Published: 2021-03-23 09:37:56 UTC


v1.3.0-pre2 - This is a pre-release (i.e. beta software).

Use this with caution!!!

Main changes to test:

  • Bitcoin Core and Tor setup: Specter now has a new setup wizard, accessible from the main screen, which allows setting up Bitcoin Core and Tor directly from Specter. You can also setup Tor separately from the Tor settings tab. The Tor and Bitcoin Core will automatically start and stop with Specter launch/ close. (Warning: If you're already using Bitcoin Core on the machine you're testing the setup on, Specter by default will use and override existing files in the default location of Bitcoin Core - since we assume users who need Bitcoin Core installation from Specter don't have a node there already. If that is a concern for you, make sure to specify a custom path to Bitcoin Core data folder so Specter will use that instead, this can be done from the advanced section of the wizard).
  • Full RBF editing option: You can now fully edit an RBF transaction - i.e. change recipient address, add inputs, edit amounts etc.
  • HWI v2.0.0: New version of HWI with major changes, meaning all USB-connected hardware wallets should be tested to ensure the new version did not break any integration.
  • BitBox02 Multisig support: With HWI v2.0.0, Specter now supports using BitBox02 in multisig setups.
  • Async wallets loading: The process of loading existing wallets into Specter on startup has been moved to the background. Specter should now start up much faster, and you may see loading indication at first for the wallets.
  • Abandon transaction: If you sent a transaction that has been purged from the mempool, it is now possible to make your wallet forget it so that the funds are spendable again.
  • Mempool.space fee estimation: The default fee estimation source is now mempool.space. It's also possible to configure in the general settings to use either Bitcoin Core, or a self-hosted instance of mempool.space.
  • Block explorer default options: We now have default options for block explorers instead of only free text. It's still possible to use as free text by choosing custom.
  • HWI Bridge Redesign: The process and design of configuring Specter used on a remote machine to allow USB connections has been simplified and redesigned.
  • More currencies and precious metals in price bar: More currencies are now available for automated price pulling, also precious metals, with multiple weight unit options, are now available too.
  • Fix escaping of JSON wallet backup: Avoid escaping the JSON file downloaded on wallet backup.
  • Fix Bitcoin Core v0.21 UTXO consolidation issue: Previous version had a bug where UTXO consolidation transactions were would always show up as unconfirmed if Bitcoin Core v0.21 is used.
  • Fix Signet Nested SegWit: Nested SegWit addresses on Signet were previously generated incorrectly.

Planned release-notes:

  • Bugfix: bump embit version, add secp binary #1031 (Stepan Snigirev)
  • Bugfix: consolidations issue #1034 (benk10)
  • Bugfix: Default bitcoind timeout to 60s for all platforms #1044 (kdmukai)
  • Bugfix: Raspberry Pi check; fixing breaking changes when not using built-in Tor #1037 (kdmukai)
  • Bugfix: Remove potentially non-final txid #1011 (benk10)
  • Bugfix: auto-escaping of wallet.account_map json in pdf backup #976 (djpnewton)
  • Bugfix: typo #1008 (Jan Rothen)
  • Bugfix: HWI2 integration issues #1045 (benk10)
  • Chore: Bump jinja2 from 2.11.2 to 2.11.3 #1033 (dependabot[bot])
  • Chore: Some more Cypress tests #970 (benk10)
  • Chore: Re-applying config change to pass Black formatting #1003 (kdmukai)
  • Chore: Cypress travis #997 (Kim Neunert)
  • Docs: added signature-verification to FAQ #1042 (Kim Neunert)
  • Docs: Update DEVELOPMENT.md for Raspi #1032 (kdmukai)
  • Docs: update to specify correct docker tag #971 (kdmukai)
  • Docs: Fixed typos in faq.md #1004 (Dimitris Tsapakidis)
  • Docs: Add link to RaspiBlitz connection guide #1041 (d11n)
  • Feature: Add "Abandon transaction" option for low fee txs that have been purged from the mempool #991 (kdmukai)
  • Feature: Add full edit transaction for RBF #998 (benk10)
  • Feature: Add mempool.space as an option for fee estimation and block explorer #1020 (benk10)
  • Feature: many more currencies to the price provider #1021 (benk10)
  • Feature: Move wallets loading process to background #1017 (benk10)
  • Feature: Setup Bitcoin Core from Specter #1007 (benk10)
  • Feature: Show wallets overview for / , resolves #1018 #1019 (benk10)
  • Feature: improved the description of the CLI arguments/options #984 (8go)
  • Feature: Logging improvements #1043 (Kim Neunert)
  • Feature: Move to HWI v2 #1001 (benk10)
  • Feature: Specter-DIY: add sd card support #1047 (Stepan Snigirev)
  • UIUX: changing the background color of that input/output (using colors based on the send/receive svg icons) #989 (djpnewton)
  • UIUX: HWI Bridge design improvement #1015 (benk10)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @ben-kaufman's GPG key. You can get the public key from here: https://benkaufman.info/ben-kaufman.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 5DF6 A760 1DB8 B78E BDEC 18DB 5D27 DE56 4153 F2BD, short id: 5d27de564153f2bd

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.3.0-pre1

Published: 2021-03-22 19:05:18 UTC


v1.3.0-pre1 - This is a pre-release (i.e. beta software).

Use this with caution!!!

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @ben-kaufman's GPG key. You can get the public key from here: https://benkaufman.info/ben-kaufman.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 5DF6 A760 1DB8 B78E BDEC 18DB 5D27 DE56 4153 F2BD, short id: 5d27de564153f2bd

Go to Repo Go to Release

rust-bitcoin/rust-lightning: v0.0.13

Published: 2021-03-22 16:49:11 UTC


Go to Repo Go to Release

zkSNACKs/WalletWasabi: v1.1.12.6

Published: 2021-03-22 10:21:30 UTC


Summary

The last hotfix release broke the Tor installation on fresh installs. This release fixes this.

  • Fix Tor installation on fresh installs

Newbie Guide

While setting up Wasabi is straightforward, even a Linux wizard with the longest beard can get stuck on the most basic tasks. Consider taking a look at the Installation Instructions guide.

Advanced Guide

If you want to build Wasabi from source code or update the source code check out these instructions.

From version 1.1.3 Wasabi also introduces reproducible builds: Deterministic Build Guide

Build with .NET Core 3.1.407-win-x64.

FAQ

  • Frequently asked questions here.
  • Requirements? x64, Linux, >Win10, >macOS 10.13.

Release Notes

Go to Repo Go to Release

bwt-dev/bwt: v0.2.3

Published: 2021-03-17 04:02:43 UTC


Changelog

  • New --prune-until <target> option to automatically prune the chain up to the given target (height, unix timestamp or YYYY-MM-DD formatted date)

Require configuring bitcoind with prune=1 to allow manual pruning via the RPC.

  • New --no-wait-sync option to allow importing addresses without waiting for bitcoind to finish syncing first

Useful for tracking wallets during the IBD of a pruned node, so transactions could be indexed before the blocks get pruned.

Breaking CLI changes:

  • The Electrum SOCKS5-based authentication needs to be explicitly enabled with --electrum-socks-auth, in addition to enabling the --auth-* options. By default, authentication will only be enabled for the HTTP API server.

Also see the v0.2.3 releases for bwt-electrum-plugin, libbwt, libbwt-nodejs and libbwt-jni.

Installation

Installation instructions are available on the README.

Verifying signatures

The releases are signed by Nadav Ivgi (@shesek). The public key can be verified on the PGP WoT, github, twitter, keybase, hacker news and this video presentation.

```bash

Download (change x86_64-linux to your platform)

$ wget https://github.com/bwt-dev/bwt/releases/download/v0.2.3/bwt-0.2.3-x86_64-linux.tar.gz

Fetch public key

$ gpg --keyserver keyserver.ubuntu.com --recv-keys FCF19B67866562F08A43AAD681F6104CD0F150FC

Verify signature

$ wget -qO - https://github.com/bwt-dev/bwt/releases/download/v0.2.3/SHA256SUMS.asc \ | gpg --decrypt - | grep ' bwt-0.2.3-x86_64-linux.tar.gz$' | sha256sum -c -

$ tar zxvf bwt-0.2.3-x8664-linux.tar.gz $ ./bwt-0.1.5-x8664-linux/bwt --xpub ... ```

The signature verification should show Good signature from "Nadav Ivgi <nadav@shesek.info>" ... Primary key fingerprint: FCF1 9B67 ... and bwt-0.2.3-x86_64-linux.tar.gz: OK.

Reproducible builds

The builds are fully reproducible.

You can verify the checksums against the v0.2.3 builds on Travis CI: https://travis-ci.org/github/bwt-dev/bwt/builds/763199070

See more details here.

Go to Repo Go to Release

zkSNACKs/WalletWasabi: v1.1.12.5

Published: 2021-03-16 17:43:47 UTC


Summary

The recent macOS update broke the initialization of the build-in Tor client in Wasabi. As a result, the client was not able to start Tor client, thus it was not able to connect to our Backend.

  • Tor fix on the newest macOS.
  • Update HWI to 2.0.0
  • Add Ledger Nano X support

Newbie Guide

While setting up Wasabi is straightforward, even a Linux wizard with the longest beard can get stuck on the most basic tasks. Consider taking a look at the Installation Instructions guide.

Advanced Guide

If you want to build Wasabi from source code or update the source code check out these instructions.

From version 1.1.3 Wasabi also introduces reproducible builds: Deterministic Build Guide

Build with .NET Core 3.1.407-win-x64.

FAQ

  • Frequently asked questions here.
  • Requirements? x64, Linux, >Win10, >macOS 10.13.

Release Notes

Go to Repo Go to Release

bitcoin-core/HWI: 2.0.0

Published: 2021-03-15 18:00:02 UTC


Also available on PyPi and can be installed with pip install -U hwi

Added

  • BitBox02 multisig signing.
  • Documentation automatically generated with sphinx and hosted on https://hwi.readthedocs.io.
  • Support for Python 3.9.
  • Trezor allows transactions with OP_RETURN outputs.
  • Full type annotations within hwilib and type checking.
  • Updated documentation for Bitcoin Core descriptor wallets.
  • Device support policy
  • Enforce that the Ledger is in either the Bitcoin or Bitcoin Testnet apps.

Changed

  • --sh_wpkh and --wpkh options have been replaced with --addr-type with the options legacy, sh_wit, and wit.
  • --testnet option replaced with --chain with the options main, test, signet, and regtest.
  • Overhauled descriptors implementation to be similar to Bitcoin Core's descriptors implementation.
  • Replaced HardwareWalletClient.display_address with display_singlesig_address and display_multisig_address.
  • Overhauled HardwareWalletClient functions to return the correct objects rather than string dictionaries.
  • Raise errors and exceptions instead of returning string dictionary containing error.
  • bech32.py, base58.py, cli.py, and gui.py are made internal modules.
  • serializations.py is split into tx.py, psbt.py with some functions made internal with _script.py and _serialize.py.
  • getmasterxpub takes options for chain type, address type, and BIP 44 account in order to provide the master xpub accordingly.

Removed

  • Removed option to provide redeem script to displayaddress.

Fixed

  • Fixed Ledger change path detection.
  • Fixed Ledger message signing when the signature is shorter than expected.
  • Fixed Trezor One pin sending when a passphrase is expected.
  • Fixed handling of sortedmulti() descriptors. Some devices which only supported key sorting will be no longer allow multi() descriptors. The multisigs that devices use when given a sortedmulti() descriptor will now match what Bitcoin Core derives for those descriptors.
  • Several fixes to device enumeration.
  • installudevrules will search for the correct binaries in the PATH rather than assuming their locations.

Go to Repo Go to Release

bitcoin-core/HWI: 2.0.0-rc.3

Published: 2021-03-11 22:15:31 UTC


Release Candidate 3 for HWI 2.0.0

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.7.0

Published: 2021-03-11 14:50:16 UTC


See blog post for more details.

Features:

  • New Wallet Setup UI (see #2164, #2296) @dennisreimann @dstrukt
  • Greenfield: New on-chain wallet API @Kukks
  • Greenfield: Ability to configure store's lightning payment methods @Kukks
  • Allow an invoice to be marked invalid/complete even from the new state @Kukks
  • Point of Sale and Crowdfund: Allow custom buy button text (see #2299) @dennisreimann
  • Specter wallet file import (see #2252) @dennisreimann

Improvements:

  • Reenabling uppercase BECH32 in QR codes (see #2110) @rockstardev
  • If a store is set to internal node, use "Internal Node" as connection string rather than the actual connection string. @NicolasDorier
  • Improve Policies options UX in server settings (see #2307) @dstrukt @dennisreimann
  • Fix view payment request loading spinner alignment @bumbummen99
  • Fix cart pay button loading spinner vertical alignment @bumbummen99
  • Invoices list: Remove icon indicator for onchain (see #2240) @dennisreimann
  • Login: Improve tab navigation for input fields (see #2258) @dennisreimann

Bug fixes:

  • Hovering the mouse pointer on invoice logs row would make them unreadable @bolatovumar
  • Remove exchange rates that lost support in Coingecko @NicolasDorier
  • Get invoice in greenfield was crashing if invoiceId did not exist @NicolasDorier
  • Getting a file from the storage service which did not exist would return http 500 instead of 404 @NicolasDorier
  • Fix direct URL for local storage with custom root path #2318 @bolatovumar
  • The pay button would not show up properly on some websites @bolatovumar
  • Profile email change should check email's availability @NicolasDorier
  • Fixed mysql/sqlite support @ketominer
  • Checkout: Fix scan/copy tab sizes with varying content (see #2264) @dennisreimann
  • Greenfield: Lightning API would return HTTP 500 if store owner did not set the connection string @dennisreimann
  • Point of Sale: The custom price was not properly working (see #2248) @bolatovumar

Go to Repo Go to Release

bitcoin-core/HWI: 2.0.0-rc.2

Published: 2021-03-05 19:53:45 UTC


Release Candidate 2 for HWI 2.0.0

Go to Repo Go to Release

ACINQ/phoenix: v1.4.8

Published: 2021-03-04 15:20:44 UTC


Main changes

The channel creation fee for pay-to-open has been increased: it's still 0.1% but there is now a 1000 sat minimum. The manual confirmation dialog and asynchronous pay-to-open logic have been removed. The FTUE page regarding the channel opening cost has been updated as well as the swap-in dialog so that we can display this new fee minimum value.

Complete list of changes

Verifying signatures

You will need gpg and our release signing key E434ED292E85643A. Note that you can get it: - from our website: https://acinq.co/pgp/padioupm.asc - from github user @pm47, a committer on eclair: https://api.github.com/users/pm47/gpg_keys

To import our signing key: $ gpg --import padioupm.asc

To verify the release file checksums and signatures: $ gpg -d SHA256SUMS.asc > SHA256SUMS.stripped $ sha256sum -c SHA256SUMS.stripped

Go to Repo Go to Release

ACINQ/phoenix: v1.4.7

Published: 2021-03-04 15:20:33 UTC


Main changes

Improve LNURL error feedback

Errors returned by LNURL services were not properly handled and information was lost, causing confusion, especially for LNURL-withdraw.

Notify user when channel opening is rejected

If a new channel must be created to receive an incoming payment but the amount is below the channel creation threshold, a notification is displayed. Note that this is not enabled yet because changes on the peer side are also needed.

-- edit: this is now enabled.

Complete list of changes

Thanks again @bitcoinuser for updating the Portuguese-Brazilian translation.

Verifying signatures

You will need gpg and our release signing key E434ED292E85643A. Note that you can get it: - from our website: https://acinq.co/pgp/padioupm.asc - from github user @pm47, a committer on eclair: https://api.github.com/users/pm47/gpg_keys

To import our signing key: $ gpg --import padioupm.asc

To verify the release file checksums and signatures: $ gpg -d SHA256SUMS.asc > SHA256SUMS.stripped $ sha256sum -c SHA256SUMS.stripped

Go to Repo Go to Release

bisq-network/bisq: v1.5.9

Published: 2021-03-03 12:38:54 UTC


A newer version is already available! Please don’t use this version anymore.

This is a hotfix release that fixes an issue when trading messages are resent on application startup.

Here are the release notes from v1.5.8:

Release notes

This release improves DAO charts to make it easier to drill into the DAO economics, it ships improvements for Amazon eGift Cards, adds new SEPA countries and the possibility to try out pre-release versions without the need of manual downloads and verification (see settings)...and lots of bug fixes and improvements across the board.

DAO

UI

Trading

Wallet

Reliability

Privacy

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.9.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.9.jar The output need to match the value from the Bisq-1.5.9.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.9.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @huey735
  • @jakub_cz
  • @jmacxx
  • @sqrrm
  • @stejbac
  • @bisqubutor

A special thanks to our first time contributor:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

ACINQ/eclair: v0.5.1

Published: 2021-03-03 12:33:57 UTC


This release includes many bug fixes and improvements, a new API and monitoring updates. It is fully compatible with 0.5.0 (and all previous versions of eclair).

Major changes

Improved startup performance

When eclair starts up and restores channels, it makes a lot of calls to bitcoind to check the status of each channel. We improved our calling pattern to greatly reduce the number of calls made when some channels are closing. This is particularly noticeable when the mempool is quite full and you have many channels.

See #1699 for details.

Gossip sync improvements

Most of the bandwidth consumed by lightning nodes is due to gossip (syncing the network graph). When your eclair node has a lot of peers and doesn't use a sync-whitelist, you may end up syncing with many different peers and obtaining redundant information, thus wasting bandwidth. Eclair now only syncs with peers you have a channel with to reduce bandwidth usage.

Anchor outputs

This release contains a lot of changes for the upcoming anchor outputs commitment format:

  • the feerate of the commitment transaction is kept low to improve off-chain channel usage
  • transactions with multiple inputs and outputs are now supported
  • CPFP and RBF utilities have been added to increase the feerate of commitment and htlc transactions

While you can start experimenting with this commitment format, it is still not safe to activate in production. Anchor outputs is a complex and subtle change that requires re-architecting most of our transaction broadcasting logic and utxo management. We are making steady progress towards that, but we're not there yet.

Monitoring changes

Kamon tracing has been removed in this release. It was too invasive in the codebase, generally unused and was costing some bandwidth. We've found that metrics and logs are enough to correctly monitor your eclair node.

Additional metrics to monitor transaction signing have been added. The rate of transaction signatures is a good indicator of how busy your node is.

API changes

This release adds a new path-finding API:

  • findroutebetweennodes lets you inspect the network graph by looking for routes between two nodes (whereas findroute only allowed finding routes between your node and a remote node)

Head over to our API documentation for more details.

Miscellaneous improvements and bug fixes

  • Correctly sort addresses in its node_announcement (#1693)
  • Allow 2016 blocks before unconfirmed channels are forgotten (#1692)
  • Re-emit private channel updates more frequently, improving payments to mobile wallets (#1671)
  • Correctly handle channel failures in private routing hints, fixing an edge case for payments to mobile wallets (#1675)
  • Drop support for initial_routing_sync: this was bandwidth-heavy and now unnecessary (#1683)
  • Fix an MPP-send edge-case (#1685)
  • Fix race condition between outgoing payment and peer disconnection (#1688)
  • Fix race condition between update_fee and shutdown, which could lead to channels stuck in shutdown (#1661)
  • Ensure transactions we publish always meet bitcoin's min_relay_fee (#1687)
  • Fix an edge case where an HTLC failure was not correctly relayed upstream if revoke_and_ack had not been received (#1706)

Verifying signatures

You will need gpg and our release signing key 7A73FE77DE2C4027. Note that you can get it:

To import our signing key:

sh $ gpg --import drouinf.asc

To verify the release file checksums and signatures:

sh $ gpg -d SHA256SUMS.asc > SHA256SUMS.stripped $ sha256sum -c SHA256SUMS.stripped

Building

Eclair builds are deterministic. To reproduce our builds, please use the following environment (*):

  • Ubuntu 19.10
  • AdoptOpenJDK 11.0.6
  • Maven 3.6.3

Use the following command to generate the eclair-node package:

sh mvn clean install -DskipTests

That should generate eclair-node/target/eclair-node-0.5.1-XXXXXXX-bin.zip with sha256 checksums that match the one we provide and sign in SHA256SUMS.asc

(*) You may be able to build the exact same artefacts with other operating systems or versions of JDK 11, we have not tried everything.

Upgrading

This release is fully compatible with Eclair v0.5.0. You don't need to close your channels, just stop eclair, upgrade and restart.

Changelog

  • 923ca26f Set version to 0.5.1-SNAPSHOT (#1651)
  • b75f6c36 Fix duplicate commit id in awseb bundle (#1650)
  • 5f9d0d91 Relax cltv-expiry-delta requirement when selecting a channel to relay (#1655)
  • dd8975ae Make ChannelVersion methods public (#1656)
  • 7343283f Add test for duplicate temporary channel id (#1660)
  • 629c2e69 Fix rare race conditions in integration tests (#1653)
  • b477d179 Update build instructions for front (#1658)
  • e369ba9a More aggressively re-emit private channel updates (#1671)
  • d40b321d Blockchain watchdogs use unique actor name (#1667)
  • 9c4ab7d9 Fix HTLC fulfill race condition in integration spec (#1666)
  • 81f15aab Refactor and improve some channel tests (#1654)
  • 54ca2922 Remove kamon tracing (#1662)
  • 34e901db Clarify default relay fee change (#1673)
  • c75d9143 Fix failing reconnection tests (#1678)
  • 0127ace4 Remote failure updating routing hint (#1675)
  • ac054a2b Only sync with channel peers (#1587)
  • d0531883 Truncate hex strings in front logs (#1679)
  • 49023625 Refactor channel test helpers (#1682)
  • f241ef93 Remove support for initialroutingsync (#1683)
  • 63d972bd Fix a few typos (#1684)
  • 5d3958dd Fix MPP path-finding edge case (#1685)
  • 15c1837d Add tx signing metrics (#1659)
  • 72179de0 PaymentLifecycle handle disconnected peers (#1688)
  • fdeb3ce7 Correctly set gossip sync_complete (#1668)
  • 36e8c056 Shutdown and UpdateFee should not be intertwined (#1661)
  • 2a359c6a Publish txs with min-relay-fee met (#1687)
  • 82e5b596 Sort addresses in node announcement (#1693)
  • 3a94a804 Reject unreasonable remote dust limit (#1694)
  • fdb57b43 Find route between nodes (#1695)
  • 9618a6a7 Add a maximum fee threshold for anchor outputs (#1672)
  • ab89851c Relax single tx input requirements (#1677)
  • 08351508 Update funding timeout fundee (#1692)
  • d9c0b862 Refactor bitcoin clients (#1697)
  • 5163749a [eclair-cli] Use multiplatform escape sequence
  • fa759f1e Fix PaymentLifecycle warning (#1703)
  • c1bf9bd1 Optimize watching for spending txs (#1699)
  • d02b900a Fix annoying compiler warning (#1704)
  • a3c477e3 Address all intellij warnings for Channel.scala (#1705)
  • bf2a35f7 Relay partially failed htlcs when closing (#1706)
  • 5d662fc3 Set anchor output feerates when force-closing (#1702)
  • 8065d0bb Add a serializer for DoSync (#1708)
  • 8d4da2fa Improve channel state tests (#1709)
  • 26468862 fixup! Improve channel state tests (#1709) (#1712)
  • 34796691 Disable jdbc instrumentation by default (#1713)
  • 98bb7be7 Set version to 0.5.1 (#1707)

Thanks to our new contributors, @tompro and @ariskk!

Go to Repo Go to Release

BlueWallet/BlueWallet: v6.0.6

Published: 2021-03-02 14:09:23 UTC


New

  • Offline Signing and Cold Storage

Allows a BlueWallet app on any mobile phone to sign transactions offline. Using PSBTs and Airgapped Animated QR codes to transmit information on the dark.

  • Long press on Transaction Row to get shortcuts
  • Tap and hold to Share QRCode image
  • QR code scanner to wallet/broadcast screen
  • Apple Watch Price Complication
  • Copying Block Explorer Link
  • If unable to connect to server, show alert

Fixed

  • Wallet delete would cause crash
  • Browser crash when accessing wallet
  • Widgets were not showing on drawer
  • Screen titles language
  • QRCode save alert description
  • QRCode size on large devices
  • Transactions/details screen graceful error handling
  • Electrum protocol graceful error handling
  • Better bitcoinscript error handling
  • Fee selection in darkmode

Languages updates

  • Arabic, Russian, Greek, Polish, Japanese, Portuguese, Portuguese Brazilian, Swedish, Thai, Finnish, Persian, Dutch, German, French and Chinese.

A special shout out to @bitkarrot and @et_sam from the Hong Kong Bitcoin Association on the Chinese translation work.

Download

Appstore

Playstore

Go to Repo Go to Release

bisq-network/bisq: v1.5.8

Published: 2021-03-01 14:26:42 UTC


A newer version is already available! Please don’t use this version anymore.

This is a follow-up release that obtains the minimum withdrawal fee from mempool.space to avoid transactions being rejected by the bitcoin network for having too low a fee.

Here are the release notes from v1.5.7:

Release notes

This release improves DAO charts to make it easier to drill into the DAO economics, it ships improvements for Amazon eGift Cards, adds new SEPA countries and the possibility to try out pre-release versions without the need of manual downloads and verification (see settings)...and lots of bug fixes and improvements across the board.

DAO

UI

Trading

Wallet

Reliability

Privacy

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.8.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.8.jar The output need to match the value from the Bisq-1.5.8.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.8.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @huey735
  • @jakub_cz
  • @jmacxx
  • @sqrrm
  • @stejbac
  • @bisqubutor

A special thanks to our first time contributor:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

getumbrel/umbrel: v0.3.7

Published: 2021-02-28 15:02:41 UTC


This update includes minor bug fixes for improved stability and security of your Umbrel.

If you face any difficulties while updating, please message us on Telegram: https://t.me/getumbrel

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.6...v0.3.7

Go to Repo Go to Release

getumbrel/umbrel: v0.3.6

Published: 2021-02-27 16:44:00 UTC


Umbrel v0.3.6 brings some performance improvements to the Mempool app, updates LND to v0.12.1, and includes some other small bug fixes.

If you face any difficulties while updating, please message us on Telegram: https://t.me/getumbrel

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.5...v0.3.6

Go to Repo Go to Release

bisq-network/bisq: v1.5.7

Published: 2021-02-26 19:18:20 UTC


A newer version is already available! Please don’t use this version anymore.

Release notes

This release improves DAO charts to make it easier to drill into the DAO economics, it ships improvements for Amazon eGift Cards, adds new SEPA countries and the possibility to try out pre-release versions without the need of manual downloads and verification (see settings)...and lots of bug fixes and improvements across the board.

DAO

UI

Trading

Wallet

Reliability

Privacy

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.7.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.7.jar The output need to match the value from the Bisq-1.5.7.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.7.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @huey735
  • @jakub_cz
  • @jmacxx
  • @sqrrm
  • @stejbac
  • @bisqubutor

A special thanks to our first time contributor:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.1-beta

Published: 2021-02-23 18:16:42 UTC


Database Migrations

There are no database migrations in v0.12.1-beta.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.12.1-beta.sig and manifest-v0.12.1-beta.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.12.1-beta.sig manifest-v0.12.1-beta.txt

You should see the following if the verification was successful:

gpg: Signature made Mon Feb 22 19:23:11 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.1-beta.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.1-beta.sig.ots ots verify manifest-v0.12.1-beta.txt.ots

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.1-beta gpg: Signature made Mon Feb 22 17:11:56 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.1-beta /verify-install.sh v0.12.1-beta $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.1-beta.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.1-beta.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Spec Compatibility

Gossip Propagation Improvements

This release reverts the removal of the premature channel update cache that was removed in 0.12.0-beta. Absence of the cache was seen to cause issues with channel update propagation, so the change is reverted to restore the pre-0.12.0-beta behavior and stability. The current plan is to reschedule the cache's removal for 0.13 after performing more extensive investigation.

In addition, the gossip throttling adding in v0.12.0 has been refactored to be less aggressive with respect to non-keepalive channel updates, i.e. channel updates that differ in more than just the timestamp. Previously lnd would drop all but the first such update that it received over the course of a block, which has reportedly been too restrictive and resulted in degraded propagation of routine channel updates.

The new throttling logic now employs a directional token bucket rate limiter, the same approach used by lnd to rate-limit gossip requests from sync peers. Each token bucket is configured to drop non-keepalive updates arriving faster that once per minute, yet permitting bursts of up 10 updates. This improves on the previous approach in a few ways: - Updates are now limited with respect to a consistent time source, i.e. seconds, rather than block height. This makes it easier to reason about when channel updates might get dropped as an average user, and places a deterministic bound on the next time a normal user can reliably update their channel again. - The rate limits are now applied directionally, so that one end of the channel cannot cause their counterparty's channel updates to be dropped. This has the effect of making the penalization more precise, and better targets individuals that exhibit abusive behavior. - By factoring in bursts, it provides enough tolerance for cases where policy changes that may occur in quick succession, e.g. disable followed by reenable, or modifying a channel policy immediately after open.

No Gossip Mode

This release includes support for a no-graph sync mode which can be enabled by setting numgraphsyncpeers=0. In prior versions, running lnd in this configuration would still trigger an initial historical sync with the first connected peer on each restart. The behavior was modified under the assumption that users who have already configured lnd to not receive gossip updates probably don't want to sync the graph at all.

This mode is especially helpful to wallet developers that choose to outsource pathfinding via their own service, or purely forwarding nodes that never need to perform pathfinding.

Pinned Gossip Syncers

Typically lnd performs this historical channel reconciliation periodically, rotating between the set of all active peers, and attempting to keep numgraphsyncpeers (defaults to 3) in a state where they are receiving new gossip messages. Due to the eventually consistent properties of this algorithm (and the gossip protocol in general), there are some cases that lead to long delays in a node receiving newer updates. Notably, if a node has many peers, then it may be a while before the sync rotation algorithm queries a given peer for newer updates.

To provide more control, a new configuration option has been added allowing users to pin their nodes into an ActiveSync with particular nodes. Each time a connection is established with a pinned syncer, lnd will first perform a historical channel reconciliation, followed by a request for the pinned syncer to forward all new gossip messages. Doing so allows users to keep their routing table tightly synchronized with nodes in their list of configured, pinned syncers. Users can add one or more pinned syncers via: gossip.pinned-syncers=<pubkey1> gossip.pinned-syncers=<pubkey2> This can be especially useful for services that run multiple, well-connected lnd nodes, and want their own nodes to maintain similar views of the channel graph. Users can also use gossip.pinned-syncers in combination with numgraphsyncpeers=0 to only sync from a specific peer.

RPC Changes

  • lnd 0.12.1-beta now exposes the HTLC attempt_id on response from TrackPayment. Internally, lnd uses attempt_id as a unique identifier for each HTLC it sends out, and to provide a total ordering on all HTLC sent by the daemon. This identifier can be used by developers to better reflect progress of a payment, making it easier to extract per-HTLC state deltas rather than displaying the full payment state every time.
    • Adds a new MaxShardSizeMsat argument to SendPayment, allowing users to cap the maximum value of any MPP shard sent out by lnd. Users can now set this from lncli via either the max_shard_size_sat or max_shard_size_msat field.

Deterministic Build / Release Verification

Developer Toolchain

Bug Fixes

Full Changelog

Contributors (Alphabetical Order)

Andras Banki-Horvath Carla Kirk-Cohen Conner Fromknecht Eugene Siegel Jake Sylvestre Johan T. Halseth Joost Jager Juan Pablo Civile Olaoluwa Osuntokun Oliver Gugger rockstardev Umar Bolatov Vlad Stan Wilmer Paulino

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.2.2

Published: 2021-02-21 13:31:31 UTC


v1.2.2 (Hotfix release for Send transaction error)

Binaries

There are two types of binaries:

Specter Desktop

It's a windowed GUI application with Specter server included. Supported platforms: Windows, MacOS, Linux (x86_64)

Note on Linux: you need to set up udev rules (included in the archive). Check out readme.

Note on macOS: The current build supports only macOS Catalina (10.15) or higher. If you'd like to run Specter on an older macOS version, you can install Specter from Pip.

specterd

It's a command-line program that only runs Specter server. Supported platforms: Windows, MacOS, Linux (x86_64)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @stepansnigirev's GPG key. You can get the public key from here: https://stepansnigirev.com/ss-specter-release.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 6F16 E354 F833 93D6 E52E C25F 36ED 357A B24B 915F, short id: 36ed357ab24b915f

Release notes

  • Bugfix: Hot fix for: Transactions sending/ signing failure
  • Bugfix: Hot fix for Tor connections
  • Bugfix: a minor bug that always shows address as used #927 (jleo84)
  • Bugfix: cypress-tests #961 (Kim Neunert)
  • Bugfix: Fix key initial format in wallet info #925 (benk10)
  • Bugfix: Use the request session API for authentification #958 (Jürgen Hötzel)
  • Chore: Bump cryptography from 3.2 to 3.3.2 #943 (dependabot[bot])
  • Chore: enable dev-restart-login #960 (Kim Neunert)
  • Chore: fix release-notes #928 (Kim Neunert)
  • Docs: Typos #941 (Max Hillebrand)
  • Feature: Add failed wallets popup #952 (benk10)
  • Feature: Freeze UTXO and select UTXO for new transaction from the UTXO tab #956 (benk10)
  • Feature: Use descriptor wallet for Bitcoin Core >= v0.21.0 #737 (Sjors Provoost)
  • UIUX: Add reason for why device is disabled in new wallet screen #932 (benk10)
  • UIUX: pass result of createpsbt call back to calculateEstimatedFee #945 (djpnewton)
  • UIUX: Preserve form status when creating a transaction #938 (djpnewton)

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.2.1

Published: 2021-02-20 17:26:35 UTC


v1.2.1 (Hotfix release for Tor connections)

Binaries

There are two types of binaries:

Specter Desktop

It's a windowed GUI application with Specter server included. Supported platforms: Windows, MacOS, Linux (x86_64)

Note on Linux: you need to set up udev rules (included in the archive). Check out readme.

Note on macOS: The current build supports only macOS Catalina (10.15) or higher. If you'd like to run Specter on an older macOS version, you can install Specter from Pip.

specterd

It's a command-line program that only runs Specter server. Supported platforms: Windows, MacOS, Linux (x86_64)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @stepansnigirev's GPG key. You can get the public key from here: https://stepansnigirev.com/ss-specter-release.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 6F16 E354 F833 93D6 E52E C25F 36ED 357A B24B 915F, short id: 36ed357ab24b915f

Release notes

  • Bugfix: Hot fix for Tor connections
  • Bugfix: a minor bug that always shows address as used #927 (jleo84)
  • Bugfix: cypress-tests #961 (Kim Neunert)
  • Bugfix: Fix key initial format in wallet info #925 (benk10)
  • Bugfix: Use the request session API for authentification #958 (Jürgen Hötzel)
  • Chore: Bump cryptography from 3.2 to 3.3.2 #943 (dependabot[bot])
  • Chore: enable dev-restart-login #960 (Kim Neunert)
  • Chore: fix release-notes #928 (Kim Neunert)
  • Docs: Typos #941 (Max Hillebrand)
  • Feature: Add failed wallets popup #952 (benk10)
  • Feature: Freeze UTXO and select UTXO for new transaction from the UTXO tab #956 (benk10)
  • Feature: Use descriptor wallet for Bitcoin Core >= v0.21.0 #737 (Sjors Provoost)
  • UIUX: Add reason for why device is disabled in new wallet screen #932 (benk10)
  • UIUX: pass result of createpsbt call back to calculateEstimatedFee #945 (djpnewton)
  • UIUX: Preserve form status when creating a transaction #938 (djpnewton)

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.2.0

Published: 2021-02-20 15:04:18 UTC


Binaries

There are two types of binaries:

Specter Desktop

It's a windowed GUI application with Specter server included. Supported platforms: Windows, MacOS, Linux (x86_64)

Note on Linux: you need to set up udev rules (included in the archive). Check out readme.

Note on macOS: The current build supports only macOS Catalina (10.15) or higher. If you'd like to run Specter on an older macOS version, you can install Specter from Pip.

specterd

It's a command-line program that only runs Specter server. Supported platforms: Windows, MacOS, Linux (x86_64)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @stepansnigirev's GPG key. You can get the public key from here: https://stepansnigirev.com/ss-specter-release.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 6F16 E354 F833 93D6 E52E C25F 36ED 357A B24B 915F, short id: 36ed357ab24b915f

Release notes

  • Bugfix: a minor bug that always shows address as used #927 (jleo84)
  • Bugfix: cypress-tests #961 (Kim Neunert)
  • Bugfix: Fix key initial format in wallet info #925 (benk10)
  • Bugfix: Use the request session API for authentification #958 (Jürgen Hötzel)
  • Chore: Bump cryptography from 3.2 to 3.3.2 #943 (dependabot[bot])
  • Chore: enable dev-restart-login #960 (Kim Neunert)
  • Chore: fix release-notes #928 (Kim Neunert)
  • Docs: Typos #941 (Max Hillebrand)
  • Feature: Add failed wallets popup #952 (benk10)
  • Feature: Freeze UTXO and select UTXO for new transaction from the UTXO tab #956 (benk10)
  • Feature: Use descriptor wallet for Bitcoin Core >= v0.21.0 #737 (Sjors Provoost)
  • UIUX: Add reason for why device is disabled in new wallet screen #932 (benk10)
  • UIUX: pass result of createpsbt call back to calculateEstimatedFee #945 (djpnewton)
  • UIUX: Preserve form status when creating a transaction #938 (djpnewton)

Go to Repo Go to Release

getumbrel/umbrel: v0.3.5

Published: 2021-02-20 10:15:13 UTC


Umbrel v0.3.5 fixes some bugs that were preventing the sending of transactions and causing Umbrel to hang on the "Loading LND..." message.

If your update gets stuck for some reason, please message us on Telegram: https://t.me/getumbrel

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.4...v0.3.5

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.1-beta.rc6

Published: 2021-02-19 20:02:23 UTC


Database Migrations

There are no database migrations in v0.12.1-beta.rc6.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.12.1-beta.rc6.sig and manifest-v0.12.1-beta.rc6.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.12.1-beta.rc6.sig manifest-v0.12.1-beta.rc6.txt

You should see the following if the verification was successful:

gpg: Signature made Thu Feb 18 18:01:34 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.1-beta.rc6.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.1-beta.rc6.sig.ots -f manifest-roasbeef-v0.12.1-beta.rc6.sig

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.1-beta.rc6 gpg: Signature made Thu Feb 18 17:04:03 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.1-beta.rc6 $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.1-beta.rc6 /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.1-beta.rc6.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.1-beta.rc6.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc6" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc6" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Spec Compatibility

Gossip Propagation Improvements

This release reverts the removal of the premature channel update cache that was removed in 0.12.0-beta. Absence of the cache was seen to cause issues with channel update propagation, so the change is reverted to restore the pre-0.12.0-beta behavior and stability. The current plan is to reschedule the cache's removal for 0.13 after performing more extensive investigation.

In addition, the gossip throttling adding in v0.12.0 has been refactored to be less aggressive with respect to non-keepalive channel updates, i.e. channel updates that differ in more than just the timestamp. Previously lnd would drop all but the first such update that it received over the course of a block, which has reportedly been too restrictive and resulted in degraded propagation of routine channel updates.

The new throttling logic now employs a directional token bucket rate limiter, the same approach used by lnd to rate-limit gossip requests from sync peers. Each token bucket is configured to drop non-keepalive updates arriving faster that once per minute, yet permitting bursts of up 10 updates. This improves on the previous approach in a few ways: - Updates are now limited with respect to a consistent time source, i.e. seconds, rather than block height. This makes it easier to reason about when channel updates might get dropped as an average user, and places a deterministic bound on the next time a normal user can reliably update their channel again. - The rate limits are now applied directionally, so that one end of the channel cannot cause their counterparty's channel updates to be dropped. This has the effect of making the penalization more precise, and better targets individuals that exhibit abusive behavior. - By factoring in bursts, it provides enough tolerance for cases where policy changes that may occur in quick succession, e.g. disable followed by reenable, or modifying a channel policy immediately after open.

No Gossip Mode

This release includes support for a no-graph sync mode which can be enabled by setting numgraphsyncpeers=0. In prior versions, running lnd in this configuration would still trigger an initial historical sync with the first connected peer on each restart. The behavior was modified under the assumption that users who have already configured lnd to not receive gossip updates probably don't want to sync the graph at all.

This mode is especially helpful to wallet developers that choose to outsource pathfinding via their own service, or purely forwarding nodes that never need to perform pathfinding.

Pinned Gossip Syncers

Typically lnd performs this historical channel reconciliation periodically, rotating between the set of all active peers, and attempting to keep numgraphsyncpeers (defaults to 3) in a state where they are receiving new gossip messages. Due to the eventually consistent properties of this algorithm (and the gossip protocol in general), there are some cases that lead to long delays in a node receiving newer updates. Notably, if a node has many peers, then it may be a while before the sync rotation algorithm queries a given peer for newer updates.

To provide more control, a new configuration option has been added allowing users to pin their nodes into an ActiveSync with particular nodes. Each time a connection is established with a pinned syncer, lnd will first perform a historical channel reconciliation, followed by a request for the pinned syncer to forward all new gossip messages. Doing so allows users to keep their routing table tightly synchronized with nodes in their list of configured, pinned syncers. Users can add one or more pinned syncers via: gossip.pinned-syncers=<pubkey1> gossip.pinned-syncers=<pubkey2> This can be especially useful for services that run multiple, well-connected lnd nodes, and want their own nodes to maintain similar views of the channel graph. Users can also use gossip.pinned-syncers in combination with numgraphsyncpeers=0 to only sync from a specific peer.

RPC Changes

  • lnd 0.12.1-beta.rc6 now exposes the HTLC attempt_id on response from TrackPayment. Internally, lnd uses attempt_id as a unique identifier for each HTLC it sends out, and to provide a total ordering on all HTLC sent by the daemon. This identifier can be used by developers to better reflect progress of a payment, making it easier to extract per-HTLC state deltas rather than displaying the full payment state every time.
    • Adds a new MaxShardSizeMsat argument to SendPayment, allowing users to cap the maximum value of any MPP shard sent out by lnd. Users can now set this from lncli via either the max_shard_size_sat or max_shard_size_msat field.

Deterministic Build / Release Verification

Developer Toolchain

Bug Fixes

Full Changelog

Contributors (Alphabetical Order)

Andras Banki-Horvath Carla Kirk-Cohen Conner Fromknecht Eugene Siegel Jake Sylvestre Johan T. Halseth Joost Jager Juan Pablo Civile Olaoluwa Osuntokun Oliver Gugger rockstardev Umar Bolatov Vlad Stan Wilmer Paulino

Go to Repo Go to Release

mempool/mempool: v2.1.2

Published: 2021-02-18 11:47:39 UTC


This is a patch release that optimizes memory usage for embedded devices like Raspberry Pi

Notes: * The disk cache now has its own folder, so mv cache*.json ./cache/ before restart to migrate

Changes: * Optimize memory usage when writing disk cache (#342) * Reduce backend maximum heap size setting to 2G (#345) * Enable mempool clear protection on all backends (#335) * Make mempool clear protection timeout configurable (#343) * Minor tweaks to About page text, links (#350) * Logo design update (#349) by @pedromvpg * Fix style on block hover (#347) by @Czino and @Eric-Machinas

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.1.1-pre1

Published: 2021-02-18 07:56:16 UTC


This is a pre-release. Use this with caution!

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.1-beta.rc5

Published: 2021-02-18 00:33:15 UTC


Database Migrations

There are no database migrations in v0.12.1-beta.rc5.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-bitconner-v0.12.1-beta.rc5.sig and manifest-v0.12.1-beta.rc5.txt are in the current directory) with:

gpg --verify manifest-bitconner-v0.12.1-beta.rc5.sig manifest-v0.12.1-beta.rc5.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Feb 17 14:16:06 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.1-beta.rc5.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.1-beta.rc5.sig.ots -f manifest-roasbeef-v0.12.1-beta.rc5.sig

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.1-beta.rc5 gpg: Signature made Wed Feb 17 12:59:15 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.1-beta.rc5 $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.1-beta.rc5 /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.1-beta.rc5.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.1-beta.rc5.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc5" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc5" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Spec Compatibility

Gossip Propagation Improvements

This release reverts the removal of the premature channel update cache that was removed in 0.12.0-beta. Absence of the cache was seen to cause issues with channel update propagation, so the change is reverted to restore the pre-0.12.0-beta behavior and stability. The current plan is to reschedule the cache's removal for 0.13 after performing more extensive investigation.

In addition, the gossip throttling adding in v0.12.0 has been refactored to be less aggressive with respect to non-keepalive channel updates, i.e. channel updates that differ in more than just the timestamp. Previously lnd would drop all but the first such update that it received over the course of a block, which has reportedly been too restrictive and resulted in degraded propagation of routine channel updates.

The new throttling logic now employs a directional token bucket rate limiter, the same approach used by lnd to rate-limit gossip requests from sync peers. Each token bucket is configured to drop non-keepalive updates arriving faster that once per minute, yet permitting bursts of up 10 updates. This improves on the previous approach in a few ways: - Updates are now limited with respect to a consistent time source, i.e. seconds, rather than block height. This makes it easier to reason about when channel updates might get dropped as an average user, and places a deterministic bound on the next time a normal user can reliably update their channel again. - The rate limits are now applied directionally, so that one end of the channel cannot cause their counterparty's channel updates to be dropped. This has the effect of making the penalization more precise, and better targets individuals that exhibit abusive behavior. - By factoring in bursts, it provides enough tolerance for cases where policy changes that may occur in quick succession, e.g. disable followed by reenable, or modifying a channel policy immediately after open.

No Gossip Mode

This release includes support for a no-graph sync mode which can be enabled by setting numgraphsyncpeers=0. In prior versions, running lnd in this configuration would still trigger an initial historical sync with the first connected peer on each restart. The behavior was modified under the assumption that users who have already configured lnd to not receive gossip updates probably don't want to sync the graph at all.

This mode is especially helpful to wallet developers that choose to outsource pathfinding via their own service, or purely forwarding nodes that never need to perform pathfinding.

Pinned Gossip Syncers

Typically lnd performs this historical channel reconciliation periodically, rotating between the set of all active peers, and attempting to keep numgraphsyncpeers (defaults to 3) in a state where they are receiving new gossip messages. Due to the eventually consistent properties of this algorithm (and the gossip protocol in general), there are some cases that lead to long delays in a node receiving newer updates. Notably, if a node has many peers, then it may be a while before the sync rotation algorithm queries a given peer for newer updates.

To provide more control, a new configuration option has been added allowing users to pin their nodes into an ActiveSync with particular nodes. Each time a connection is established with a pinned syncer, lnd will first perform a historical channel reconciliation, followed by a request for the pinned syncer to forward all new gossip messages. Doing so allows users to keep their routing table tightly synchronized with nodes in their list of configured, pinned syncers. Users can add one or more pinned syncers via: gossip.pinned-syncers=<pubkey1> gossip.pinned-syncers=<pubkey2> This can be especially useful for services that run multiple, well-connected lnd nodes, and want their own nodes to maintain similar views of the channel graph. Users can also use gossip.pinned-syncers in combination with numgraphsyncpeers=0 to only sync from a specific peer.

RPC Changes

  • lnd 0.12.1-beta.rc5 now exposes the HTLC attempt_id on response from TrackPayment. Internally, lnd uses attempt_id as a unique identifier for each HTLC it sends out, and to provide a total ordering on all HTLC sent by the daemon. This identifier can be used by developers to better reflect progress of a payment, making it easier to extract per-HTLC state deltas rather than displaying the full payment state every time.
    • Adds a new MaxShardSizeMsat argument to SendPayment, allowing users to cap the maximum value of any MPP shard sent out by lnd. Users can now set this from lncli via either the max_shard_size_sat or max_shard_size_msat field.

Deterministic Build / Release Verification

Developer Toolchain

Bug Fixes

Full Changelog

Contributors (Alphabetical Order)

Andras Banki-Horvath Carla Kirk-Cohen Conner Fromknecht Eugene Siegel Jake Sylvestre Johan T. Halseth Joost Jager Juan Pablo Civile Olaoluwa Osuntokun Oliver Gugger rockstardev Umar Bolatov Vlad Stan Wilmer Paulino

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.1-beta.rc4

Published: 2021-02-17 08:05:12 UTC


Database Migrations

There are no migrations in lnd v0.12.1-beta.rc4.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-bitconner-v0.12.1-beta.rc4.sig and manifest-v0.12.1-beta.rc4.txt are in the current directory) with:

gpg --verify manifest-bitconner-v0.12.1-beta.rc4.sig manifest-v0.12.1-beta.rc4.txt

You should see the following if the verification was successful:

gpg: Signature made Tue Feb 16 17:45:05 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.1-beta.rc4.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.1-beta.rc4.sig.ots -f manifest-roasbeef-v0.12.1-beta.rc4.sig

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.1-beta.rc4 gpg: Signature made Tue Feb 16 16:35:12 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.1-beta.rc4 $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.1-beta.rc4 /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.1-beta.rc4.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.1-beta.rc4.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc4" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc4" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Spec Compatibility

Gossip Propagation Improvements

This release reverts the removal of the premature channel update cache that was removed in 0.12.0-beta. Absence of the cache was seen to cause issues with channel update propagation, so the change is reverted to restore the pre-0.12.0-beta behavior and stability. The current plan is to reschedule the cache's removal for 0.13 after performing more extensive investigation.

In addition, the gossip throttling adding in v0.12.0 has been refactored to be less aggressive with respect to non-keepalive channel updates, i.e. channel updates that differ in more than just the timestamp. Previously lnd would drop all but the first such update that it received over the course of a block, which has reportedly been too restrictive and resulted in degraded propagation of routine channel updates.

The new throttling logic now employs a directional token bucket rate limiter, the same approach used by lnd to rate-limit gossip requests from sync peers. Each token bucket is configured to drop non-keepalive updates arriving faster that once per minute, yet permitting bursts of up 10 updates. This improves on the previous approach in a few ways: - Updates are now limited with respect to a consistent time source, i.e. seconds, rather than block height. This makes it easier to reason about when channel updates might get dropped as an average user, and places a deterministic bound on the next time a normal user can reliably update their channel again. - The rate limits are now applied directionally, so that one end of the channel cannot cause their counterparty's channel updates to be dropped. This has the effect of making the penalization more precise, and better targets individuals that exhibit abusive behavior. - By factoring in bursts, it provides enough tolerance for cases where policy changes that may occur in quick succession, e.g. disable followed by reenable, or modifying a channel policy immediately after open.

No Gossip Mode

This release includes support for a no-graph sync mode which can be enabled by setting numgraphsyncpeers=0. In prior versions, running lnd in this configuration would still trigger an initial historical sync with the first connected peer on each restart. The behavior was modified under the assumption that users who have already configured lnd to not receive gossip updates probably don't want to sync the graph at all.

This mode is especially helpful to wallet developers that choose to outsource pathfinding via their own service, or purely forwarding nodes that never need to perform pathfinding.

Pinned Gossip Syncers

Typically lnd performs this historical channel reconciliation periodically, rotating between the set of all active peers, and attempting to keep numgraphsyncpeers (defaults to 3) in a state where they are receiving new gossip messages. Due to the eventually consistent properties of this algorithm (and the gossip protocol in general), there are some cases that lead to long delays in a node receiving newer updates. Notably, if a node has many peers, then it may be a while before the sync rotation algorithm queries a given peer for newer updates.

To provide more control, a new configuration option has been added allowing users to pin their nodes into an ActiveSync with particular nodes. Each time a connection is established with a pinned syncer, lnd will first perform a historical channel reconciliation, followed by a request for the pinned syncer to forward all new gossip messages. Doing so allows users to keep their routing table tightly synchronized with nodes in their list of configured, pinned syncers. Users can add one or more pinned syncers via: gossip.pinned-syncers=<pubkey1> gossip.pinned-syncers=<pubkey2> This can be especially useful for services that run multiple, well-connected lnd nodes, and want their own nodes to maintain similar views of the channel graph. Users can also use gossip.pinned-syncers in combination with numgraphsyncpeers=0 to only sync from a specific peer.

RPC Changes

  • lnd 0.12.1-beta.rc4 now exposes the HTLC attempt_id on response from TrackPayment. Internally, lnd uses attempt_id as a unique identifier for each HTLC it sends out, and to provide a total ordering on all HTLC sent by the daemon. This identifier can be used by developers to better reflect progress of a payment, making it easier to extract per-HTLC state deltas rather than displaying the full payment state every time.
    • Changes the default value of the max-parts argument to SendPayment from 1 to 16. When called without any arguments previously, lnd would only ever attempt paths with 1 HTLC, and give up if it couldn't find such a path. This change makes it so that lnd will attempt to make payments using a small number of shards if it can't be done using a single HTLC.
    • Adds a new MaxShardSizeMsat argument to SendPayment, allowing users to cap the maximum value of any MPP shard sent out by lnd. Users can now set this from lncli via either the max_shard_size_sat or max_shard_size_msat field.

Deterministic Build / Release Verification

Developer Toolchain

Bug Fixes

Full Changelog

Contributors (Alphabetical Order)

Andras Banki-Horvath Carla Kirk-Cohen Conner Fromknecht Eugene Siegel Jake Sylvestre Johan T. Halseth Joost Jager Juan Pablo Civile Olaoluwa Osuntokun Oliver Gugger rockstardev Umar Bolatov Vlad Stan Wilmer Paulino

Go to Repo Go to Release

bisq-network/bisq: v1.5.6

Published: 2021-02-16 16:07:33 UTC


A newer version is already available! Please don’t use this version anymore.

This is a hotfix that fixes a startup issue with limit offers.

Here are the release notes from v1.5.5:

Release notes

ATTENTION: This release changes the trade protocol.

DO NOT specify trade ID or any other value in the 'reason for payment' field. LEAVE IT BLANK.

If it is mandatory for your payment service add a dash character ('-') or coordinate with your counterparty over trader chat to agree on a reason for payment.

This change reduces the chances that certain payment accounts get flagged. Please see https://github.com/bisq-network/bisq/issues/2869 for more details on this change.

This release introduces the option to create limit offers to be able to deactivate an offer if a certain price limit is reached. It also introduces cash-by-mail as a new payment method. In addition to multiple minor UI changes, we squashed lots of bugs and improved reliability and performance of the app across the board.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.6.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.6.jar The output need to match the value from the Bisq-1.5.6.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.6.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @jakub_cz
  • @jmacxx
  • @m52go
  • @sqrrm
  • @stejbac

A special thanks to our first time contributors:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

zkSNACKs/WalletWasabi: v1.1.12.4

Published: 2021-02-16 15:36:21 UTC


Summary

This silent release contains an updated Tor client that has the fix for the DDoS vulnerability. Users who encountered Tor connection problems should update their Wasabi.

  • Tor client update (Tor 0.4.4.7), fixed the DDos vulnerability.
  • Best effort node connection strategy, more stable peer connections. This will also solve the v2 onion service deprecation problem.
  • Bitcoin Knots v0.21.0

Newbie Guide

While setting up Wasabi is straightforward, even a Linux wizard with the longest beard can get stuck on the most basic tasks. Consider taking a look at the Installation Instructions guide.

Advanced Guide

If you want to build Wasabi from source code or update the source code check out these instructions.

From version 1.1.3 Wasabi also introduces reproducible builds: Deterministic Build Guide

Build with .NET Core 3.1.403-win-x64.

FAQ

  • Frequently asked questions here.
  • Requirements? x64, Linux, >Win10, >macOS 10.13.

Release Notes

Go to Repo Go to Release

getumbrel/umbrel: v0.3.4

Published: 2021-02-15 16:38:17 UTC


Umbrel v0.3.4 fixes a minor bug in v0.3.3 that was causing the update process to fail for some users.

Here's what new in Umbrel v0.3.3:

Umbrel v0.3.3 is here with 3 brand new apps in the Umbrel App Store — Samourai Server (Dojo + Whirlpool), Mempool, LNbits — a totally redesigned wallet connector, Lightning Pool, Bitcoin Core v0.21.0, and more.

If your update gets stuck for some reason, please message us on Telegram: https://t.me/getumbrel"

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.3...v0.3.4

Go to Repo Go to Release

getumbrel/umbrel: v0.3.3

Published: 2021-02-15 13:50:58 UTC


Umbrel v0.3.3 is here with 3 brand new apps in the Umbrel App Store — Samourai Server (Dojo + Whirlpool), Mempool, LNbits — a totally redesigned wallet connector, Lightning Pool, Bitcoin Core v0.21.0, and more.

If your update gets stuck for some reason, please message us on Telegram: https://t.me/getumbrel

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.2...v0.3.3

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.1-beta.rc3

Published: 2021-02-12 06:30:35 UTC


Database Migrations

There are no migrations in lnd v0.12.1-beta.rc3.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-bitconner-v0.12.1-beta.rc3.txt.asc is in the current directory) with:

gpg --verify manifest-bitconner-v0.12.1-beta.rc3.txt.asc

You should see the following if the verification was successful:

gpg: Signature made Thu Feb 11 18:44:20 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.1-beta.rc3.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.1-beta.rc3.txt.asc.ots -f manifest-roasbeef-v0.12.1-beta.rc3.txt.asc

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.1-beta.rc3 gpg: Signature made Thu Feb 11 18:03:36 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.1-beta.rc3 $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.1-beta.rc3 /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.1-beta.rc3.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.1-beta.rc3.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc3" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc3" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Spec Compatibility

Gossip Propagation Improvements

This release reverts the removal of the premature channel update cache that was removed in 0.12.0-beta. Absence of the cache was seen to cause issues with channel update propagation, so the change is reverted to restore the pre-0.12.0-beta behavior and stability. The current plan is to reschedule the cache's removal for 0.13 after performing more extensive investigation.

In addition, the gossip throttling adding in v0.12.0 has been refactored to be less aggressive with respect to non-keepalive channel updates, i.e. channel updates that differ in more than just the timestamp. Previously lnd would drop all but the first such update that it received over the course of a block, which has reportedly been too restrictive and resulted in degraded propagation of routine channel updates.

The new throttling logic now employs a directional token bucket rate limiter, the same approach used by lnd to rate-limit gossip requests from sync peers. Each token bucket is configured to drop non-keepalive updates arriving faster that once per minute, yet permitting bursts of up 10 updates. This improves on the previous approach in a few ways: - Updates are now limited with respect to a consistent time source, i.e. seconds, rather than block height. This makes it easier to reason about when channel updates might get dropped as an average user, and places a deterministic bound on the next time a normal user can reliably update their channel again. - The rate limits are now applied directionally, so that one end of the channel cannot cause their counterparty's channel updates to be dropped. This has the effect of making the penalization more precise, and better targets individuals that exhibit abusive behavior. - By factoring in bursts, it provides enough tolerance for cases where policy changes that may occur in quick succession, e.g. disable followed by reenable, or modifying a channel policy immediately after open.

No Gossip Mode

This release includes support for a no-graph sync mode which can be enabled by setting numgraphsyncpeers=0. In prior versions, running lnd in this configuration would still trigger an initial historical sync with the first connected peer on each restart. The behavior was modified under the assumption that users who have already configured lnd to not receive gossip updates probably don't want to sync the graph at all.

This mode is especially helpful to wallet developers that choose to outsource pathfinding via their own service, or purely forwarding nodes that never need to perform pathfinding.

Pinned Gossip Syncers

Typically lnd performs this historical channel reconciliation periodically, rotating between the set of all active peers, and attempting to keep numgraphsyncpeers (defaults to 3) in a state where they are receiving new gossip messages. Due to the eventually consistent properties of this algorithm (and the gossip protocol in general), there are some cases that lead to long delays in a node receiving newer updates. Notably, if a node has many peers, then it may be a while before the sync rotation algorithm queries a given peer for newer updates.

To provide more control, a new configuration option has been added allowing users to pin their nodes into an ActiveSync with particular nodes. Each time a connection is established with a pinned syncer, lnd will first perform a historical channel reconciliation, followed by a request for the pinned syncer to forward all new gossip messages. Doing so allows users to keep their routing table tightly synchronized with nodes in their list of configured, pinned syncers. Users can add one or more pinned syncers via: gossip.pinned-syncers=<pubkey1> gossip.pinned-syncers=<pubkey2> This can be especially useful for services that run multiple, well-connected lnd nodes, and want their own nodes to maintain similar views of the channel graph. Users can also use gossip.pinned-syncers in combination with numgraphsyncpeers=0 to only sync from a specific peer.

RPC Changes

  • lnd 0.12.1-beta.rc3 now exposes the HTLC attempt_id on response from TrackPayment. Internally, lnd uses attempt_id as a unique identifier for each HTLC it sends out, and to provide a total ordering on all HTLC sent by the daemon. This identifier can be used by developers to better reflect progress of a payment, making it easier to extract per-HTLC state deltas rather than displaying the full payment state every time.

Deterministic Build / Release Verification

Developer Toolchain

Bug Fixes

Full Changelog

Contributors (Alphabetical Order)

Andras Banki-Horvath Carla Kirk-Cohen Conner Fromknecht Eugene Siegel Jake Sylvestre Johan T. Halseth Joost Jager Juan Pablo Civile Olaoluwa Osuntokun Oliver Gugger rockstardev Umar Bolatov Vlad Stan Wilmer Paulino

Go to Repo Go to Release

BlueWallet/BlueWallet: v6.0.4

Published: 2021-02-11 20:26:03 UTC


New

  • Fee estimation based on mempool
  • iOS 14.5 support
  • Electrum json import support
  • AEZEED mnemonics support (LND wallet)
  • Remove Location permission (Local trader)
  • Wallet update indicator
  • Vault manage keys - show alert if unsaved
  • Lower fee value if balance is not enough

Fixed

  • "Can't finalize input"' error (Vaults)
  • Scroll on multi sig creation (Vaults)
  • Loading on creation (Vaults)
  • Import seed hangs forever (Vaults)
  • Scanning invalid QR code throws multiple alerts
  • Cached wallet address wouldn't change
  • 'Few seconds ago' -> 'pending'
  • Legacy wallet can now derive UTXO from transactions if fetching listUnspent from network is not possible
  • Biometrics with PSBT
  • Better support of coldcard's 'p2sh-p2wsh'
  • Do not show notification settings if device does not support it

Download

Appstore

Playstore

Go to Repo Go to Release

mempool/mempool: v2.1.1

Published: 2021-02-10 14:28:06 UTC


This update adds support for Umbrel, together with a few minor bugfixes:

  • Improve Docker workflow for Umbrel (#326) by @bguillaumat
  • BSQ token market cap calculation fix (#332) by @devinbileck
  • Lightning HTLC identification label fix (#320) by @fiatjaf

Go to Repo Go to Release

bitcoin-s/bitcoin-s: v0.5.0

Published: 2021-02-04 19:04:36 UTC


v0.5.0 - The release who must not be named

Running Bitcoin-S

If you want to run the standalone server binary, after verifying gpg signatures, you can unzip bitcoin-s-server-0.5.0.zip and then run it with ./bin/bitcoin-s-server to start the node. You will need to configure the node properly first, you can find example configurations here.

You can then unzip the bitcoin-s-cli-0.5.0.zip folder and start using the bitcoin-s-cli like this:

```bashrc ./bin/bitcoin-s-cli --help Usage: bitcoin-s-cli [options] []

-n, --network Select the active network. --debug Print debugging information --rpcport The port to send our rpc request to on the server -h, --help Display this help message and exit ```

For more information on what commands bitcoin-s-cli supports check the documentation, here is where to start: https://bitcoin-s.org/docs/next/applications/server#server-endpoints

Running the oracle server

If you want to run the standalone oracle server binary, after verifying gpg signatures, you can unzip bitcoin-s-oracle-server-0.5.0.zip and then run it with ./bin/bitcoin-s-oracle-server to start the node. You will need to configure the node properly first, you can find example configurations here.

You can then unzip the bitcoin-s-cli-0.5.0.zip folder and start using the bitcoin-s-cli like this:

```bashrc ./bin/bitcoin-s-cli --help Usage: bitcoin-s-cli [options] []

-n, --network Select the active network. --debug Print debugging information --rpcport The port to send our rpc request to on the server -h, --help Display this help message and exit ```

For more information on what commands bitcoin-s-cli supports check the documentation, here is where to start: https://bitcoin-s.org/docs/oracle/oracle-server

Verifying signatures

This release is signed with Chris's signing key with fingerprint 339A49229576050819083EB3F99724872F822910

To do the verification, first hash the executable using sha256sum. You should check that the result is listed in the SHA256SUMS.asc file next to its file name. After doing that you can use gpg --verify to authenticate the signature.

Example:

$ sha256sum bitcoin-s-server-0.5.0.zip 59c14b9fa27731d7a97f61145569619c5c497c22a976add7e554ea063c63d373 bitcoin-s-server-0.5.0.zip $ gpg --verify SHA256SUMS.asc gpg: Signature made Thu 04 Feb 2021 12:49:59 PM CST gpg: using RSA key 339A49229576050819083EB3F99724872F822910 gpg: Good signature from "Chris Stewart <stewart.chris1234@gmail.com>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 339A 4922 9576 0508 1908 3EB3 F997 2487 2F82 2910

Website

https://bitcoin-s.org/

Releases

https://repo1.maven.org/maven2/org/bitcoin-s/

Snapshot releases

https://oss.sonatype.org/content/repositories/snapshots/org/bitcoin-s/

BREAKING CHANGES to Configuration Options

It is required that all wallets pre #2217 need to have the configuration

bitcoin-s.wallet.aesPassword = "changeMe"

See issue #2245 for the errors that are thrown when this isn't set.

This password can be changed now with the keymanagerpassphrasechange RPC command.

Multi Wallet Support

Initial support for saving multiple seeds and wallets has been added to Bitcoin-S! This does not yet allow you to load and use multiple wallets at once, but you can switch between wallets using the bitcoin-s.wallet.walletName config option.

Module Level Changes

Bitcoind RPC Client

The Bitcoind RPC Client now has support for v0.20 & v0.21!

The Bitcoind RPC Client now has support for using it with a bitcoind that has multiple wallets loaded, this is done by setting the walletName parameter in the required functions.

Commits

940fce433d4 Fix rescans with bitcoind backend (#2605)

648e7d9abac Bitcoind v0.21.0 support (#2414)

3f18ba18d7e Bitcoind Version from String (#2421)

905491fe0e8 Fix getPeerInfo for v0.20 (#2402)

e8305477739 Use PSBT type in bitcoind calls (#2242)

aaf1a81d4ca Bitcoind RPC Multi-wallet support (#2231)

7c887cc144b Move newer functions to common rpc interface (#2230)

a5621f5f565 Add bitcoind functions for load and unload wallet (#2229)

ead4eaa1477 Make bitcoind extend chain api (#2087)

206c5a93d00 Bitcoind v0.20 updated rpcs & tests (#2061)

0b100383f32 Create initial BitcoindV20RpcClient (#2060)

Chain

The ChainHandler has been split up into two different types: ChainHandler and CachedChainHandler.

CachedChainHandler stores in memory the latest block headers and allows for faster syncing. ChainHandler uses the chain database to access all data, this is necessary for things like the wallet to be able to point to a single ChainApi and not get outdated data.

Neutrino syncing should be faster after some optimizations.

Commits

d159f3eb5fc Reduce number of rows selected by best filter header/best filter query (#2617)

1dacb74edf7 Optimize filter sync and fetching filter heights (#2568)

e44a620ea1a Small cleanups on the chain docs (#2515)

4e285e67469 Make ChainApi.processHeaders() return a failed future in the case we … (#2436)

9bef444fe70 Rework BlockHeaderDAO.chainTips into two methods: BlockHeaderDAO.{get… (#2443)

40f46d7c7a8 Remove BlockHeader.getBlockchainsFrom(), rework type signature for Bl… (#2431)

2de17bb4e47 2020 11 13 issue 2258 (#2260)

CLI

New CLI commands have been added such as decodepsbt, getblockheader, and bumpfeecpfp. For a full list of available CLI commands check the docs.

The Cli module is now published as a library, this should allow other projects to easily interact with a Bitcoin-S server.

The cli is also published using the sbt-native-image plugin. (#2494)

Commits

f849ba492f1 Wallet name in walletinfo (#2603)

94c71543fb9 Add createmultisig cli command (#2495)

fb43748d978 Version Number in logs & Cli Command (#2467)

2be2df12dbb Publish Cli as library (#2433)

847981317a0 Add getblockheader cli command (#2424)

f135322c094 Bump Fee Cli commands (#2415)

a2b54eef308 Import Seed cli commands (#2376)

ce9fbb0807a Analyze PSBT function (#2240)

c08379b2361 Decode PSBT function (#2237)

c662cf802d1 Make tx an argument for decoderawtransaction (#2155)

8c4308e2c6a Make cli pretty print json (#2130)

Core

Fixed some bugs with PSBT parsing and adding witness scripts.

Initial BIP 155 support for sending and receiving addrv2 messages.

Initial BIP 325 support for interacting with Signet.

Experimental TLV support for DLC messaging, data structures, and algorithms. These are subject to change and if your project is looking to use them it is recommended to use nightly builds to stay up to date.

Commits

0280707eaa5 Make contract info lazy so native image works (#2606)

c4edcb2d5f4 Update dlc before release (#2543)

04cc10effec Add better Block.toString that doesn't blow up logs (#2585)

810ca7c678c Create BlockSyncState type (#2567)

aa0a6f96b8b Bech32 address improvements (#2571)

abc1fdd23fb 2021 01 15 dlc refactors (#2518)

c4650e3930b Make allFactories lazy so we don't hit NPE exceptions (#2491)

056702f61c1 Add explicit signing version associated with a EventDescriptor (#2487)

223be805735 Limit bech32 addresses to segwitv0 (#2471)

141fc548bcb Modified rounding on DLCPayoutCurve interpolation to match spec (#2470)

aba109de16a Add attestation verification utility (#2438)

ff60c6e03e9 OutcomePayoutPoint now has the correct types and deffers rounding due to extra_precision in serialized points (#2441)

036d714563b Made TLV serialization and deserialization uniform under a succinct and expressive API (#2420)

13c4b0d9556 Added length prefixes to contractinfo and cetsignatures TLVs (#2419)

719fab23b7a Remove CompatEither, it was needed for historical purposes to support… (#2394)

378c51991b9 DLC Data Structures on Master Cleanup (#2375)

49a281acaf0 Pulled down work from adaptor-dlc onto master (#2339)

49871df0c35 Require CJDNS starts with 0xFC (#2356)

3e7fade2240 Add latest ProtocolVersion (#2332)

13443fd0d1e Implement BIP 155 addrv2 messages (#2321)

b3d70f559a6 Fix TLV parsing for non-standard strings (#2312)

0c03aa9c24d Add function to validate OracleAnnouncementV0TLV's signature (#2308)

28c37ccf1fe trivial: Add a sha256 hash field on all TLV (#2300)

b638c6837e6 Move english word list to be represented by a Vector in memory (#2287)

18dfbed8c90 Add helper OracleEventTLVV0.maturation method (#2267)

e4194220c1e Update Oracle TLVs (#2185)

7178cb7136f Fixed P2SH(Segwit) bug and brought down DLC-used PSBT functionality (#2140)

ddf39057fe0 Only Validate PSBT BIP143 vulnerability on signing (#2204)

02c10fd89ed Pretty Fee Rate toStrings (#2210)

c275a8c8aa6 Make tx bytes functions lazy vals (#2180)

c5be81d5e21 Add address descriptors (#2176)

2e1b4d04919 P2SHTxSigComponent constructor now detects witness data (#2169)

7bbc89fb33f Optimize GetHeadersMessage.fromBytes (#2131)

4ac93660d2c Add BIP45 Multisig Purpose (#2103)

f69678d74bf Allow any HDCoinType (#2097)

fa31609daca Enable AddrMessageTest (#2106)

d158f4fcb08 Calculate HRP from network param instead of the inverse (#2079)

c2315082d8c Create ExtPrivateKeyHardened (#2073)

856f88f0ddb Initial SigNet support (#2057)

Crypto

ECDSA Adaptor signatures have been added in a basic Java implementation. These should be used with caution as they are experimental and still being developed. They are based on the specification located here, however they do not fully follow the specification and will be updated in the future.

Low R Signing should now use the same algorithm as Bitcoin Core. Previously our first attempted signature would use different added entropy.

Commits

2c2646c78d8 Commit add Opt/T fromBytes/fromHex methods similar to StringFactory (#2499)

e944ed083f3 Bump size of data for AesCryptTest (#2483)

313e9d6e798 Update secp branch with synced java files (#2448)

70d014f7b26 Fixed Low R signing (#2408)

c7e5c634f3a Brought down ecdsa adaptor signatures implemented in scala from the dlc-crypto branch (#2034)

5bcf3e2a533 Introduced NFC normalization for strings in CryptoUtil and added String hashing functions (#2102)

Db Commons

Various improvements to initializing and parsing an AppConfig.

Commits

c91f81bdbfb Fix all DAOs to use safeDatabase (#2556)

0cc85cc0b3d Simplify DBConfig Test to fix failures (#2459)

00e6a81a2a6 Safely delete files in DBConfigTest (#2451)

6b2237d2e81 Fix overrides AppConfig.configOverrides with DLCOracleAppConfig, also remove hardcoded value out of AppConfig.configOverrides so people have to implement it (#2209)

ca5324c6a22 2020 10 12 issue 2164 (#2173)

1997f22e7d3 Refactor db configuration to use the key 'user' rather than 'username' inline with slick documentation (#2184)

56b385a0e79 Create fromConfig functions for AppConfigs (#2170)

0e41c29a3fe 2020 10 08 issue 2147 (#2153)

da2f3232cd0 2020 10 06 explicit classloader (#2148)

475ed19df66 2020 10 05 redo config (#2121)

4aec33f38cc Move configuration for sqlite into the 'bitcoin-s' key (#2113)

DLC Oracle

The DLC Oracle is a new module in Bitcoin-S! The DLC Oracle allows you to attest to events and sign their outcomes for DLC participants.

The DLC Oracle can be used to as a standalone module or as an RPC server. You can check out the documentation to find out more.

This is still in beta and is likely to have some breaking changes in the future. As of this release, it is up to date with the DLC Spec.

Commits

779eefb6a58 Rename createevent rpc to createenumevent (#2604)

89e3fc54f59 Fix oracle cli to use announcements (#2576)

7cce23abf72 Implement OracleAttestmentV0TLV, save outcome to db (#2516)

166440b34b4 Update DLC Oracle Signing Algo (#2465)

7ad477fdaa2 Don't allow negative outcome for unsigned digit decomp events (#2446)

0897ea5da17 2020 11 17 dlcoracle dbutil (#2272)

4c623a8fcb5 Fix listEvents in DLCOracle (#2265)

cc428498648 Use New Oracle TLVs in DLCOracle (#2162)

be6a2a21846 Add DbManagement tests for Oracle (#2186)

f55e83ae21e Oracle Announcement TLVs (#2149)

bc3c0af1632 Use Llyod's Oracle recommendations on commitment Signature (#2117)

4cc30e15a99 Don't allow duplcate or 0 outcomes for a DLCOracle (#2120)

fcc6558a651 Increase DLC Oracle test coverage (#2128)

5d56e95af7e Add basic DLC Oracle (#2094)

28ed8db9a58 Move DLC Oracle module to master (#2083)

Eclair RPC

Eclair RPC is now updated to be compatible with v0.5

Commits

d2203f2359f Bump Eclair version (#2405)

e38569db105 Add officially supported version of bitcoind by eclair, also add the ability to specify which version of bitcoind you are using for EclairRpcTestUtil.getBitcoindRpc (#2490)

Fee Provider

Fixed a bug with the BitGo fee provider that occurred during high fee environments.

Commits

a08fc0c8a24 Fix BitGo fee provider parser (#2381)

GUI

The GUI's icon now changes based on the network of the running server. The GUI now will update its balance periodically.

Commits

827f0f3b6a8 Uniform GUI denominations (#2534)

95935dca34f Make GUI auto-update balance (#2197)

d2f08fd2269 Add network specific icons for bitcoin-s (#2067)

Key Manager

The password to encrypt a seed as well as a BIP 39 password are both now configurable. There also exists now the ability to change your seed's password.

The Key Manager now supports the ability to store an ExtPrivateKey instead of a Mnemonic. This is only used when using the importxprv cli command.

Commits

f5dae427613 Make KeyManager return better error messages (#2464)

0e9449d9a18 Add ability to store ExtPrivateKey instead of Mnemonic (#2372)

bd3584eb43f Mask BIP39 password in the BIP39KeyManager (#2350)

79b3d959d3a Create KeyManagerAppConfig (#2268)

744d8d18ab5 Add ability to change aes password (#2254)

15bb9357696 Use same config option for key manager projects (#2252)

42e9cbb1f21 Make aesPassword option for wallet config (#2217)

7b72d82440d Make BIP 39 password a config option (#2234)

Node

Fixed an issue where the node would not request witness data for blocks.

Fixed an issue with parsing unknown messages.

Commits

d608a442556 Ignore block messages while syncing (#2587)

ddd47b1cf10 Optimize node.start() and fetching filter & filter header heights (#2554)

7e942ba66dc Add unit test to make sure DataMessageHandler exception doesn't stop node (#2536)

da54d2e9fbd 2021 01 11 issue 2493 (#2503)

1ddd7bec1dd Recover errors in DataMessageHandler (#2460)

2b94b330528 2021 01 02 issue 2457 (#2461)

ecc4532bf7b Remove callbacks param from DataMessageHandler & PeerMessageReceiver (#2476)

238bd025952 Request filters after processing (#2463)

9aa4d0fcd1c Fail broadcasting transaction when disconnected (#2336)

9a5ba7bd4f3 Fix P2PClient parsing unknown messages (#2315)

7172b4a049b Request witness blocks from peers (#2289)

61c1b916113 Bump user agent to new version (#2055)

Server

Can now use bitcoind as a backend for your bitcoin-s server. Checkout the docs on how to set this up.

Fixed issues where the server wasn't always returning correctly formatted json.

Commits

db6cd10c2f1 Fix bestblockhash rpc call (#2612)

a42601ebacd Fix rpc bind address from config (#2542)

a1a2524b56e Use mainnet for default server (#2453)

93dae6c2394 2021 01 09 issue 2496 (#2500)

8e6a37e9880 Remove extra logback files (#2456)

7409bae8f9d Remove need for params in RPC request (#2418)

eaecc1c377b Implement rpcbind to allow for binding to a different interface (#2409)

de5041ee278 Fix server configuration for the app server (#2413)

42c15ba6726 Fix datadir config option (#2271)

55249669989 Add directive to configure timeout on the appServer (#2275)

37012819959 Have api endpoints return json (#2178)

720932f7975 BitcoindRpcConfig Test (#2181)

9036869990a Add test for server startup (#2171)

8577bfd34d8 Remove requirement for ZMQ with bitcoind backend (#2137)

30b6e226622 Fix NPE and log location on server start up (#2163)

6b98154622f Fix npe exception on oracleServer/run (#2160)

593f170f2a2 Refactor Mains to use common BitcoinSRunner (#2141)

8048f1e80c7 Add DLC Oracle Server Endpoints (#2105)

105260249f1 Bitcoind backend on server start up (#2088)

c853151206f Create Util functions for wallets with a bitcoind backend (#2076)

23d0d7e0eaa Create BitcoindRpcAppConfig (#2077)

Testkit

The testkit now allows you to set any binary location for bitcoind and eclair.

Commits

4bf637a008b Fix 'client1.getDaemon.datadir.exists() was true' (#2544)

d5f162ee09d Fix BitcoindV21RpcClient testkit errors (#2533)

8c918ac0a72 Refactor test case to be more idiomatic in hopes this kills CI failures (#2524)

84ce69eac85 Clean up fixture shutdown code a bit to try and see if this resolves … (#2498)

48cb939976f Don't allow fee unit gen to be 0 (#2346)

cbd6ea2cbec Start refactoring testkit to allow for specifying a different binary … (#2325)

8f9f7750d90 Remove hard coded bitcoind version eclair was depending on and switch to latest version of bitcoind (#2324)

c29d95eeceb Make BitcoinSAyncTest more thread safe and make sure we have all the … (#2292)

Wallet

Multi-Wallet support has been added.

New wallet commands have been added like signpsbt, listreservedutxos, and more.

The wallet now stores its last sync height to allow for chainApis that are ahead of the wallet.

The wallet now defaults to use native segwit (bc1 addresses) instead of legacy addresses.

Commits

ee7c96245e9 Add walletinfo rpc (#2546)

cba90e5c2bb Fix rescan to fetch blocks during scan (#2540)

36b5fc14271 Create isChange function for wallet (#2535)

f3e81d027df Remove WalletSync.sync() -> WalletSync.syncFullBlocks() (#2522)

b76be736b83 Rename wallet.getSyncHeight() -> wallet.getSyncDescriptorOpt(). We don't just use height in the descriptor, the hash is just as valuable for connecting to chains (#2479)

1d701c48a3c Use written txDbs in TransactionProcessing (#2449)

90e2a4b6f17 Account for rounding of fee rate in CPFP test (#2423)

92ac986baad Add extra checks for RBF transactions (#2416)

89222eb7669 Add wallet function to bump fee with CPFP (#2399)

64a6b6bbc5b Add wallet function to bump fee with RBF (#2392)

2db21fc3d21 Add get transaction cli command (#2370)

901fb2af17a Rescan Improvements (#2379)

18755df3d17 Multi Wallet support (#2345)

d884f7b4e9b Have makeOpReturnCommitment use random UTXO selection (#2320)

641b2236d6a Let wallet sign PSBTs (#2236)

7530a138300 Add listreservedutxos cli command (#2247)

641538440f1 Fee Provider from config (#2219)

49a58133ec2 Add Wallet State Descriptors (#2157)

e2b01e17ba8 Small improvements on FundTransactionHandling (#2143)

f7b97ba36eb Use SubtractFeeFromOutputsFinalizer when sending full utxos (#2072)

b59a17def0d Add ability to fully spend utxos (#2063)

Website & Documentation

865f1a6d460 DLC + Adaptor Docs (#2552)

8e799a4b245 Update website dependencies to address security warnings (#2607)

edf81251340 Hide chain api creation (#2569)

9f36250646c Add documentation to website for bitcoin-s-cli native image (#2591)

096504b905f Add enum oracle example (#2601)

61c3b8185e5 Add oracle configuration to example configuration.md (#2592)

0424bd8309a Fix aesPassword config in configuration docs (#2588)

ec65e48a29e Update Oracle Server docs, fix oracle server bugs (#2581)

d5243adf5a9 Add wallet sync documentation (#2565)

7c18083577c Remove range event example from website docs (#2575)

10c54186811 Updated DLC cli docs (#2551)

74884a50d27 Clarify getting-setup.md -- make distinctions between optional steps … (#2528)

f34f35ae2b7 Default to native segwit wallet (#2548)

663d94d1c0c Add comment about using defaultAccountType (#2549)

4a6c45f3137 Add whitepaper to website (#2547)

48918380003 Rescan/Restore wallet docs improvements (#2539)

65919e135b1 Touch up bitcoind docs (#2514)

1ea4e1b0be5 Add download link to navbar & downloads page (#2473)

78e28baf3c5 Rename v0.4 version to 0.4.0 in docs (#2478)

4cd3079d890 Fix docs sidebar (#2466)

3e9b6881d23 KeyManager Docs (#2426)

ef1a3e7baf5 Add doc about no mempool (#2429)

2610a23a234 Fix broken links in docs (#2439)

732c38486ee Add to docs we support schnorr (#2428)

3d37d919a36 Add supported Bips docs (#2427)

c33f88eb050 Add old release notes (#2385)

e5225993c3c Change CI Status to use Github Actions badge (#2364)

7f759ab0840 docs: Logback conf command line docs (#2270)

3314cd36d05 docs: Add DLC Oracle db conf to docs (#2269)

add6b495b3c Add release notes directory similar to what bitcoin core does, docume… (#2246)

881d3b0b781 docs: Oracle Server setup docs (#2187)

25bc97765ed docs: Clarify there are 2 options for node backend (#2177)

6db248de032 docs: Fix internal database configuration docs (#2156)

08ac5cc9f12 docs: Add Bitcoind Backend Docs (#2136)

0c31a9d3e69 Update slack links (#2134)

2882956f303 docs: DLC Oracle Server (#2125)

ffc42a1ed3b Server installation guide (#2091)

dd272a8d8e3 systemd script (#2074)

c857f5e6c7b Change versions in readme (#2065)

40db826ffc5 docs: Calculate correct hashes in dlc doc (#2059)

Other

72db35112d3 Fix compiler warning (#2609)

2f00b4a5deb Update sbt to 1.4.7 (#2598)

f2172965221 Update scala-collection-compat to 2.4.1 (#2597)

409373b89db Update metrics-core to 4.1.17 (#2580)

4a1316263f8 2021 01 27 conectionpool (#2578)

3ebf786fcd3 Update website deps (#2573)

23f15dffc71 Update sourcecode to 0.2.3 (#2557)

7bb0b10cd5e Update akka-actor, akka-slf4j, akka-stream, ... to 2.6.11 (#2517)

93fea25c32e Fix native CI workflow for different branches (#2521)

a16018bf172 Update sbt-mdoc to 2.2.16 (#2541)

1903ee30b07 Update native-lib-loader to 2.3.5 (#2523)

d21657e18bb Update sbt-native-image to 0.3.0 (#2511)

0f84e3d158b Add new sbt-native-image plugin that helps generate a correct native … (#2494)

0c0e2090136 Update scalafx to 15.0.1-R21 (#2492)

27e50b2c34e Update javafx-base, javafx-controls, ... to 16-ea+6 (#2489)

9eb6ec84582 Update play-json to 2.9.2 (#2468)

663a9514301 Update LICENSE year (#2474)

cc2c438da19 Remove -Xfatal-warnings flag for tests (#2469)

b0b56dd5da2 2020 12 18 enable lint options (#2454)

4e862b72976 Move RPC server logic into separate project (#2440)

f7c6fc141d0 Skip CI tests for docs PRs (#2435)

19c68b77b97 Update sbt to 1.4.6 (#2434)

528b4e01ee5 Outstanding DLC branch diff (#2432)

41b1c4a88d5 Update bcprov-jdk15on to 1.68 (#2422)

b5d62161501 Windows Secp Update & fix for parsing Windows paths (#2398)

8ed30e72a8c 2020 12 20 root dependson (#2404)

bc6561465e0 Update scala-collection-compat to 2.3.2 (#2401)

bb4a2667d14 2020 12 19 enable test compileropts (#2400)

719ccbe9326 PoC: Attempt to enable parallel execution on CI now that we have github ac… (#2396)

0f037f3fb9d Remove autoScalaLibrary := false, this was not being used correctly and now is hindering builds on intellij (#2397)

0f56ab2113e Update scodec-bits to 1.1.23 (#2391)

307ba23d0d1 Update sbt-native-packager to 1.8.0 (#2382)

a080fc6730c Update scalacheck to 1.15.2 (#2378)

44d54ff5a52 Update sbt-mdoc to 2.2.14 (#2383)

ac374780c14 Ignore DLCPayoutCurveTest until issue 2369 is resolved (#2388)

c43e78adf3f Move CI into indiviual workflows (#2353)

35025f9843e Setup Github Actions (#2319)

4bfcaa22353 docs: Fix dependabot warning for highlight.js (#2328)

e6d8a02e42f docs: Replace Large Range with Digit Decomp (#2331)

a1862cb6489 Bump sbt to 1.4.5 (#2358)

696dce912d4 Bump ini from 1.3.5 to 1.3.7 in /website (#2349)

f3ce3619b04 Update scalafx to 15.0.1-R20 (#2348)

1e7e8473a30 Update sqlite-jdbc to 3.34.0 (#2347)

afeb992ca66 Update sqlite-jdbc to 3.32.3.3 (#2342)

cec0593929a Update scalamock to 5.1.0 (#2327)

92b7944e230 Bump scalac setting in secp256k1jni.sbt to scala 2.12.12 (#2317)

ebd917b363c Update sbt-bloop to 1.4.6 (#2316)

5927a2e2c2c Update sbt-ci-release to 1.5.5 (#2322)

fd08c98be09 Update javafx-base, javafx-controls, ... to 16-ea+5 (#2304)

f0d925fda17 Update scopt to 4.0.0 (#2298)

8836ed5e4fb Get Scala 2.13.4 compiling (#2294)

c5c7a423b29 Update scodec-bits to 1.1.22 (#2296)

b2fe48e9fbc Update sbt-mdoc to 2.2.13 (#2291)

d12c857441e Update scala-collection-compat to 2.3.1 (#2290)

9d842897f5b Update scala-collection-compat to 2.3.0 (#2285)

d0e3561bca9 Update sbt to 1.4.4 (#2288)

f22e1b6edb8 Update akka-http, akka-http-testkit to 10.1.13 (#2276)

76d4e36097d Update sbt to 1.4.3 (#2266)

ff9119e9757 Update spray-json to 1.3.6 (#2256)

ea232969068 Update sbt-mdoc to 2.2.12 (#2253)

35aae036f07 Update javafx-base, javafx-controls, ... to 16-ea+4 (#2249)

6538a14097b Update scalatest to 3.2.3 (#2250)

a6156cd2f3a Update scalacheck to 1.15.1 (#2243)

30cd7ed0b04 Update sbt-bloop to 1.4.5 (#2241)

497e33c1a39 Update scodec-bits to 1.1.21 (#2239)

3ba3ea61256 Update sbt-mdoc to 2.2.11 (#2238)

8a148357d56 2020 11 02 cleanup (#2233)

aca5e82bcd7 Exclude sbt keys that unused (are they really unused?) (#2194)

8346010027c trivial: Cache new modules for travis (#2190)

02eb3b8805a Update sbt-ci-release to 1.5.4 (#2235)

23a143d1950 Update bcprov-jdk15on to 1.67 (#2228)

8d379e39a0f Update sbt to 1.4.2 (#2232)

ac53a5ee637 Update javafx-base, javafx-controls, ... to 16-ea+3 (#2205)

c4970a3e3ec Update typesafe:config to 1.4.1 (#2212)

a679950ac52 Update sbt to 1.4.1 (#2202)

f75ca45e50e Update sbt-mdoc to 2.2.10 (#2199)

bc36519c06b Update postgresql to 42.2.18 (#2195)

77892490782 Update sbt to 1.4.0 (#2119)

b0b1f41ba01 Update akka-actor, akka-slf4j, akka-stream, ... to 2.6.10 (#2166)

708b160260b Update postgresql to 42.2.17 (#2168)

898a9df1dcc Update sbt-native-packager to 1.7.6 (#2172)

14cfa06a4bc Add -Xcheckinit copmiler flag to tests to try and find uninitialized vals (#2165)

c4bb3ac1218 Conslidate DLC tests into existing CI rows rather than having unique … (#2152)

6267512c4da Make ZMQ Listeners typed (#2144)

6ce7d3d7019 Upgrade to scalac 2.13.3 (#2115)

679691be27f Add signet db settings (#2068)

2abe5dff250 Update javafx-base, javafx-controls, ... to 16-ea+2 (#2038)

c2bf6dc4315 Update akka-actor, akka-slf4j, akka-stream, ... to 2.6.9 (#1993)

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.1-beta.rc1

Published: 2021-02-04 08:23:19 UTC


Database Migrations

There are no database migrations in v0.12.1-beta.rc1.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-bitconner-v0.12.1-beta.rc1.txt.asc is in the current directory) with:

gpg --verify manifest-bitconner-v0.12.1-beta.rc1.txt.asc

You should see the following if the verification was successful:

gpg: Signature made Wed Feb 3 22:51:31 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.1-beta.rc1.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.1-beta.rc1.txt.asc.ots -f manifest-roasbeef-v0.12.1-beta.rc1.txt.asc

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.1-beta.rc1 gpg: Signature made Wed Feb 3 22:09:02 2021 PST gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7 gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.1-beta.rc1 $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.1-beta.rc1 /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.1-beta.rc1.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.1-beta.rc1.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc1" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.1-beta.rc1" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Spec Compatibility

Pinned Gossip Syncers

Typically lnd performs this historical channel reconciliation periodically, rotating between the set of all active peers, and attempting to keep numgraphsyncpeers (defaults to 3) in a state where they are receiving new gossip messages. Due to the eventually consistent properties of this algorithm (and the gossip protocol in general), there are some cases that lead to long delays in a node receiving newer updates. Notably, if a node has many peers, then it may be a while before the sync rotation algorithm queries a given peer for newer updates.

To provide more control, a new configuration option has been added allowing users to pin their nodes into an ActiveSync with particular nodes. Each time a connection is established with a pinned syncer, lnd will first perform a historical channel reconciliation, followed by a request for the pinned syncer to forward all new gossip messages. Doing so allows users to keep their routing table tightly synchronized with nodes in their list of configured, pinned syncers. Users can add one or more pinned syncers via: gossip.pinned-syncers=<pubkey1> gossip.pinned-syncers=<pubkey2> This can be especially useful for services that run multiple, well-connected lnd nodes, and want their own nodes to maintain similar views of the channel graph.

RPC Changes

  • lnd 0.12.1-beta.rc1 now exposes the HTLC attempt_id on response from TrackPayment. Internally, lnd uses attempt_id as a unique identifier for each HTLC it sends out, and to provide a total ordering on all HTLC sent by the daemon. This identifier can be used by developers to better reflect progress of a payment, making it easier to extract per-HTLC state deltas rather than displaying the full payment state every time.

Build / verification

Bug Fixes

Full Changelog

  • #4958 - netann: ignore unknown channel update on startup
  • #4962 - scripts: add halseth key to verify script
  • #4938 - docker: add an extra listener for localhost
  • #4944 - docs: Add clang-format instructions for mac
  • #4956 - lnrpc: add htlc attempt id
  • #4952 - Github: use vendored actions for steps with sensitive info
  • #4963 - scripts: don't fail signature verification on missing public key
  • #2162 - Makefile: define make imports
  • #4911 - lnrpc/mobile: use docker to compile/format protos
  • #4974 - Fix typo in restorechanbackup command description
  • #4902 - lntest/channels: introduce subpackage to deduplicate structs
  • #4978 - invoices+rpc: add missing channel graph to the AddInvoiceConfig
  • #4934 - discovery: pinned syncers
  • #4924 - routerrpc,routing: limit max parts if the invoice doesn't declare MPP support
  • #4961 - build: update CI builds to use go 1.15.7
  • #4979 - routing: add new TestPaymentAddrOnlyNoSplit test case
  • #4915 - multi: store bool to determine retransmission ordering

Contributors (Alphabetical Order)

András Bánki-Horváth Conner Fromknecht eugene Jake Sylvestre Johan T. Halseth Joost Jager Juan Pablo Civile Olaoluwa Osuntokun Oliver Gugger Umar Bolatov Vlad Stan

Go to Repo Go to Release

mempool/mempool: v2.1.0

Published: 2021-02-04 06:17:59 UTC


Mempool v2.1.0 is a minor release that brings bug fixes and improvements.

Screen Shot 2021-02-03 at 18 06 20

  • Implement workflow to publish mempool on DockerHub. #67
  • Add CoreRPC "Minimum fee" to the dashboard. #171
  • Fix for occasional inability to change language to English. #275
  • Fix for anguage dropdown select styling. #293
  • Display a red RBF button when RBF is not enabled. #279
  • Don't save disk cache on exit. Handle corrupted mempool disk cache. #304
  • Fix for fee estimate not being correct when block is almost full. #278
  • Bisq stats calculation fixed. #280
  • Fix for sub networks not detected when using languages. #287
  • Don't display fee rating when block medianFee is empty. #228
  • Display P2PK inputs as "P2PK" instead of empty string. #290
  • Better identification of Lightning and Liquid scripts. #324
  • Add new languages: Hungarian and Italian
  • (Bitcoind) Return correct http status message when tx not found. #295
  • (Bitcoind) Adding missing basic API endpoints. #291
  • (Bitcoind) Parse witness scripts from P2SH transactions. #323
  • (Electrum) Hide missing address received/sent from address page. #294

Go to Repo Go to Release

ACINQ/phoenix: v1.4.6

Published: 2021-02-02 16:40:13 UTC


Display min amount for pay-to-open

The minimum amount that the wallet can receive is now displayed when the wallet does not have any channels. It is also displayed for swap-ins. This minimum amount prevents creating new channels for very small amounts.

Complete list of changes

Thanks @bitcoinuser for updating the Portuguese-Brazilian translation.

Verifying signatures

You will need gpg and our release signing key E434ED292E85643A. Note that you can get it: - from our website: https://acinq.co/pgp/padioupm.asc - from github user @pm47, a committer on eclair: https://api.github.com/users/pm47/gpg_keys

To import our signing key: $ gpg --import padioupm.asc

To verify the release file checksums and signatures: $ gpg -d SHA256SUMS.asc > SHA256SUMS.stripped $ sha256sum -c SHA256SUMS.stripped

Go to Repo Go to Release

ACINQ/phoenix: v1.4.5

Published: 2021-02-02 16:39:53 UTC


Main changes

Closing logic is cooperative when we have nothing at stake

More information here: https://github.com/ACINQ/eclair/pull/1633

Add links to terms

A link to the terms (explaining how the wallet works and what can be expected) has been added to the about and initialization screens.

Complete list of changes

Thanks @bitcoinuser for updating the Portuguese-Brazilian translation.

Verifying signatures

You will need gpg and our release signing key E434ED292E85643A. Note that you can get it: - from our website: https://acinq.co/pgp/padioupm.asc - from github user @pm47, a committer on eclair: https://api.github.com/users/pm47/gpg_keys

To import our signing key: $ gpg --import padioupm.asc

To verify the release file checksums and signatures: $ gpg -d SHA256SUMS.asc > SHA256SUMS.stripped $ sha256sum -c SHA256SUMS.stripped

Go to Repo Go to Release

bisq-network/bisq: v1.5.5

Published: 2021-02-02 09:22:14 UTC


A newer version is already available! Please don’t use this version anymore.

Release notes

ATTENTION: This release changes the trade protocol.

DO NOT specify trade ID or any other value in the 'reason for payment' field. LEAVE IT BLANK.

If it is mandatory for your payment service add a dash character ('-') or coordinate with your counterparty over trader chat to agree on a reason for payment.

This change reduces the chances that certain payment accounts get flagged. Please see https://github.com/bisq-network/bisq/issues/2869 for more details on this change.

This release introduces the option to create limit offers to be able to deactivate an offer if a certain price limit is reached. It also introduces cash-by-mail as a new payment method. In addition to multiple minor UI changes, we squashed lots of bugs and improved reliability and performance of the app across the board.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.5.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.5.jar The output need to match the value from the Bisq-1.5.5.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.5.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @ghubstan
  • @jakub_cz
  • @jmacxx
  • @m52go
  • @sqrrm
  • @stejbac

A special thanks to our first time contributors:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

rsksmart/rskj: PAPYRUS-2.2.0

Published: 2021-02-01 22:19:58 UTC


This release contains relevant improvements from community feedback. Thanks to all RSK buidlers for your contributions!

This is a summary of the changes included in this version:

  • Add Content-Type field in JSON RPC responses (#1390)
  • Consider minimum gas price in eth_gasPrice method (#1389)
  • On-the-fly block blooms cache for faster events retrieval (#1384)
  • Fix v value in JSON RPC transaction result (#1382)

You can find a complete list of the changes introduced in Papyrus 2.2.0 milestone.

SHA256 (see Reproducible Build guide for further details): f7cb1e6c5568332d047c602a5b2c464c41688336b824d92ef3a40b89a8f55b60 rskj-core-2.2.0-PAPYRUS-all.jar

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.1.0

Published: 2021-01-30 14:59:17 UTC


Binaries

There are two types of binaries:

Specter Desktop

It's a windowed GUI application with Specter server included. Supported platforms: Windows, MacOS, Linux (x86_64)

Note on Linux: you need to set up udev rules (included in the archive). Check out readme.

Note on macOS: The current build supports only macOS Catalina (10.15) or higher. If you'd like to run Specter on an older macOS version, you can install Specter from Pip.

specterd

It's a command-line program that only runs Specter server. Supported platforms: Windows, MacOS, Linux (x86_64)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @stepansnigirev's GPG key. You can get the public key from here: https://stepansnigirev.com/ss-specter-release.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 6F16 E354 F833 93D6 E52E C25F 36ED 357A B24B 915F, short id: 36ed357ab24b915f

Release notes

  • Bugfix: #784 URL encode to prevent breaking characters on RPC connection #866 (Maxi Dev)
  • Bugfix: #829 - font size and horizontal alignment #900 (Patrick)
  • Bugfix: Check whether tx address contains list before enumerating it #855 (Ondrej Calda)
  • Bugfix: Fix #605 - Display UI notification after btc core connection test #912 (Patrick)
  • Bugfix: Fix key purpose labeling being overwritten #887 (benk10)
  • Bugfix: Fix no block height with Bitcoin Core v0.19 #859 (benk10)
  • Bugfix: Fix tx info showing wrong input address #865 (benk10)
  • Bugfix: ugly fix utxo blockexplorer rescan #897 (Stepan Snigirev)
  • Bugfix: Util testing and small bugfix about multisig treshold #698 (Manolis)
  • Chore: Bump electron from 10.1.3 to 10.2.0 in /pyinstaller/electron #916 (dependabot[bot])
  • Devops: Added PyCharm IDE configuration + fixed DEVELOPMENT.md title level hierachy (incl. TOC) #892 (paeet)
  • devops: Fixed deprecation warnings #894 (Patrick)
  • Devops: Specify that hwi is not compatible with Python 3.9 #883 (Franck Royer)
  • Docs: Add existing file #846 (bitballin)
  • Docs: Add more info to connect Desktop via TOR #847 (Ramon Tayag)
  • Docs: add multisig tradeoffs note and doc #885 (djpnewton)
  • Docs: add notes about built in authentication methods #871 (djpnewton)
  • Docs: Removing high level consulting request #901 (Callum Macdonald)
  • Docs: Update connect-your-node.md #893 (fatrattombala)
  • Feature: Add addresses tab allowing users to navigate through derived addresses #781 (jleo84)
  • Feature: Added persistent tor setting. #848 (Raj)
  • Feature: add rate limiting and registration link expiry #852 (djpnewton)
  • Feature: address-tab pagination, sorting and exporting to CSV #873 (jleo84)
  • Feature: Auth improvements #860 (benk10)
  • Feature: Get whitepaper via timechain #905 (Manolis)
  • Feature: improve hints for not working connections #888 (Kim Neunert)
  • Feature: Replace address list on receive tab with addresses tab #914 (benk10)
  • Feature: SLIP-132 switch for PDF backup key format #849 (Maxi Dev)
  • Feature: Support Cobo single key files #915 (benk10)
  • UIUX: Add target="_blank" for help links #911 (benk10)
  • UIUX: fixed typos in walletreceive.jinja and walletsettings.jinja #853 (Zach Zager)
  • UIUX: Fixes - TX table toolbar alignment, Network label alignment #899 (Patrick)
  • UIUX: Fix typo (puropse -> purpose) #898 (Stacie)
  • UIUX: Fix Typos #879 (Franck Royer)
  • UIUX: Keep slashes and parentheses in tx labels #861 (Ondrej Calda)
  • UIUX: Make Add Keys more obvious #884 (Franck Royer)

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.6.8

Published: 2021-01-29 09:55:09 UTC


This release is trying some improvement to decrease the chances of being falsy flagged by Google Safe Browsing.

  • Remove Tor URL from login page (useless now thanks to the url bar link) @dennisreimann
  • Remove allowtransparency from checkout overlay @dennisreimann
  • Remove clipboard code from the login page (was used to copy the tor url) @dennisreimann
  • Rename some pages from PascalCase to lowercase. (Register => register, Login => login) @dennisreimann

Go to Repo Go to Release

bwt-dev/bwt: v0.2.2

Published: 2021-01-29 02:18:21 UTC


Changelog

  • Authentication support for the Electrum and HTTP API servers (#70)

  • Compatibility with Bitcoin Core v0.21 (#78)

  • Support for Signet

  • New GET /bitcoin.pdf HTTP API endpoint for extracting the Bitcoin whitepaper from the block chain (https://twitter.com/shesek/status/1352368296553836544)

  • New --create-wallet-if-missing option to ease the creation of a designated bitcoind wallet (#76)

  • Docker: Multi-arch images for amd64, arm32v7 and arm64v8 (#79)

  • Indexer: Fix detection of conflicted mempool transactions

  • Support setting boolean options using environment variables (FORCE_RESCAN, CREATE_WALLET_IF_MISSING, ELECTRUM_SKIP_MERKLE, NO_STARTUP_BANNER and VERBOSE)

  • Accept wildcard envirnoment variables for options that accept multiple values (XPUB_*, DESC_*/DESCRIPTOR_* and ADDRESS_*)

  • Upgrade to rust-bitcoin v0.26.0, rust-miniscript v5.0.1 and bitcoincore-rpc v0.13.0


Also see the v0.2.2 releases for bwt-electrum-plugin, libbwt, libbwt-nodejs and libbwt-jni.

Installation

Installation instructions are available on the README.

Verifying signatures

The releases are signed by Nadav Ivgi (@shesek). The public key can be verified on the PGP WoT, github, twitter, keybase, hacker news and this video presentation.

```bash

Download (change x86_64-linux to your platform)

$ wget https://github.com/bwt-dev/bwt/releases/download/v0.2.2/bwt-0.2.2-x86_64-linux.tar.gz

Fetch public key

$ gpg --keyserver keyserver.ubuntu.com --recv-keys FCF19B67866562F08A43AAD681F6104CD0F150FC

Verify signature

$ wget -qO - https://github.com/bwt-dev/bwt/releases/download/v0.2.2/SHA256SUMS.asc \ | gpg --decrypt - | grep ' bwt-0.2.2-x86_64-linux.tar.gz$' | sha256sum -c -

$ tar zxvf bwt-0.2.2-x8664-linux.tar.gz $ ./bwt-0.1.5-x8664-linux/bwt --xpub ... ```

The signature verification should show Good signature from "Nadav Ivgi <nadav@shesek.info>" ... Primary key fingerprint: FCF1 9B67 ... and bwt-0.2.2-x86_64-linux.tar.gz: OK.

Reproducible builds

The builds are fully reproducible.

You can verify the checksums against the v0.2.2 builds on Travis CI: https://travis-ci.org/github/bwt-dev/bwt/builds/756663238

See more details here.

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.0-beta

Published: 2021-01-27 03:43:57 UTC


This release marks the first major release in the v0.12.x series! As this is a major release several new features are included in this release including: anchor commitment types are now the default, anchor commitment support for watchtowers, new arguments to auto compact the database as well as drop the wtxmgr state, generic wallet PSBT crafting+signing, and much more! As usual, this release contains several important bug fixes, so we recommend all users update.

Database Migrations

A migration to initialize a top-level peers bucket is included in this release. The bucket is used to track flap counts for peers that we have channels open with across restarts. These values are used to rate-limit the amount of memory that lnd uses to track peers online state, ensuring that we do not store large volumes of uptime information for peers that are constantly changing online state.

This release contains a migration to initialize a top-level-bucket for an outpoint index. There is also a subsequent migration that populates this index with an outpoint's status. This will cut down on expensive bbolt transactions throughout the codebase. The migration process should look something like this upon initial start up: 2020-12-21 10:45:07.256 [INF] LTND: Version: 0.12.0-beta commit=v0.12.0-beta, build=production, logging=default 2020-12-21 10:45:07.257 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2020-12-21 10:45:07.257 [INF] LTND: Opening the main database, this might take a few minutes... 2020-12-21 10:45:07.257 [INF] LTND: Opening bbolt database, sync_freelist=false, auto_compact=false 2020-12-21 10:45:07.304 [INF] CHDB: Checking for schema update: latest_version=20, db_version=17 2020-12-21 10:45:07.304 [INF] CHDB: Performing database schema migration 2020-12-21 10:45:07.304 [INF] CHDB: Applying migration #18 2020-12-21 10:45:07.304 [INF] CHDB: Creating top-level bucket: "peers-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "peers-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #19 2020-12-21 10:45:07.305 [INF] CHDB: Creating top-level bucket: "outpoint-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "outpoint-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #20 2020-12-21 10:45:07.324 [INF] LTND: Database now open (time_to_open=67.71764ms)!

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.12.0-beta.txt.asc is in the current directory) with:

gpg --verify manifest-roasbeef-v0.12.0-beta.txt.asc

You should see the following if the verification was successful:

gpg: Signature made Tue Jan 26 23:22:18 2021 PST gpg: using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.0-beta.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.0-beta.txt.asc.ots -f manifest-roasbeef-v0.12.0-beta.txt.asc

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.7, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.0-beta gpg: Signature made Wed 27 Jan 2021 02:29:33 AM UTC using RSA key ID 9B280306 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" Primary key fingerprint: E4D8 5299 674B 2D31 FAA1 892E 372C BD76 33C6 1696 Subkey fingerprint: 60A1 FA7D A5BF F08B DCBB E790 3BBD 59E9 9B28 0306

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.0-beta $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.0-beta /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.0-beta.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.0-beta.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

New Default Autopilot Heuristic

In this version of lnd, the default heursitic for autopilot has been changed from preferential attachment, to a version that will attempt to optimize for the betweeness centrality of the node. At a high level, this change means that rather than trying to connect (stochastically) to the nodes that have the most channels, lnd will instead attempt to connect to the nodes that appear most often in the shortest paths within the network. This change will serve to step as a stepping stone to further diffuse the graph to make it more resilient.

Pathfinding Improvements

lnd will now properly penalize attempts of larger "wumbo" sized payments proportionally. This will serve to ensure that clients with less active failure information are able to properly prune the search space by increasing the attempt cost for larger payments. New flags has been added to allow users to configure the attempt cost for this value (attemptcost and attemptcostppm). We encourage users taht frequently send larger payments to tweak these parameters to find what works best, and ideally communicate this information back to the maintainers of lnd so we can better tune the current default value.

Graph Download Optimizations

lnd will now batch all insertion operations related to channel graph which should greatly speed up initial graph download. Initial becnhmarks show this change resluting in a 3x speed increase, with further gains likely being seen on mobile and more constrained platforms.

Peer to Peer Updates

A new flag has been added to lnd to enforce a global connection timeout when trying to connect out to new peers. Setting a lower value for this new command line option (timeout) will mean that lnd will give up on unreachable peers much sooner than before, which can be useful when attempting to connect to a set of addresses to open channel to a peer.

Automatic Database Compaction

The most important data of any lnd node is stored in its channel database (channel.db). The database library currently used for this DB is bbolt which by design does not give back free space to the file system, even if data is deleted from the DB. This can lead to large DB files and slow startup times. Compaction is the process of creating a fresh copy of a bbolt database that only contains data and no "reserved free space". This process also de-fragments and validates the integrity of the data.

Automatic compaction of the channel.db can now be turned on with the flag --db.bolt.auto-compact. By default this will compact on startup, if the last compaction was more than a week ago. The flag --db.bolt.auto-compact-min-age can also be set to 0 to force compaction on every startup, independent of how long ago it happened last.

Protocol Upgrades

Anchor Output Channels

lnd will now open the new channel type dubbed "anchor channels" by default if both peers support it. You signal support by setting the --protocol.anchors flag at lnd startup. This is a channel type that has been available to advanced users since lnd v0.10, but it has seen a few updates that makes it even safer and useful in high fee scenarios, and it is now in line with a proposed BOLT change.

The anchor channel type is a new type of channel that is much safer in high fee scenarios, as it allows bumping the fees after the channel has been force closed, instead of making the peers agreeing on a future close fee. This is also a nice UX improvement, as less of the channel capacity needs to go towards the commitment fee reserve, and can instead be used for payments. In addition it allows bundling multiple HTLC transactions together into one, potentially saving on chain fees in force close scenarios.

The commitment transaction still needs to be signed up front with a fee that ensures its mempool acceptance, and this fee now defaults to 10 sat/vbyte. This can be tuned by the --max-commit-fee-rate-anchors flag, but this should be used with caution.

Note that one has to have on-chain funds available in the wallet for fee bumping channel closes for anchor channels. Because of this, a small portion of the wallet balance will be reserved for this purpose, and some on-chain actions that used to be allowed can now be rejected if you have anchor channels open.

Static Remote Key Feature Bit Required

This new version of lnd now requires channels that use a static remote key, AKA "tweakless commitments". This change improves safety and security for users as now when a channel is force closed by the remote party, the funds will go directly to a user control key. Prior versions of lnd have supported this channel type, but lnd will now only allow this type of channel when making channels with new peer.

Lnd will waive this requirement in the case where it still has legacy channels with a peer. This ensures that lnd can still connect to nodes it has existing channels with, even if they do not understand the feature bit.

Improved End to End Payment Security

The MPP protocol upgrade included a so called "payment address" that improves end-to-end payment security by requiring the sender to include a special nonce in the onion payload specify by the receiver. As intermediate nodes can't guess this secret ahead of time, and it's encrypted in the onion only to the finally receiver, they thwarts a large class of probing and de-anonymization attacks. This new release of lnd will now require this feature bit set in any new invoices it creates, which means all payments that don't include this new payment secret will be rejected.

PSBT Signing

The internal wallet can now create and sign PSBTs. In combination with the ListUnspent RPC this allows RPC users to implement full coin control. This feature also takes us one step closer to the goal of supporting watch-only on-chain wallets in lnd where an online node would only have public keys to track the UTXOs and would delegate the signing to a non-networked lnd node that has the private keys, all through using PSBTs. Read more about the possible use cases and dive into the examples in our PSBT documentation.

Build System

Leveraging the power of GitHub Workflows, we now automatically build and push docker images of all our releases to Docker Hub. This includes images for amd64 and arm64.

The distinction between the production Dockerfile and the development dev.Dockerfile were made more clear in the documentation.

The release binaries for all OS/architectures are now also built by a GitHub Workflow. The deterministic build system introduced in a previous release allows us to independently build and sign the binaries locally. Signatures of more than just one developer will be added to releases in the future.

The experiential build tag has been removed for the assumechanvalid flag that is used to prevent long rescans for neutrino nodes.

Continuous Integration

Our continuous integration pipeline, most notably our integration tests, has received a number of improvements and bug fixes making them considerably faster and somewhat more stable: - An integration test suite running against a bitcoind with the TX index disabled was added. - The ~70 integration tests are now split into 4 parts and run in parallel reducing the execution time by ~50%. - Log files are only uploaded to termbin.com and file.io for failed runs and the bitcoind binaries are extracted from a docker image instead of being downloaded, shaving off a few more minutes from the total itest execution time. - The test harness for the btcd node used as the mining node were improved to fix port collisions which resulted in flaky tests. - A check was added that forces new command line flags to also be documented in the sample-lnd.conf file. - A new make target for itest flake hunting was added. - New make targets for running fuzz tests were added. - Build tags were removed from the integration test files, allowing the linter to check those as well. - The zpay32 package's Decode and Encode functions now have corresponding fuzz tests in the fuzz package. - The brontide fuzz tests have been fixed. - Fuzz testing has been optimized to instruct gofuzz to always mutate the input.

Contract Court Performance Improvements

Performance improvements were made to the contract court subsystem which is responsible for closing out channels on chain and taking on-chain actions required to fully resolve the channel. The number of database transactions required to start up the subsystem has been reduced from one per channel to a single transaction, which reduces startup time. Improvements to the way the subsystem consumes new blocks from its backing bitcoin node have also improved the memory footprint of the system.

Extended Health Checks

A new optional healthcheck has been added to insturct lnd to restart itself in order to refresh an expired RPC TLS cert. This change is useful in containerized contexts such as k8s, where an auto restarting lnd is able to propagate any auth changes in a decoupled manner upon restart.

htlcswitch Enhancements

Database contention has been reduced in the link by batching removal of forwarding packages. The removal timer has also been increased from 1 minute to 1 hour.

A bug has been fixed in our non-strict forwarding randomization to ensure we explicitly randomize our link selection rather than relying on the undefined ordering of map interation in the Go spec.

Gossip Enhancements

During the development of this release, an increase in high disk usage was reported by several users throughout the network due to channel update spam. To minimize the effects to disks, lnd will now rate limit channel updates in two ways. Keep-alive updates, those which only increase their timestamps to signal liveliness, are now limited to one per rebroadcast interval (current default of 24H). Non-keep-alive updates are now limited to one per block per direction.

As required by the specification, lnd now enforces all channels for a block must fit within a single reply. It would previously not enforce this as it would allow an overlap of blocks across multiple replies, which could lead other implementations to send us a error due to the overlap and cause connect/disconnect cycles.

lnd will no longer accept premature channel announcements/updates and wait for their maturity.

Peer Flap Rate Tracking

An update to the channel fitness subsystem has introduced tracking of the number of times lnd is connected and disconnected from each of its peers. This information is surfaced in the output of the ListPeers API.

The flap rate we have recorded for peers is also used to rate limit the amount of data lnd will store to track the peer’s uptime. If a peer has a high flap rate, lnd will reduce the amount of data it stores in memory, resulting in more aggregated uptime information. This change is intended to protect against constantly flapping peers, and will have little effect on peers that are consistently online with the occasional restart. To ensure that we do not permanently punish a peer for a period of instability long in the past, the flap rate we track for peers is exponentially cooled down over time.

RPC Enchancements & Bug Fixes

GetInfo best_header_timestamp

The best_header_timestamp field included in the GetInfo's RPC response will now be set to what the backend reports while it is syncing. This will restore the ability for higher-level applications to determine their sync progress.

Watchtower Address Removal

The last address of a registered watchtower can no longer be removed to prevent a potential panic.

Uniform Unconfirmed Coin Selection for SendCoins+

lnd now allows all RPC calls that craft and send transactions to spend unconfirmed coins.

This change the following RPCs:

  • Lightning.SendCoins
  • Lightning.SendMany
  • WalletKit.SendOutputs

We've added two new parameters for these methods, following the same format as used for Lightning.OpenChannel RPC:

  • min_confs (default=1)
  • spend_unconfirmed (default=false)

Macaroon Root ID Key Rotation

lnd now supports root ID key rotation. This allows the baker (creator) of a set of macaroons to invalidate them all by deleting and regenerating the root key used to generate the macaroons. This feature is a useful security tool, as if an application/system that uses lnd's macaroons in a fine grained manner is compromised, the admin is able to revoke all generated macaroons.

Several new calls have been added to allow users to take advantage of this feature, namely: * The lncli bakemacaroon call now accepts a new parameter: root_key_id. This new field is an integer that can be used to rotate root ID keys. * A new lncli listmacaroonids command has been added to allow callers to monitor all their existing allocated root IDs. * A new lncli deletemacaroonid call has been added which implements macaroon revocation by allowing the caller to delete a specified root key ID.

New Verbose Output for ChannelBalance

The lncli channebalance call now returns much more information than before in order to give users more insight w.r.t exactly how their funds are distributed off-chain. An output of the new call resmbles the following: ⛰lncli channelbalance { "balance": "27476201", "pending_open_balance": "0", "local_balance": { "sat": "27476201", "msat": "27476201135" }, "remote_balance": { "sat": "109137173", "msat": "109137173865" }, "unsettled_local_balance": { "sat": "0", "msat": "0" }, "unsettled_remote_balance": { "sat": "0", "msat": "0" }, "pending_open_local_balance": { "sat": "0", "msat": "0" }, "pending_open_remote_balance": { "sat": "1783362", "msat": "1783362000" } }

Note that the first two fields (balance and pending_open_balance) are now deprecated and will be removed in the future. Callers should use the new fields that return both sat and msat instead.

Raw Key Support for SharedKeyRequest

The DeriveSharedKey now accepts a raw public key in addition to key locator.

Additional HTLC Information in ListChannels

The ListChannels call will now return additional information about the set of linked HTLCs in a channel. Namely, we'll now return: * The htlc_index of the HTLC within the channel * The forwarding_channel, or the channel that forwarded the HTLC to the targte channel * The forwarding_htlc_index, or the HTLC index on the forwarded channel.

Automated Let's Encrypt Certificates

A new series of command line flags have been added to lnd which allows users to automatically obtain and renew a Let's Encrypt Certificate for the RPC interface of their lnd node. With this change, in certain configurations, callers will be able to hit an lnd now without having to manually store and update the tls.cert locally. New flags added to the lnd command line and lnd.conf:

  • --letsencryptport: The port on which lnd will listen for Let's Encrypt challenges. Let's Encrypt will always try to contact on port 80. Often non-root processes are not allowed to bind to ports lower than 1024. This configuration option allows a different port to be used, but must be used in combination with port forwarding from port 80.
  • --letsencryptdir: The directory to store Let's Encrypt certificates within. By default this is .lnd/letsencrypt.
  • --letsencryptdomain: Request a Let's Encrypt certificate for the domain specified using this flag.

When lncli cannot find a tls.cert file, it will assume the server has a valid (Let's Encrypt) certificate. It is important to pass the domain name as a command line flag to lncli:

lncli --rpcserver my.domain.org:10009

This is necessary as well when connecting to localhost.

Custom Routing Hints for AddHoldInvoice

The AddHoldInvoice RPC call now allows the users to specify their own custom routing hints.

Allow No RPC Auth on Private Addresses

A new config evaluation has been added to allow user to instruct lnd that it should allow RPC requests with no authentiation only if lnd is listening on a private address. This makes certain Docker based configurations more user friendly, as any dependent containers no longer need to obtain and update lnd's RPC authentication information. Assuming lnd is only listening on a non-public private interface, then the --no-macaroons config option is now valid.

New Channel Acceptor Parameters

Additional fields have been added to the ChannelAcceptor API, which allow custom setting of custom errors for the remote peer, an upfront shutdown address for the channel (if supported by the peer), and more. Note that the error provided will be sent to the peer verbatim, so should not contain sensitive information.

Maximum Local CSV

When opening a channel, the remote party can specify the CSV delay for your funds. This value determines the amount of time that your balance will be unavailable in the case where your force close the channel. A max_local_csv parameter has been added to allow setting of custom limitations on this value. For outgoing channels, this can be set using the max_local_csv field in the OpenChannel request. The maxlocaldelay config value can be used to set a default maximum value for all channels.

Disable TLS for REST

It is now possible to disable TLS for REST RPC using --no-rest-tls.

Refactoring

This release sees the removal of several components from the main lnd package: - fundingmanager.go and tests are moved to the funding package. - chainregistry.go and chainparams.go have been moved to the chainreg package. - mock.go has been removed in favor of the lntest/mock package. - A global variable activeNetParams has been removed.

The peer package's dependency on brontide has been removed.

Miscellaneous

The DNS servers to use for initial peer bootstrapping can now be specified to overwrite the hard coded default values.

All supported command line flags are now also properly documented in the sample-lnd.conf file.

A new flag has been added to instruct lnd to timeout early if it can't obtain the file lock on bolt DB.

Multi node management

Hosting nodes on non-trusted (cloud) hardware was made safer by adding a stateless initialization mode that instructs lnd to not store any unencrypted macaroons on the host's file system. Instead, the admin macaroon is returned in the response of the wallet creation request and must be stored by the caller.

To support the stateless initialization mode mentioned above on the client side as well, configuration profiles for lncli can now be created. Those profiles make it easy to interact with multiple nodes from the same client machine. For additional security the macaroons stored in the profiles can optionally be encrypted with a password.

Recovery

Forcing the on-chain wallet to rescan its state from chain was made easier by adding the --reset-wallet-transactions flag to lnd that replaces the functionality previously only available in the external tool dropwtxmgr.

Individual subsystem log levels

A change that makes it possible to set the log level for individual subsystems was merged. One can now specify a global log level, and subsystem log levels that will override the global setting: --debuglevel=debug,PEER=info,SRVR=trace.

Bug fixes

The full list of changes since v0.11.0-beta can be found here:

Contributors (Alphabetical Order)

Alex Bosworth András Bánki-Horváth Ben Woosley Bjarne Magnussen Calvin Zachman Carla Kirk-Cohen Carsten Otto Conner Fromknecht Dan Janosik Daniel Babbev Dominik Spicher Eugene Siegel Federico Bond Glen Cooper githorray Graham Krizek Hampus Sjöberg Johan T. Halseth Joost Jager Juan Pablo Civile Jules Lamur Kartik Shah Marty Jones Matheus Degiovani Mayank Chhabra MrManPew Olaoluwa Osuntokun Oliver Gugger positiveblue Roei Erez Tom Kirkpatrick Torkel Rogstad Wilmer Paulino Yaacov Akiba Slama Yan Pritzker yyforyongyu

Go to Repo Go to Release

ElementsProject/lightning: v0.9.3

Published: 2021-01-20 17:39:58 UTC


We're pleased to announce the 0.9.3 release of c-lightning, named by Karol Hosiawa.

This is a minor release, but it also introduces a number of new features that we're really exited about, including a number of usability improvements, better access to lower-level primitives to build on top, and experimental extensions to the lightning protocol.

Highlights for Users

  • Much improved parameter verification in lightning-cli makes it easier to debug why a call failed.
  • You can now query for the status of an invoice based on the hash or the invoice.
  • Plugins that are started while the node is running can now receive command line arguments as if they were provided at node startup.
  • The security of the hsmtool used to encrypt and decrypt the node's seed key was improved by switching to a passphrase prompt instead of a command line argument.
  • Multiple plugins can now register for the db_write hook, which means you can now run multiple backup plugins at the same time. In addition we wrote extensive documentation on how to secure your node from dataloss.

Highlights for the Network

  • No more reckless: the default network changed from testnet to bitcoin.
  • We have experimental support for the onion messages proposal, allowing arbitrary messages to be exchanged between nodes in the network.
  • We have experimental support for the offers proposal, enabling reusable invoices, refunds, invoices denominated in currencies other than bitcoins, and much much more. If you ever wanted to have an inline communication step with the other endpoint of a payment then take a look at this.

Highlights for Developers

  • pyln now supports both receiving notifications from the RPC interface, as well as sending notifications in methods implemented by plugins. No more waiting in front of a blank screen for your users.
  • The new createinvoice allows you to create an invoice externally, then have your node sign it and manage it internally.
  • You can use sendonionmessage to send an onion routed message, which recipient can receive using a plugin that register for the onion_message or onion_message_blinded hook.

More details can be found in the changelog

Thanks to everyone for their contributions and bug reports; please keep them coming.

Since 0.9.2, we've had 360 commits from 13 different authors over 60 days, an average commit rate of 6.51 commits per day 🤓

A special thanks goes to the 2 first time contributors:

  • João Paulo
  • Karol Hosiawa

Cheers, Christian, Rusty, Lisa, ZmnSCPxj

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.0-beta.rc6

Published: 2021-01-20 04:02:34 UTC


This release marks the first major release in the v0.12.x series! As this is a major release several new features are included in this release including: anchor commitment types are now the default, anchor commitment support for watchtowers, new arguments to auto compact the database as well as drop the wtxmgr state, generic wallet PSBT crafting+signing, and much more! As usual, this release contains several important bug fixes, so we recommend all users update.

Database Migrations

A migration to initialize a top-level peers bucket is included in this release. The bucket is used to track flap counts for peers that we have channels open with across restarts. These values are used to rate-limit the amount of memory that lnd uses to track peers online state, ensuring that we do not store large volumes of uptime information for peers that are constantly changing online state.

This release contains a migration to initialize a top-level-bucket for an outpoint index. There is also a subsequent migration that populates this index with an outpoint's status. This will cut down on expensive bbolt transactions throughout the codebase. The migration process should look something like this upon initial start up: 2020-12-21 10:45:07.256 [INF] LTND: Version: 0.12.0-beta commit=v0.12.0-beta, build=production, logging=default 2020-12-21 10:45:07.257 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2020-12-21 10:45:07.257 [INF] LTND: Opening the main database, this might take a few minutes... 2020-12-21 10:45:07.257 [INF] LTND: Opening bbolt database, sync_freelist=false, auto_compact=false 2020-12-21 10:45:07.304 [INF] CHDB: Checking for schema update: latest_version=20, db_version=17 2020-12-21 10:45:07.304 [INF] CHDB: Performing database schema migration 2020-12-21 10:45:07.304 [INF] CHDB: Applying migration #18 2020-12-21 10:45:07.304 [INF] CHDB: Creating top-level bucket: "peers-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "peers-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #19 2020-12-21 10:45:07.305 [INF] CHDB: Creating top-level bucket: "outpoint-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "outpoint-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #20 2020-12-21 10:45:07.324 [INF] LTND: Database now open (time_to_open=67.71764ms)!

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.12.0-beta.rc6.txt.asc is in the current directory) with:

gpg --verify manifest-roasbeef-v0.12.0-beta.rc6.txt.asc

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT gpg: using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.12.0-beta.rc6.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-roasbeef-v0.12.0-beta.rc6.txt.asc.ots -f manifest-roasbeef-v0.12.0-beta.rc6.txt.asc

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.6, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.0-beta.rc6 gpg: Signature made Tue Sep 15 18:55:00 2020 PDT gpg: using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

Verifying the Docker Images

To verify the lnd and lncli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

shell $ docker pull lightninglabs/lnd:v0.12.0-beta.rc6 $ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.0-beta.rc6 /verify-install.sh $ OK=$? $ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done $ docker run lightninglabs/lnd [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.0-beta.rc6.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.0-beta.rc6.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta.rc6" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta.rc6" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

New Default Autopilot Heuristic

In this version of lnd, the default heursitic for autopilot has been changed from preferential attachment, to a version that will attempt to optimize for the betweeness centrality of the node. At a high level, this change means that rather than trying to connect (stochastically) to the nodes that have the most channels, lnd will instead attempt to connect to the nodes that appear most often in the shortest paths within the network. This change will serve to step as a stepping stone to further diffuse the graph to make it more resilient.

Pathfinding Improvements

lnd will now properly penalize attempts of larger "wumbo" sized payments proportionally. This will serve to ensure that clients with less active failure information are able to properly prune the search space by increasing the attempt cost for larger payments. New flags has been added to allow users to configure the attempt cost for this value (attemptcost and attemptcostppm). We encourage users taht frequently send larger payments to tweak these parameters to find what works best, and ideally communicate this information back to the maintainers of lnd so we can better tune the current default value.

Graph Download Optimizations

lnd will now batch all insertion operations related to channel graph which should greatly speed up initial graph download. Initial becnhmarks show this change resluting in a 3x speed increase, with further gains likely being seen on mobile and more constrained platforms.

Peer to Peer Updates

A new flag has been added to lnd to enforce a global connection timeout when trying to connect out to new peers. Setting a lower value for this new command line option (timeout) will mean that lnd will give up on unrechable peers much sooner than before, which can be useful when attempting to connect to a set of addresses to open chnnel to a peer.

Automatic Database Compaction

The most important data of any lnd node is stored in its channel database (channel.db). The database library currently used for this DB is bbolt which by design does not give back free space to the file system, even if data is deleted from the DB. This can lead to large DB files and slow startup times. Compaction is the process of creating a fresh copy of a bbolt database that only contains data and no "reserved free space". This process also de-fragments and validates the integrity of the data.

Automatic compaction of the channel.db can now be turned on with the flag --db.bolt.auto-compact. By default this will compact on startup, if the last compaction was more than a week ago. The flag --db.bolt.auto-compact-min-age can also be set to 0 to force compaction on every startup, independent of how long ago it happened last.

Protocol Upgrades

Anchor Output Channels

lnd will now open the new channel type dubbed "anchor channels" by default if both peers support it. You signal support by setting the --protocol.anchors flag at lnd startup. This is a channel type that has been available to advanced users since lnd v0.10, but it has seen a few updates that makes it even safer and useful in high fee scenarios, and it is now in line with a proposed BOLT change.

The anchor channel type is a new type of channel that is much safer in high fee scenarios, as it allows bumping the fees after the channel has been force closed, instead of making the peers agreeing on a future close fee. This is also a nice UX improvement, as less of the channel capacity needs to go towards the commitment fee reserve, and can instead be used for payments. In addition it allows bundling multiple HTLC transactions together into one, potentially saving on chain fees in force close scenarios.

The commitment transaction still needs to be signed up front with a fee that ensures its mempool acceptance, and this fee now defaults to 10 sat/vbyte. This can be tuned by the --max-commit-fee-rate-anchors flag, but this should be used with caution.

Note that one has to have on-chain funds available in the wallet for fee bumping channel closes for anchor channels. Because of this, a small portion of the wallet balance will be reserved for this purpose, and some on-chain actions that used to be allowed can now be rejected if you have anchor channels open.

Static Remote Key Feature Bit Required

This new version of lnd now requires channels that use a static remote key, AKA "tweakless commitments". This change improves safety and security for users as now when a channel is force closed by the remote party, the funds will go directly to a user control key. Prior versions of lnd have supported this channel type, but lnd will now only allow this type of channel when making channels with new peer.

Lnd will waive this requirement in the case where it still has legacy channels with a peer. This ensures that lnd can still connect to nodes it has existing channels with, even if they do not understand the feature bit.

Improved End to End Payment Security

The MPP protocol upgrade included a so called "payment address" that improves end-to-end payment security by requiring the sender to include a special nonce in the onion payload specify by the receiver. As intermediate nodes can't guess this secret ahead of time, and it's encrypted in the onion only to the finally receiver, they thwarts a large class of probing and de-anonymization attacks. This new release of lnd will now require this feature bit set in any new invoices it creates, which means all payments that don't include this new payment secret will be rejected.

PSBT Signing

The internal wallet can now create and sign PSBTs. In combination with the ListUnspent RPC this allows RPC users to implement full coin control. This feature also takes us one step closer to the goal of supporting watch-only on-chain wallets in lnd where an online node would only have public keys to track the UTXOs and would delegate the signing to a non-networked lnd node that has the private keys, all through using PSBTs. Read more about the possible use cases and dive into the examples in our PSBT documentation.

Build System

Leveraging the power of GitHub Workflows, we now automatically build and push docker images of all our releases to Docker Hub. This includes images for amd64 and arm64.

The distinction between the production Dockerfile and the development dev.Dockerfile were made more clear in the documentation.

The release binaries for all OS/architectures are now also built by a GitHub Workflow. The deterministic build system introduced in a previous release allows us to independently build and sign the binaries locally. Signatures of more than just one developer will be added to releases in the future.

The experiential build tag has been removed for the assumechanvalid flag that is used to prevent long rescans for neutrino nodes.

Continuous Integration

Our continuous integration pipeline, most notably our integration tests, has received a number of improvements and bug fixes making them considerably faster and somewhat more stable: - An integration test suite running against a bitcoind with the TX index disabled was added. - The ~70 integration tests are now split into 4 parts and run in parallel reducing the execution time by ~50%. - Log files are only uploaded to termbin.com and file.io for failed runs and the bitcoind binaries are extracted from a docker image instead of being downloaded, shaving off a few more minutes from the total itest execution time. - The test harness for the btcd node used as the mining node were improved to fix port collisions which resulted in flaky tests. - A check was added that forces new command line flags to also be documented in the sample-lnd.conf file. - A new make target for itest flake hunting was added. - New make targets for running fuzz tests were added. - Build tags were removed from the integration test files, allowing the linter to check those as well. - The zpay32 package's Decode and Encode functions now have corresponding fuzz tests in the fuzz package. - The brontide fuzz tests have been fixed. - Fuzz testing has been optimized to instruct gofuzz to always mutate the input.

Contract Court Performance Improvements

Performance improvements were made to the contract court subsystem which is responsible for closing out channels on chain and taking on-chain actions required to fully resolve the channel. The number of database transactions required to start up the subsystem has been reduced from one per channel to a single transaction, which reduces startup time. Improvements to the way the subsystem consumes new blocks from its backing bitcoin node have also improved the memory footprint of the system.

Extended Health Checks

A new optional healthcheck has been added to insturct lnd to restart itself in order to refresh an expired RPC TLS cert. This change is useful in containerized contexts such as k8s, where an auto restarting lnd is able to propagate any auth changes in a decoupled manner upon restart.

htlcswitch Enhancements

Database contention has been reduced in the link by batching removal of forwarding packages. The removal timer has also been increased from 1 minute to 1 hour.

A bug has been fixed in our non-strict forwarding randomization to ensure we explciitly randomize our link sleection rather than relying on the undefined ordering of map interation in the Go spec.

Gossip Enhancements

During the development of this release, an increase in high disk usage was reported by several users throughout the network due to channel update spam. To minimize the effects to disks, lnd will now rate limit channel updates in two ways. Keep-alive updates, those which only increase their timestamps to signal liveliness, are now limited to one per rebroadcast interval (current default of 24H). Non-keep-alive updates are now limited to one per block per direction.

As required by the specification, lnd now enforces all channels for a block must fit within a single reply. It would previously not enforce this as it would allow an overlap of blocks across multiple replies, which could lead other implementations to send us a error due to the overlap and cause connect/disconnect cycles.

lnd will no longer accept premature channel announcements/updates and wait for their maturity.

Peer Flap Rate Tracking

An update to the channel fitness subsystem has introduced tracking of the number of times lnd is connected and disconnected from each of its peers. This information is surfaced in the output of the ListPeers API.

The flap rate we have recorded for peers is also used to rate limit the amount of data lnd will store to track the peer’s uptime. If a peer has a high flap rate, lnd will reduce the amount of data it stores in memory, resulting in more aggregated uptime information. This change is intended to protect against constantly flapping peers, and will have little effect on peers that are consistently online with the occasional restart. To ensure that we do not permanently punish a peer for a period of instability long in the past, the flap rate we track for peers is exponentially cooled down over time.

RPC Enchancements & Bug Fixes

GetInfo best_header_timestamp

The best_header_timestamp field included in the GetInfo's RPC response will now be set to what the backend reports while it is syncing. This will restore the ability for higher-level applications to determine their sync progress.

Watchtower Address Removal

The last address of a registered watchtower can no longer be removed to prevent a potential panic.

Uniform Unconfirmed Coin Selection for SendCoins+

lnd now allows all RPC calls that craft and send transactions to spend unconfirmed coins.

This change the following RPCs:

  • Lightning.SendCoins
  • Lightning.SendMany
  • WalletKit.SendOutputs

We've added two new parameters for these methods, following the same format as used for Lightning.OpenChannel RPC:

  • min_confs (default=1)
  • spend_unconfirmed (default=false)

Macaroon Root ID Key Rotation

lnd now supports root ID key rotation. This allows the baker (creator) of a set of macaroons to invalidate them all by deleting and regenerating the root key used to generate the macaroons. This feature is a useful security tool, as if an application/system that uses lnd's macaroons in a fine grained manner is compromised, the admin is able to revoke all generated macaroons.

Several new calls have been added to allow users to take advantage of this feature, namely: * The lncli bakemacaroon call now accepts a new parameter: root_key_id. This new field is an integer that can be used to rotate root ID keys. * A new lncli listmacaroonids command has been added to allow callers to monitor all their existing allocated root IDs. * A new lncli deletemacaroonid call has been added which implements macaroon revocation by allowing the caller to delete a specified root key ID.

New Verbose Output for ChannelBalance

The lncli channebalance call now returns much more information than before in order to give users more insight w.r.t exactly how their funds are distributed off-chain. An output of the new call resmbles the following: ⛰lncli channelbalance { "balance": "27476201", "pending_open_balance": "0", "local_balance": { "sat": "27476201", "msat": "27476201135" }, "remote_balance": { "sat": "109137173", "msat": "109137173865" }, "unsettled_local_balance": { "sat": "0", "msat": "0" }, "unsettled_remote_balance": { "sat": "0", "msat": "0" }, "pending_open_local_balance": { "sat": "0", "msat": "0" }, "pending_open_remote_balance": { "sat": "1783362", "msat": "1783362000" } }

Note that the first two fields (balance and pending_open_balance) are now deprecated and will be removed in the future. Callers should use the new fields that return both sat and msat instead.

Raw Key Support for SharedKeyRequest

The DeriveSharedKey now accepts a raw public key in addition to key locator.

Additional HTLC Information in ListChannels

The ListChannels call will now return additional information about the set of linked HTLCs in a channel. Namely, we'll now return: * The htlc_index of the HTLC within the channel * The forwarding_channel, or the channel that forwarded the HTLC to the targte channel * The forwarding_htlc_index, or the HTLC index on the forwarded channel.

Automated Let's Encrypt Certificates

A new series of command line flags have been added to lnd which allows users to automatically obtain and renew a Let's Encrypt Certificate for the RPC interface of their lnd node. With this change, in certain configurations, callers will be able to hit an lnd now without having to manually store and update the tls.cert locally. New flags added to the lnd command line and lnd.conf:

  • --letsencryptport: The port on which lnd will listen for Let's Encrypt challenges. Let's Encrypt will always try to contact on port 80. Often non-root processes are not allowed to bind to ports lower than 1024. This configuration option allows a different port to be used, but must be used in combination with port forwarding from port 80.
  • --letsencryptdir: The directory to store Let's Encrypt certificates within. By default this is .lnd/letsencrypt.
  • --letsencryptdomain: Request a Let's Encrypt certificate for the domain specified using this flag.

When lncli cannot find a tls.cert file, it will assume the server has a valid (Let's Encrypt) certificate. It is important to pass the domain name as a command line flag to lncli:

lncli --rpcserver my.domain.org:10009

This is necessary as well when connecting to localhost.

Custom Routing Hints for AddHoldInvoice

The AddHoldInvoice RPC call now allows the users to specify their own custom routing hints.

Allow No RPC Auth on Private Addresses

A new config evaluation has been added to allow user to instruct lnd that it should allow RPC requests with no authentiation only if lnd is listening on a private address. This makes certain Docker based configurations more user friendly, as any dependent containers no longer need to obtain and update lnd's RPC authentication information. Assuming lnd is only listening on a non-public private interface, then the --no-macaroons config option is now valid.

New Channel Acceptor Parameters

Additional fields have been added to the ChannelAcceptor API, which allow custom setting of custom errors for the remote peer, an upfront shutdown address for the channel (if supported by the peer), and more. Note that the error provided will be sent to the peer verbatim, so should not contain sensitive information.

Maximum Local CSV

When opening a channel, the remote party can specify the CSV delay for your funds. This value determines the amount of time that your balance will be unavailable in the case where your force close the channel. A max_local_csv parameter has been added to allow setting of custom limitations on this value. For outgoing channels, this can be set using the max_local_csv field in the OpenChannel request. The maxlocaldelay config value can be used to set a default maximum value for all channels.

Disable TLS for REST

It is now possible to disable TLS for REST RPC using --no-rest-tls.

Refactoring

This release sees the removal of several components from the main lnd package: - fundingmanager.go and tests are moved to the funding package. - chainregistry.go and chainparams.go have been moved to the chainreg package. - mock.go has been removed in favor of the lntest/mock package. - A global variable activeNetParams has been removed.

The peer package's dependency on brontide has been removed.

Miscellaneous

The DNS servers to use for initial peer bootstrapping can now be specified to overwrite the hard coded default values.

All supported command line flags are now also properly documented in the sample-lnd.conf file.

A new flag has been added to instruct lnd to timeout early if it can't obtain the file lock on bolt DB.

Multi node management

Hosting nodes on non-trusted (cloud) hardware was made safer by adding a stateless initialization mode that instructs lnd to not store any unencrypted macaroons on the host's file system. Instead, the admin macaroon is returned in the response of the wallet creation request and must be stored by the caller.

To support the stateless initialization mode mentioned above on the client side as well, configuration profiles for lncli can now be created. Those profiles make it easy to interact with multiple nodes from the same client machine. For additional security the macaroons stored in the profiles can optionally be encrypted with a password.

Recovery

Forcing the on-chain wallet to rescan its state from chain was made easier by adding the --reset-wallet-transactions flag to lnd that replaces the functionality previously only available in the external tool dropwtxmgr.

Individual subsystem log levels

A change that makes it possible to set the log level for individual subsystems was merged. One can now specify a global log level, and subsystem log levels that will override the global setting: --debuglevel=debug,PEER=info,SRVR=trace.

Bug fixes

The full list of changes since v0.11.0-beta can be found here:

Contributors (Alphabetical Order)

Alex Bosworth András Bánki-Horváth Ben Woosley Bjarne Magnussen Calvin Zachman Carla Kirk-Cohen Carsten Otto Conner Fromknecht Dan Janosik Daniel Babbev Dominik Spicher Eugene Siegel Federico Bond Glen Cooper githorray Graham Krizek Hampus Sjöberg Johan T. Halseth Joost Jager Juan Pablo Civile Jules Lamur Kartik Shah Marty Jones Matheus Degiovani Mayank Chhabra MrManPew Olaoluwa Osuntokun Oliver Gugger positiveblue Roei Erez Tom Kirkpatrick Torkel Rogstad Wilmer Paulino Yaacov Akiba Slama Yan Pritzker yyforyongyu

Go to Repo Go to Release

getumbrel/umbrel: v0.3.2

Published: 2021-01-19 12:25:20 UTC


This update brings the latest versions of BTCPay Server, Sphinx Relay, Specter Desktop and Thunderhub to your Umbrel.

Changes:

  • Run Umbrel OS security updates during OTA update (#293) 08c6f85 (@AaronDewes)
  • Update sphinx-relay to v1.3.8 bb0b867 (@lukechilds)
  • Update sphinx-relay version in app registry fbd4aa9 (@lukechilds)
  • Upgrade thunderhub app to v0.12.2 (#402) e7a836a (@louneskmt)
  • Update specter-desktop app to v1.0.0 (#400) 2ec9b24 (@nolim1t)
  • Update thunderhub app to use Tor proxy (#434) c7faead (@louneskmt @lukechilds)
  • Use updated brew install command (#421) 604db87 (@goums)
  • Update to getumbrel/dashboard to v0.3.15 (#437) 3e1cd09 (@lukechilds)
  • Fix unattended-upgrades package installation (#439) 44b4882 (@lukechilds)
  • Update thunderhub app to v0.12.4 (#440) 74ded27 (@AaronDewes @louneskmt)
  • Fix incorrect version of btc-rpc-explorer app in registry (#442) 0cf5d8c (@AaronDewes)
  • Update btcpay-server app to v1.0.6.7 (#441) 24233c7 (@AaronDewes @louneskmt)
  • Umbrel v0.3.2 (#438) 56ad651 (@lukechilds)

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.1...v0.3.2

Go to Repo Go to Release

BlueWallet/BlueWallet: v6.0.3

Published: 2021-01-18 16:57:51 UTC


  • Vaults coin control
  • Share panel when sharing Vault cosigner
  • Ask fp & path when scanning Zpub
  • Show spinner if Vault is trying to cosign
  • Disable RPC batching for Fulcrum electrum
  • Coin control hangs (no connection on fetchUtxo)
  • Scanning a Vault PSBT Qr code when scanning address
  • Some devices wouldn't allow writing files
  • Label is not set to created Vault wallet

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.6.7

Published: 2021-01-17 12:56:17 UTC


Bug fixes:

  • Reverted the new Greenfield API: Can configure lightning payment methods @NicolasDorier

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.6.6

Published: 2021-01-17 10:24:33 UTC


Bug fixes:

  • Load correct connection string when using SQLite @Kukks
  • Greenfeld API: Invoice Metadata update was not updating @saliehendricks
  • Prevent access to wallet page if wallet not set @dennisreimann

New features

  • Greenfield API: Can configure lightning payment methods @Kukks

Go to Repo Go to Release

bitcoin/bitcoin: v0.21.0

Published: 2021-01-15 19:52:11 UTC


Bitcoin Core version 0.21.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-0.21.0/

For the release notes please see the git repository:

https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.0.md

Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

Go to Repo Go to Release

bwt-dev/bwt: v0.2.1

Published: 2021-01-14 13:06:37 UTC


Changelog

  • Migrated to the @bwt-dev github org and split up into:

bwt, bwt-electrum-plugin, libbwt, libbwt-jni and libbwt-nodejs.

  • Java Native Bindings for libbwt (libbwt-jni, #73)

  • Support for tracking standalone addresses (#14)

Using --address <address> or --address-file <path>.

  • New config options: force_rescan (9e7ccbe), setup_logger (35fc49f) and require_addresses (162790d)

  • Gracefully wait for bitcoind to warm-up (dec6d46)

  • Support for android_logger (74b2b2f)

  • Scrub bitcoin authentication from logs (c31def7)

  • Improved syncing/scanning progress updates (faba3f, 6e282fd, fdd46f3, 5ba2a0b)

  • Indexer: Fix excessive importing/rescanning (a20ae79)

  • Indexer: Fix cache invalidation for spends lookups (360eaee)

  • Indexer: Fix handling of missing mempool entries (e9b7511)

  • Electrum: Fix TCP listener not shutting down on shutdown signal (5bd639a)

  • Docker/CI: Update to Rust v1.49 (5bd639a)

Breaking CLI changes:

  • The --bare-xpub option was removed. Use a descriptor instead.

Also see the v0.2.1 releases for bwt-electrum-plugin, libbwt, libbwt-nodejs and libbwt-jni.

Installation

Installation instructions are available on the README.

Verifying signatures

The releases are signed by Nadav Ivgi (@shesek). The public key can be verified on the PGP WoT, github, twitter, keybase, hacker news and this video presentation.

```bash

Download (change x86_64-linux to your platform)

$ wget https://github.com/bwt-dev/bwt/releases/download/v0.2.1/bwt-0.2.1-x86_64-linux.tar.gz

Fetch public key

$ gpg --keyserver keyserver.ubuntu.com --recv-keys FCF19B67866562F08A43AAD681F6104CD0F150FC

Verify signature

$ wget -qO - https://github.com/bwt-dev/bwt/releases/download/v0.2.1/SHA256SUMS.asc \ | gpg --decrypt - | grep ' bwt-0.2.1-x86_64-linux.tar.gz$' | sha256sum -c -

$ tar zxvf bwt-0.2.1-x8664-linux.tar.gz $ ./bwt-0.1.5-x8664-linux/bwt --xpub ... ```

The signature verification should show Good signature from "Nadav Ivgi <nadav@shesek.info>" ... Primary key fingerprint: FCF1 9B67 ... and bwt-0.2.1-x86_64-linux.tar.gz: OK.

Reproducible builds

The builds are fully reproducible.

You can verify the checksums against the v0.2.1 builds on Travis CI: https://travis-ci.org/github/bwt-dev/bwt/builds/754451937

See more details here.

Go to Repo Go to Release

rootzoll/raspiblitz: v1.6.3

Published: 2021-01-14 02:48:02 UTC


with mempool 2.0.1, specter 1.0.0, joininbox v0.1.16 & smaller updates + fixes

Go to Repo Go to Release

unchained-capital/caravan: v0.3.5

Published: 2021-01-12 20:01:19 UTC


Update unchained-wallets version in order to support new Coldcard firmware version.

Go to Repo Go to Release

mempool/mempool: v2.0.1

Published: 2021-01-12 12:19:10 UTC


Mempool v2.0.1 is a hotfix release:

  • Fixes memory leak by not stacking data in the scan accumulator (#273)
  • Also handle going from zero to initial graph data on dashboard

Go to Repo Go to Release

btcpayserver/btcpayserver: v1.0.6.5

Published: 2021-01-11 14:59:56 UTC


This release includes changes in the way we index invoices for search. As such, after update, the invoice search feature of BTCPay Server might not work for a while. (~5min if you have lot's of invoices)

Improvements:

  • Support a subset of output descriptor in the wallet setup @Kukks
  • Improved styling of the notification dropdown (see #2167) @ubolator @dennisreimann
  • API keys and server's url can be shown as QR Code to facilitate pairing @Kukks
  • Greenfield API: Add DefaultPaymentMethod to the store's settings @Kukks
  • Greenfield API: Can configure on-chain payment methods @Kukks @NicolasDorier
  • UI Improvements (see this commit list) @dennisreimann

Bug fixes:

  • Always normalize the invoice's currency in uppercase @NicolasDorier
  • If a label on a wallet's transaction does not have color, it should still show it @NicolasDorier
  • Do not include Tor Location header when querying the modal checkout (see #2180) @Kukks
  • Webhooks should not be randomly deleted anymore. @NicolasDorier
  • Fix header not showing properly after login to BTCPay Server (see #2155) @dennisreimann
  • Bug: Searching invoices was timing out if there was too much invoices @rockstardev @Kukks

Miscellaneous:

  • Removing the old text search engine (DBreeze) @rockstardev @Kukks
  • Add doc for asking permissions to BTCPayServer see link. @Kukks

Go to Repo Go to Release

mempool/mempool: v2.0.0

Published: 2021-01-11 14:43:58 UTC


Mempool v2 is here!

Screen Shot 2021-01-11 at 23 38 10

  • Supports Bitcoin Core RPC, Electrum Server, or Esplora backends
  • Fully functional block, address, and transaction explorer with APIs
  • Dashboard layout displaying fee estimates and other real-time stats
  • Support for multiple networks including Testnet, Liquid, and Bisq
  • Optional support for Angular Universal Server Side Rendering
  • Internationalization support for 20+ languages and locales
  • And much more!

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.0-beta.rc5

Published: 2021-01-09 01:30:55 UTC


Go to Repo Go to Release

BlueWallet/BlueWallet: v6.0.2

Published: 2021-01-07 22:06:03 UTC


  • ADD: Easily share a Vault key with QR code
  • ADD: How many signatures can this Vault make
  • ADD: Electrum servers history - fast connect
  • ADD: Ability to set servers via QR code scanning
  • ADD: CoinControl multi-selection
  • FIX: better support multisig cosigning with Electrum desktop
  • FIX: multisig 'Too many signatures' error
  • FIX: Amount displayed on success invoice payment
  • FIX: localizations for frFR, esES, deDE, faIR, csCZ, frFR, nlNL, fiFI
  • FIX: Hide balance on reorder screen
  • FIX: disallow importing non-multisignature xpubs into multisig setup
  • FIX: better multisig wallet descriptors suppport
  • FIX: Incorrect import from Specter - p2sh wrapped segwit multisig
  • FIX: Clear quick actions if storage is encrypted
  • FIX: use dayjs localizedFormat plugin to render tx time
  • FIX: show more accurate precalculation fee on "Not enough balance." exception
  • FIX: Wallet Delete on new install was not being triggered
  • FIX: Fallback to English if case isn't found
  • FIX: animated qr scan progress readability
  • FIX: rerender UI after language change
  • FIX: Hide modal when scanning
  • FIX: reorder screen bug
  • FIX: Don't show clipboard modal if user has already acted on it
  • REF: processing push notifications
  • REF: Add warning to LN
  • REF: Github link on about
  • DOC: Telegram and Discord links on about section

Go to Repo Go to Release

cryptoadvance/specter-desktop: v1.0.0

Published: 2021-01-06 14:52:03 UTC


Binaries

There are two types of binaries:

Specter Desktop

It's a windowed GUI application with Specter server included. Supported platforms: Windows, MacOS, Linux (x86_64)

Note on Linux: you need to set up udev rules (included in the archive). Check out readme.

Note on macOS: The current build supports only macOS Catalina (10.15) or higher. If you'd like to run Specter on an older macOS version, you can install Specter from Pip.

specterd

It's a command-line program that only runs Specter server. Supported platforms: Windows, MacOS, Linux (x86_64)

Signatures and hashes

sha256.signed.txt file contains sha256 hashes of all binary files and signed with @stepansnigirev's GPG key. You can get the public key from here: https://stepansnigirev.com/ss-specter-release.asc. It is also available via keys.gnupg.net or keys.openpgp.org. Fingerprint of the key is 6F16 E354 F833 93D6 E52E C25F 36ED 357A B24B 915F, short id: 36ed357ab24b915f

Release notes

  • Bugfix: Fix Windows CI build (#842) (@k9ert)
  • Bugfix: Allow sending to uppercase bech32 addresses (#837) (@ben-kaufman)
  • Bugfix: Disable deleting a key used in an existing wallet (#822) (@ben-kaufman)
  • Bugfix: Fix fiat symbol direction (#802) (@figgyfigs)
  • Bugfix: Fix Electrum export for signing with ColdCard (#800) (@ben-kaufman)
  • Bugfix: Fix wrong wallet address type in PDF backup file (#800) (@ben-kaufman)
  • Bugfix: Fix QR scanner timeout breaking the signing UI (#800) (@ben-kaufman)
  • Bugfix: Fix issue with wallet name in JSON backup download (#790) (@rajarshimaitra)
  • Bugfix: Properly handle exception if address not found in wallet (#783) (@ben-kaufman)
  • Bugfix: Fix spelling mistake (#766) (@szollo)
  • Bugfix: Fix transaction caching to track all transactions (#760) (@ben-kaufman)
  • Bugfix: Require authentication be on for stating Tor hidden service (#765) (@ben-kaufman)
  • Bugfix: Make HWI Bridge settings available to all users in multiuse mode (#765) (@ben-kaufman)
  • Feature: Add automatic SSL certificate generation from CLI (#789) (@k9ert)
  • Feature: Allow configuring custom Tor proxy URL and control port (#765) (@ben-kaufman)
  • Feature: Add Tor-only mode to force all external calls go over Tor (#765) (@ben-kaufman)
  • Feature: Label any addresses from everywhere (#760) (@ben-kaufman)
  • Feature: Search, sort, page limit, and jump between pages in the transactions and UTXO tabs. (#760) (@ben-kaufman)
  • Feature: Export transactions, UTXO, and addresses into CSV file (#758) (@ben-kaufman)
  • UI: Consistent rescan labels (#843) (@justinmoon)
  • UI: Fix typo in price update notification (#831) (@instagibbs)
  • UI: Change wallet type labels on new device popup (#798) (@rajarshimaitra)
  • UI: Fix closing notification issue on mobile (#791) (@ben-kaufman)
  • UI: Add Wallets Overview UTXO tab (#760) (@ben-kaufman)
  • UI: Refactor the UTXO tab to look like the tx history tab (#760) (@ben-kaufman)
  • UI: Rename address table column to label (#764) (@figgyfigs)
  • UI: Move all Tor settings to new "Tor" Setting tab (#765) (@ben-kaufman)
  • Docs: Fix Docker docs issue (#792) (@RandyMcMillan)
  • Docs: Update FAQ on Appimage on Debian 10 (#773) (@k9ert)
  • Devops: Improve dev-toolings with Cypress snapshots (#797) (@k9ert)
  • Test: Add Cypress as a new testing framework (#712) (@k9ert)

Go to Repo Go to Release

cryptoadvance/specter-desktop: v0.11.0-pre6

Published: 2021-01-05 07:20:02 UTC


This is a pre-release! Do not use unless you're sure know what you're doing!

This is a pre-release for beta-testing the next version of Specter.

Changes to notice while testing: - Fix Coldcard signing issue when exporting to Electrum - Fix wrong address type inPDF backup - Fix issue when camera is open and scanning doesn't work for too long. - Export transactions history, UTXOs, and addresses to CSV - Reorganize the UTXO screen - Label any address from any screen it is at. - Sorting, searching, page limit, of the transactions/ utxo lists. - New Tor tab in the settings for managing the connections over Tor and the Specter Tor hidden service

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.0-beta.rc3

Published: 2021-01-04 04:21:01 UTC


This release marks the first major release in the v0.12.x series! As this is a major release several new features are included in this release including: anchor commitment types are now the default, anchor commitment support for watchtowers, new arguments to auto compact the database as well as drop the wtxmgr state, generic wallet PSBT crafting+signing, and much more! As usual, this release contains several important bug fixes, so we recommend all users update.

Database Migrations

A migration to initialize a top-level peers bucket is included in this release. The bucket is used to track flap counts for peers that we have channels open with across restarts. These values are used to rate-limit the amount of memory that lnd uses to track peers online state, ensuring that we do not store large volumes of uptime information for peers that are constantly changing online state.

This release contains a migration to initialize a top-level-bucket for an outpoint index. There is also a subsequent migration that populates this index with an outpoint's status. This will cut down on expensive bbolt transactions throughout the codebase. The migration process should look something like this upon initial start up: 2020-12-21 10:45:07.256 [INF] LTND: Version: 0.12.0-beta commit=v0.12.0-beta, build=production, logging=default 2020-12-21 10:45:07.257 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2020-12-21 10:45:07.257 [INF] LTND: Opening the main database, this might take a few minutes... 2020-12-21 10:45:07.257 [INF] LTND: Opening bbolt database, sync_freelist=false, auto_compact=false 2020-12-21 10:45:07.304 [INF] CHDB: Checking for schema update: latest_version=20, db_version=17 2020-12-21 10:45:07.304 [INF] CHDB: Performing database schema migration 2020-12-21 10:45:07.304 [INF] CHDB: Applying migration #18 2020-12-21 10:45:07.304 [INF] CHDB: Creating top-level bucket: "peers-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "peers-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #19 2020-12-21 10:45:07.305 [INF] CHDB: Creating top-level bucket: "outpoint-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "outpoint-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #20 2020-12-21 10:45:07.324 [INF] LTND: Database now open (time_to_open=67.71764ms)!

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-v0.12.0-beta.rc3.txt and manifest-v0.12.0-beta.rc3.txt.sig are in the current directory) with:

gpg --verify manifest-v0.12.0-beta.rc3.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.12.0-beta.rc3.txt' gpg: Signature made Tue Dec 15 18:57:27 2020 PST gpg: using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

For this release roasbeef's signature is the secondary signature which can be verified with the following command: gpg --verify roasbeef-manifest-v0.12.0-beta.rc3.txt.sig manifest-v0.12.0-beta.rc3.txt gpg: Signature made Wed Sep 30 17:35:20 2020 PDT gpg: using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

Verifying the Release Timestamp

From this new version onwards, in addition to time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-v0.12.0-beta.rc3.txt.sig.ots and manifest-v0.12.0-beta.rc3.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-v0.12.0-beta.rc3.txt.ots ots verify manifest-v0.12.0-beta.rc3.txt.sig.ots -f roasbeef-manifest-v0.12.0-beta.rc3.txt.sig

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.6, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.0-beta.rc3 gpg: Signature made Tue 15 Dec 2020 10:31:06 PM UTC using RSA key ID 9B280306 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>"

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.0-beta.rc3.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.0-beta.rc3.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta.rc3" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta.rc3" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

New Default Autopilot Heuristic

In this version of lnd, the default heursitic for autopilot has been changed from preferential attachment, to a version that will attempt to optimize for the betweeness centrality of the node. At a high level, this change means that rather than trying to connect (stochastically) to the nodes that have the most channels, lnd will instead attempt to connect to the nodes that appear most often in the shortest paths within the network. This change will serve to step as a stepping stone to further diffuse the graph to make it more resilient.

Pathfinding Improvements

lnd will now properly penalize attempts of larger "wumbo" sized payments proportionally. This will serve to ensure that clients with less active failure information are able to properly prune the search space by increasing the attempt cost for larger payments. New flags has been added to allow users to configure the attempt cost for this value (attemptcost and attemptcostppm). We encourage users taht frequently send larger payments to tweak these parameters to find what works best, and ideally communicate this information back to the maintainers of lnd so we can better tune the current default value.

Graph Download Optimizations

lnd will now batch all insertion operations related to channel graph which should greatly speed up initial graph download. Initial becnhmarks show this change resluting in a 3x speed increase, with further gains likely being seen on mobile and more constrained platforms.

Peer to Peer Updates

A new flag has been added to lnd to enforce a global connection timeout when trying to connect out to new peers. Setting a lower value for this new command line option (timeout) will mean that lnd will give up on unrechable peers much sooner than before, which can be useful when attempting to connect to a set of addresses to open chnnel to a peer.

Automatic Database Compaction

The most important data of any lnd node is stored in its channel database (channel.db). The database library currently used for this DB is bbolt which by design does not give back free space to the file system, even if data is deleted from the DB. This can lead to large DB files and slow startup times. Compaction is the process of creating a fresh copy of a bbolt database that only contains data and no "reserved free space". This process also de-fragments and validates the integrity of the data.

Automatic compaction of the channel.db can now be turned on with the flag --db.bolt.auto-compact. By default this will compact on startup, if the last compaction was more than a week ago. The flag --db.bolt.auto-compact-min-age can also be set to 0 to force compaction on every startup, independent of how long ago it happened last.

Protocol Upgrades

Anchor Output Channels

lnd will now open the new channel type dubbed "anchor channels" by default if both peers support it. This is a channel type that has been available to advanced users since lnd v0.10, but it has seen a few updates that makes it even safer and useful in high fee scenarios, and it is now in line with a proposed BOLT change.

The anchor channel type is a new type of channel that is much safer in high fee scenarios, as it allows bumping the fees after the channel has been force closed, instead of making the peers agreeing on a future close fee. This is also a nice UX improvement, as less of the channel capacity needs to go towards the commitment fee reserve, and can instead be used for payments. In addition it allows bundling multiple HTLC transactions together into one, potentially saving on chain fees in force close scenarios.

The commitment transaction still needs to be signed up front with a fee that ensures its mempool acceptance, and this fee now defaults to 10 sat/vbyte. This can be tuned by the --max-commit-fee-rate-anchors flag, but this should be used with caution. One can opt-out of the anchor channel type for new channels by setting the --protocol.no-anchors flag.

Static Remote Key Feature Bit Required

This new version of lnd now requires channels that use a static remote key, AKA "tweakless commitments". This change improves safety and security for users as now when a channel is force closed by the remote party, the funds will go directly to a user control key. Prior versions of lnd have supported this channel type, but lnd will now only allow this type of channel when making channels with new peer.

Lnd will waive this requirement in the case where it still has legacy channels with a peer. This ensures that lnd can still connect to nodes it has existing channels with, even if they do not understand the feature bit.

Improved End to End Payment Security

The MPP protocol upgrade included a so called "payment address" that improves end-to-end payment security by requiring the sender to include a special nonce in the onion payload specify by the receiver. As intermediate nodes can't guess this secret ahead of time, and it's encrypted in the onion only to the finally receiver, they thwarts a large class of probing and de-anonymization attacks. This new release of lnd will now require this feature bit set in any new invoices it creates, which means all payments that don't include this new payment secret will be rejected.

PSBT Signing

The internal wallet can now create and sign PSBTs. In combination with the ListUnspent RPC this allows RPC users to implement full coin control. This feature also takes us one step closer to the goal of supporting watch-only on-chain wallets in lnd where an online node would only have public keys to track the UTXOs and would delegate the signing to a non-networked lnd node that has the private keys, all through using PSBTs. Read more about the possible use cases and dive into the examples in our PSBT documentation.

Build System

Leveraging the power of GitHub Workflows, we now automatically build and push docker images of all our releases to Docker Hub. This includes images for amd64 and arm64.

The distinction between the production Dockerfile and the development dev.Dockerfile were made more clear in the documentation.

The release binaries for all OS/architectures are now also built by a GitHub Workflow. The deterministic build system introduced in a previous release allows us to independently build and sign the binaries locally. Signatures of more than just one developer will be added to releases in the future.

The experiential build tag has been removed for the assumechanvalid flag that is used to prevent long rescans for neutrino nodes.

Continuous Integration

Our continuous integration pipeline, most notably our integration tests, has received a number of improvements and bug fixes making them considerably faster and somewhat more stable: - An integration test suite running against a bitcoind with the TX index disabled was added. - The ~70 integration tests are now split into 4 parts and run in parallel reducing the execution time by ~50%. - Log files are only uploaded to termbin.com and file.io for failed runs and the bitcoind binaries are extracted from a docker image instead of being downloaded, shaving off a few more minutes from the total itest execution time. - The test harness for the btcd node used as the mining node were improved to fix port collisions which resulted in flaky tests. - A check was added that forces new command line flags to also be documented in the sample-lnd.conf file. - A new make target for itest flake hunting was added. - New make targets for running fuzz tests were added. - Build tags were removed from the integration test files, allowing the linter to check those as well. - The zpay32 package's Decode and Encode functions now have corresponding fuzz tests in the fuzz package. - The brontide fuzz tests have been fixed. - Fuzz testing has been optimized to instruct gofuzz to always mutate the input.

Contract Court Performance Improvements

Performance improvements were made to the contract court subsystem which is responsible for closing out channels on chain and taking on-chain actions required to fully resolve the channel. The number of database transactions required to start up the subsystem has been reduced from one per channel to a single transaction, which reduces startup time. Improvements to the way the subsystem consumes new blocks from its backing bitcoin node have also improved the memory footprint of the system.

Extended Health Checks

A new optional healthcheck has been added to insturct lnd to restart itself in order to refresh an expired RPC TLS cert. This change is useful in containerized contexts such as k8s, where an auto restarting lnd is able to propagate any auth changes in a decoupled manner upon restart.

htlcswitch Enhancements

Database contention has been reduced in the link by batching removal of forwarding packages. The removal timer has also been increased from 1 minute to 1 hour.

A bug has been fixed in our non-strict forwarding randomization to ensure we explciitly randomize our link sleection rather than relying on the undefined ordering of map interation in the Go spec.

Peer Flap Rate Tracking

An update to the channel fitness subsystem has introduced tracking of the number of times lnd is connected and disconnected from each of its peers. This information is surfaced in the output of the ListPeers API.

The flap rate we have recorded for peers is also used to rate limit the amount of data lnd will store to track the peer’s uptime. If a peer has a high flap rate, lnd will reduce the amount of data it stores in memory, resulting in more aggregated uptime information. This change is intended to protect against constantly flapping peers, and will have little effect on peers that are consistently online with the occasional restart. To ensure that we do not permanently punish a peer for a period of instability long in the past, the flap rate we track for peers is exponentially cooled down over time.

RPC Enchancements & Bug Fixes

Uniform Unconfirmed Coin Selection for SendCoins+

lnd now allows all RPC calls that craft and send transactions to spend unconfirmed coins.

This change the following RPCs:

  • Lightning.SendCoins
  • Lightning.SendMany
  • WalletKit.SendOutputs

We've added two new parameters for these methods, following the same format as used for Lightning.OpenChannel RPC:

  • min_confs (default=1)
  • spend_unconfirmed (default=false)

Macaroon Root ID Key Rotation

lnd now supports root ID key rotation. This allows the baker (creator) of a set of macaroons to invalidate them all by deleting and regenerating the root key used to generate the macaroons. This feature is a useful security tool, as if an application/system that uses lnd's macaroons in a fine grained manner is compromised, the admin is able to revoke all generated macaroons.

Several new calls have been added to allow users to take advantage of this feature, namely: * The lncli bakemacaroon call now accepts a new parameter: root_key_id. This new field is an integer that can be used to rotate root ID keys. * A new lncli listmacaroonids command has been added to allow callers to monitor all their existing allocated root IDs. * A new lncli deletemacaroonid call has been added which implements macaroon revocation by allowing the caller to delete a specified root key ID.

New Verbose Output for ChannelBalance

The lncli channebalance call now returns much more information than before in order to give users more insight w.r.t exactly how their funds are distributed off-chain. An output of the new call resmbles the following: ⛰lncli channelbalance { "balance": "27476201", "pending_open_balance": "0", "local_balance": { "sat": "27476201", "msat": "27476201135" }, "remote_balance": { "sat": "109137173", "msat": "109137173865" }, "unsettled_local_balance": { "sat": "0", "msat": "0" }, "unsettled_remote_balance": { "sat": "0", "msat": "0" }, "pending_open_local_balance": { "sat": "0", "msat": "0" }, "pending_open_remote_balance": { "sat": "1783362", "msat": "1783362000" } }

Note that the first two fields (balance and pending_open_balance) are now deprecated and will be removed in the future. Callers should use the new fields that return both sat and msat instead.

Raw Key Support for SharedKeyRequest

The DeriveSharedKey now accepts a raw public key in addition to key locator.

Additional HTLC Information in ListChannels

The ListChannels call will now return additional information about the set of linked HTLCs in a channel. Namely, we'll now return: * The htlc_index of the HTLC within the channel * The forwarding_channel, or the channel that forwarded the HTLC to the targte channel * The forwarding_htlc_index, or the HTLC index on the forwarded channel.

Automated Let's Encrypt Certificates

A new series of command line flags have been added to lnd which allows users to automatically obtain and renew a Let's Encrypt Certificate for the RPC interface of their lnd node. With this change, in certain configurations, callers will be able to hit an lnd now without having to manually store and update the tls.cert locally. New flags added to the lnd command line and lnd.conf:

  • --letsencryptport: The port on which lnd will listen for Let's Encrypt challenges. Let's Encrypt will always try to contact on port 80. Often non-root processes are not allowed to bind to ports lower than 1024. This configuration option allows a different port to be used, but must be used in combination with port forwarding from port 80.
  • --letsencryptdir: The directory to store Let's Encrypt certificates within. By default this is .lnd/letsencrypt.
  • --letsencryptdomain: Request a Let's Encrypt certificate for the domain specified using this flag.

When lncli cannot find a tls.cert file, it will assume the server has a valid (Let's Encrypt) certificate. It is important to pass the domain name as a command line flag to lncli:

lncli --rpcserver my.domain.org:10009

This is necessary as well when connecting to localhost.

Custom Routing Hints for AddHoldInvoice

The AddHoldInvoice RPC call now allows the users to specify their own custom routing hints.

Allow No RPC Auth on Private Addresses

A new config evaluation has been added to allow user to instruct lnd that it should allow RPC requests with no authentiation only if lnd is listening on a private address. This makes certain Docker based configurations more user friendly, as any dependent containers no longer need to obtain and update lnd's RPC authentication information. Assuming lnd is only listening on a non-public private interface, then the --no-macaroons config option is now valid.

New Channel Acceptor Parameters

Additional fields have been added to the ChannelAcceptor API, which allow custom setting of custom errors for the remote peer, an upfront shutdown address for the channel (if supported by the peer), and more. Note that the error provided will be sent to the peer verbatim, so should not contain sensitive information.

Maximum Local CSV

When opening a channel, the remote party can specify the CSV delay for your funds. This value determines the amount of time that your balance will be unavailable in the case where your force close the channel. A max_local_csv parameter has been added to allow setting of custom limitations on this value. For outgoing channels, this can be set using the max_local_csv field in the OpenChannel request. The maxlocaldelay config value can be used to set a default maximum value for all channels.

Disable TLS for REST

It is now possible to disable TLS for REST RPC using --no-rest-tls.

Refactoring

This release sees the removal of several components from the main lnd package: - fundingmanager.go and tests are moved to the funding package. - chainregistry.go and chainparams.go have been moved to the chainreg package. - mock.go has been removed in favor of the lntest/mock package. - A global variable activeNetParams has been removed.

The peer package's dependency on brontide has been removed.

Miscellaneous

The DNS servers to use for initial peer bootstrapping can now be specified to overwrite the hard coded default values.

All supported command line flags are now also properly documented in the sample-lnd.conf file.

A new flag has been added to instruct lnd to timeout early if it can't obtain the file lock on bolt DB.

Multi node management

Hosting nodes on non-trusted (cloud) hardware was made safer by adding a stateless initialization mode that instructs lnd to not store any unencrypted macaroons on the host's file system. Instead, the admin macaroon is returned in the response of the wallet creation request and must be stored by the caller.

To support the stateless initialization mode mentioned above on the client side as well, configuration profiles for lncli can now be created. Those profiles make it easy to interact with multiple nodes from the same client machine. For additional security the macaroons stored in the profiles can optionally be encrypted with a password.

Recovery

Forcing the on-chain wallet to rescan its state from chain was made easier by adding the --reset-wallet-transactions flag to lnd that replaces the functionality previously only available in the external tool dropwtxmgr.

Individual subsystem log levels

A change that makes it possible to set the log level for individual subsystems was merged. One can now specify a global log level, and subsystem log levels that will override the global setting: --debuglevel=debug,PEER=info,SRVR=trace.

Bug fixes

The full list of changes since v0.11.0-beta can be found here:

Contributors (Alphabetical Order)

Alex Bosworth András Bánki-Horváth Ben Woosley Bjarne Magnussen Calvin Zachman Carla Kirk-Cohen Carsten Otto Conner Fromknecht Dan Janosik Daniel Babbev Dominik Spicher Eugene Siegel Federico Bond Glen Cooper githorray Graham Krizek Hampus Sjöberg Johan T. Halseth Joost Jager Juan Pablo Civile Jules Lamur Kartik Shah Marty Jones Matheus Degiovani Mayank Chhabra MrManPew Olaoluwa Osuntokun Oliver Gugger positiveblue Roei Erez Tom Kirkpatrick Torkel Rogstad Wilmer Paulino Yaacov Akiba Slama Yan Pritzker yyforyongyu

Go to Repo Go to Release

getumbrel/umbrel: v0.3.1

Published: 2021-01-03 08:53:13 UTC


This update brings some minor bug fixes to keep your Umbrel ticking over smoothly.

Changes:

  • Fix IP Collisions (#390) ba058d9 (@lukechilds)
  • Update to getumbrel/manager to v0.2.9 (#393) 516fe31 (@lukechilds)
  • Fix incorrect app version for sphinx-relay (#378) c303778 (@AaronDewes)
  • Fix lncli and bitcoin-cli wrapper scripts (#388) 9ef5fd7 (@AaronDewes @lukechilds)
  • Wrap sphinx-relay process with init system (#395) 8bb1d1e (@lukechilds)
  • Umbrel v0.3.1 (#394) 2735baa (@lukechilds)

Diff: https://github.com/getumbrel/umbrel/compare/v0.3.0...v0.3.1

Go to Repo Go to Release

bisq-network/bisq: v1.5.4

Published: 2020-12-31 12:50:14 UTC


A newer version is already available! Please don’t use this version anymore.

This is a hotfix that improves DoS protection.

For a full list of changes please see milestone v1.5.4 for more details.

Here are the release notes from v1.5.2:

Release notes

This release improves transaction handling in certain edge cases and contains multiple fixes making Bisq more reliable in general. There are also some notable UI updates for the payment accounts and offer book screens.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.4.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.4.jar The output need to match the value from the Bisq-1.5.4.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.4.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Cleanup tool for saved trades that failed market price check

With this release we are also shipping a cleanup tool (Bisq-cleanup-trades*). It will remove corrupt trade entries added due to bug https://github.com/bisq-network/bisq/issues/2924. Install and run once, it will shut down automatically, then install version 1.5.4 or later. You can verify the binary the same way as you do with the Bisq application.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @deusmax
  • @ghubstan
  • @jmacxx
  • @m52go
  • @oscarguindzberg
  • @sqrrm
  • @stejbac
  • @wiz

A special thanks to our first time contributors:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

getumbrel/umbrel: v0.3.0

Published: 2020-12-30 14:26:35 UTC


Introducing the Umbrel App Store. You can now download and install BTCPay Server, Specter Desktop, Sphinx Relay, BTC RPC Explorer, Ride The Lightning, Lightning Terminal, and ThunderHub — all on your Umbrel in one click.

Changes:

  • Add Electrs to README.md (#330) 7ab2d06 (@PeterXMR)
  • Add app framework (#333) ffe9e2f (@lukechilds)
  • Add btc-rpc-explorer app (#334) e9ceed5 (@lukechilds)
  • Update example app PR link in docs c114eaa (@lukechilds)
  • Tweak support link (#337) 83f7f87 (@mayankchhabra)
  • Correctly set project name for apps (#338) 433794a (@lukechilds)
  • Pass APPHIDDENSERVICE environment variable to apps (#340) 56343b1 (@lukechilds)
  • Set default APPHIDDENSERVICE value to "notyetset.onion" 9fcc687 (@lukechilds)
  • Supress errors when app hidden service does not yet exist 4b6546a (@lukechilds)
  • Only ignore top level dotfiles (#344) d7b68c6 (@lukechilds)
  • Remove quotes from .env-sample file (#346) 6f4241f (@AaronDewes)
  • Reduce dbcache post IBD (#345) 1354cdf (@lukechilds)
  • Upgrade btc-rpc-explorer to v2.1.0 (#350) 353cec4 (@lukechilds)
  • Add thunderhub app (#343) 3d9902d (@apotdevin)
  • Add sphinx-relay app (#341) 9f46a08 (@gonzaloaune)
  • Add ride-the-lightning app (#336) f8179b5 (@louneskmt @lukechilds)
  • Add lightning-terminal app (#348) 29cad06 (@louneskmt @lukechilds)
  • Add specter-desktop app (#339) 5a763f6 (@k9ert @lukechilds)
  • Exclude .gitkeep files when creating app data dir bcc71e9 (@lukechilds)
  • Add btcpay-server app (#353) 52bde35 (@louneskmt @mayankchhabra @lukechilds)
  • Remove specter-desktop authentication 9c224e8 (@lukechilds)
  • Set shutdown timeouts for all apps to 1m b658d31 (@lukechilds)
  • Update sphinx-relay to v1.3.2 6231fdb (@lukechilds)
  • Exclude app-data from UMBREL_ROOT chown (#365) 828b133 (@lukechilds)
  • Pull new app containers on update (#364) 35007d1 (@lukechilds)
  • Kill karen on update (#366) a0baddc (@lukechilds)
  • Clarify app logs (#367) b9c1bb8 (@mayankchhabra)
  • Check for empty value before pulling app (#369) 549f985 (@mayankchhabra)
  • Create app data dir before pulling images (#371) a1a41bf (@louneskmt)
  • Add apps to registry.json (#373) c3f3571 (@mayankchhabra)
  • Add debug script (#294) e5ac5e3 (@AaronDewes @louneskmt @mayankchhabra)
  • Umbrel App Framework (#374) df2d1ec (@mayankchhabra)
  • Update to getumbrel/dashboard to v0.3.14 (#375) 9575b7e (@lukechilds)
  • Update to getumbrel/manager to v0.2.8 (#376) 46de834 (@lukechilds

Diff: https://github.com/getumbrel/umbrel/compare/v0.2.15...v0.3.0

Go to Repo Go to Release

bisq-network/bisq: v1.5.3

Published: 2020-12-30 13:52:55 UTC


A newer version is already available! Please don’t use this version anymore.

This is a hotfix that introduces DoS protection.

Here are the release notes from v1.5.2:

Release notes

This release improves transaction handling in certain edge cases and contains multiple fixes making Bisq more reliable in general. There are also some notable UI updates for the payment accounts and offer book screens.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.3.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.3.jar The output need to match the value from the Bisq-1.5.3.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

~The binary of this version is not signed by a code signing certificate right now as it was in previous versions. This is because of an expired certificate that wasn't renewed in-time. It will be signed on 28th of Dec with the newly received certificate and this note will be removed afterwards.~ The Windows binary was signed on Dec 27th and uploaded together with an updated signature file.

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.3.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Cleanup tool for saved trades that failed market price check

With this release we are also shipping a cleanup tool (Bisq-cleanup-trades*). It will remove corrupt trade entries added due to bug https://github.com/bisq-network/bisq/issues/2924. Install and run once, it will shut down automatically, then install version 1.5.3 or later. You can verify the binary the same way as you do with the Bisq application.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @deusmax
  • @ghubstan
  • @jmacxx
  • @m52go
  • @oscarguindzberg
  • @sqrrm
  • @stejbac
  • @wiz

A special thanks to our first time contributors:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

cryptoadvance/specter-desktop: v0.11.0-pre4

Published: 2020-12-28 13:43:43 UTC


This is a pre-release! Do not use unless you're sure know what you're doing!

This is a pre-release for beta-testing the next version of Specter.

Changes to notice while testing: - Fix Coldcard signing issue when exporting to Electrum - Fix wrong address type inPDF backup - Fix issue when camera is open and scanning doesn't work for too long. - Export transactions history, UTXOs, and addresses to CSV - Reorganize the UTXO screen - Label any address from any screen it is at. - Sorting, searching, page limit, of the transactions/ utxo lists. - New Tor tab in the settings for managing the connections over Tor and the Specter Tor hidden service

Go to Repo Go to Release

cryptoadvance/specter-desktop: v0.11.0-pre3

Published: 2020-12-26 16:15:48 UTC


This is a pre-release! Do not use unless you're sure know what you're doing!

This is a pre-release for beta-testing the next version of Specter.

Changes to notice while testing: - Fix Coldcard signing issue when exporting to Electrum - Fix wrong address type inPDF backup - Fix issue when camera is open and scanning doesn't work for too long. - Export transactions history, UTXOs, and addresses to CSV - Reorganize the UTXO screen - Label any address from any screen it is at. - Sorting, searching, page limit, of the transactions/ utxo lists. - New Tor tab in the settings for managing the connections over Tor and the Specter Tor hidden service

Go to Repo Go to Release

bisq-network/bisq: v1.5.2

Published: 2020-12-22 15:04:56 UTC


A newer version is already available! Please don’t use this version anymore.

Release notes

This release improves transaction handling in certain edge cases and contains multiple fixes making Bisq more reliable in general. There are also some notable UI updates for the payment accounts and offer book screens.

DAO

UI

Trading

Wallet

Reliability

Mediation/Arbitration

Performance

Network

API

Development

Assets

No new assets.

Verification

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: "This key is not certified with a trusted signature!" - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-1.5.2.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-1.5.2.jar The output need to match the value from the Bisq-1.5.2.jar.txt file.

Known issues with installation

macOS Catalina:

Bisq can't be opened because Apple cannot check it for malicious software

This happens the first time Bisq is run on macOS Catalina. It is because a new security feature in Catalina has newer requirements of how apps are packaged. We are working on ways to address this (see #3402 and #4196 for details).

Workaround: Right click on the installed Bisq app > Click Open (warning popup shown again, but with new button available) > Click Open

Bisq would like to receive keystrokes from any application.

Discussed in issue https://github.com/bisq-network/bisq/issues/3373, you will see a permission request in the latest macOS version that Bisq wants to receive keystrokes from any application. Unfortunately that is an issue for all Java applications that are run on Catalina right now. We are investigating already how to solve this issue and will fix in one of our next updates.

Windows:

~The binary of this version is not signed by a code signing certificate right now as it was in previous versions. This is because of an expired certificate that wasn't renewed in-time. It will be signed on 28th of Dec with the newly received certificate and this note will be removed afterwards.~ The Windows binary was signed on Dec 27th and uploaded together with an updated signature file.

There is a known issue with Anti Virus software. We got several reports from users running into different problems. Either the AV software blocks Bisq or Tor, delete files in the data directory [2] or app directory [1]) or cause such a long delay at startup that Tor gets terminated and a file remains locked which can cause that Bisq cannot be started afterwards. To resolve that you need to restart Windows then the lock get released. We are working on solutions to fix those issues.

If you use Crypto currencies on your Windows system be aware that Windows is much more vulnerable to malware than Linux or OSX. Consider to use a dedicated non-Windows system when dealing with cryptocurrencies.

[1] Application directory (contains application installation files): C:\Users<username>\AppData\Local\Bisq

[2] Data directory (contains all Bisq data including wallet): C:\Users<username>\AppData\Roaming\Bisq\btc_mainnet\tor (you can delete everything except the hiddenservice directory)

Linux:

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction: cd ~/Downloads mkdir tmp cd tmp ar x ../Bisq-64bit-1.5.2.deb sudo tar Jxvf data.tar.xz sudo cp -rp opt/Bisq /opt/ That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

Cleanup tool for saved trades that failed market price check

With this release we are also shipping a cleanup tool (Bisq-cleanup-trades*). It will remove corrupt trade entries added due to bug https://github.com/bisq-network/bisq/issues/2924. Install and run once, it will shut down automatically, then install version 1.5.2 or later. You can verify the binary the same way as you do with the Bisq application.

Credits

Thanks to everyone who directly contributed to this release:

  • @chimp1984
  • @ripcurlx
  • @deusmax
  • @ghubstan
  • @jmacxx
  • @m52go
  • @oscarguindzberg
  • @sqrrm
  • @stejbac
  • @wiz

A special thanks to our first time contributors:

As well as to everyone that helped with translations on Transifex.

Go to Repo Go to Release

unchained-capital/caravan: v0.3.4

Published: 2020-12-21 16:07:38 UTC


Adding Coldcard support to caravan

Go to Repo Go to Release

cryptoadvance/specter-desktop: v0.11.0-pre2

Published: 2020-12-21 13:54:58 UTC


This is a pre-release! Do not use unless you're sure know what you're doing!

This is a pre-release for beta-testing the next version of Specter.

Changes to notice while testing: - Export transactions history, UTXOs, and addresses to CSV - Reorganize the UTXO screen - Label any address from any screen it is at. - Sorting, searching, page limit, of the transactions/ utxo lists. - New Tor tab in the settings for managing the connections over Tor and the Specter Tor hidden service

Go to Repo Go to Release

lightningnetwork/lnd: v0.12.0-beta.rc2

Published: 2020-12-19 01:34:49 UTC


This release marks the first major release in the v0.12.x series! As this is a major release several new features are included in this release including: anchor commitment types are now the default, anchor commitment support for watchtowers, new arguments to auto compact the database as well as drop the wtxmgr state, generic wallet PSBT crafting+signing, and much more! As usual, this release contains several important bug fixes, so we recommend all users update.

Database Migrations

  • TODO: describe "peers-bucket"

This release contains a migration to initialize a top-level-bucket for an outpoint index. There is also a subsequent migration that populates this index with an outpoint's status. This will cut down on expensive bbolt transactions throughout the codebase. The migration process should look something like this upon initial start up: 2020-12-21 10:45:07.256 [INF] LTND: Version: 0.12.0-beta commit=v0.12.0-beta, build=production, logging=default 2020-12-21 10:45:07.257 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2020-12-21 10:45:07.257 [INF] LTND: Opening the main database, this might take a few minutes... 2020-12-21 10:45:07.257 [INF] LTND: Opening bbolt database, sync_freelist=false, auto_compact=false 2020-12-21 10:45:07.304 [INF] CHDB: Checking for schema update: latest_version=20, db_version=17 2020-12-21 10:45:07.304 [INF] CHDB: Performing database schema migration 2020-12-21 10:45:07.304 [INF] CHDB: Applying migration #18 2020-12-21 10:45:07.304 [INF] CHDB: Creating top-level bucket: "peers-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "peers-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #19 2020-12-21 10:45:07.305 [INF] CHDB: Creating top-level bucket: "outpoint-bucket" ... 2020-12-21 10:45:07.305 [INF] CHDB: Created top-level bucket: "outpoint-bucket" 2020-12-21 10:45:07.305 [INF] CHDB: Applying migration #20 2020-12-21 10:45:07.324 [INF] LTND: Database now open (time_to_open=67.71764ms)!

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-v0.12.0-beta.rc2.txt and manifest-v0.12.0-beta.rc2.txt.sig are in the current directory) with:

gpg --verify manifest-v0.12.0-beta.rc2.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.12.0-beta.rc2.txt' gpg: Signature made Tue Dec 15 18:57:27 2020 PST gpg: using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

For this release roasbeef's signature is the secondary signature which can be verified with the following command: gpg --verify roasbeef-manifest-v0.12.0-beta.rc2.txt.sig manifest-v0.12.0-beta.rc2.txt gpg: Signature made Wed Sep 30 17:35:20 2020 PDT gpg: using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

Verifying the Release Timestamp

From this new version onwards, in addition to time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-v0.12.0-beta.rc2.txt.sig.ots and manifest-v0.12.0-beta.rc2.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands: ots verify manifest-v0.12.0-beta.rc2.txt.ots ots verify manifest-v0.12.0-beta.rc2.txt.sig.ots -f roasbeef-manifest-v0.12.0-beta.rc2.txt.sig

Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.15.6, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.12.0-beta.rc2 gpg: Signature made Tue 15 Dec 2020 10:31:06 PM UTC using RSA key ID 9B280306 gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>"

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.12.0-beta.rc2.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz tar -xvzf lnd-source-v0.12.0-beta.rc2.tar.gz GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta.rc2" ./cmd/lnd GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.12.0-beta.rc2" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

New Default Autopilot Heuristic

In this version of lnd, the default heursitic for autopilot has been changed from preferential attachment, to a version that will attempt to optimize for the betweeness centrality of the node. At a high level, this change means that rather than trying to connect (stochastically) to the nodes that have the most channels, lnd will instead attempt to connect to the nodes that appear most often in the shortest paths within the network. This change will serve to step as a stepping stone to further diffuse the graph to make it more resilient.

Pathfinding Improvements

lnd will now properly penalize attempts of larger "wumbo" sized payments proportionally. This will serve to ensure that clients with less active failure information are able to properly prune the search space by increasing the attempt cost for larger payments. New flags has been added to allow users to configure the attempt cost for this value (attemptcost and attemptcostppm). We encourage users taht frequently send larger payments to tweak these parameters to find what works best, and ideally communicate this information back to the maintainers of lnd so we can better tune the current default value.

Graph Download Optimizations

lnd will now batch all insertion operations related to channel graph which should greatly speed up initial graph download. Initial becnhmarks show this change resluting in a 3x speed increase, with further gains likely being seen on mobile and more constrained platforms.

Peer to Peer Updates

A new flag has been added to lnd to enforce a global connection timeout when trying to connect out to new peers. Setting a lower value for this new command line option (timeout) will mean that lnd will give up on unrechable peers much sooner than before, which can be useful when attempting to connect to a set of addresses to open chnnel to a peer.

Automatic Database Compaction

The most important data of any lnd node is stored in its channel database (channel.db). The database library currently used for this DB is bbolt which by design does not give back free space to the file system, even if data is deleted from the DB. This can lead to large DB files and slow startup times. Compaction is the process of creating a fresh copy of a bbolt database that only contains data and no "reserved free space". This process also de-fragments and validates the integrity of the data.

Automatic compaction of the channel.db can now be turned on with the flag --db.bolt.auto-compact. By default this will compact on startup, if the last compaction was more than a week ago. The flag --db.bolt.auto-compact-min-age can also be set to 0 to force compaction on every startup, independent of how long ago it happened last.

Protocol Upgrades

Anchor Output Channels

lnd will now open the new channel type dubbed "anchor channels" by default if both peers support it. This is a channel type that has been available to advanced users since lnd v0.10, but it has seen a few updates that makes it even safer and useful in high fee scenarios, and it is now in line with a proposed BOLT change.

The anchor channel type is a new type of channel that is much safer in high fee scenarios, as it allows bumping the fees after the channel has been force closed, instead of making the peers agreeing on a future close fee. This is also a nice UX improvement, as less of the channel capacity needs to go towards the commitment fee reserve, and can instead be used for payments. In addition it allows bundling multiple HTLC transactions together into one, potentially saving on chain fees in force close scenarios.

The commitment transaction still needs to be signed up front with a fee that ensures its mempool acceptance, and this fee now defaults to 10 sat/vbyte. This can be tuned by the --max-commit-fee-rate-anchors flag, but this should be used with caution. One can opt-out of the anchor channel type for new channels by setting the --protocol.no-anchors flag.

Static Remote Key Feature Bit Required

This new version of lnd now requires channels that use a static remote key, AKA "tweakless commitments". This change improves safety and security for users as now when a channel is force closed by the remote party, the funds will go directly to a user control key. Prior versions of lnd have supported this channel type, but lnd will now only allow this type of channel when making channels with new peer.

Lnd will waive this requirement in the case where it still has legacy channels with a peer. This ensures that lnd can still connect to nodes it has existing channels with, even if they do not understand the feature bit.

Improved End to End Payment Security

The MPP protocol upgrade included a so called "payment address" that improves end-to-end payment security by requiring the sender to include a special nonce in the onion payload specify by the receiver. As intermediate nodes can't guess this secret ahead of time, and it's encrypted in the onion only to the finally receiver, they thwarts a large class of probing and de-anonymization attacks. This new release of lnd will now require this feature bit set in any new invoices it creates, which means all payments that don't include this new payment secret will be rejected.

PSBT Signing

The internal wallet can now create and sign PSBTs. In combination with the ListUnspent RPC this allows RPC users to implement full coin control. This feature also takes us one step closer to the goal of supporting watch-only on-chain wallets in lnd where an online node would only have public keys to track the UTXOs and would delegate the signing to a non-networked lnd node that has the private keys, all through using PSBTs. Read more about the possible use cases and dive into the examples in our PSBT documentation.

Build System

Leveraging the power of GitHub Workflows, we now automatically build and push docker images of all our releases to Docker Hub. This includes images for amd64 and arm64.

The distinction between the production Dockerfile and the development dev.Dockerfile were made more clear in the documentation.

The release binaries for all OS/architectures are now also built by a GitHub Workflow. The deterministic build system introduced in a previous release allows us to independently build and sign the binaries locally. Signatures of more than just one developer will be added to releases in the future.

The experiential build tag has been removed for the assumechanvalid flag that is used to prevent long rescans for neutrino nodes.

Continuous Integration

Our continuous integration pipeline, most notably our integration tests, has received a number of improvements and bug fixes making them considerably faster and somewhat more stable: - An integration test suite running against a bitcoind with the TX index disabled was added. - The ~70 integration tests are now split into 4 parts and run in parallel reducing the execution time by ~50%. - Log files are only uploaded to termbin.com and file.io for failed runs and the bitcoind binaries are extracted from a docker image instead of being downloaded, shaving off a few more minutes from the total itest execution time. - The test harness for the btcd node used as the mining node were improved to fix port collisions which resulted in flaky tests. - A check was added that forces new command line flags to also be documented in the sample-lnd.conf file. - A new make target for itest flake hunting was added. - New make targets for running fuzz tests were added. - Build tags were removed from the integration test files, allowing the linter to check those as well. - The zpay32 package's Decode and Encode functions now have corresponding fuzz tests in the fuzz package. - The brontide fuzz tests have been fixed. - Fuzz testing has been optimized to instruct gofuzz to always mutate the input.

Contract Court Performance Improvements

Performance improvements were made to the contract court subsystem which is responsible for closing out channels on chain and taking on-chain actions required to fully resolve the channel. The number of database transactions required to start up the subsystem has been reduced from one per channel to a single transaction, which reduces startup time. Improvements to the way the subsystem consumes new blocks from its backing bitcoin node have also improved the memory footprint of the system.

Extended Health Checks

A new optional healthcheck has been added to insturct lnd to restart itself in order to refresh an expired RPC TLS cert. This change is useful in containerized contexts such as k8s, where an auto restarting lnd is able to propagate any auth changes in a decoupled manner upon restart.

htlcswitch Enhancements

Database contention has been reduced in the link by batching removal of forwarding packages. The removal timer has also been increased from 1 minute to 1 hour.

A bug has been fixed in our non-strict forwarding randomization to ensure we explciitly randomize our link sleection rather than relying on the undefined ordering of map interation in the Go spec.

Peer Flap Rate Tracking

An update to the channel fitness subsystem has introduced tracking of the number of times lnd is connected and disconnected from each of its peers. This information is surfaced in the output of the ListPeers API.

The flap rate we have recorded for peers is also used to rate limit the amount of data lnd will store to track the peer’s uptime. If a peer has a high flap rate, lnd will reduce the amount of data it stores in memory, resulting in more aggregated uptime information. This change is intended to protect against constantly flapping peers, and will have little effect on peers that are consistently online with the occasional restart. To ensure that we do not permanently punish a peer for a period of instability long in the past, the flap rate we track for peers is exponentially cooled down over time.

RPC Enchancements & Bug Fixes

Uniform Unconfirmed Coin Selection for SendCoins+

lnd now allows all RPC calls that craft and send transactions to spend unconfirmed coins.

This change the following RPCs:

  • Lightning.SendCoins
  • Lightning.SendMany
  • WalletKit.SendOutputs

We've added two new parameters for these methods, following the same format as used for Lightning.OpenChannel RPC:

  • min_confs (default=1)
  • spend_unconfirmed (default=false)

Macaroon Root ID Key Rotation

lnd now supports root ID key rotation. This allows the baker (creator) of a set of macaroons to invalidate them all by deleting and regenerating the root key used to generate the macaroons. This feature is a useful security tool, as if an application/system that uses lnd's macaroons in a fine grained manner is compromised, the admin is able to revoke all generated macaroons.

Several new calls have been added to allow users to take advantage of this feature, namely: * The lncli bakemacaroon call now accepts a new parameter: root_key_id. This new field is an integer that can be used to rotate root ID keys. * A new lncli listmacaroonids command has been added to allow callers to monitor all their existing allocated root IDs. * A new lncli deletemacaroonid call has been added which implements macaroon revocation by allowing the caller to delete a specified root key ID.

New Verbose Output for ChannelBalance

The lncli channebalance call now returns much more information than before in order to give users more insight w.r.t exactly how their funds are distributed off-chain. An output of the new call resmbles the following: ⛰lncli channelbalance { "balance": "27476201", "pending_open_balance": "0", "local_balance": { "sat": "27476201", "msat": "27476201135" }, "remote_balance": { "sat": "109137173", "msat": "109137173865" }, "unsettled_local_balance": { "sat": "0", "msat": "0" }, "unsettled_remote_balance": { "sat": "0", "msat": "0" }, "pending_open_local_balance": { "sat": "0", "msat": "0" }, "pending_open_remote_balance": { "sat": "1783362", "msat": "1783362000" } }

Note that the first two fields (balance and pending_open_balance) are now deprecated and will be removed in the future. Callers should use the new fields that return both sat and msat instead.

Raw Key Support for SharedKeyRequest

The DeriveSharedKey now accepts a raw public key in addition to key locator.

Additional HTLC Information in ListChannels

The ListChannels call will now return additional information about the set of linked HTLCs in a channel. Namely, we'll now return: * The htlc_index of the HTLC within the channel * The forwarding_channel, or the channel that forwarded the HTLC to the targte channel * The forwarding_htlc_index, or the HTLC index on the forwarded channel.

Automated Let's Encrypt Certificates

A new series of command line flags have been added to lnd which allows users to automatically obtain and renew a Let's Encrypt Certificate for the RPC interface of their lnd node. With this change, in certain configurations, callers will be able to hit an lnd now without having to manually store and update the tls.cert locally. New flags added to the lnd command line and lnd.conf:

  • --letsencryptport: The port on which lnd will listen for Let's Encrypt challenges. Let's Encrypt will always try to contact on port 80. Often non-root processes are not allowed to bind to ports lower than 1024. This configuration option allows a different port to be used, but must be used in combination with port forwarding from port 80.
  • --letsencryptdir: The directory to store Let's Encrypt certificates within. By default this is .lnd/letsencrypt.
  • --letsencryptdomain: Request a Let's Encrypt certificate for the domain specified using this flag.

When lncli cannot find a tls.cert file, it will assume the server has a valid (Let's Encrypt) certificate. It is important to pass the domain name as a command line flag to lncli:

lncli --rpcserver my.domain.org:10009

This is necessary as well when connecting to localhost.

Custom Routing Hints for AddHoldInvoice

The AddHoldInvoice RPC call now allows the users to specify their own custom routing hints.

Allow No RPC Auth on Private Addresses

A new config evaluation has been added to allow user to instruct lnd that it should allow RPC requests with no authentiation only if lnd is listening on a private address. This makes certain Docker based configurations more user friendly, as any dependent containers no longer need to obtain and update lnd's RPC authentication information. Assuming lnd is only listening on a non-public private interface, then the --no-macaroons config option is now valid.

New Channel Acceptor Parameters

Additional fields have been added to the ChannelAcceptor API, which allow custom setting of custom errors for the remote peer, an upfront shutdown address for the channel (if supported by the peer), and more. Note that the error provided will be sent to the peer verbatim, so should not contain sensitive information.

Maximum Local CSV

When opening a channel, the remote party can specify the CSV delay for your funds. This value determines the amount of time that your balance will be unavailable in the case where your force close the channel. A max_local_csv parameter has been added to allow setting of custom limitations on this value. For outgoing channels, this can be set using the max_local_csv field in the OpenChannel request. The maxlocaldelay config value can be used to set a default maximum value for all channels.

Disable TLS for REST

It is now possible to disable TLS for REST RPC using --no-rest-tls.

Refactoring

This release sees the removal of several components from the main lnd package: - fundingmanager.go and tests are moved to the funding package. - chainregistry.go and chainparams.go have been moved to the chainreg package. - mock.go has been removed in favor of the lntest/mock package. - A global variable activeNetParams has been removed.

The peer package's dependency on brontide has been removed.

Miscellaneous

The DNS servers to use for initial peer bootstrapping can now be specified to overwrite the hard coded default values.

All supported command line flags are now also properly documented in the sample-lnd.conf file.

A new flag has been added to instruct lnd to timeout early if it can't obtain the file lock on bolt DB.

Multi node management

Hosting nodes on non-trusted (cloud) hardware was made safer by adding a stateless initialization mode that instructs lnd to not store any unencrypted macaroons on the host's file system. Instead, the admin macaroon is returned in the response of the wallet creation request and must be stored by the caller.

To support the stateless initialization mode mentioned above on the client side as well, configuration profiles for lncli can now be created. Those profiles make it easy to interact with multiple nodes from the same client machine. For additional security the macaroons stored in the profiles can optionally be encrypted with a password.

Recovery

Forcing the on-chain wallet to rescan its state from chain was made easier by adding the --reset-wallet-transactions flag to lnd that replaces the functionality previously only available in the external tool dropwtxmgr.

Individual subsystem log levels

A change that makes it possible to set the log level for individual subsystems was merged. One can now specify a global log level, and subsystem log levels that will override the global setting: --debuglevel=debug,PEER=info,SRVR=trace.

Bug fixes

Contributors (Alphabetical Order)

Alex Bosworth András Bánki-Horváth Ben Woosley Bjarne Magnussen Calvin Zachman Carla Kirk-Cohen Carsten Otto Conner Fromknecht Dan Janosik Daniel Babbev Dominik Spicher Eugene Siegel Federico Bond Glen Cooper githorray Graham Krizek Hampus Sjöberg Johan T. Halseth Joost Jager Juan Pablo Civile Jules Lamur Kartik Shah Marty Jones Matheus Degiovani Mayank Chhabra MrManPew Olaoluwa Osuntokun Oliver Gugger positiveblue Roei Erez Tom Kirkpatrick Torkel Rogstad Wilmer Paulino Yaacov Akiba Slama Yan Pritzker yyforyongyu

Go to Repo Go to Release

BlueWallet/BlueWallet: v6.0.1

Published: 2020-12-18 19:51:22 UTC


  • ADD: enable batch-send on multisig wallets
  • FIX: Speed-up multisig wallets (disable handoff for multisig)
  • FIX: Import Multisig from Specter Desktop - Fingerprint is Incorrect
  • FIX: broken export .txn file on tx confirmation screen
  • FIX: backup screen would flash during loading on dark mode
  • FIX: Handle opening links if the default browser isn't Safari
  • FIX: contradiction in Vault introduction text
  • FIX: localizations for CA, DE, ES, faIR, slSI, csCZ, ptBR

Go to Repo Go to Release