A Merkle tree is a data structure with unique properties which make it useful for Bitcoin. Merkle trees are used to store all transactions in a given block. The advantage of this system is that one node can easily prove to another that a given transaction was contained in a specific block. This is useful for SPV nodes and light clients, who do not store the entire blockchain and are only interested in certain transactions or blocks.
For example, if Alice runs a wallet and is waiting for her transaction to confirm, but she does not run a node, she can request a Merkle proof from Bob, who runs a full node. This proof will convince Alice that the transaction she is interested in was included in a valid block, without Bob needing to share all of the transactions or the entire block with Alice.
From a technical point of view, a Merkle tree has layers. The first layer is the list of all transaction IDs (txids) in a block. To produce the second layer, these txids are concatenated and hashed in pairs using SHA-256. Thus, the second layer will be half as long as the first layer. This process is continued until the last layer contains exactly one hash. This is called the Merkle root. Given the properties of a hash, if a single transaction id is changed, that change will trickle up the tree and change the root hash entirely.
The advantage of a Merkle tree is that the presence of any given transaction id in a Merkle tree can be proven without revealing the entire Merkle tree. For example, in a Merkle tree with eight transactions, only three hashes must be provided to prove that one of the txids were included in that tree. This provides great efficiency for light clients, which do not store the entire blockchain, and therefore must query other nodes for proof that certain transactions are confirmed.
Anti-Money Laundering (AML) is a category of laws and regulations that are intended to prevent money laundering, terrorist financing, tax evasion, and other illicit activities.
Most AML laws place requirements on financial institutions for keeping detailed records of their customers’ transactions and interactions so as to enable authorities to track the financial history of any customer.Additionally, financial institutions must often take a variety of steps to prevent illicit money transfers ahead of time. One such requirement of AML is Know Your Customer (KYC) laws, which require a financial institution to verify the identities of their customers.
Bitcoin brokerages and exchanges which take custody of user funds are subject to AML compliance in order to prevent money from being laundered between Bitcoin and other currencies. However, AML compliance varies significantly across jurisdictions.
マリアビリティ Malleability 2,100 sats
Transaction malleability is the ability of a transaction to have multiple valid IDs (txids). Malleability occurs when a part of a transaction can change after the transaction has been signed without invalidating the signature. Since a txid is a hash of the transaction, any change to the transaction will result in a change of the txid. However, changes that alter the txid and invalidate the signature are not a concern; only changes which alter the txid and do not invalidate the signature raise malleability concerns. Malleability is a problem for developers and users who want to reference a previous transaction in a spending transaction before the previous transaction has been confirmed on the blockchain. This problem arises because, in order to spend an output created by a previous transaction, the spending transaction must reference the txid of the previous transaction. If this txid can change, the reference will fail, and the spending transaction will be rendered invalid. A transaction can be malleated in two ways. First, after being signed, additional data can be added to a ScriptSig. Secondly, the signature itself, which is contained within the ScriptSig, can be changed. These options are both possible because a signature cannot sign itself.Eliminating transaction malleability was achieved by the SegWit upgrade, enabling more innovation on top of Bitcoin, including the Lightning Network and Taproot. SegWit eliminated transaction malleability by moving the ScriptSig—the transaction signature and the malleable part of the transaction—from the main body of the transaction into a separate Witness section.
A multipath payment (MPP) is a type of Lightning payment which is executed as an atomic set of smaller payments. These smaller payments are more reliable and easier to execute; they also offer privacy advantages, as a set of multipath payments is harder to track than a single payment. Multipath payments are atomic, meaning they must all succeed, or they all fail. This is done to avoid the confusion of partial payments.
Multipath payments solve a few issues faced by the Lightning Network. When a Lightning channel is established, it has a defined capacity. Each user can send only as much bitcoin as they have committed to the channel. Thus, larger payments strain the capacity of channels and can fail if capacity is insufficient. This problem is especially salient for routed payments, which traverse several channels to get from sender to receiver. In order to reduce the strain of large payments, Lightning implementations allow users or their Lightning wallets to break the payment up into smaller payments. Each payment can be routed across a different path, distributing the strain across many different channels.
The term multipath payment is a general term, and MPP is not fully implemented on the Lightning Network. There exist different proposals and implementations of this concept across the different Lightning implementations, including Basic MPP and Atomic Multipath Payments (AMP). These different versions attempt to solve several security and reliability issues with the basic concept of multipath payments.
Mainnet is the term for the real Bitcoin blockchain and network, and is used in contrast with testnet, signet, and regtest networks. Unlike the other networks, which are used for testing purposes, mainnet coins (BTC) have monetary value. When people refer to the Bitcoin network, they are usually referring to mainnet.
Each network has its own blockchain, and its own token. Additionally, addresses have different prefixes for each network. Mainnet addresses begin with ‘1’, ‘3’, or ‘bc1’, while testnet addresses begin with ‘2’, ‘m’, ‘n’, or ‘tb1’. Coins cannot be sent between networks. If mainnet bitcoin is sent to a testnet address, it is destroyed and unrecoverable. The same fate applies to testnet coins sent to mainnet addresses.
A mempool explorer is a software application, often in the form of a website, which displays useful information about the current state of the mempool. The mempool is the collection of unconfirmed transactions, transactions which have not yet been included in a block.
Mempool explorers commonly publish stats including average and median fee rates, estimated fee rates required to achieve specific confirmation times, and total data size and bitcoin volume of the mempool. All of these statistics can be useful to Bitcoin users who intend to submit new transactions to the network by informing them on how much to pay in fees, and how soon to expect their transaction to be confirmed in a block.
Several popular mempool explorers exist, each optimized for different uses. Mempool.Space is helpful in setting fees for Bitcoin transactions in order to optimize for fee savings or rapid confirmation. Jochen Hoenicke's Mempool Explorer is more helpful for analyzing past data on Bitcoin fee rates and visualizing mempool traffic and trends. Lastly, Blockstream includes data about unconfirmed transactions, including confirmation time estimates and highlights if a given transaction overpaid in fees.
コンテンツの著作権は River Financial に帰属します。二次利用の可否は権利者にご確認ください。 / All rights reserved to River Financial.
