River Financial の Bitcoin Glossary をベースに、日本語のビットコイン用語集を構築中です。用語集作りに参加して、ビットコインを稼ぎませんか？
Application-Specific Integrated Circuit (ASIC)
|An Application-Specific Integrated Circuit (ASIC) is a special microchip built for exactly one purpose. Bitcoin ASIC miners, the hardware devices that contain these chips, are designed solely to hash blocks in order to find a valid Proof-of-Work. Essentially, the only function these microchips perform is the SHA-256 hash function on a block header. Because mining has become such a large industry, the difficulty has risen to the point where using a CPU or GPU to mine is no longer profitable. Having a single purpose affords ASIC miners critical efficiency gains in an industry where the tiniest efficiency improvement can give a miner the edge. The rapid innovation around Bitcoin ASICs has partially driven the explosion of hash rate over the last decade, bolstering Bitcoin’s security.
|BIP 125 (RBF)
BIP 125 (Replace-by-Fee)
|Bitcoin Improvement Proposal (BIP) 125 introduces Replace-by-Fee (RBF) to Bitcoin. This soft fork enables users to replace an unconfirmed transaction with a similar transaction paying a larger fee. Some Bitcoin wallets, such as Electrum, now allow users to use RBF. When a transaction is broadcast, it pays a defined fee to the miner of that transaction. If the fee is too low, miners will defer mining that transaction in favor of other transactions which paid higher fees. In order to speed up a transaction’s confirmation, a user can take advantage of RBF to increase the fee of their transaction. Nodes following BIP 125 will accept the new transaction and remove the older version from their mempool. Before BIP 125, Bitcoin nodes would automatically reject a transaction which attempted to spend UTXOs already spent in a different transaction in their mempool. BIP 125 created a caveat to that rule. However, a transaction must opt into RBF in its first version to make RBF possible. This is done using the sequence, a previously unused field of a transaction input.
|BIP 174 (PSBT)
BIP 174 (PSBT)
|Bitcoin Improvement Proposal (BIP) 174 introduced Partially Signed Bitcoin Transactions (PSBT) as a community standard. PSBT is a standardized format for communicating unsigned or partially signed Bitcoin transactions. PSBT was originally designed to enhance interoperability between wallets and other Bitcoin software, making it easier for a transaction to be constructed by one wallet, transferred to another for signing, and then transferred to a Bitcoin node for broadcasting. PSBT is also particularly useful for coordinating between parties who wish to sign the same transaction. For example, CoinJoin protocols and multisig outputs require multiple different actors to all sign the same transaction. The PSBT format provides a method for constructing the transaction, passing it between the different signers, and then assembling the final transaction to be broadcast. BIP 174 is currently widely adopted as a community standard, however it has several downsides, which are currently being addressed by a proposal for PSBT v2.
|BIP 32 (階層型決定性ウォレット)
BIP 32 (Hierarchical Deterministic Wallets)
|BIP 340 (シュノア署名)
BIP 340 (Schnorr Signatures)
|Bitcoin Improvement Proposal (BIP) 340 introduces Schnorr signatures to Bitcoin Core. Schnorr signatures offer several significant advantages over ECDSA, the digital signature scheme Bitcoin has used since inception.
Included in BIP 340 is a detailed description of how Schnorr signatures can be created and validated. In addition, new formats for Schnorr signatures and public keys are defined. Schnorr public keys will be 32 bytes, and Schnorr signatures will be 64 bytes long, compared to ECDSA public keys and signatures, which are 33 and 70-72 bytes long respectively. These minor space savings will yield savings on transaction fees for Bitcoin users who use Schnorr.
Along with BIP 341 and BIP 342, BIP 340 is an integral part of the Taproot upgrade, which is in the process of being activated.
|BIP 39 (ニモニックフレーズ)
BIP 39 (Mnemonic Phrases)
BIP 39が定める規格はほぼ全ての主要ビットコインウォレットに採用されていますが、Bitcoin Coreには実装されておらず、技術的な難点もいくつかあります。ただ、ニーモニックフレーズにはセキュリティ上の既知の弱点はなく、ビットコインウォレットを容易にバックアップする方法として普及しています。
|BTC is the ticker symbol for Bitcoin. One bitcoin is denoted as 1 BTC, just as one U.S. dollar is denoted as 1 USD or one share of Apple Inc. is denoted by 1 AAPL. One BTC is divisible into 100,000,000 units, called satoshis or sats.
|Child-Pays-for-Parent is a transaction mechanism with a similar purpose as Replace-by-Fee (RBF). While RBF allows the sender to speed up a transaction’s confirmation, Child-Pays-for-Parent allows the recipient to speed up the transaction’s confirmation.
In case a transaction is sent with a low fee and is not being confirmed fast enough for the recipient’s liking, the recipient may create a new transaction spending the bitcoin they received in the previous transaction (even though it is still unconfirmed in the mempool). This second transaction will pay a higher fee and signal to miners that they must mine the first transaction first in order to mine the second transaction. In this way, the recipient will receive their funds faster despite the low fee paid by the sender.
Decentralized Exchange (DEX)
|A decentralized exchange (DEX) is meant to facilitate the exchange of bitcoin without forcing users to sacrifice privacy or custody to an exchange. DEXs offer access to their exchange without Anti-Money Laundering (AML) procedures, meaning they do not collect a user’s government-issued ID, address, or phone number. Decentralized exchanges vary in the full extent of their decentralization; some are simply non-custodial, but maintain a central authority to arbitrate disputes while others are fully decentralized protocols. Most DEXs also execute bitcoin trades directly between users without taking control of the bitcoin as middlemen. Often, decentralized exchanges will require the bitcoin seller to deposit bitcoin into a 2-of-3 multisig address, where each party - the buyer, the seller, and the DEX, holds a key. When the seller receives payment, the buyer and seller then co-sign a transaction sending the bitcoin from the multisig address to the seller’s address. If either party breaches the agreement, the aggreived party can appeal to the DEX, who can use their key to resolve the dispute.
|The Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic scheme for producing digital signatures using public and private keys. All Bitcoin keys and signatures are currently generated using ECDSA. An ECDSA signature allows someone to publish a public key and then create a signature of some data with their private key, such that anyone can verify that the signature was created by the owner of this public key. However, no one is capable of deriving the private key from the public key or the signature. Nor can this signature be used to forge a signature for other data. ECDSA signatures are used to sign all Bitcoin transactions thanks to these strong security features. An elliptic curve is a defined mathematical function of the general format y^2 = x^3 + ax + b. For Bitcoin, this curve has the specific equation y^2 = x^3 + 7, as a = 0 and b = 7. Any point on this elliptic curve, called secp256k1, is a valid Bitcoin public key. In order to generate a public key, a user must generate a private key, which is simply a large number. Next, this private key is multiplied by a defined point called the Generator Point, to produce the public key. This multiplication is point multiplication, which behaves differently than normal multiplication. Critically, point division is incalculable, meaning a public key cannot currently be used to derive a private key, giving the ECDSA scheme its security.
|Eltoo—pronounced as “L2”—is a proposed upgrade to Bitcoin whose main goal is to improve layer two solutions, most importantly, the Lightning Network.
Eltoo would implement these upgrades by introducing a new sighash flag called SIGHASH_NOINPUT to the Bitcoin protocol. The new sighash flag would allow a Bitcoin signature to commit to a transaction without specifying the txid of the input.
Leaving the txid unspecified enables greater flexibility for transactions. It means descendant transactions can be signed before their ancestors are published to the blockchain.
For example, if Alice and Bob open a Lightning channel, they first sign a funding transaction, which sends bitcoin to a 2-of-2 multisig address. Once the channel is open, Alice and Bob make a series of update transactions, which spend the funds in the 2-of-2 multisig address. When Alice and Bob wish to close the channel, they must sign a settlement transaction to do so.
Without eltoo, each transaction in this process can only be signed once the previous one has been created. With eltoo, the settlement transaction can be signed at the same time as the funding transaction. This eliminates the need for the Lightning Network penalty, significantly simplifying the Lightning Network’s double spend protection.
Key Fact: Because eltoo would introduce a new sighash flag, it is a change to the consensus protocol, and would require a soft fork.
|HODL is an adage native to the Bitcoin community, derived simply from a misspelling of the word “hold”. It advises bitcoiners to remain stoic and avoid selling in the face of the extreme price volatility Bitcoin often experiences. Bitcoiners believe bitcoin to be the future global reserve asset, and thus, its gains should be astronomical, even relative to current prices. Thus, while trading could potentially offer short term gains, hodling is the safer alternative in that a hodler can never find themself with fewer bitcoin than they started with. The term HODL finds its origins in a post on the BitcoinTalk forum from an inebriated bitcoiner during a price crash.
|Courts use the Howey test from 1946 to assess which offerings qualify as securities. In SEC v. W.J. Howey Co., the court held that the sale of land within a common enterprise was an investment contract, which is subject to the Securities Act of 1933 and other Securities and Exchange Commission (SEC) regulations. A common enterprise is a business in which external investors contribute to the same pool of funds as the party offering the investment.
An investment contract exists when there is the investment of money in a common enterprise with a reasonable expectation of profits to be derived from the efforts of others
Most recently, the Howey test was used in the SEC’s action against Ripple Labs, Inc., where the court found that XRP offerings constituted an investment contract. Although it raised capital to finance the company’s business, Ripple did not register with the SEC. The subsequent SEC investigation revealed that Ripple failed to comply with SEC requirements for broad public offerings, highlighting the importance of investor protection when issuing a new virtual currency.
Hashed Time Locked Contract (HTLC)
|A Time Locked Contract is a Bitcoin transaction which includes a timelock. This Bitcoin transaction is hashed to form a Hashed Time Locked Contract or HTLC, which is used mainly on the Lightning Network to allow Lightning payments to be routed across multiple nodes. Lightning routing allows two parties to trustlessly transact without a direct channel between them, using intermediary channels instead.
|The Liquid Network is a sidechain protocol built on top of the Bitcoin blockchain. The Liquid Network was created by Blockstream but is governed by a federation of parties and operated on an open source blockchain platform called Elements. The Liquid Network offers several features not offered on the Bitcoin blockchain:
・Fast, Final settlements. Liquid blocks are added precisely every minute, compared to Bitcoin’s 10 minute, probabilistic block times. Additionally, reorganizations are disallowed, ensuring that two confirmations is sufficient to establish the final settlement of a transaction.
Bitcoin on the Liquid Network is known as L-BTC or Liquid Bitcoin, and using it is analogous to depositing cash at a casino in exchange for chips. In order to use Bitcoin on the Liquid Network, a user must lock up their bitcoin in a transaction known as a peg-in. This is achieved by depositing bitcoin to an address generated by the Liquid Network. When this deposit is confirmed, the user will be issued an equivalent amount of L-BTC and be able to transact on the Liquid Network. In order to peg-out and receive their bitcoin back, a user must deposit their L-BTC before the Liquid Network sends the bitcoin. Currently, the Liquid Network will only return bitcoin to a verified address.
|LNURL makes communication between Lightning wallets and other applications easier through QR codes. LNURL enables a better user experience on Lightning by abstracting away payment flow complexities such as exchanging full-length LN invoices with counterparties.
Technically, “LNURL” is a collection of open-source protocols that work to coordinate payments on the Lightning Network by leveraging HTTP.
Users are able to login with a lightning wallet to services that support LNURL, as well as send and receive payments by utilizing static payment codes, typically in the form of a QR code. At the time of writing, LNURL has 20 features that can be implemented in applications.
The most popular features are:
・LNURL-pay: A user scans an LNURL-pay QR code with their wallet, which then requests a Lightning invoice for the payer. This invoice can be a fixed amount or a range; the payer can also leave a message.
Resources to learn more about LNURL:
|The term m-of-n describes the precise conditions of a multisig setup, with m being the number of signatures required, and n being the number of authorized keys from which the signatures can come. A Multiple Signature (multisig) address is a Bitcoin address which requires the signatures of multiple private keys in order to be spent. While most bitcoin is controlled in a single signature setup, some Bitcoin users store their bitcoin in a multisig setup to avoid a single point of failure. If one of their keys is compromised, they do not lose their funds.
Let’s walk through an example: Alice, Bob, and Charlie want to start a company and hold joint custody of some bitcoin. To ensure that one of them cannot steal the collective funds, Alice, Bob, and Charlie share one public key each. They also decide that they will run their company based on majority rule. Thus, any two signatures are sufficient to spend their shared bitcoin. This requirement of two signatures (m) coming from any of the three (n) public keys is translated into a script, which is hashed to yield the address to which all three partners will send their contributions to the company fund. This set up would be described as a 2-of-3 multisig.
|MuSig is a protocol for creating Taproot multisig public keys and signatures. MuSig makes use of Schnorr signature and public key aggregation, and thus will only be possible with the activation of the Taproot upgrade.
MuSig is special in that a resulting multisig transaction is no longer discernible from a single signature transaction. This is because MuSig combines the individual public keys of each party to create a single public key. When bitcoin is spent from this public key, the spenders are not forced to reveal their individual public keys. Instead, they collectively create a single signature valid for the public key they created earlier. This is not the case for typical multisig transactions, which use P2SH scripts and force the signatures and public keys of each signer to be revealed on the blockchain.
MuSig presents a significant privacy improvement over the current multisig implementation, and not just for MuSig users. MuSig will undermine many heuristics currently used for chain analysis by removing any differentiation between single signature and multi signature transactions.
Point Time Locked Contract (PTLC)
|A Point Time Locked Contract (PTLC) is a Bitcoin transaction which locks bitcoin to a point on Bitcoin’s elliptic curve. The outputs created by this transaction type are also time locked, meaning they cannot be spent before a certain time, as denominated in UTC time or block height. PTLCs are similar to Hashed Time Locked Contracts (HTLCs), but offer privacy gains as well as fee savings. For this reason, PTLCs may replace HTLCs as the driving contract behind the Lightning Network and other off-chain protocols.
Point Time Locked Contracts will become most accessible after Schnorr signatures have been implemented on Bitcoin, which will occur when the Taproot upgrade is activated.
|In Bitcoin, RBF stands for Replace-by-Fee. A Bitcoin transaction can be designated as RBF in order to allow the sender to replace this transaction with another similar transaction which pays a higher fee. This mechanism exists to allow users to respond if the network becomes congested and fees rise unexpectedly. If a user sends a transaction with a low fee, and finds that it is taking too long to confirm, the user can raise the fee they pay to confirm their transaction faster. RBF only works while the transaction is in the mempool. As soon as a transaction enters a block, it cannot be replaced by fee. Additionally, when a transaction is first sent, it must specify that it is available to be replaced by fee. This is achieved by setting the nSequence, a small part of each transaction, to any value below 0xfffffffe. The nSequence of a transaction is intended to allow a transaction to be updated after it has been broadcast. Also see BIP 125 (RBF)
|Segregated Witness (SegWit) is a soft-fork upgrade to Bitcoin which was activated in 2017. SegWit fixed the problem of transaction malleability, wherein a transaction could have several possible txids. This upgrade paved the way for the implementation of the Lightning Network, and will open the door for several future upgrades, including Taproot.
SegWit also allowed more transactions to be included in a single block, which eased fee pressure and provided a partial scaling solution.
One of the most noticeable changes introduced by SegWit was the switch from using Base58 encoding to Bech32 encoding.
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 the Script Witness, which resides in the Witness section. The Witness of each transaction is still stored on the blockchain, but only by nodes whose version includes SegWit.
Because the Witness is not included in the main body of a transaction, it does not affect the txid. However, in order to ensure that the Witness of a transaction cannot be altered after its inclusion in a block, a separate Witness txid (wtxid) is calculated. This wtxid includes the Witness and a Merkle tree of wtxids are recorded in an output of each block’s coinbase transaction.
|SHA-256 is a cryptographic hash function. A cryptographic hash function has a few key properties. It takes an input, called a preimage, and produces an output of a fixed length—all SHA-256 outputs are 256 bits long. This process is deterministic, meaning a given input will produce the exact same output every time. Hash functions are also unpredictable: the slightest change to an input yields an entirely different output, such that it is infeasible to craft a desired output or calculate an input based on the outputs. SHA-256 is a member of a family of hash functions called Secure Hashing Algorithm (SHA) functions.
The Bitcoin protocol uses SHA-256 to derive transaction IDs (txids), block hashes, addresses, and Merkle trees. Occasionally, SHA-256 is applied twice, as in the case of txids.
Simplified Payment Verification (SPV)
|Simplified Payment Verification (SPV) is a term used to describe software which queries other nodes for new blocks and transactions but does not store the blockchain itself, like a node. An SPV client is a form of light client described by Satoshi Nakamoto in the whitepaper.
The purpose of SPV is to afford users a trust-minimized way of examining the blockchain without the inconvenience of running a node. SPV clients do trust the nodes through which they query the blockchain, but the ability to abuse this trust is extremely limited thanks to the cryptographic security of Merkle trees and the presence of other nodes.
User-Activated Soft Fork (UASF)
|A User-Activated Soft Fork (UASF) is an update or change to the Bitcoin network’s protocol initiated by users or nodes, who integrate new code into their Bitcoin implementations and demonstrate their acceptance of the change so that miners and other users can implement the same changes knowing they will maintain consensus. Since the update is a soft fork, updating is not required because the changes to the protocol are backwards compatible. If a node does not update, they are not harmed at all.
|The UTXO set is the comprehensive set of all UTXOs existing at a given point in time. The sum of the amounts of each UTXO in this set is the total supply of existing bitcoin at that point of time. Bitcoin is special as a money in that anyone can verify the total supply at any time in a trustless manner. All nodes maintain identical copies of the UTXO set. When a new block is created, the UTXO set is updated as some UTXOs were spent and new ones were created. The UTXO set is also important because it allows all nodes in the Bitcoin network to detect and reject attempted double spends, wherein someone attempts to spend the same bitcoin twice. Nodes must store the entire UTXO at all times in order to determine which bitcoin exist, and thus can be spent, at any given point in time.
|A vByte is a unit of measure for the weight of blocks and transactions. The vByte was introduced by the SegWit upgrade. A vByte is equivalent to 4 weight units, and thus, a block is limited to being 1 vMegabyte large, or 4 million weight units. Wallets usually calculate and display transaction fees in terms of sats/vByte, meaning the fee is paid per vByte of data used. Thus, the larger the transaction, the larger the total fee must be to ensure the desired speed of verification. This setup also makes SegWit transactions cheaper than regular transactions, as a byte of Witness data is only equivalent to 1 weight unit (1/4 vByte), while a byte of non-Witness data is 4 weight units (1 vByte).
コンテンツの著作権は River Financial に帰属します。二次利用の可否は権利者にご確認ください。 / All rights reserved to River Financial.