mirror of
https://github.com/lightninglabs/loop.git
synced 2026-08-13 12:33:03 +02:00
6b942941fb
Document every published Loop release and preserve authoritative notes. Add the next-release workflow and rebuild chronological navigation. Rename the reproducible-build guide for clarity.
153 lines
7.1 KiB
Markdown
153 lines
7.1 KiB
Markdown
# Loop Client Release Notes
|
|
|
|
- **Release date:** 2019-06-26
|
|
- **Release page:**
|
|
[v0.2-alpha](https://github.com/lightninglabs/loop/releases/tag/v0.2-alpha)
|
|
- **Previous release:** [v0.1.3-alpha](release-notes-0.1.3.md)
|
|
- **Next release:** [v0.2.0-alpha](release-notes-0.2.0.md)
|
|
|
|
#### New Features
|
|
|
|
This is the first second release of Lightning Loop! This new release enables
|
|
**Loop In** on mainnet, and also exposes some additional code used to build the
|
|
`loop` daemon as an external package that others can use.
|
|
[Check out our latest blog post for more details on Loop In, and the future of Lightning Loop](https://blog.lightning.engineering/announcement/2019/06/25/loop-in.html).
|
|
|
|
**Loop In**
|
|
|
|
At a high-level a Loop In swap can be used to:
|
|
* Refilling depleted channels with funds from cold-wallets or exchange
|
|
withdrawals
|
|
* Servicing off-chain Lightning withdrawals using on-chain payments, with no
|
|
funds in channels required
|
|
|
|
#### Breaking Changes
|
|
|
|
#### Bug Fixes
|
|
|
|
* As a failsafe payment method that can be used when channel liquidity along a
|
|
route is insufficient
|
|
|
|
A new command has been added to the `loop` cli command to allow users to drive
|
|
Loop In swaps:
|
|
```
|
|
NAME:
|
|
loop in - perform an on-chain to off-chain swap (loop in)
|
|
|
|
USAGE:
|
|
loop in [command options] amt
|
|
|
|
DESCRIPTION:
|
|
|
|
Send the amount in satoshis specified by the amt argument off-chain.
|
|
|
|
OPTIONS:
|
|
--amt value the amount in satoshis to loop in (default: 0)
|
|
--external expect htlc to be published externally
|
|
```
|
|
|
|
The `--external` argument allows the on-chain HTLC transacting to be published
|
|
externally. This allows for a number of use cases like using this address to
|
|
withdraw from an exchange into your Lightning channel!
|
|
|
|
[Additionally, the gRPC API (and REST!) docs have also been updated](https://lightning.engineering/loop).
|
|
|
|
Loop there it is!! ⚡️🔁
|
|
|
|
#### Maintenance
|
|
|
|
**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 his PGP key you can verify the release (assuming
|
|
`manifest-v0.2-alpha.txt` and `manifest-v0.2-alpha.txt.sig` are in the current
|
|
directory) with:
|
|
```
|
|
gpg --verify manifest-v0.2-alpha.txt
|
|
```
|
|
|
|
You should see the following if the verification was successful:
|
|
```
|
|
gpg: assuming signed data in 'manifest-v0.2-alpha.txt'
|
|
gpg: Signature made Wed Jun 26 09:56:58 2019 PDT
|
|
gpg: using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
|
|
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]
|
|
```
|
|
|
|
That will verify the signature on the main manifest page which ensures integrity
|
|
and authenticity of the binaries you've downloaded locally. Next, depending on
|
|
your operating system you should then re-calculate the `sha256` sum of the
|
|
binary, and compare that with the following hashes (which are included in the
|
|
manifest file):
|
|
```
|
|
de97a2e33fcce9650911f8976ed9089d061a1d5fb374bdfd3be0d6101871585d loop-darwin-386-v0.2-alpha.tar.gz
|
|
666a5910757cb15dd2a62ac009b31359a97f4f1c83803d4028d10d23db6ee587 loop-darwin-amd64-v0.2-alpha.tar.gz
|
|
4a06d43e48e7537975a92d25ac187b78a74426976ffd36bb1efaeb83bae7aa4f loop-dragonfly-amd64-v0.2-alpha.tar.gz
|
|
f6cf356db4060d8c90b91dc1d8547472b255ceb8aae2197f531a177a285f60fc loop-freebsd-386-v0.2-alpha.tar.gz
|
|
74fdb8d3a8e0a91cfeabe5e06f2be386a68e4524fa42d9c042b9a2030499a76d loop-freebsd-amd64-v0.2-alpha.tar.gz
|
|
d500f36eefc1e1ee63b8259d4eefcd64f34b295781956559bd52389b5a37a98b loop-freebsd-arm-v0.2-alpha.tar.gz
|
|
d2d01f9a8d1483173c5f1618477ff1929e8aa5e322849091d7b86694fedbf0bb loop-linux-386-v0.2-alpha.tar.gz
|
|
da92445ec5e754da3f379e85310d697f3609a17e6639d1251a479a09fc0c16e1 loop-linux-amd64-v0.2-alpha.tar.gz
|
|
04edae2cbdb6943b70b13cbc678901d26f4f06767f60f591f7c7d791c8b5925f loop-linux-arm64-v0.2-alpha.tar.gz
|
|
5fae0185f8849364af9b998609d002f5e226d3e937dabfd56d1474415f6555db loop-linux-armv6-v0.2-alpha.tar.gz
|
|
931a43c8a936db0a3a6a3d099b67d953b69344259bfa7d37faac985341ff27e9 loop-linux-armv7-v0.2-alpha.tar.gz
|
|
757ae30b349f8fc209f7df20e1b6010814d0dd279a3717b8c7ba5cb7a092103b loop-linux-mips64-v0.2-alpha.tar.gz
|
|
900c8ce735ac94f1d35c179e4387cc9292f261be685eb57b865d772bd668d8ec loop-linux-mips64le-v0.2-alpha.tar.gz
|
|
aeb3d2f882405308827974515ea5d652d5e6d72188165ab315dbbb4c7402bc3f loop-linux-ppc64-v0.2-alpha.tar.gz
|
|
0d072fd9ed648de679f46ee959a3aef1ae9e025d756140e432df2a51bfe57221 loop-netbsd-386-v0.2-alpha.tar.gz
|
|
f26cedf2e8a38b175b47a6b6101edab99033e4776c6de21306cdc793e6dc0b0b loop-netbsd-amd64-v0.2-alpha.tar.gz
|
|
3ea2bb1482c78d2bb45358c3de7961670b5ed64a231ec9a2dc2b6ba13a3e76a6 loop-openbsd-386-v0.2-alpha.tar.gz
|
|
7a67ae9805beb8e43bd257e8355f8c471bbc740b1b2f1bbf8f834d50312299fe loop-openbsd-amd64-v0.2-alpha.tar.gz
|
|
8f15d5c5f56bd19952361ee27b1821306d634bbe8799e52ab36a09f8c151ff6d loop-source-v0.2-alpha.tar.gz
|
|
99de0a0e0464a5d7910e6ec4c5cdc881db278bf1bbb6095d5aec7c7a033aca0f loop-windows-386-v0.2-alpha.zip
|
|
fb1e4dca3728a2608dce560385bf6e07cb319d27f4d7cfeb0a4aaf00b1cc2a4c loop-windows-amd64-v0.2-alpha.zip
|
|
47b208033931c22fd6b1b23b723d49e18359709cb6b29a3f2623e6f80179bfbf vendor.tar.gz
|
|
```
|
|
|
|
One can use the `shasum -a 256 <file name here>` tool in order to re-compute the
|
|
`sha256` hash of the target binary for your operating system. The produced hash
|
|
should be compared with the hashes listed above and they should match *exactly*.
|
|
|
|
Finally, you can also verify the _tag_ itself with the following command:
|
|
```
|
|
git verify-tag v0.2-alpha
|
|
```
|
|
|
|
**Building the Contained Release**
|
|
|
|
With this new version of `loop`, we've modified our release process to ensure
|
|
the bundled release is now _fully self contained_. As a result, with only the
|
|
attached payload with this release, users will be able to rebuild the target
|
|
release themselves without having to fetch any of the dependancies. Note that at
|
|
this stage, binaries aren't yet fully reproducible (even with `go modules` ).
|
|
This is due to the fact that by default,
|
|
[Go will include the full directory path where the binary was built in the binary itself](https://github.com/golang/go/issues/16860).
|
|
As a result, unless your file system exactly mirrors the machine used to build
|
|
the binary, you'll get a different binary, as it includes artifacts from your
|
|
local file system. This will be fixed in `go1.13`, and before then we may modify
|
|
our release system to do this automatically.
|
|
|
|
In order to re-build from scratch, assuming that `vendor.tar.gz` and
|
|
`loop-source-v0.2-alpha.tar.gz` are in the current directory:
|
|
```
|
|
tar -xvzf vendor.tar.gz
|
|
tar -xvzf loop-source-v0.2-alpha.tar.gz
|
|
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/loop.Commit=v0.2-alpha" ./cmd/loop
|
|
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/loop.Commit=v0.2-alpha" ./cmd/loopd
|
|
```
|
|
|
|
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.
|
|
|
|
#### Contributors (Alphabetical Order)
|
|
|
|
No additional contributors; this tag points to the same commit as
|
|
`v0.1.3-alpha`.
|