UI

package qtls partially implements TLS 1.2, as specified in RFC 5246, and TLS 1.3, as specified in RFC 8446.

Package build contains constants for the Go continuous build system.

btcd is a full-node bitcoin implementation written in Go. The default options are sane for most users. This means btcd will work 'out of the box' for most users. However, there are also a wide variety of flags that can be used to control it. The following section provides a usage overview which enumerates the flags. An interesting point to note is that the long form of all of these options (except -C) can be specified in a configuration file that is automatically parsed when btcd starts up. By default, the configuration file is located at ~/.btcd/btcd.conf on POSIX-style operating systems and %LOCALAPPDATA%\btcd\btcd.conf on Windows. The -C (--configfile) flag, as shown below, can be used to override this location. Usage: Application Options: Help Options:

Package btcec implements support for the elliptic curves needed for bitcoin. Bitcoin uses elliptic curve cryptography using koblitz curves (specifically secp256k1) for cryptographic functions. See http://www.secg.org/collateral/sec2_final.pdf for details on the standard. This package provides the data structures and functions implementing the crypto/elliptic Curve interface in order to permit using these curves with the standard crypto/ecdsa package provided with go. Helper functionality is provided to parse signatures and public keys from standard formats. It was designed for use with btcd, but should be general enough for other uses of elliptic curve crypto. It was originally based on some initial work by ThePiachu, but has significantly diverged since then.

Package chainhash provides abstracted hash functionality. This package provides a generic hash type and associated functions that allows the specific hash algorithm to be abstracted.

Package uuid provides implementation of Universally Unique Identifier (UUID). Supported versions are 1, 3, 4 and 5 (as specified in RFC 4122) and version 2 (as specified in DCE 1.1).

GopherLua: VM and compiler for Lua in Go

Package btcutil provides bitcoin-specific convenience functions and types. 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. 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. 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 may well support more in the future. This package currently provides implementations for the pay-to-pubkey, pay-to-pubkey-hash, and pay-to-script-hash address types. To decode/encode an address:

Package termui is a library for creating terminal user interfaces (TUIs) using widgets.

Package squirrel provides a fluent SQL generator. See https://github.com/Masterminds/squirrel for examples.

Package uuid generates and inspects UUIDs. UUIDs are based on RFC 4122 and DCE 1.1: Authentication and Security Services. A UUID is a 16 byte (128 bit) array. UUIDs may be used as keys to maps or compared directly.

Package promptui is a library providing a simple interface to create command-line prompts for go. It can be easily integrated into spf13/cobra, urfave/cli or any cli go application. promptui has two main input modes: Prompt provides a single line for user input. It supports optional live validation, confirmation and masking the input. Select provides a list of options to choose from. It supports pagination, search, detailed view and custom templates. This is an example for the Prompt mode of promptui. In this example, a prompt is created with a validator function that validates the given value to make sure its a number. If successful, it will output the chosen number in a formatted message. This is an example for the Select mode of promptui. In this example, a select is created with the days of the week as its items. When an item is selected, the selected day will be displayed in a formatted message.

Package psbt is an implementation of Partially Signed Bitcoin Transactions (PSBT). The format is defined in BIP 174: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki

Package gocui allows to create console user interfaces. Create a new GUI: Set GUI managers: Managers are in charge of GUI's layout and can be used to build widgets. On each iteration of the GUI's main loop, the Layout function of each configured manager is executed. Managers are used to set-up and update the application's main views, being possible to freely change them during execution. Also, it is important to mention that a main loop iteration is executed on each reported event (key-press, mouse event, window resize, etc). GUIs are composed by Views, you can think of it as buffers. Views implement the io.ReadWriter interface, so you can just write to them if you want to modify their content. The same is valid for reading. Create and initialize a view with absolute coordinates: Views can also be created using relative coordinates: Configure keybindings: gocui implements full mouse support that can be enabled with: Mouse events are handled like any other keybinding: IMPORTANT: Views can only be created, destroyed or updated in three ways: from the Layout function within managers, from keybinding callbacks or via *Gui.Update(). The reason for this is that it allows gocui to be concurrent-safe. So, if you want to update your GUI from a goroutine, you must use *Gui.Update(). For example: By default, gocui provides a basic edition mode. This mode can be extended and customized creating a new Editor and assigning it to *View.Editor: DefaultEditor can be taken as example to create your own custom Editor: Colored text: Views allow to add colored text using ANSI colors. For example: For more information, see the examples in folder "_examples/".

Package uuid provides implementation of Universally Unique Identifier (UUID). Supported versions are 1, 3, 4 and 5 (as specified in RFC 4122) and version 2 (as specified in DCE 1.1).

Package goldmark implements functions to convert markdown text to a desired format.

Package kubebuilder contains pkged files compiled into the go binaries.

Package uuid provides RFC4122 and DCE 1.1 UUIDs. Use NewV1, NewV2, NewV3, NewV4, NewV5, for generating new UUIDs. Use New([]byte), NewHex(string), and Parse(string) for creating UUIDs from existing data. The original version was from Krzysztof Kowalik <chris@nu7hat.ch> Unfortunately, that version was non compliant with RFC4122. The package has since been redesigned. The example code in the specification was also used as reference for design. Copyright (C) 2016 myesui@github.com 2016 MIT licence

Package quicktemplate provides fast and powerful template engine. See https://github.com/valyala/quicktemplate for details.

Package codebuild provides the API client, operations, and parameter types for AWS CodeBuild. CodeBuild is a fully managed build service in the cloud. CodeBuild compiles your source code, runs unit tests, and produces artifacts that are ready to deploy. CodeBuild eliminates the need to provision, manage, and scale your own build servers. It provides prepackaged build environments for the most popular programming languages and build tools, such as Apache Maven, Gradle, and more. You can also fully customize build environments in CodeBuild to use your own build tools. CodeBuild scales automatically to meet peak build requests. You pay only for the build time you consume. For more information about CodeBuild, see the CodeBuild User Guide.

Package uuid provides implementation of Universally Unique Identifier (UUID). Supported versions are 1, 3, 4 and 5 (as specified in RFC 4122) and version 2 (as specified in DCE 1.1).

Package btcutil provides bitcoin-specific convenience functions and types. 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. 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. 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 may well support more in the future. This package currently provides implementations for the pay-to-pubkey, pay-to-pubkey-hash, and pay-to-script-hash address types. To decode/encode an address:

Package uuid provides implementations of the Universally Unique Identifier (UUID), as specified in RFC-4122 and the Peabody RFC Draft (revision 03). RFC-4122[1] provides the specification for versions 1, 3, 4, and 5. The Peabody UUID RFC Draft[2] provides the specification for the new k-sortable UUIDs, versions 6 and 7. DCE 1.1[3] provides the specification for version 2, but version 2 support was removed from this package in v4 due to some concerns with the specification itself. Reading the spec, it seems that it would result in generating UUIDs that aren't very unique. In having read the spec it seemed that our implementation did not meet the spec. It also seems to be at-odds with RFC 4122, meaning we would need quite a bit of special code to support it. Lastly, there were no Version 2 implementations that we could find to ensure we were understanding the specification correctly. [1] https://tools.ietf.org/html/rfc4122 [2] https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-03 [3] http://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01

Package txauthor provides transaction creation code for wallets.

Package grpcui provides a gRPC web UI in the form of HTTP handlers that can be added to a web server. This package provides multiple functions which, all combined, provide a fully functional web UI. Users of this package can use these pieces to embed a UI into any existing web application. The web form sources can be embedded in an existing HTML page, and the HTTP handlers wired up to make the form fully functional. For users that don't need as much control over layout and style of the web page, instead consider using standalone.Handler, which is an all-in-one handler that includes its own HTML and CSS as well as all other dependencies.

Package txrules provides transaction rules that should be followed by transaction authors for wide mempool acceptance and quick mining.

Package walletdb provides a namespaced database interface for btcwallet. 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 metadata. One of the issues with many wallets is they are tightly integrated. Designing a wallet with loosely coupled components that provide specific functionality is ideal, however it presents a challenge in regards to data storage since each component needs to store its own data without knowing the internals of other components or breaking atomicity. This package solves this issue by providing a pluggable driver, namespaced database interface that is intended to be used by the main wallet daemon. This allows the potential for any backend database type with a suitable driver. Each component, which will typically be a package, can then implement various functionality such as address management, voting pools, and colored coin metadata in their own namespace without having to worry about conflicts with other packages even though they are sharing the same database that is managed by the wallet. A quick overview of the features walletdb provides are as follows: The main entry point is the DB interface. It exposes functionality for creating, retrieving, and removing namespaces. It is obtained via the Create 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. The Namespace interface is an abstraction that provides facilities for obtaining transactions (the Tx interface) that are the basis of all database reads and writes. Unlike some database interfaces that support reading and writing without transactions, this interface requires transactions even when only reading or writing a single key. The Begin function provides an unmanaged transaction while the View and Update functions provide a managed transaction. These are described in more detail below. 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. 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 automatically depending on whether or not the provided function returns an error. Attempting to manually call Rollback or Commit on the managed transaction will result in a panic. An unmanaged transaction, on the other hand, requires the caller to manually 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. The Bucket interface provides the ability to manipulate key/value pairs and nested buckets as well as iterate through them. The Get, Put, and Delete functions work with key/value pairs, while the Bucket, 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. 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 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. The CreateBucket and CreateBucketIfNotExists functions on the Bucket interface provide the ability to create an arbitrary number of nested buckets. It is a good idea to avoid a lot of buckets with little data in them as it could lead to poor page utilization depending on the specific driver in use. This example demonstrates creating a new database, getting a namespace from it, and using a managed read-write transaction against the namespace to store and retrieve data.

Package wtxmgr provides an implementation of a transaction database handling spend tracking for a bitcoin wallet. Its primary purpose is to save transactions with outputs spendable with wallet keys and transactions that are signed by wallet keys in memory, handle spend tracking for unspent outputs and newly-inserted transactions, and report the spendable balance from each unspent transaction output. It uses walletdb as the backend for storing the serialized transaction objects in buckets. Transaction outputs which are spendable by wallet keys are called credits (because they credit to a wallet's total spendable balance). Transaction inputs which spend previously-inserted credits are called debits (because they debit from the wallet's spendable balance). Spend tracking is mostly automatic. When a new transaction is inserted, if it spends from any unspent credits, they are automatically marked spent by the new transaction, and each input which spent a credit is marked as a debit. However, transaction outputs of inserted transactions must manually marked as credits, as this package has no knowledge of wallet keys or addresses, and therefore cannot determine which outputs may be spent. Details regarding individual transactions and their credits and debits may be queried either by just a transaction hash, or by hash and block. When querying for just a transaction hash, the most recent transaction with a matching hash will be queried. However, because transaction hashes may collide with other transaction hashes, methods to query for specific transactions in the chain (or unmined) are provided as well.

Package cpuid provides information about the CPU running the current program. CPU features are detected on startup, and kept for fast access through the life of the application. Currently x86 / x64 (AMD64) as well as arm64 is supported. You can access the CPU information by accessing the shared CPU variable of the cpuid library. Package home: https://github.com/klauspost/cpuid