Releases: lightninglabs/pool
pool v0.5.3-alpha
This marks the second minor release of poold
in the 0.5.x series (since v0.5.2-alpha
was unfortunately never officially released, only tagged)! This release includes bug fixes and some developer improvements.
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/guggero/pgp_keys.asc | gpg --import
Once you have the required PGP keys, you can verify the release (assuming manifest-v0.5.3-alpha.txt
and manifest-v0.5.3-alpha.sig
are in the current directory) with:
gpg --verify manifest-v0.5.3-alpha.sig manifest-v0.5.3-alpha.txt
You should see the following if the verification was successful:
gpg: Signature made Mi 29 Jul 2020 14:59:19 CEST
gpg: using RSA key 6E01EEC9656903B0542B8F1003DB6322267C373B
gpg: Good signature from "Oliver Gugger <gugger@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 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.17.3
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.5.3-alpha
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 poold-source-v0.5.3-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.5.3-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Release Notes (since v0.5.1-alpha
)
Bug Fixes
- Fixed a crash in the auctioneer client.
- Fixed an issue with the internal signing client.
- Fixed missing balance in account renewal, deposits and withdrawals.
- Fixed an issue with the macaroon DB not being closed correctly.
- Fixed remote side not getting noticed on sidecar ticket cancellation.
- Added an example for a required flag in the docs.
Miscellaneous improvements
- Added JS stubs.
- Added a command to decode a sidecar ticket.
- Added commands to list and cancel sidecar tickets.
- Added
--sats_per_vbyte
flag to account creation command. - Added compatibility with
lnd v0.14.x-beta
. - Moved CI pipeline from Travis to GitHub Actions.
- Prepared macaroon service for stateless init in LiT.
- Enabled client side support for script-enforced leases.
- Add scaffold and initial example for using
mock-gen
in unit tests. - Add renew flags to account deposit and withdrawal commands.
- Add client side support for per-batch account auto-renewal.
Contributors (Alphabetical Order)
Carla Kirk Cohen
Jordi Montes
Olaoluwa Osuntokun
Oliver Gugger
Turtle
Wilmer Paulino
pool v0.5.1-alpha
This marks the first minor release of poold
in the 0.5.x series.! This release includes bug fixes and some developer improvements.
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/guggero/pgp_keys.asc | gpg --import
Once you have the required PGP keys, you can verify the release (assuming manifest-v0.5.1-alpha.txt
and manifest-v0.5.1-alpha.txt.sig
are in the current directory) with:
gpg --verify manifest-v0.5.1-alpha.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.5.1-alpha.txt'
gpg: Signature made Mi 29 Jul 2020 14:59:19 CEST
gpg: using RSA key 6E01EEC9656903B0542B8F1003DB6322267C373B
gpg: Good signature from "Oliver Gugger <gugger@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 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.5
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.5.1-alpha
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 poold-source-v0.5.1-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.5.1-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Release Notes
Bug Fixes
- An exponential backoff for re-connects is used when using the mailbox to negotiate sidecar channels.
- The trader key is now interpreted correctly in the
pool sidecar offer
command. - The default allowed routing fee for paying the initial LSAT is now 5% and can additionally be customized in the config.
- A bug that prevented the trader from re-connecting to the server in certain cases is now fixed.
Miscellaneous improvements
- The nonce of the matched order is now returned in the
pool auction leases
call. - Proto files are now compiled using Docker to make version pinning easier.
Contributors (Alphabetical Order)
Carla Kirk Cohen
Olaoluwa Osuntokun
Oliver Gugger
Turtle
pool v0.5.0-alpha
This marks the 5th major release of poold
! This release includes initial support for the new sidecar channels feature, adds a new SelfBalance
field to Bid
orders to allow dual funded channels, adds a new endpoint for observing real-time market data, and includes several bug fixes!
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.5.0-alpha.txt
and manifest-v0.5.0-alpha.txt.asc
are in the current directory) with:
gpg --verify manifest-v0.5.0-alpha.txt.asc
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.5.0-alpha.txt'
gpg: Signature made Wed May 26 00:04:18 2021 PDT
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 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.5
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.5.0-alpha
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 poold-source-v0.5.0-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.5.0-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Release Notes
RPC Changes
New GetInfo
RPC
A new GetInfo
RPC call was added that shows useful information:
- Version of the trader daemon and synced block height
- Own node rating and batch/account/order summary
- Current market statistics (see below)
- The state of the
--newnodesonly
flag. - Auctioneer connection and LSAT token statistics
Market Information within GetInfo
The GetInfo
call has been enhanced to include additional information related to the current market depth interest in the auction. The new field present in the GetInfo
response looks something like:
"market_info": {
"2016": {
"num_asks": [
{
"tier": "TIER_0",
"value": 112
},
{
"tier": "TIER_1",
"value": 65
}
],
"num_bids": [
{
"tier": "TIER_0",
"value": 3
},
{
"tier": "TIER_1",
"value": 34
}
],
"ask_open_interest_units": [
{
"tier": "TIER_0",
"value": 1308
},
{
"tier": "TIER_1",
"value": 11204
}
],
"bid_open_interest_units": [
{
"tier": "TIER_0",
"value": 15
},
{
"tier": "TIER_1",
"value": 5874
}
]
}
}
Bug Fixes
A bug has been fixed that would cause Python gRPC clients to be unable to connect to the main auctioneer server.
If the main Pool database is locked by another instance of poold
an error is now returned instead of blocking indefinitely.
Market Order Enhancements
Sidecar Channels
This release includes preliminary support for sidecar channels! Sidecar channels are a new order variant that allows a party Alice to buy a channel for another peer Bob, using Carol as the source of inbound liquidity. Sidecar channels allows users to be on boarded directly onto Lightning with a minimal amount of on-chain transactions, as each funded channel is batched along-side a normal auction batch.
A series of new RPCs have been added to permit the creation and registration of a sidecar ticket. Once negotiation has been completed (either automatically or manually) a bid with a new field set is submitted to the marketplace. After the bid has been matched, during execution rather than creating a channel between the marker and taker, the maker establishes a connection to the sidecar channel recipient to complete the funding flow. All parties fully verify the integrity of any proposed channel or funding states to ensure the new contract is executed properly.
Check out out high level walk through for more information on how sidecar channels work in practice.
Dual Funding Support
Bid orders have gained a new self_chan_balance
field that allows the taker of a liquidity match to also commit funds to the channel. These funds are debited from their on-chain Pool account, and are made available in the channel via the use of the existing push_amt
field in the BOLT funding protocol. The end result is channels that start out as balanced (potentially 50/50) enabling a cheaper way for a node to allocate outbound bandwidth and gain inbound bandwidth when compared to submitting an ask and a bid.
Miscellaneous improvements
- To simplify the setup, a single macaroon can now be specified for the connection to
lnd
. - A
Stop
RPC call and CLI command was added to properly shut down Pool. - A basic user agent string is sent when creating an account or submitting an order to distinguish usage between CLI and Lightning Terminal users.
- Pool is now licensed under the MIT license.
- A Tor proxy can be specified for the conn...
pool v0.4.1-alpha
This marks the fourth public release of poold
, and the second minor release after the initial public release.
This release contains new features as well as bug fixes and one breaking change to the output of the batch snapshot response (see Release Notes below).
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.4.1-alpha.txt
and manifest-v0.4.1-alpha.txt.asc
are in the current directory) with:
gpg --verify manifest-v0.4.1-alpha.txt.asc
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.4.1-alpha.txt'
gpg: Signature made Thu Nov 12 16:31:37 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.
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.5
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.4.1-alpha
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 poold-source-v0.4.1-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.4.1-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Release Notes
Bug fixes
Pending channels from batches that were never finalized and never made it to the chain are now also cleaned up on restart.
A misleading and dangerous sounding error message related to removing those pending channels was demoted to DBG
instead of WRN
.
A bug that lead to a de-synced account state was fixed by properly removing stale batch snapshots if a new pending batch is accepted.
Improvements
The trader client was updated to support multiple distinct lease durations for orders. New markets with other (most likely longer) lease durations will be added over time, depending on demand. The current available markets can be queried with the pool auction leasedurations
command.
Accounts can now be renewed in one on-chain transaction instead of needing to close and re-open them with 2 transactions. New accounts are now created with a default expiration of 30 days (expressed in blocks). This value can be overwritten by setting the --expiry_height
(absolute) or --expiry_height
(relative) flags on the pool accounts new
command.
Further improvements:
- Update to be compatible with
lnd v0.12.0-beta.rc5
and later: #199 - Update documentation on how to cancel orders: ae48cf3
- Refactor work to the funding manager for better unit testing: #187
Breaking Changes
As a preparation for supporting multiple distinct lease duration buckets, the batch snapshot responses (pool auction snapshot
command or BatchSnapshot
RPC method) no longer contain a single clearing_price_rate
field. Previous versions of Pool clients will always show a value of 0
for all snapshots.
After updating to v0.4.1-alpha
, there is a new field matched_markets
that is a map of the lease duration (by default 2016
blocks) and the orders that were matched for the duration, with the rate given as clearing_price_rate
.
Example:
$ pool auction snapshot
[
{
"version": 0,
"batch_id": "...",
"prev_batch_id": "...",
"batch_tx_id": "...",
"batch_tx": "...",
"batch_tx_fee_rate_sat_per_kw": 254,
"creation_timestamp_ns": 11651379494838206464,
"matched_markets": {
"2016": {
"matched_orders": [
{
"ask": {
"lease_duration_blocks": 4032,
"rate_fixed": 2
},
"bid": {
"lease_duration_blocks": 144,
"rate_fixed": 6
},
"matching_rate": 6,
"total_sats_cleared": 5000000,
"units_matched": 50
}
],
"clearing_price_rate": 6
}
}
}
]
Contributors (Alphabetical Order)
BLdotN
Olaoluwa Osuntokun
Oliver Gugger
Wilmer Paulino
pool v0.3.4-alpha
This marks the third public release of poold
, and the second minor release after the initial public release. This release contains no new features. Instead, this release packages a number of important bug fixes related to account management, and the REST API server.
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/guggero/pgp_keys.asc | gpg --import
Once you have the required PGP keys, you can verify the release (assuming manifest-v0.3.4-alpha.txt
and manifest-v0.3.4-alpha.txt.asc
are in the current directory) with:
gpg --verify manifest-v0.3.4-alpha.txt.asc
You should see the following if the verification was successful:
gpg: Signature made Mi 29 Jul 2020 14:59:19 CEST
gpg: using RSA key 6E01EEC9656903B0542B8F1003DB6322267C373B
gpg: Good signature from "Oliver Gugger <gugger@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 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.5
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.3.4-alpha
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 poold-source-v0.3.4-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.3.4-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Release Notes
Bug fixes
- Fix a problem in REST server that resulted in the
grpc: the client connection is closing
error: #175 - Fix
no order found
error when trying to close an account: #180 - Remove irritating error message
Unable to determine spend for account xxxx: context canceled
: #181 - Fix startup problem when pending batch was found in database: #179
- Fix typo in
pool
CLI: #182 - Add debug commands and wrap some errors to add more information: #178
Improvements
- By default only show active accounts: #164
- Add RPC to query multiple past batches in one query: #165
Contributors (Alphabetical Order)
cryptagoras
Oliver Gugger
Wilmer Paulino
pool v0.3.3-alpha
This marks the second public release of poold
, and the first minor release after the initial public release. This release contains no new features. Instead, this release packages a number of important bug fixes related to account management, and worst-case order execution cost estimation.
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.3.3-alpha.txt
and manifest-v0.3.3-alpha.txt.sig
are in the current directory) with:
gpg --verify manifest-v0.3.3-alpha.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.3.3-alpha.txt'
gpg: Signature made Thu Nov 12 16:31:37 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.
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.3
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.3.3-alpha
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 poold-source-v0.3.3-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.3.3-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Release Notes
CLI Commands
The pool orders list
command will now default to only showing active orders.
Documentation
The docs have been updated to show the proper name of the config file for poold
.
Account Management & Order Handling
An edge case has been fixed that would otherwise cause an account to partially apply an update. We'll now ensure that we obtain all signatures from the auctioneer before we commit the new state to disk.
We'll now properly round up the min channel amt to the nearest unit, eliminating an cryptic error message that would reject orders at times.
Dust values resulting from an account deposit or withdrawal are now filtered out sooner in the process. This eliminates a class of limbo accounts that could result otherwise.
Deposits that include a nested P2WKH input are now properly handled.
An estimation error that would allow a trader to place an order larger than its account balance (which ofc would never be able to be executed) has been fixed.
Contributors (Alphabetical Order)
Jamal James
Johan T. Halseth
Justin O'Brien
Olaoluwa Osuntokun
Oliver Gugger
Wilmer Paulino
v0.3.2-alpha
This marks the first public release of poold
, and the Lightning Pool system! This is the first public alpha release that contains all functionality needed to buy/sell channel leases with Lightning Pool. Check out our documentation for more details.
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.3.2-alpha.txt
and manifest-v0.3.2-alpha.txt.sig
are in the current directory) with:
gpg --verify manifest-v0.3.2-alpha.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.3.2-alpha.txt'
gpg: Signature made Sun Nov 1 20:06:04 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.
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.3
, which is required by verifiers to arrive at the same ones.
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:
The signature on the tag itself can be verified with:
git verify-tag v0.3.2-alpha
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 poold-source-v0.3.2-alpha.tar.gz
are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.3.2-alpha.tar.gz
GO111MODULE=on go install -v -mod=vendor ./cmd/poold
GO111MODULE=on go install -v -mod=vendor ./cmd/pool
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"
Contributors (Alphabetical Order)
Bryan Vu
Gabriel Comte
HenryBl
Johan T. Halseth
Justin O'Brien
Nicolas Burtey
Olaoluwa Osuntokun
Oliver Gugger
Ryan Gentry
Wilmer Paulino