multi: Run gofmt on the entire repository

The doc formatting changes introduced in the recent go version is
increasing the diff for all of the new commits.  Formatting it all in
this commit will help the readability of future PRs by reducing the
diff.

addrmgr/doc.go

@@ -5,7 +5,7 @@
 /*
 Package addrmgr implements concurrency safe Bitcoin address manager.
 
-Address Manager Overview
+# Address Manager Overview
 
 In order maintain the peer-to-peer Bitcoin network, there needs to be a source
 of addresses to connect to as nodes come and go.  The Bitcoin protocol provides

blockchain/accept.go

@@ -7,8 +7,8 @@ package blockchain
 import (
 	"fmt"
 
-	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/database"
 )
 
 // maybeAcceptBlock potentially accepts a block into the block chain and, if

blockchain/chain.go

@@ -34,6 +34,7 @@ const (
 // from the block being located.
 //
 // For example, assume a block chain with a side chain as depicted below:
+//
 //	genesis -> 1 -> 2 -> ... -> 15 -> 16  -> 17  -> 18
 //	                              \-> 16a -> 17a
 //
@@ -386,7 +387,7 @@ func (b *BlockChain) calcSequenceLock(node *blockNode, tx *btcutil.Tx, utxoView
 	// return sequence lock values of -1 indicating that this transaction
 	// can be included within a block at any given height or time.
 	mTx := tx.MsgTx()
-	sequenceLockActive := mTx.Version >= 2 && csvSoftforkActive
+	sequenceLockActive := uint32(mTx.Version) >= 2 && csvSoftforkActive
 	if !sequenceLockActive || IsCoinBase(tx) {
 		return sequenceLock, nil
 	}
@@ -468,7 +469,7 @@ func (b *BlockChain) calcSequenceLock(node *blockNode, tx *btcutil.Tx, utxoView
 // LockTimeToSequence converts the passed relative locktime to a sequence
 // number in accordance to BIP-68.
 // See: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
-//  * (Compatibility)
+//   - (Compatibility)
 func LockTimeToSequence(isSeconds bool, locktime uint32) uint32 {
 	// If we're expressing the relative lock time in blocks, then the
 	// corresponding sequence number is simply the desired input age.

blockchain/chain_test.go

@@ -9,10 +9,10 @@ import (
 	"testing"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // TestHaveBlock tests the HaveBlock API to ensure proper functionality.

blockchain/chainio.go

@@ -12,10 +12,10 @@ import (
 	"sync"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

blockchain/chainview.go

@@ -36,10 +36,12 @@ func fastLog2Floor(n uint32) uint8 {
 // for comparing chains.
 //
 // For example, assume a block chain with a side chain as depicted below:
+//
 //	genesis -> 1 -> 2 -> 3 -> 4  -> 5 ->  6  -> 7  -> 8
 //	                      \-> 4a -> 5a -> 6a
 //
 // The chain view for the branch ending in 6a consists of:
+//
 //	genesis -> 1 -> 2 -> 3 -> 4a -> 5a -> 6a
 type chainView struct {
 	mtx   sync.Mutex
@@ -258,11 +260,13 @@ func (c *chainView) next(node *blockNode) *blockNode {
 // view.
 //
 // For example, assume a block chain with a side chain as depicted below:
+//
 //	genesis -> 1 -> 2 -> 3 -> 4  -> 5 ->  6  -> 7  -> 8
 //	                      \-> 4a -> 5a -> 6a
 //
 // Further, assume the view is for the longer chain depicted above.  That is to
 // say it consists of:
+//
 //	genesis -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8
 //
 // Invoking this function with block node 5 would return block node 6 while
@@ -321,11 +325,13 @@ func (c *chainView) findFork(node *blockNode) *blockNode {
 // the chain view.  It will return nil if there is no common block.
 //
 // For example, assume a block chain with a side chain as depicted below:
+//
 //	genesis -> 1 -> 2 -> ... -> 5 -> 6  -> 7  -> 8
 //	                             \-> 6a -> 7a
 //
 // Further, assume the view is for the longer chain depicted above.  That is to
 // say it consists of:
+//
 //	genesis -> 1 -> 2 -> ... -> 5 -> 6 -> 7 -> 8.
 //
 // Invoking this function with block node 7a would return block node 5 while

blockchain/checkpoints.go

@@ -8,10 +8,10 @@ import (
 	"fmt"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // CheckpointConfirmations is the number of blocks before the end of the current

blockchain/difficulty.go

@@ -42,9 +42,9 @@ func HashToBig(hash *chainhash.Hash) *big.Int {
 // Like IEEE754 floating point, there are three basic components: the sign,
 // the exponent, and the mantissa.  They are broken out as follows:
 //
-//	* the most significant 8 bits represent the unsigned base 256 exponent
-// 	* bit 23 (the 24th bit) represents the sign bit
-//	* the least significant 23 bits represent the mantissa
+// - the most significant 8 bits represent the unsigned base 256 exponent
+// - bit 23 (the 24th bit) represents the sign bit
+// - the least significant 23 bits represent the mantissa
 //
 //	-------------------------------------------------
 //	|   Exponent     |    Sign    |    Mantissa     |
@@ -53,6 +53,7 @@ func HashToBig(hash *chainhash.Hash) *big.Int {
 //	-------------------------------------------------
 //
 // The formula to calculate N is:
+//
 //	N = (-1^sign) * mantissa * 256^(exponent-3)
 //
 // This compact form is only used in bitcoin to encode unsigned 256-bit numbers

blockchain/doc.go

@@ -26,7 +26,7 @@ caller a high level of flexibility in how they want to react to certain events
 such as orphan blocks which need their parents requested and newly connected
 main chain blocks which might result in wallet updates.
 
-Bitcoin Chain Processing Overview
+# Bitcoin Chain Processing Overview
 
 Before a block is allowed into the block chain, it must go through an intensive
 series of validation rules.  The following list serves as a general outline of
@@ -61,7 +61,7 @@ is by no means exhaustive:
     coins
   - Insert the block into the block database
 
-Errors
+# Errors
 
 Errors returned by this package are either the raw errors provided by underlying
 calls or of type blockchain.RuleError.  This allows the caller to differentiate
@@ -70,7 +70,7 @@ violations through type assertions.  In addition, callers can programmatically
 determine the specific rule violation by examining the ErrorCode field of the
 type asserted blockchain.RuleError.
 
-Bitcoin Improvement Proposals
+# Bitcoin Improvement Proposals
 
 This package includes spec changes outlined by the following BIPs:
 

blockchain/example_test.go

@@ -11,10 +11,10 @@ import (
 	"path/filepath"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
 	_ "github.com/btcsuite/btcd/database/ffldb"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // This example demonstrates how to create a new chain instance and use

blockchain/fullblocks_test.go

@@ -14,13 +14,13 @@ import (
 
 	"github.com/btcsuite/btcd/blockchain"
 	"github.com/btcsuite/btcd/blockchain/fullblocktests"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	_ "github.com/btcsuite/btcd/database/ffldb"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

blockchain/fullblocktests/generate.go

@@ -20,11 +20,11 @@ import (
 
 	"github.com/btcsuite/btcd/blockchain"
 	"github.com/btcsuite/btcd/btcec/v2"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

blockchain/indexers/blocklogger.go

@@ -8,8 +8,8 @@ import (
 	"sync"
 	"time"
 
-	"github.com/btcsuite/btclog"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btclog"
 )
 
 // blockProgressLogger provides periodic logging for other services in order
@@ -27,6 +27,7 @@ type blockProgressLogger struct {
 
 // newBlockProgressLogger returns a new block progress logger.
 // The progress message is templated as follows:
+//
 //	{progressAction} {numProcessed} {blocks|block} in the last {timePeriod}
 //	({numTxs}, height {lastBlockHeight}, {lastBlockTimeStamp})
 func newBlockProgressLogger(progressMessage string, logger btclog.Logger) *blockProgressLogger {

blockchain/indexers/cfindex.go

@@ -8,13 +8,13 @@ import (
 	"errors"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/btcutil/gcs"
+	"github.com/btcsuite/btcd/btcutil/gcs/builder"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
-	"github.com/btcsuite/btcd/btcutil/gcs"
-	"github.com/btcsuite/btcd/btcutil/gcs/builder"
 )
 
 const (

blockchain/indexers/common.go

@@ -12,8 +12,8 @@ import (
 	"errors"
 
 	"github.com/btcsuite/btcd/blockchain"
-	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/database"
 )
 
 var (

blockchain/indexers/manager.go

@@ -9,10 +9,10 @@ import (
 	"fmt"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 var (

blockchain/indexers/txindex.go

@@ -9,10 +9,10 @@ import (
 	"fmt"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

blockchain/merkle.go

@@ -9,9 +9,9 @@ import (
 	"fmt"
 	"math"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

blockchain/process.go

@@ -8,9 +8,9 @@ import (
 	"fmt"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // BehaviorFlags is a bitmask defining tweaks to the normal behavior when

blockchain/upgrade.go

@@ -244,6 +244,7 @@ func determineMainChainBlocks(blocksMap map[chainhash.Hash]*blockChainContext, t
 //	  compressed script  []byte   variable
 //
 // The serialized header code format is:
+//
 //	bit 0 - containing transaction is a coinbase
 //	bit 1 - output zero is unspent
 //	bit 2 - output one is unspent

blockchain/validate_test.go

@@ -10,10 +10,10 @@ import (
 	"testing"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // TestSequenceLocksActive tests the SequenceLockActive function to ensure it

btcjson/doc.go

@@ -5,7 +5,7 @@
 /*
 Package btcjson provides primitives for working with the bitcoin JSON-RPC API.
 
-Overview
+# Overview
 
 When communicating via the JSON-RPC protocol, all of the commands need to be
 marshalled to and from the the wire in the appropriate format.  This package
@@ -14,7 +14,7 @@ provides data structures and primitives to ease this process.
 In addition, it also provides some additional features such as custom command
 registration, command categorization, and reflection-based help generation.
 
-JSON-RPC Protocol Overview
+# JSON-RPC Protocol Overview
 
 This information is not necessary in order to use this package, but it does
 provide some intuition into what the marshalling and unmarshalling that is
@@ -47,24 +47,24 @@ with it) doesn't always follow the spec and will sometimes return an error
 string in the result field with a null error for certain commands.  However,
 for the most part, the error field will be set as described on failure.
 
-Marshalling and Unmarshalling
+# Marshalling and Unmarshalling
 
 Based upon the discussion above, it should be easy to see how the types of this
 package map into the required parts of the protocol
 
   - Request Objects (type Request)
-    - Commands (type <Foo>Cmd)
-    - Notifications (type <Foo>Ntfn)
+    1. Commands (type <Foo>Cmd)
+    2. Notifications (type <Foo>Ntfn)
   - Response Objects (type Response)
-    - Result (type <Foo>Result)
+    1. Result (type <Foo>Result)
 
 To simplify the marshalling of the requests and responses, the MarshalCmd and
 MarshalResponse functions are provided.  They return the raw bytes ready to be
 sent across the wire.
 
 Unmarshalling a received Request object is a two step process:
-  1) Unmarshal the raw bytes into a Request struct instance via json.Unmarshal
-  2) Use UnmarshalCmd on the Result field of the unmarshalled Request to create
+ 1. Unmarshal the raw bytes into a Request struct instance via json.Unmarshal
+ 2. Use UnmarshalCmd on the Result field of the unmarshalled Request to create
     a concrete command or notification instance with all struct fields set
     accordingly
 
@@ -72,14 +72,14 @@ This approach is used since it provides the caller with access to the additional
 fields in the request that are not part of the command such as the ID.
 
 Unmarshalling a received Response object is also a two step process:
-  1) Unmarhsal the raw bytes into a Response struct instance via json.Unmarshal
-  2) Depending on the ID, unmarshal the Result field of the unmarshalled
+ 1. Unmarhsal the raw bytes into a Response struct instance via json.Unmarshal
+ 2. Depending on the ID, unmarshal the Result field of the unmarshalled
     Response to create a concrete type instance
 
 As above, this approach is used since it provides the caller with access to the
 fields in the response such as the ID and Error.
 
-Command Creation
+# Command Creation
 
 This package provides two approaches for creating a new command.  This first,
 and preferred, method is to use one of the New<Foo>Cmd functions.  This allows
@@ -93,7 +93,7 @@ obviously, run-time which means any mistakes won't be found until the code is
 actually executed.  However, it is quite useful for user-supplied commands
 that are intentionally dynamic.
 
-Custom Command Registration
+# Custom Command Registration
 
 The command handling of this package is built around the concept of registered
 commands.  This is true for the wide variety of commands already provided by the
@@ -104,7 +104,7 @@ function for this purpose.
 A list of all registered methods can be obtained with the RegisteredCmdMethods
 function.
 
-Command Inspection
+# Command Inspection
 
 All registered commands are registered with flags that identify information such
 as whether the command applies to a chain server, wallet server, or is a
@@ -112,7 +112,7 @@ notification along with the method name to use.  These flags can be obtained
 with the MethodUsageFlags flags, and the method can be obtained with the
 CmdMethod function.
 
-Help Generation
+# Help Generation
 
 To facilitate providing consistent help to users of the RPC server, this package
 exposes the GenerateHelp and function which uses reflection on registered
@@ -122,7 +122,7 @@ generate the final help text.
 In addition, the MethodUsageText function is provided to generate consistent
 one-line usage for registered commands and notifications using reflection.
 
-Errors
+# Errors
 
 There are 2 distinct type of errors supported by this package:
 

btcjson/help.go

@@ -476,6 +476,7 @@ func isValidResultType(kind reflect.Kind) bool {
 // an error will use the key in place of the description.
 //
 // The following outlines the required keys:
+//
 //	"<method>--synopsis"             Synopsis for the command
 //	"<method>-<lowerfieldname>"      Description for each command argument
 //	"<typename>-<lowerfieldname>"    Description for each object field
@@ -492,6 +493,7 @@ func isValidResultType(kind reflect.Kind) bool {
 // For example, consider the 'help' command itself.  There are two possible
 // returns depending on the provided parameters.  So, the help would be
 // generated by calling the function as follows:
+//
 //	GenerateHelp("help", descs, (*string)(nil), (*string)(nil)).
 //
 // The following keys would then be required in the provided descriptions map:

btcjson/walletsvrcmds.go

@@ -875,6 +875,7 @@ func (s *ScriptPubKey) UnmarshalJSON(data []byte) error {
 //
 // Descriptors are typically ranged when specified in the form of generic HD
 // chain paths.
+//
 //	Example of a ranged descriptor: pkh(tpub.../*)
 //
 // The value can be an int to specify the end of the range, or the range

btcutil/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

btcutil/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

btcutil/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

btcutil/block_test.go

@@ -11,9 +11,9 @@ import (
 	"testing"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	"github.com/davecgh/go-spew/spew"
 )
 

btcutil/bloom/example_test.go

@@ -9,9 +9,9 @@ import (
 	"math/rand"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil/bloom"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil/bloom"
 )
 
 // This example demonstrates how to create a new bloom filter, add a transaction

btcutil/bloom/filter.go

@@ -9,10 +9,10 @@ import (
 	"math"
 	"sync"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // ln2Squared is simply the square of the natural log of 2.

btcutil/bloom/filter_test.go

@@ -9,10 +9,10 @@ import (
 	"encoding/hex"
 	"testing"
 
-	"github.com/btcsuite/btcd/chaincfg/chainhash"
-	"github.com/btcsuite/btcd/wire"
 	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/btcutil/bloom"
+	"github.com/btcsuite/btcd/chaincfg/chainhash"
+	"github.com/btcsuite/btcd/wire"
 )
 
 // TestFilterLarge ensures a maximum sized filter can be created.

btcutil/bloom/merkleblock.go

@@ -6,9 +6,9 @@ package bloom
 
 import (
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // merkleBlock is used to house intermediate information needed to generate a

btcutil/bloom/merkleblock_test.go

@@ -9,10 +9,10 @@ import (
 	"encoding/hex"
 	"testing"
 
-	"github.com/btcsuite/btcd/chaincfg/chainhash"
-	"github.com/btcsuite/btcd/wire"
 	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/btcutil/bloom"
+	"github.com/btcsuite/btcd/chaincfg/chainhash"
+	"github.com/btcsuite/btcd/wire"
 )
 
 func TestMerkleBlock3(t *testing.T) {

btcutil/coinset/coins.go

@@ -9,9 +9,9 @@ import (
 	"errors"
 	"sort"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // Coin represents a spendable transaction outpoint
@@ -238,7 +238,6 @@ func (s MaxValueAgeCoinSelector) CoinSelect(targetValue btcutil.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        btcutil.Amount

btcutil/coinset/coins_test.go

@@ -11,10 +11,10 @@ import (
 	"fmt"
 	"testing"
 
-	"github.com/btcsuite/btcd/chaincfg/chainhash"
-	"github.com/btcsuite/btcd/wire"
 	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/btcutil/coinset"
+	"github.com/btcsuite/btcd/chaincfg/chainhash"
+	"github.com/btcsuite/btcd/wire"
 )
 
 type TestCoin struct {

btcutil/doc.go

@@ -5,21 +5,21 @@
 /*
 Package btcutil 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

btcutil/gcs/builder/builder.go

@@ -10,10 +10,10 @@ import (
 	"fmt"
 	"math"
 
+	"github.com/btcsuite/btcd/btcutil/gcs"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil/gcs"
 )
 
 const (

btcutil/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:

btcutil/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

btcutil/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

btcutil/hdkeychain/example_test.go

@@ -7,8 +7,8 @@ package hdkeychain_test
 import (
 	"fmt"
 
-	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/btcutil/hdkeychain"
+	"github.com/btcsuite/btcd/chaincfg"
 )
 
 // This example demonstrates how to generate a cryptographically random seed

btcutil/hdkeychain/extendedkey.go

@@ -517,6 +517,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) {

btcutil/hdkeychain/extendedkey_test.go

@@ -1095,6 +1095,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 {

btcutil/net.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 btcutil

btcutil/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 btcutil

btcutil/tx_test.go

@@ -10,8 +10,8 @@ import (
 	"reflect"
 	"testing"
 
-	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/davecgh/go-spew/spew"
 )
 

btcutil/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

btcutil/txsort/txsort_test.go

@@ -11,8 +11,8 @@ import (
 	"path/filepath"
 	"testing"
 
-	"github.com/btcsuite/btcd/wire"
 	"github.com/btcsuite/btcd/btcutil/txsort"
+	"github.com/btcsuite/btcd/wire"
 )
 
 // TestSort ensures the transaction sorting works according to the BIP.

btcutil/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
-//  * Optional 1 byte (equal to 0x01) if the address being imported or exported
+//   - 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
 //     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

chaincfg/params.go

@@ -1007,6 +1007,7 @@ func IsBech32SegwitPrefix(prefix string) bool {
 // ErrInvalidHDKeyID error will be returned.
 //
 // Reference:
+//
 //	SLIP-0132 : Registered HD version bytes for BIP-0032
 //	https://github.com/satoshilabs/slips/blob/master/slip-0132.md
 func RegisterHDKeyID(hdPublicKeyID []byte, hdPrivateKeyID []byte) error {

cmd/addblock/config.go

@@ -9,11 +9,11 @@ import (
 	"os"
 	"path/filepath"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
 	_ "github.com/btcsuite/btcd/database/ffldb"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	flags "github.com/jessevdk/go-flags"
 )
 

cmd/addblock/import.go

@@ -13,10 +13,10 @@ import (
 
 	"github.com/btcsuite/btcd/blockchain"
 	"github.com/btcsuite/btcd/blockchain/indexers"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 var zeroHash = chainhash.Hash{}

cmd/btcctl/config.go

@@ -14,8 +14,8 @@ import (
 	"strings"
 
 	"github.com/btcsuite/btcd/btcjson"
-	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/chaincfg"
 	flags "github.com/jessevdk/go-flags"
 )
 
@@ -176,10 +176,10 @@ func cleanAndExpandPath(path string) string {
 // 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 functioning properly without any config settings
 // while still allowing the user to override settings with config files and

cmd/findcheckpoint/config.go

@@ -9,11 +9,11 @@ import (
 	"os"
 	"path/filepath"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
 	_ "github.com/btcsuite/btcd/database/ffldb"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	flags "github.com/jessevdk/go-flags"
 )
 

config.go

@@ -22,6 +22,7 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/connmgr"
@@ -30,7 +31,6 @@ import (
 	"github.com/btcsuite/btcd/mempool"
 	"github.com/btcsuite/btcd/peer"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/go-socks/socks"
 	flags "github.com/jessevdk/go-flags"
 )
@@ -403,10 +403,10 @@ func newConfigParser(cfg *config, so *serviceOptions, options flags.Options) *fl
 // 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 btcd functioning properly without any config settings
 // while still allowing the user to override settings with config files and

connmgr/doc.go

@@ -5,7 +5,7 @@
 /*
 Package connmgr implements a generic Bitcoin network connection manager.
 
-Connection Manager Overview
+# Connection Manager Overview
 
 Connection Manager handles all the general connection concerns such as
 maintaining a set number of outbound connections, sourcing peers, banning,

database/cmd/dbtool/globalconfig.go

@@ -10,11 +10,11 @@ import (
 	"os"
 	"path/filepath"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
 	_ "github.com/btcsuite/btcd/database/ffldb"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 var (

database/cmd/dbtool/insecureimport.go

@@ -12,10 +12,10 @@ import (
 	"sync"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // importCmd defines the configuration options for the insecureimport command.

database/doc.go

@@ -5,7 +5,7 @@
 /*
 Package database provides a block and metadata storage database.
 
-Overview
+# Overview
 
 As of Feb 2016, there are over 400,000 blocks in the Bitcoin block chain and
 and over 112 million transactions (which turns out to be over 60GB of data).
@@ -26,7 +26,7 @@ A quick overview of the features database 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
 transactional-based access and storage of metadata and block data.  It is
@@ -43,14 +43,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 committing changes that
 took place while the transaction was active.  It also provides the root metadata
 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
@@ -63,7 +63,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.
@@ -73,7 +73,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.
 
-Metadata Bucket
+# Metadata 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 metadata
@@ -81,7 +81,7 @@ bucket is the upper-most bucket in which data is stored and is created at the
 same time as the database.  Use the Metadata 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

database/ffldb/bench_test.go

@@ -9,9 +9,9 @@ import (
 	"path/filepath"
 	"testing"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // BenchmarkBlockHeader benchmarks how long it takes to load the mainnet genesis

database/ffldb/blockio.go

@@ -622,8 +622,8 @@ func (s *blockStore) syncBlocks() error {
 // were partially written.
 //
 // There are effectively two scenarios to consider here:
-//   1) Transient write failures from which recovery is possible
-//   2) More permanent failures such as hard disk death and/or removal
+//  1. Transient write failures from which recovery is possible
+//  2. More permanent failures such as hard disk death and/or removal
 //
 // In either case, the write cursor will be repositioned to the old block file
 // offset regardless of any other errors that occur while attempting to undo

database/ffldb/db.go

@@ -14,11 +14,11 @@ import (
 	"sort"
 	"sync"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/database/internal/treap"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	"github.com/syndtr/goleveldb/leveldb"
 	"github.com/syndtr/goleveldb/leveldb/comparer"
 	ldberrors "github.com/syndtr/goleveldb/leveldb/errors"

database/ffldb/doc.go

@@ -10,7 +10,7 @@ This driver is the recommended driver for use with btcd.  It makes use leveldb
 for the metadata, flat files for block storage, and checksums in key areas to
 ensure data integrity.
 
-Usage
+# Usage
 
 This package is a driver to the database package and provides the database type
 of "ffldb".  The parameters the Open and Create functions take are the

database/ffldb/driver_test.go

@@ -11,10 +11,10 @@ import (
 	"reflect"
 	"testing"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/database/ffldb"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // dbType is the database type name for this driver.

database/ffldb/interface_test.go

@@ -25,11 +25,11 @@ import (
 	"testing"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 var (

database/ffldb/whitebox_test.go

@@ -17,10 +17,10 @@ import (
 	"path/filepath"
 	"testing"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	"github.com/syndtr/goleveldb/leveldb"
 	ldberrors "github.com/syndtr/goleveldb/leveldb/errors"
 )

database/interface.go

@@ -8,8 +8,8 @@
 package database
 
 import (
-	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/chaincfg/chainhash"
 )
 
 // Cursor represents a cursor over key/value pairs and nested buckets of a

database/internal/treap/treapiter.go

@@ -318,6 +318,7 @@ func (iter *Iterator) ForceReseek() {
 // unexpected keys and/or values.
 //
 // For example:
+//
 //	iter := t.Iterator(nil, nil)
 //	for iter.Next() {
 //		if someCondition {

doc.go

@@ -18,9 +18,11 @@ on Windows.  The -C (--configfile) flag, as shown below, can be used to override
 this location.
 
 Usage:
+
 	btcd [OPTIONS]
 
 Application Options:
+
 	    --addcheckpoint=        Add a custom checkpoint.  Format:
 	                            '<height>:<hash>'
 	-a, --addpeer=              Add a peer to connect with at startup
@@ -154,7 +156,7 @@ Application Options:
 	                            (eg. 192.168.1.0/24 or ::1)
 
 Help Options:
-  -h, --help           Show this help message
 
+	-h, --help           Show this help message
 */
 package main

integration/bip0009_test.go

@@ -320,6 +320,7 @@ func testBIP0009(t *testing.T, forkKey string, deploymentID uint32) {
 // - Assert the chain height is 0 and the state is ThresholdDefined
 // - Generate 1 fewer blocks than needed to reach the first state transition
 //   - Assert chain height is expected and state is still ThresholdDefined
+//
 // - Generate 1 more block to reach the first state transition
 //   - Assert chain height is expected and state moved to ThresholdStarted
 //   - Generate enough blocks to reach the next state transition window, but only
@@ -348,11 +349,14 @@ func TestBIP0009(t *testing.T) {
 // Overview:
 // - Generate block 1
 //   - Assert bit is NOT set (ThresholdDefined)
+//
 // - Generate enough blocks to reach first state transition
 //   - Assert bit is NOT set for block prior to state transition
 //   - Assert bit is set for block at state transition (ThresholdStarted)
+//
 // - Generate enough blocks to reach second state transition
 //   - Assert bit is set for block at state transition (ThresholdLockedIn)
+//
 // - Generate enough blocks to reach third state transition
 //   - Assert bit is set for block prior to state transition (ThresholdLockedIn)
 //   - Assert bit is NOT set for block at state transition (ThresholdActive)

integration/csv_fork_test.go

@@ -17,12 +17,12 @@ import (
 
 	"github.com/btcsuite/btcd/blockchain"
 	"github.com/btcsuite/btcd/btcec/v2"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/integration/rpctest"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (
@@ -95,16 +95,17 @@ func makeTestOutput(r *rpctest.Harness, t *testing.T,
 // them.
 //
 // Overview:
+//
 // - Pre soft-fork:
-//    - Transactions with non-final lock-times from the PoV of MTP should be
+//  1. Transactions with non-final lock-times from the PoV of MTP should be
 //     rejected from the mempool.
-//    - Transactions within non-final MTP based lock-times should be accepted
+//  2. Transactions within non-final MTP based lock-times should be accepted
 //     in valid blocks.
 //
 // - Post soft-fork:
-//    - Transactions with non-final lock-times from the PoV of MTP should be
+//  1. Transactions with non-final lock-times from the PoV of MTP should be
 //     rejected from the mempool and when found within otherwise valid blocks.
-//    - Transactions with final lock-times from the PoV of MTP should be
+//  2. Transactions with final lock-times from the PoV of MTP should be
 //     accepted to the mempool and mined in future block.
 func TestBIP0113Activation(t *testing.T) {
 	t.Parallel()
@@ -392,11 +393,12 @@ func assertTxInBlock(r *rpctest.Harness, t *testing.T, blockHash *chainhash.Hash
 //
 // Overview:
 // - Pre soft-fork:
-//    - A transaction spending a CSV output validly should be rejected from the
+//  1. A transaction spending a CSV output validly should be rejected from the
 //     mempool, but accepted in a valid generated block including the
 //     transaction.
+//
 // - Post soft-fork:
-//    - See the cases exercised within the table driven tests towards the end
+//  1. See the cases exercised within the table driven tests towards the end
 //     of this test.
 func TestBIP0068AndBIP0112Activation(t *testing.T) {
 	t.Parallel()

integration/rpctest/blockgen.go

@@ -12,12 +12,12 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/mining"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // solveBlock attempts to find a nonce which makes the passed block header hash

integration/rpctest/node.go

@@ -14,8 +14,8 @@ import (
 	"runtime"
 	"time"
 
-	rpc "github.com/btcsuite/btcd/rpcclient"
 	"github.com/btcsuite/btcd/btcutil"
+	rpc "github.com/btcsuite/btcd/rpcclient"
 )
 
 // nodeConfig contains all the args, and data required to launch a btcd process

integration/rpctest/rpc_harness_test.go

@@ -14,11 +14,11 @@ import (
 	"testing"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 func testSendOutputs(r *Harness, t *testing.T) {

limits/limits_unix.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 !windows && !plan9
 // +build !windows,!plan9
 
 package limits

mempool/doc.go

@@ -31,40 +31,40 @@ proceed.  Typically, this will involve things such as relaying the transactions
 to other peers on the network and notifying the mining process that new
 transactions are available.
 
-Feature Overview
+# Feature Overview
 
 The following is a quick overview of the major features.  It is not intended to
 be an exhaustive list.
 
   - Maintain a pool of fully validated transactions
-   - Reject non-fully-spent duplicate transactions
-   - Reject coinbase transactions
-   - Reject double spends (both from the chain and other transactions in pool)
-   - Reject invalid transactions according to the network consensus rules
-   - Full script execution and validation with signature cache support
-   - Individual transaction query support
+    1. Reject non-fully-spent duplicate transactions
+    2. Reject coinbase transactions
+    3. Reject double spends (both from the chain and other transactions in pool)
+    4. Reject invalid transactions according to the network consensus rules
+    5. Full script execution and validation with signature cache support
+    6. Individual transaction query support
   - Orphan transaction support (transactions that spend from unknown outputs)
-   - Configurable limits (see transaction acceptance policy)
-   - Automatic addition of orphan transactions that are no longer orphans as new
+    1. Configurable limits (see transaction acceptance policy)
+    2. Automatic addition of orphan transactions that are no longer orphans as new
     transactions are added to the pool
-   - Individual orphan transaction query support
+    3. Individual orphan transaction query support
   - Configurable transaction acceptance policy
-   - Option to accept or reject standard transactions
-   - Option to accept or reject transactions based on priority calculations
-   - Rate limiting of low-fee and free transactions
-   - Non-zero fee threshold
-   - Max signature operations per transaction
-   - Max orphan transaction size
-   - Max number of orphan transactions allowed
+    1. Option to accept or reject standard transactions
+    2. Option to accept or reject transactions based on priority calculations
+    3. Rate limiting of low-fee and free transactions
+    4. Non-zero fee threshold
+    5. Max signature operations per transaction
+    6. Max orphan transaction size
+    7. Max number of orphan transactions allowed
   - Additional metadata tracking for each transaction
-   - Timestamp when the transaction was added to the pool
-   - Most recent block height when the transaction was added to the pool
-   - The fee the transaction pays
-   - The starting priority for the transaction
+    1. Timestamp when the transaction was added to the pool
+    2. Most recent block height when the transaction was added to the pool
+    3. The fee the transaction pays
+    4. The starting priority for the transaction
   - Manual control of transaction removal
-   - Recursive removal of all dependent transactions
+    1. Recursive removal of all dependent transactions
 
-Errors
+# Errors
 
 Errors returned by this package are either the raw errors provided by underlying
 calls or of type mempool.RuleError.  Since there are two classes of rules

mempool/estimatefee.go

@@ -16,9 +16,9 @@ import (
 	"strings"
 	"sync"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/mining"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // TODO incorporate Alex Morcos' modifications to Gavin's initial model

mempool/estimatefee_test.go

@@ -9,10 +9,10 @@ import (
 	"math/rand"
 	"testing"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/mining"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // newTestFeeEstimator creates a feeEstimator with some different parameters

mining/cpuminer/cpuminer.go

@@ -13,11 +13,11 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/mining"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

mining/mining.go

@@ -11,11 +11,11 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

mining/policy.go

@@ -6,8 +6,8 @@ package mining
 
 import (
 	"github.com/btcsuite/btcd/blockchain"
-	"github.com/btcsuite/btcd/wire"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/wire"
 )
 
 const (

mining/policy_test.go

@@ -9,9 +9,9 @@ import (
 	"testing"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // newHashFromStr converts the passed big-endian hex string into a

netsync/blocklogger.go

@@ -8,8 +8,8 @@ import (
 	"sync"
 	"time"
 
-	"github.com/btcsuite/btclog"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btclog"
 )
 
 // blockProgressLogger provides periodic logging for other services in order
@@ -27,6 +27,7 @@ type blockProgressLogger struct {
 
 // newBlockProgressLogger returns a new block progress logger.
 // The progress message is templated as follows:
+//
 //	{progressAction} {numProcessed} {blocks|block} in the last {timePeriod}
 //	({numTxs}, height {lastBlockHeight}, {lastBlockTimeStamp})
 func newBlockProgressLogger(progressMessage string, logger btclog.Logger) *blockProgressLogger {

netsync/interface.go

@@ -6,12 +6,12 @@ package netsync
 
 import (
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/mempool"
 	"github.com/btcsuite/btcd/peer"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // PeerNotifier exposes methods to notify peers of status changes to

netsync/manager.go

@@ -13,13 +13,13 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/mempool"
 	peerpkg "github.com/btcsuite/btcd/peer"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

peer/doc.go

@@ -6,7 +6,7 @@
 Package peer provides a common base for creating and managing Bitcoin network
 peers.
 
-Overview
+# Overview
 
 This package builds upon the wire package, which provides the fundamental
 primitives necessary to speak the bitcoin wire protocol, in order to simplify
@@ -24,33 +24,33 @@ A quick overview of the major features peer provides are as follows:
   - Asynchronous message queuing of outbound messages with optional channel for
     notification when the message is actually sent
   - Flexible peer configuration
-   - Caller is responsible for creating outgoing connections and listening for
+    1. Caller is responsible for creating outgoing connections and listening for
     incoming connections so they have flexibility to establish connections as
     they see fit (proxies, etc)
-   - User agent name and version
-   - Bitcoin network
-   - Service support signalling (full nodes, bloom filters, etc)
-   - Maximum supported protocol version
-   - Ability to register callbacks for handling bitcoin protocol messages
+    2. User agent name and version
+    3. Bitcoin network
+    4. Service support signalling (full nodes, bloom filters, etc)
+    5. Maximum supported protocol version
+    6. Ability to register callbacks for handling bitcoin protocol messages
   - Inventory message batching and send trickling with known inventory detection
     and avoidance
   - Automatic periodic keep-alive pinging and pong responses
   - Random nonce generation and self connection detection
   - Proper handling of bloom filter related commands when the caller does not
     specify the related flag to signal support
-   - Disconnects the peer when the protocol version is high enough
-   - Does not invoke the related callbacks for older protocol versions
+    1. Disconnects the peer when the protocol version is high enough
+    2. Does not invoke the related callbacks for older protocol versions
   - Snapshottable peer statistics such as the total number of bytes read and
     written, the remote address, user agent, and negotiated protocol version
   - Helper functions pushing addresses, getblocks, getheaders, and reject
     messages
-   - These could all be sent manually via the standard message output function,
+    1. These could all be sent manually via the standard message output function,
     but the helpers provide additional nice functionality such as duplicate
     filtering and address randomization
   - Ability to wait for shutdown/disconnect
   - Comprehensive test coverage
 
-Peer Configuration
+# Peer Configuration
 
 All peer configuration is handled with the Config struct.  This allows the
 caller to specify things such as the user agent name and version, the bitcoin
@@ -58,7 +58,7 @@ network to use, which services it supports, and callbacks to invoke when bitcoin
 messages are received.  See the documentation for each field of the Config
 struct for more details.
 
-Inbound and Outbound Peers
+# Inbound and Outbound Peers
 
 A peer can either be inbound or outbound.  The caller is responsible for
 establishing the connection to remote peers and listening for incoming peers.
@@ -73,7 +73,7 @@ Disconnect to disconnect from the peer and clean up all resources.
 WaitForDisconnect can be used to block until peer disconnection and resource
 cleanup has completed.
 
-Callbacks
+# Callbacks
 
 In order to do anything useful with a peer, it is necessary to react to bitcoin
 messages.  This is accomplished by creating an instance of the MessageListeners
@@ -92,7 +92,7 @@ It is often useful to use closures which encapsulate state when specifying the
 callback handlers.  This provides a clean method for accessing that state when
 callbacks are invoked.
 
-Queuing Messages and Inventory
+# Queuing Messages and Inventory
 
 The QueueMessage function provides the fundamental means to send messages to the
 remote peer.  As the name implies, this employs a non-blocking queue.  A done
@@ -106,7 +106,7 @@ QueueInventory function.  It employs batching and trickling along with
 intelligent known remote peer inventory detection and avoidance through the use
 of a most-recently used algorithm.
 
-Message Sending Helper Functions
+# Message Sending Helper Functions
 
 In addition to the bare QueueMessage function previously described, the
 PushAddrMsg, PushGetBlocksMsg, PushGetHeadersMsg, and PushRejectMsg functions
@@ -128,13 +128,13 @@ appropriate reject message based on the provided parameters as well as
 optionally provides a flag to cause it to block until the message is actually
 sent.
 
-Peer Statistics
+# Peer Statistics
 
 A snapshot of the current peer statistics can be obtained with the StatsSnapshot
 function.  This includes statistics such as the total number of bytes read and
 written, the remote address, user agent, and negotiated protocol version.
 
-Logging
+# Logging
 
 This package provides extensive logging capabilities through the UseLogger
 function which allows a btclog.Logger to be specified.  For example, logging at
@@ -142,7 +142,7 @@ the debug level provides summaries of every message sent and received, and
 logging at the trace level provides full dumps of parsed messages as well as the
 raw message bytes using a format similar to hexdump -C.
 
-Bitcoin Improvement Proposals
+# Bitcoin Improvement Proposals
 
 This package supports all BIPS supported by the wire package.
 (https://pkg.go.dev/github.com/btcsuite/btcd/wire#hdr-Bitcoin_Improvement_Proposals)

rpcadapters.go

@@ -8,12 +8,12 @@ import (
 	"sync/atomic"
 
 	"github.com/btcsuite/btcd/blockchain"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/mempool"
 	"github.com/btcsuite/btcd/netsync"
 	"github.com/btcsuite/btcd/peer"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // rpcPeer provides a peer for use with the RPC server and implements the

rpcclient/doc.go

@@ -5,7 +5,7 @@
 /*
 Package rpcclient implements a websocket-enabled Bitcoin JSON-RPC client.
 
-Overview
+# Overview
 
 This client provides a robust and easy to use client for interfacing with a
 Bitcoin RPC server that uses a btcd/bitcoin core compatible Bitcoin JSON-RPC
@@ -24,7 +24,7 @@ btcd or btcwallet by default.  However, configuration options are provided to
 fall back to HTTP POST and disable TLS to support talking with inferior bitcoin
 core style RPC servers.
 
-Websockets vs HTTP POST
+# Websockets vs HTTP POST
 
 In HTTP POST-based JSON-RPC, every request creates a new HTTP connection,
 issues the call, waits for the response, and closes the connection.  This adds
@@ -40,7 +40,7 @@ can be invoked without having to go through a connect/disconnect cycle for every
 call.  In addition, the websocket interface provides other nice features such as
 the ability to register for asynchronous notifications of various events.
 
-Synchronous vs Asynchronous API
+# Synchronous vs Asynchronous API
 
 The client provides both a synchronous (blocking) and asynchronous API.
 
@@ -57,7 +57,7 @@ the Receive method on the returned instance will either return the result
 immediately if it has already arrived, or block until it has.  This is useful
 since it provides the caller with greater control over concurrency.
 
-Notifications
+# Notifications
 
 The first important part of notifications is to realize that they will only
 work when connected via websockets.  This should intuitively make sense
@@ -67,7 +67,7 @@ All notifications provided by btcd require registration to opt-in.  For example,
 if you want to be notified when funds are received by a set of addresses, you
 register the addresses via the NotifyReceived (or NotifyReceivedAsync) function.
 
-Notification Handlers
+# Notification Handlers
 
 Notifications are exposed by the client through the use of callback handlers
 which are setup via a NotificationHandlers instance that is specified by the
@@ -83,7 +83,7 @@ will cause a deadlock as more server responses won't be read until the callback
 returns, but the callback would be waiting for a response.   Thus, any
 additional RPCs must be issued an a completely decoupled manner.
 
-Automatic Reconnection
+# Automatic Reconnection
 
 By default, when running in websockets mode, this client will automatically
 keep trying to reconnect to the RPC server should the connection be lost.  There
@@ -116,7 +116,7 @@ chain services will be available.  Depending on your application, you might only
 need chain-related RPCs.  In contrast, btcwallet provides pass through treatment
 for chain-related RPCs, so it supports them in addition to wallet-related RPCs.
 
-Errors
+# Errors
 
 There are 3 categories of errors that will be returned throughout this package:
 
@@ -159,7 +159,7 @@ detect if a command is unimplemented by the remote RPC server:
 	  	// from the remote RPC server.
 	  }
 
-Example Usage
+# Example Usage
 
 The following full-blown client examples are in the examples directory:
 

rpcclient/examples/btcdwebsockets/main.go

@@ -10,9 +10,9 @@ import (
 	"path/filepath"
 	"time"
 
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/rpcclient"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 func main() {

rpcclient/examples/btcwalletwebsockets/main.go

@@ -10,8 +10,8 @@ import (
 	"path/filepath"
 	"time"
 
-	"github.com/btcsuite/btcd/rpcclient"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/rpcclient"
 	"github.com/davecgh/go-spew/spew"
 )
 

rpcclient/extensions.go

@@ -13,9 +13,9 @@ import (
 	"fmt"
 
 	"github.com/btcsuite/btcd/btcjson"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 // FutureDebugLevelResult is a future promise to deliver the result of a
@@ -56,6 +56,7 @@ func (c *Client) DebugLevelAsync(levelSpec string) FutureDebugLevelResult {
 // specification.
 //
 // The levelspec can be either a debug level or of the form:
+//
 //	<subsystem>=<level>,<subsystem2>=<level2>,...
 //
 // Additionally, the special keyword 'show' can be used to get a list of the

rpcclient/mining.go

@@ -10,8 +10,8 @@ import (
 	"errors"
 
 	"github.com/btcsuite/btcd/btcjson"
-	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/btcutil"
+	"github.com/btcsuite/btcd/chaincfg/chainhash"
 )
 
 // FutureGenerateResult is a future promise to deliver the result of a

rpcclient/notify.go

@@ -14,9 +14,9 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/btcjson"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 var (

rpcclient/rawtransactions.go

@@ -10,9 +10,9 @@ import (
 	"encoding/json"
 
 	"github.com/btcsuite/btcd/btcjson"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 )
 
 const (

rpcclient/wallet.go

@@ -1016,10 +1016,10 @@ func (c *Client) CreateWalletAsync(name string, opts ...CreateWalletOpt) FutureC
 //
 // Optional parameters can be specified using functional-options pattern. The
 // following functions are available:
-//   * WithCreateWalletDisablePrivateKeys
-//   * WithCreateWalletBlank
-//   * WithCreateWalletPassphrase
-//   * WithCreateWalletAvoidReuse
+//   - WithCreateWalletDisablePrivateKeys
+//   - WithCreateWalletBlank
+//   - WithCreateWalletPassphrase
+//   - WithCreateWalletAvoidReuse
 func (c *Client) CreateWallet(name string, opts ...CreateWalletOpt) (*btcjson.CreateWalletResult, error) {
 	return c.CreateWalletAsync(name, opts...).Receive()
 }

rpcwebsocket.go

@@ -22,12 +22,12 @@ import (
 
 	"github.com/btcsuite/btcd/blockchain"
 	"github.com/btcsuite/btcd/btcjson"
+	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/btcd/chaincfg"
 	"github.com/btcsuite/btcd/chaincfg/chainhash"
 	"github.com/btcsuite/btcd/database"
 	"github.com/btcsuite/btcd/txscript"
 	"github.com/btcsuite/btcd/wire"
-	"github.com/btcsuite/btcd/btcutil"
 	"github.com/btcsuite/websocket"
 	"golang.org/x/crypto/ripemd160"
 )

signalsigterm.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 darwin || dragonfly || freebsd || linux || netbsd || openbsd || solaris
 // +build darwin dragonfly freebsd linux netbsd openbsd solaris
 
 package main

txscript/doc.go

@@ -12,7 +12,7 @@ overview to provide information on how to use the package.
 This package provides data structures and functions to parse and execute
 bitcoin transaction scripts.
 
-Script Overview
+# Script Overview
 
 Bitcoin transaction scripts are written in a stack-base, FORTH-like language.
 
@@ -30,7 +30,7 @@ is used to prove the the spender is authorized to perform the transaction.
 One benefit of using a scripting language is added flexibility in specifying
 what conditions must be met in order to spend bitcoins.
 
-Errors
+# Errors
 
 Errors returned by this package are of type txscript.Error.  This allows the
 caller to programmatically determine the specific error by examining the

txscript/error.go

@@ -506,10 +506,10 @@ func (e ErrorCode) String() string {
 
 // Error identifies a script-related error.  It is used to indicate three
 // classes of errors:
-// 1) Script execution failures due to violating one of the many requirements
+//  1. Script execution failures due to violating one of the many requirements
 //     imposed by the script engine or evaluating to false
-// 2) Improper API usage by callers
-// 3) Internal consistency check failures
+//  2. Improper API usage by callers
+//  3. Internal consistency check failures
 //
 // The caller can use type assertions on the returned errors to access the
 // ErrorCode field to ascertain the specific reason for the error.  As an

txscript/opcode.go

@@ -1171,7 +1171,7 @@ func opcodeCheckSequenceVerify(op *opcode, data []byte, vm *Engine) error {
 
 	// Transaction version numbers not high enough to trigger CSV rules must
 	// fail.
-	if vm.tx.Version < 2 {
+	if uint32(vm.tx.Version) < 2 {
 		str := fmt.Sprintf("invalid transaction version: %d",
 			vm.tx.Version)
 		return scriptError(ErrUnsatisfiedLockTime, str)