Skip to content

Releases: lightninglabs/pool

pool v0.5.3-alpha

07 Dec 19:43
v0.5.3-alpha
902d4f6
Compare
Choose a tag to compare

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

Miscellaneous improvements

Contributors (Alphabetical Order)

Carla Kirk Cohen
Jordi Montes
Olaoluwa Osuntokun
Oliver Gugger
Turtle
Wilmer Paulino

pool v0.5.1-alpha

04 Aug 15:15
v0.5.1-alpha
2e829c0
Compare
Choose a tag to compare

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

Miscellaneous improvements

Contributors (Alphabetical Order)

Carla Kirk Cohen
Olaoluwa Osuntokun
Oliver Gugger
Turtle

pool v0.5.0-alpha

26 May 16:59
2e85746
Compare
Choose a tag to compare

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

Read more

pool v0.4.1-alpha

15 Jan 21:07
Compare
Choose a tag to compare

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

07 Dec 22:58
v0.3.4-alpha
d2852c1
Compare
Choose a tag to compare

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

13 Nov 01:31
Compare
Choose a tag to compare

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

02 Nov 04:50
Compare
Choose a tag to compare

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