ci: run goimports and gofmt

appdata.go

@@ -95,6 +95,7 @@ func appDataDir(goos, appName string, roaming bool) string {
 // (%LOCALAPPDATA%) that is used by default.
 //
 // Example results:
+//
 //	dir := AppDataDir("myapp", false)
 //	 POSIX (Linux/BSD): ~/.myapp
 //	 Mac OS: $HOME/Library/Application Support/Myapp

base58/doc.go

@@ -6,7 +6,7 @@
 Package base58 provides an API for working with modified base58 and Base58Check
 encodings.
 
-Modified Base58 Encoding
+# Modified Base58 Encoding
 
 Standard base58 encoding is similar to standard base64 encoding except, as the
 name implies, it uses a 58 character alphabet which results in an alphanumeric
@@ -17,7 +17,7 @@ The modified base58 alphabet used by Bitcoin, and hence this package, omits the
 0, O, I, and l characters that look the same in many fonts and are therefore
 hard to humans to distinguish.
 
-Base58Check Encoding Scheme
+# Base58Check Encoding Scheme
 
 The Base58Check encoding scheme is primarily used for Bitcoin addresses at the
 time of this writing, however it can be used to generically encode arbitrary

base58/genalphabet.go

@@ -2,6 +2,7 @@
 // Use of this source code is governed by an ISC
 // license that can be found in the LICENSE file.
 
+//go:build ignore
 // +build ignore
 
 package main

coinset/coins.go

@@ -75,6 +75,7 @@ func (cs *CoinSet) TotalValue() (value lbcutil.Amount) {
 }
 
 // TotalValueAge returns the total value * number of confirmations
+//
 //	of the coins in the set.
 func (cs *CoinSet) TotalValueAge() (valueAge int64) {
 	return cs.totalValueAge
@@ -238,7 +239,6 @@ func (s MaxValueAgeCoinSelector) CoinSelect(targetValue lbcutil.Amount, coins []
 // input priority over the threshold, but no guarantees will be made as to
 // minimality of the selection.  The selection below is almost certainly
 // suboptimal.
-//
 type MinPriorityCoinSelector struct {
 	MaxInputs              int
 	MinChangeAmount        lbcutil.Amount

doc.go

@@ -5,21 +5,21 @@
 /*
 Package lbcutil provides bitcoin-specific convenience functions and types.
 
-Block Overview
+# Block Overview
 
 A Block defines a bitcoin block that provides easier and more efficient
 manipulation of raw wire protocol blocks.  It also memoizes hashes for the
 block and its transactions on their first access so subsequent accesses don't
 have to repeat the relatively expensive hashing operations.
 
-Tx Overview
+# Tx Overview
 
 A Tx defines a bitcoin transaction that provides more efficient manipulation of
 raw wire protocol transactions.  It memoizes the hash for the transaction on its
 first access so subsequent accesses don't have to repeat the relatively
 expensive hashing operations.
 
-Address Overview
+# Address Overview
 
 The Address interface provides an abstraction for a Bitcoin address.  While the
 most common type is a pay-to-pubkey-hash, Bitcoin already supports others and

gcs/doc.go

@@ -6,14 +6,14 @@
 /*
 Package gcs provides an API for building and using a Golomb-coded set filter.
 
-Golomb-Coded Set
+# Golomb-Coded Set
 
 A Golomb-coded set is a probabilistic data structure used similarly to a Bloom
 filter. A filter uses constant-size overhead plus on average n+2 bits per
 item added to the filter, where 2^-n is the desired false positive (collision)
 probability.
 
-GCS use in Bitcoin
+# GCS use in Bitcoin
 
 GCS filters are a proposed mechanism for storing and transmitting per-block
 filters in Bitcoin. The usage is intended to be the inverse of Bloom filters:

gcs/gcs.go

@@ -44,7 +44,7 @@ const (
 // described in:
 // https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/
 //
-//  * v * N  >> log_2(N)
+//   - v * N  >> log_2(N)
 //
 // In our case, using 64-bit integers, log_2 is 64. As most processors don't
 // support 128-bit arithmetic natively, we'll be super portable and unfold the

hdkeychain/doc.go

@@ -6,7 +6,7 @@
 Package hdkeychain provides an API for bitcoin hierarchical deterministic
 extended keys (BIP0032).
 
-Overview
+# Overview
 
 The ability to implement hierarchical deterministic wallets depends on the
 ability to create and derive hierarchical deterministic extended keys.
@@ -16,19 +16,19 @@ deterministic extended keys by providing an ExtendedKey type and supporting
 functions.  Each extended key can either be a private or public extended key
 which itself is capable of deriving a child extended key.
 
-Determining the Extended Key Type
+# Determining the Extended Key Type
 
 Whether an extended key is a private or public extended key can be determined
 with the IsPrivate function.
 
-Transaction Signing Keys and Payment Addresses
+# Transaction Signing Keys and Payment Addresses
 
 In order to create and sign transactions, or provide others with addresses to
 send funds to, the underlying key and address material must be accessible.  This
 package provides the ECPubKey, ECPrivKey, and Address functions for this
 purpose.
 
-The Master Node
+# The Master Node
 
 As previously mentioned, the extended keys are hierarchical meaning they are
 used to form a tree.  The root of that tree is called the master node and this
@@ -36,7 +36,7 @@ package provides the NewMaster function to create it from a cryptographically
 random seed.  The GenerateSeed function is provided as a convenient way to
 create a random seed for use with the NewMaster function.
 
-Deriving Children
+# Deriving Children
 
 Once you have created a tree root (or have deserialized an extended key as
 discussed later), the child extended keys can be derived by using the Derive
@@ -46,7 +46,7 @@ the HardenedKeyStart constant + the hardened key number as the index to the
 Derive function.  This provides the ability to cascade the keys into a tree and
 hence generate the hierarchical deterministic key chains.
 
-Normal vs Hardened Derived Extended Keys
+# Normal vs Hardened Derived Extended Keys
 
 A private extended key can be used to derive both hardened and non-hardened
 (normal) child private and public extended keys.  A public extended key can only
@@ -59,22 +59,23 @@ the reason for the existence of hardened keys, and why they are used for the
 account level in the tree. This way, a leak of an account-specific (or below)
 private key never risks compromising the master or other accounts."
 
-Neutering a Private Extended Key
+# Neutering a Private Extended Key
 
 A private extended key can be converted to a new instance of the corresponding
 public extended key with the Neuter function.  The original extended key is not
 modified.  A public extended key is still capable of deriving non-hardened child
 public extended keys.
 
-Serializing and Deserializing Extended Keys
+# Serializing and Deserializing Extended Keys
 
 Extended keys are serialized and deserialized with the String and
 NewKeyFromString functions.  The serialized key is a Base58-encoded string which
 looks like the following:
+
 	public key:   xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
 	private key:  xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7
 
-Network
+# Network
 
 Extended keys are much like normal Bitcoin addresses in that they have version
 bytes which tie them to a specific network.  The SetNet and IsForNet functions

hdkeychain/extendedkey.go

@@ -470,6 +470,7 @@ func (k *ExtendedKey) Neuter() (*ExtendedKey, error) {
 // on the SLIP132 standard (serializable to yprv/ypub, zprv/zpub, etc.).
 //
 // References:
+//
 //	[SLIP132]: SLIP-0132 - Registered HD version bytes for BIP-0032
 //	https://github.com/satoshilabs/slips/blob/master/slip-0132.md
 func (k *ExtendedKey) CloneWithVersion(version []byte) (*ExtendedKey, error) {

hdkeychain/extendedkey_test.go

@@ -1094,6 +1094,7 @@ func TestMaximumDepth(t *testing.T) {
 // extended keys.
 //
 // The following tool was used for generating the tests:
+//
 //	https://jlopp.github.io/xpub-converter
 func TestCloneWithVersion(t *testing.T) {
 	tests := []struct {

net_noop.go

@@ -2,6 +2,7 @@
 // Use of this source code is governed by an ISC
 // license that can be found in the LICENSE file.
 
+//go:build appengine
 // +build appengine
 
 package lbcutil

txsort/doc.go

@@ -5,7 +5,7 @@
 /*
 Package txsort provides the transaction sorting according to BIP 69.
 
-Overview
+# Overview
 
 BIP 69 defines a standard lexicographical sort order of transaction inputs and
 outputs.  This is useful to standardize transactions for faster multi-party

wif.go

@@ -68,13 +68,13 @@ func (w *WIF) IsForNet(net *chaincfg.Params) bool {
 // The WIF string must be a base58-encoded string of the following byte
 // sequence:
 //
-//  * 1 byte to identify the network, must be 0x80 for mainnet or 0xef for
+//   - 1 byte to identify the network, must be 0x80 for mainnet or 0xef for
 //     either testnet3 or the regression test network
-//  * 32 bytes of a binary-encoded, big-endian, zero-padded private key
+//   - 32 bytes of a binary-encoded, big-endian, zero-padded private key
-//  * Optional 1 byte (equal to 0x01) if the address being imported or exported
+//   - Optional 1 byte (equal to 0x01) if the address being imported or exported
 //     was created by taking the RIPEMD160 after SHA256 hash of a serialized
 //     compressed (33-byte) public key
-//  * 4 bytes of checksum, must equal the first four bytes of the double SHA256
+//   - 4 bytes of checksum, must equal the first four bytes of the double SHA256
 //     of every byte before the checksum in this sequence
 //
 // If the base58-decoded byte sequence does not match this, DecodeWIF will