ci: bump to go 1.19 #15
19 changed files with 142 additions and 125 deletions
|
@ -15,7 +15,7 @@
|
|||
|
||||
ARG ARCH=amd64
|
||||
|
||||
FROM golang:1.18.2 AS build-container
|
||||
FROM golang:1.19 AS build-container
|
||||
|
||||
ARG ARCH
|
||||
|
||||
|
|
|
@ -25,7 +25,9 @@ func BackEnds() []string {
|
|||
}
|
||||
|
||||
// Interface allows more than one backing blockchain source, such as a
|
||||
//
|
||||
// RPC chain server, or an SPV library, as long as we write a driver for
|
||||
//
|
||||
// it.
|
||||
type Interface interface {
|
||||
Start() error
|
||||
|
|
|
@ -66,6 +66,7 @@ func pipe(c1, c2 *conn) (*conn, *conn) {
|
|||
// returns the root of the tree.
|
||||
//
|
||||
// This function was copied from:
|
||||
//
|
||||
// https://github.com/lbryio/lbcd/blob/36a96f6a0025b6aeaebe4106821c2d46ee4be8d4/blockchain/fullblocktests/generate.go#L303
|
||||
func calcMerkleRoot(txns []*wire.MsgTx) chainhash.Hash {
|
||||
if len(txns) == 0 {
|
||||
|
@ -86,6 +87,7 @@ func calcMerkleRoot(txns []*wire.MsgTx) chainhash.Hash {
|
|||
// with the solution. False is returned if no solution exists.
|
||||
//
|
||||
// This function was copied from:
|
||||
//
|
||||
// https://github.com/lbryio/lbcd/blob/36a96f6a0025b6aeaebe4106821c2d46ee4be8d4/blockchain/fullblocktests/generate.go#L324
|
||||
func solveBlock(header *wire.BlockHeader) bool {
|
||||
// sbResult is used by the solver goroutines to send results.
|
||||
|
|
|
@ -251,10 +251,10 @@ func parseAndSetDebugLevels(debugLevel string) error {
|
|||
// line options.
|
||||
//
|
||||
// The configuration proceeds as follows:
|
||||
// 1) Start with a default config with sane settings
|
||||
// 2) Pre-parse the command line to check for an alternative config file
|
||||
// 3) Load configuration file overwriting defaults with any specified options
|
||||
// 4) Parse CLI options and overwrite/add any specified options
|
||||
// 1. Start with a default config with sane settings
|
||||
// 2. Pre-parse the command line to check for an alternative config file
|
||||
// 3. Load configuration file overwriting defaults with any specified options
|
||||
// 4. Parse CLI options and overwrite/add any specified options
|
||||
//
|
||||
// The above results in lbcwallet functioning properly without any config
|
||||
// settings while still allowing the user to override settings with config files
|
||||
|
|
|
@ -18,6 +18,7 @@ type Params struct {
|
|||
}
|
||||
|
||||
// MainNetParams contains parameters specific running lbcwallet and
|
||||
//
|
||||
// on the main network (wire.MainNet).
|
||||
var MainNetParams = Params{
|
||||
Params: &chaincfg.MainNetParams,
|
||||
|
@ -26,6 +27,7 @@ var MainNetParams = Params{
|
|||
}
|
||||
|
||||
// TestNet3Params contains parameters specific running lbcwallet and
|
||||
//
|
||||
// on the test network (version 3) (wire.TestNet3).
|
||||
var TestNet3Params = Params{
|
||||
Params: &chaincfg.TestNet3Params,
|
||||
|
|
|
@ -1226,10 +1226,13 @@ func listLockUnspent(icmd interface{}, w *wallet.Wallet) (interface{}, error) {
|
|||
|
||||
// listReceivedByAccount handles a listreceivedbyaccount request by returning
|
||||
// a slice of objects, each one containing:
|
||||
//
|
||||
// "account": the receiving account;
|
||||
// "amount": total amount received by the account;
|
||||
// "confirmations": number of confirmations of the most recent transaction.
|
||||
//
|
||||
// It takes two parameters:
|
||||
//
|
||||
// "minconf": minimum number of confirmations to consider a transaction -
|
||||
// default: one;
|
||||
// "includeempty": whether or not to include addresses that have no transactions -
|
||||
|
@ -1257,11 +1260,14 @@ func listReceivedByAccount(icmd interface{}, w *wallet.Wallet) (interface{}, err
|
|||
|
||||
// listReceivedByAddress handles a listreceivedbyaddress request by returning
|
||||
// a slice of objects, each one containing:
|
||||
//
|
||||
// "account": the account of the receiving address;
|
||||
// "address": the receiving address;
|
||||
// "amount": total amount received by the address;
|
||||
// "confirmations": number of confirmations of the most recent transaction.
|
||||
//
|
||||
// It takes two parameters:
|
||||
//
|
||||
// "minconf": minimum number of confirmations to consider a transaction -
|
||||
// default: one;
|
||||
// "includeempty": whether or not to include addresses that have no transactions -
|
||||
|
|
|
@ -5,9 +5,11 @@
|
|||
Package walletrpc is a generated protocol buffer package.
|
||||
|
||||
It is generated from these files:
|
||||
|
||||
api.proto
|
||||
|
||||
It has these top-level messages:
|
||||
|
||||
VersionRequest
|
||||
VersionResponse
|
||||
TransactionDetails
|
||||
|
|
|
@ -2383,6 +2383,7 @@ func putBirthday(ns walletdb.ReadWriteBucket, t time.Time) error {
|
|||
// FetchBirthdayBlock retrieves the birthday block from the database.
|
||||
//
|
||||
// The block is serialized as follows:
|
||||
//
|
||||
// [0:4] block height
|
||||
// [4:36] block hash
|
||||
// [36:44] block timestamp
|
||||
|
@ -2423,6 +2424,7 @@ func DeleteBirthdayBlock(ns walletdb.ReadWriteBucket) error {
|
|||
// PutBirthdayBlock stores the provided birthday block to the database.
|
||||
//
|
||||
// The block is serialized as follows:
|
||||
//
|
||||
// [0:4] block height
|
||||
// [4:36] block hash
|
||||
// [36:44] block timestamp
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
Package waddrmgr provides a secure hierarchical deterministic wallet address
|
||||
manager.
|
||||
|
||||
Overview
|
||||
# Overview
|
||||
|
||||
One of the fundamental jobs of a wallet is to manage addresses, private keys,
|
||||
and script data associated with them. At a high level, this package provides
|
||||
|
@ -52,14 +52,14 @@ used to decrypt private keys and scripts on demand. Relocking the address
|
|||
manager actively zeros all private material from memory. In addition, temp
|
||||
private key material used internally is zeroed as soon as it's used.
|
||||
|
||||
Locking and Unlocking
|
||||
# Locking and Unlocking
|
||||
|
||||
As previously mentioned, this package provide facilities for locking and
|
||||
unlocking the address manager to protect access to private material and remove
|
||||
it from memory when locked. The Lock, Unlock, and IsLocked functions are used
|
||||
for this purpose.
|
||||
|
||||
Creating a New Address Manager
|
||||
# Creating a New Address Manager
|
||||
|
||||
A new address manager is created via the Create function. This function accepts
|
||||
a wallet database namespace, passphrases, network, and perhaps most importantly,
|
||||
|
@ -69,28 +69,28 @@ to be recovered with only the seed. The GenerateSeed function in the hdkeychain
|
|||
package can be used as a convenient way to create a random seed for use with
|
||||
this function. The address manager is locked immediately upon being created.
|
||||
|
||||
Opening an Existing Address Manager
|
||||
# Opening an Existing Address Manager
|
||||
|
||||
An existing address manager is opened via the Open function. This function
|
||||
accepts an existing wallet database namespace, the public passphrase, and
|
||||
network. The address manager is opened locked as expected since the open
|
||||
function does not take the private passphrase to unlock it.
|
||||
|
||||
Closing the Address Manager
|
||||
# Closing the Address Manager
|
||||
|
||||
The Close method should be called on the address manager when the caller is done
|
||||
with it. While it is not required, it is recommended because it sanely shuts
|
||||
down the database and ensures all private and public key material is purged from
|
||||
memory.
|
||||
|
||||
Managed Addresses
|
||||
# Managed Addresses
|
||||
|
||||
Each address returned by the address manager satisifies the ManagedAddress
|
||||
interface as well as either the ManagedPubKeyAddress or ManagedScriptAddress
|
||||
interfaces. These interfaces provide the means to obtain relevant information
|
||||
about the addresses such as their private keys and scripts.
|
||||
|
||||
Chained Addresses
|
||||
# Chained Addresses
|
||||
|
||||
Most callers will make use of the chained addresses for normal operations.
|
||||
Internal addresses are intended for internal wallet uses such as change outputs,
|
||||
|
@ -101,13 +101,13 @@ been provided. In addition, the LastInternalAddress and LastExternalAddress
|
|||
functions can be used to get the most recently provided internal and external
|
||||
address, respectively.
|
||||
|
||||
Requesting Existing Addresses
|
||||
# Requesting Existing Addresses
|
||||
|
||||
In addition to generating new addresses, access to old addresses is often
|
||||
required. Most notably, to sign transactions in order to redeem them. The
|
||||
Address function provides this capability and returns a ManagedAddress.
|
||||
|
||||
Importing Addresses
|
||||
# Importing Addresses
|
||||
|
||||
While the recommended approach is to use the chained addresses discussed above
|
||||
because they can be deterministically regenerated to avoid losing funds as long
|
||||
|
@ -116,27 +116,27 @@ and as a result, this package provides the ability to import existing private
|
|||
keys in Wallet Import Format (WIF) and hence the associated public key and
|
||||
address.
|
||||
|
||||
Importing Scripts
|
||||
# Importing Scripts
|
||||
|
||||
In order to support pay-to-script-hash transactions, the script must be securely
|
||||
stored as it is needed to redeem the transaction. This can be useful for a
|
||||
variety of scenarios, however the most common use is currently multi-signature
|
||||
transactions.
|
||||
|
||||
Syncing
|
||||
# Syncing
|
||||
|
||||
The address manager also supports storing and retrieving a block hash and height
|
||||
which the manager is known to have all addresses synced through. The manager
|
||||
itself does not have any notion of which addresses are synced or not. It only
|
||||
provides the storage as a convenience for the caller.
|
||||
|
||||
Network
|
||||
# Network
|
||||
|
||||
The address manager must be associated with a given network in order to provide
|
||||
appropriate addresses and reject imported addresses and scripts which don't
|
||||
apply to the associated network.
|
||||
|
||||
Errors
|
||||
# Errors
|
||||
|
||||
All errors returned from this package are of type ManagerError. This allows the
|
||||
caller to programmatically ascertain the specific reasons for failure by
|
||||
|
@ -144,7 +144,7 @@ examining the ErrorCode field of the type asserted ManagerError. For certain
|
|||
error codes, as documented by the specific error codes, the underlying error
|
||||
will be contained in the Err field.
|
||||
|
||||
Bitcoin Improvement Proposals
|
||||
# Bitcoin Improvement Proposals
|
||||
|
||||
This package includes concepts outlined by the following BIPs:
|
||||
|
||||
|
|
|
@ -1479,6 +1479,7 @@ func deriveCoinTypeKey(masterNode *hdkeychain.ExtendedKey,
|
|||
// hierarchy described by BIP0044 given the master node.
|
||||
//
|
||||
// In particular this is the hierarchical deterministic extended key path:
|
||||
//
|
||||
// m/purpose'/<coin type>'/<account>'
|
||||
func deriveAccountKey(coinTypeKey *hdkeychain.ExtendedKey,
|
||||
account uint32) (*hdkeychain.ExtendedKey, error) {
|
||||
|
@ -1502,6 +1503,7 @@ func deriveAccountKey(coinTypeKey *hdkeychain.ExtendedKey,
|
|||
// already derived accordingly.
|
||||
//
|
||||
// In particular this is the hierarchical deterministic extended key path:
|
||||
//
|
||||
// m/purpose'/<coin type>'/<account>'/<branch>
|
||||
//
|
||||
// The branch is 0 for external addresses and 1 for internal addresses.
|
||||
|
|
|
@ -7,6 +7,5 @@ Package wallet provides ...
|
|||
TODO: Flesh out this section
|
||||
|
||||
Overview
|
||||
|
||||
*/
|
||||
package wallet
|
||||
|
|
|
@ -756,13 +756,13 @@ func (w *Wallet) recovery(chainClient chain.Interface,
|
|||
// previously used addresses for a particular account derivation path. At a high
|
||||
// level, the algorithm works as follows:
|
||||
//
|
||||
// 1) Ensure internal and external branch horizons are fully expanded.
|
||||
// 2) Filter the entire range of blocks, stopping if a non-zero number of
|
||||
// 1. Ensure internal and external branch horizons are fully expanded.
|
||||
// 2. Filter the entire range of blocks, stopping if a non-zero number of
|
||||
// address are contained in a particular block.
|
||||
// 3) Record all internal and external addresses found in the block.
|
||||
// 4) Record any outpoints found in the block that should be watched for spends
|
||||
// 5) Trim the range of blocks up to and including the one reporting the addrs.
|
||||
// 6) Repeat from (1) if there are still more blocks in the range.
|
||||
// 3. Record all internal and external addresses found in the block.
|
||||
// 4. Record any outpoints found in the block that should be watched for spends
|
||||
// 5. Trim the range of blocks up to and including the one reporting the addrs.
|
||||
// 6. Repeat from (1) if there are still more blocks in the range.
|
||||
//
|
||||
// TODO(conner): parallelize/pipeline/cache intermediate network requests
|
||||
func (w *Wallet) recoverScopedAddresses(
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
Package bdb implements an instance of walletdb that uses boltdb for the backing
|
||||
datastore.
|
||||
|
||||
Usage
|
||||
# Usage
|
||||
|
||||
This package is only a driver to the walletdb package and provides the database
|
||||
type of "bdb". The only parameters the Open and Create functions take are the
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
/*
|
||||
Package walletdb provides a namespaced database interface for lbcwallet.
|
||||
|
||||
Overview
|
||||
# Overview
|
||||
|
||||
A wallet essentially consists of a multitude of stored data such as private
|
||||
and public keys, key derivation bits, pay-to-script-hash scripts, and various
|
||||
|
@ -35,7 +35,7 @@ A quick overview of the features walletdb provides are as follows:
|
|||
- Supports registration of backend databases
|
||||
- Comprehensive test coverage
|
||||
|
||||
Database
|
||||
# Database
|
||||
|
||||
The main entry point is the DB interface. It exposes functionality for
|
||||
creating, retrieving, and removing namespaces. It is obtained via the Create
|
||||
|
@ -43,7 +43,7 @@ and Open functions which take a database type string that identifies the
|
|||
specific database driver (backend) to use as well as arguments specific to the
|
||||
specified driver.
|
||||
|
||||
Namespaces
|
||||
# Namespaces
|
||||
|
||||
The Namespace interface is an abstraction that provides facilities for obtaining
|
||||
transactions (the Tx interface) that are the basis of all database reads and
|
||||
|
@ -55,14 +55,14 @@ The Begin function provides an unmanaged transaction while the View and Update
|
|||
functions provide a managed transaction. These are described in more detail
|
||||
below.
|
||||
|
||||
Transactions
|
||||
# Transactions
|
||||
|
||||
The Tx interface provides facilities for rolling back or commiting changes that
|
||||
took place while the transaction was active. It also provides the root bucket
|
||||
under which all keys, values, and nested buckets are stored. A transaction
|
||||
can either be read-only or read-write and managed or unmanaged.
|
||||
|
||||
Managed versus Unmanaged Transactions
|
||||
# Managed versus Unmanaged Transactions
|
||||
|
||||
A managed transaction is one where the caller provides a function to execute
|
||||
within the context of the transaction and the commit or rollback is handled
|
||||
|
@ -75,7 +75,7 @@ call Commit or Rollback when they are finished with it. Leaving transactions
|
|||
open for long periods of time can have several adverse effects, so it is
|
||||
recommended that managed transactions are used instead.
|
||||
|
||||
Buckets
|
||||
# Buckets
|
||||
|
||||
The Bucket interface provides the ability to manipulate key/value pairs and
|
||||
nested buckets as well as iterate through them.
|
||||
|
@ -85,7 +85,7 @@ CreateBucket, CreateBucketIfNotExists, and DeleteBucket functions work with
|
|||
buckets. The ForEach function allows the caller to provide a function to be
|
||||
called with each key/value pair and nested bucket in the current bucket.
|
||||
|
||||
Root Bucket
|
||||
# Root Bucket
|
||||
|
||||
As discussed above, all of the functions which are used to manipulate key/value
|
||||
pairs and nested buckets exist on the Bucket interface. The root bucket is the
|
||||
|
@ -93,7 +93,7 @@ upper-most bucket in a namespace under which data is stored and is created at
|
|||
the same time as the namespace. Use the RootBucket function on the Tx interface
|
||||
to retrieve it.
|
||||
|
||||
Nested Buckets
|
||||
# Nested Buckets
|
||||
|
||||
The CreateBucket and CreateBucketIfNotExists functions on the Bucket interface
|
||||
provide the ability to create an arbitrary number of nested buckets. It is
|
||||
|
|
Loading…
Reference in a new issue