ci: run "make fmt"

chain/interface.go

@@ -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

chain/utils_test.go

@@ -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.

config.go

@@ -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

netparams/params.go

@@ -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,

rpc/legacyrpc/methods.go

@@ -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 -

rpc/walletrpc/api.pb.go

@@ -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

waddrmgr/db.go

@@ -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

waddrmgr/doc.go

@@ -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:
 

waddrmgr/manager.go

@@ -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.

wallet/doc.go

@@ -7,6 +7,5 @@ Package wallet provides ...
 TODO: Flesh out this section
 
 Overview
-
 */
 package wallet

wallet/wallet.go

@@ -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(

walletdb/bdb/doc.go

@@ -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

walletdb/doc.go

@@ -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