The wallet loader has a dependency to the internal/prompt package for
prompting the user for certain inputs (e.g. wallet password or new
seed).
This makes it impossible for projects that use the wallet as a
dependency and always provide those inputs as parameters to compile for
JavaScript/WebAssembly targets because the prompt code uses some
terminal functionality that is not available in JS syscalls.
By providing a JS specific implementation that just returns an error we
can compile the dependent projects.
Adding acutal support for prompting the user in the browser is currently
not planned as that can easily be circumvented by providing all inputs
as parameters.
This method returns the first N external and internal addresses, which
can be presented to users to confirm whether the account has been
imported correctly.
This commit extends the ReadTx (and ReadWriteTx) interface with
ForEachBucket which can be used to iterate through all top level
buckets. This is a missing piece from the walletdb abstraction which
will allow us to iterate all keys in a walletdb opening the possibility
to build generic tools to browse and edit walletdb files regardless of
the underlying driver.
It's possible for bitcoind instances to only have connections to pruned
nodes after its initial block download, which are incompatible with the
PrunedBlockDispatcher. This would result in GetBlock requests for pruned
blocks to never resolve. Since bitcoind also exposes a GetNodeAddresses
RPC, which returns random reachable addresses from its address manager,
we can leverage it to obtain a new candidate set of peers that we
otherwise wouldn't obtain through GetPeers.
Addresses an issue with the previous version where one of its
dependencies was removed:
go: github.com/ory/x@v0.0.216 requires
github.com/ory/cli@v0.0.49 requires
github.com/ory/kratos@v0.5.5-alpha.1.0.20210319103511-3726ed4d145a requires
github.com/ory/kratos/corp@v0.0.0-00010101000000-000000000000: invalid version: unknown revision 000000000000
Simnet was previously left out as it didn't have defined HD versions for
some of our key scopes. To allow testing importing accounts into simnet
wallets, we fall back to use the mainnet HD versions.
This commit also addresses an issue with simnet wallets that would arise
whenever ScopedKeyManager.AccountProperties was invoked:
`failed to retrieve account public key: unsupported net SimNet`
As reported by https://github.com/lightningnetwork/lnd/issues/5196, the
new atomic integer isn't properly aligned which can caus panics on
32-bit operating systems.. Tof fix this issue, we move the 64-bit
integer to lay after the two 32-bit integers at the top of the struct.
To minimally support wallets connected to pruned nodes, we add a new
subsystem that can be integrated with chain clients to request blocks
that the server has already pruned. This is done by connecting to the
server's full node peers and querying them directly. Ideally, this is a
capability supported by the server, though this is not yet possible with
bitcoind.
Now that we're able to fund transactions from multiple accounts within
different key scopes, we extend our transaction creation methods to
accept a key scope parameter as well, to determine the correct account
to select inputs from.
Following the previous commit, some external hardware signers require a
master key fingerprint to be present within the PSBT input derivation
paths so that the signer can recognize which inputs are relevant and
must be signed.
Watch-only accounts are usually backed by an external hardware signer,
some of which require derivation paths to be populated for each relevant
input to sign.
This configuration to run the checks on appveyor looks very old and
unused since it still refers to glide for dependency management. We
remove the file as it no longer serves a purpose.
We use the golangci-lint in lnd and it has quite a few more detections
enabled than what's in the current gotest.sh script.
We don't start with a given base commit on purpose but instead fix
everything the linter finds in the following commits.
For key scopes which have an address schema where the external and
internal branches differ, we always assume that imported keys use the
external address type defined in the scope's address schema. This may
not always be the case however, and should be handled correctly.
Ideally, we generate two addresses per imported key (only if the
external and internal address types differ) and scan for both in the
chain.
