In this commit, we use exhaustive build tags to ensure that we can
always build the `sqlbase` package, independent of the set build tags.
To do this, we move the type declarations _into_ the parsing functions.
This then allows us to create two versions for each db: with the db, and
without it.
To avoid a module tag round trip to get this working, we use a local
replace for now. Once this is merged in, we can do the tag (along side
rc3), then remove the replace.
This commit fixes the error,
```
go: version constraints conflict:
github.com/dhui/dktest@v0.3.16 requires golang.org/x/time@v0.0.0-20220224211638-0e9765cccd65, but golang.org/x/time@v0.0.0-20210220033141-f8bda1e9f3ba is requested
github.com/golang-migrate/migrate/v4@v4.16.1 requires golang.org/x/time@v0.0.0-20220224211638-0e9765cccd65, but golang.org/x/time@v0.0.0-20210220033141-f8bda1e9f3ba is requested
```
By calling `go get golang.org/x/time@v0.0.0-20220224211638-0e9765cccd65"
and `go mod tidy`.
This commit provides the scaffolding for using the new sql stores.
The new interfaces, structs and methods are in sync with other projects
like Taproot Assets.
- Transactional Queries: the sqldb package defines the interfaces required
to execute transactional queries to our storage interface.
- Migration Files Embedded: the migration files are embedded into the binary.
- Database Migrations: I kept the use of 'golang-migrate' to ensure our
codebase remains in sync with the other projects, but can be changed.
- Build Flags for Conditional DB Target: flexibility to specify our database
target at compile-time based on the build flags in the same way we do
with our kv stores.
- Update modules: ran `go mod tidy`.
With recent updates to some of our dependencies, the
github.com/dgrijalva/jwt-go package is not referenced in any transitive
dependency anymore which allows us to remove one of the replace
directives which was added as a security precaution before.
With this commit we bump the github.com/btcd/btcec/v2 library to v2.3.2
which implements the MuSig2 BIP version v1.0.0rc2. With this the
github.com/btcsuite/btcd/btcec/v2/schnorr/musig2 package becomes
v1.0.0rc2 and the github.com/lightningnetwork/lnd/internal/musig2v040
stays at the old v0.4.0 version.
With this commit we copy the exact code of the MuSig2 code as found in
github.com/btcsuite/btcec/v2/schnorr/musig2 at the tag btcec/v2.2.2.
This corresponds to the MuSig2 BIP specification version of v0.4.0.
Use kvdb package v1.4.1. This update also forced the protobuf version to
be bumped which required `make rpc` to be run to update the generated
files. This also required a bump in the github pinned dependencies
config for the grpc and protobuf libs.
This changes the call-sites in several places to use the *P2P variants
to not trigger an OOM on untrusted input. This makes the code safe with
the new tlv version. Note that the call-sites prior to this change were
also safe.
This commit bumps the btcwallet dependency to the version that includes
the address validation that asserts we can sign for an address before we
use it.
It's possible that a user might not want the Tor private key to sit on the disk in plaintext (it is a private key after all). So this commit adds a new flag to encrypt the Tor private key on disk using the wallet's seed. When the --tor.encryptkey flag is used, LND will still write the Tor key to the same file, however it will now be encrypted intead of plaintext. This essentially uses the same method to encrypt the Tor private key as is used to encrypt the Static Channel Backup file.
As usual, we keep with the last two Go versions, which means the last
year of Go release (they release every 6 months or so).
This change means we can now use the type params (generics) in the
project!
This commit upgrades to the latest version of btcwallet that fixes an
issue that would cause us to not properly sign a validate populated PSBT
in certain scenarios.
Fixes https://github.com/lightningnetwork/lnd/issues/6579
This commit bumps the btcwallet version to the latest master branch that
contains the fixes to add Taproot related fields to a PSBT in the
FundPsbt method.
Because the original dcrec secp256k1 library that is used for the
Schnorr signature primitives uses different hash algorithms than the
btcd secp256k1 library. Therefore pulling in the wrong library can lead
to weird and unexpected errors. We try to make it harder to make the
mistake by not using the library directly in lnd in the first place.
Note that it is still indirectly needed by the btcd secp256k1 library,
therefore the module dependency is still expected to be there, just
moved to the indirect section.
Fixes#6386.
Bumps the btcutil/psbt library to the latest version v1.1.3 that fixes
an issue with de-serializing a PSBT that contains an unsigned
transaction with no inputs.
The newest version of aez points directly to
gitlab.com/yawning/bsaes.git instead of the unreachable
git.schwanenlied.me/yawning/bsaes.git that required the replace
directive.
With the recent PR #6285 merged that bumped the btcd dependency, we no
longer need to bump the github.com/onsi/ginkgo package with a replace
directive. Instead it was bumped indirectly by merging
https://github.com/btcsuite/btcd/pull/1780 which is included in the btcd
version we reference.
With the dependency to lnd@v0.14.2-beta removed, we no longer depend on
the mongo-driver indirectly so we can remove the security related
replace directive.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
In this commit we update go-pretty to use the latest v6 version of the
library. The existing version we used had a reported vulnerability.
Updating to this newest version also helped to shrink our set of
indirect dependencies.
In the future we can use
https://github.com/lightningnetwork/lnd/pull/5870 to detect/flag these
issues automatically.
Fixes#6293
Apparently we already pushed a tag named tlv/v1.0.0 a while ago (which
points to a commit not in master)...
We need to bump the version of the tag to v1.0.1 since we cannot replace
old tags (without causing a lot of caching problems).
