Bitcoin Wiki - User contributions [en]

Multisignature transaction

2022-04-26T01:58:17Z

Todd Price:

Multi-Signature Transactions requires multiple participants to sign a [[transaction]] with their [[private key]] rather than just one.

Multisignature transactions differ from [[threshold signature]]s in that they require m/n complete [[digital signature]]s, whereas a threshold signature scheme requires m/n partial fragments of a digital signature be added together in a [[multi-party computation]].

Multisignature transaction

2022-04-26T01:57:57Z

Todd Price:

Multi-Signature Transactions requires multiple participants to sign a [[transaction]] with their [[private key]] rather than just one.

Multisignature transactions differ from threshold signatures in that they require m/n complete [[digital signature]]s, whereas a threshold signature scheme requires m/n partial fragments of a digital signature be added together in a [[multi-party computation]].

Multisignature transaction

2022-04-26T01:57:38Z

Todd Price:

Multi-Signature Transactions requires multiple participants to sign a [[transaction]] with their [[private key]] rather than just one.

Multisignature transactions differ from threshold signatures in that they require m/n complete digital signatures, whereas a threshold signature scheme requires m/n partial fragments of a digital signature be added together in a [[multi-party computation]].

Multisignature transaction

2022-04-26T01:57:19Z

Todd Price: Created page with "Multi-Signature Transactions requires multiple participants to sign a transaction with their private key rather than just one. Multisignature transactions differ from..."

Multi-Signature Transactions requires multiple participants to sign a [[transaction]] with their [[private key]] rather than just one.

Multisignature transactions differ from threshold signatures in that they require m/n complete digital signatures, whereas a threshold signature scheme requires m/n partial fragments of a digital signature be added together in a [[multiparty computation]].

Multi-edge graph

2022-04-26T01:51:48Z

Todd Price: Created page with "A Multi-Edge Graph is a graph where there are multiple parallel edges between the same nodes. For example, multiples flights between two cities."

A Multi-Edge Graph is a [[graph]] where there are multiple parallel [[edge]]s between the same [[node(graph)|node]]s. For example, multiples flights between two cities.

Multi-party computation

2022-04-26T01:48:38Z

Todd Price: Created page with "MPC (Multi Party Computation) is a secure computation that several participants jointly execute. It requires that the number of participants who do not trust each other co..."

MPC (Multi Party Computation) is a secure computation that several participants jointly execute.

It requires that the number of participants who do not trust each other come together to jointly perform an operation over their inputs while keeping the inputs private from each other.

A threshold signature scheme or TSS is the name given to this process in the context of distributed key generation and distributed signing.

Modular arithmetic

2022-04-26T01:07:00Z

Todd Price: Created page with "Modular Arithmetic is a system of arithmetic for integers, which considers the remainder. In modular arithmetic, numbers "wrap around" upon reaching a given fixed quant..."

Modular Arithmetic is a system of arithmetic for integers, which considers the remainder.

In modular arithmetic, numbers "wrap around" upon reaching a given fixed quantity (this given quantity is known as the modulus) to leave a remainder.

It can be though of as a clock face with the modulus amount of numbers on it. The modulus of n will be the value that you find if you wrapped around the clock values n times.

Metanet Protocol

2022-04-26T01:00:12Z

Todd Price:

[[File:Metanet_graph.png|thumb|A typical Metanet graph.]]

The '''Metanet Protocol''' is a layer-2 overlay protocol that defines a method for creating data structure over Bitcoin SV. The protocol utilises [[Metanet_Protocol#Node and Edge Structure|nodes and edges]] to specify directed acyclic graph (DAG) data structures on the Bitcoin SV ledger. The Metanet protocol can be used to construct diverse systems such as file systems, internet domains, ownership structures and code repositories.

There are tools available to write and read Metanet graphs, and a growing range of projects that use the Metanet protocol to structure their application data.

==Node and Edge Structure==

The Metanet Protocol (MNP) is a protocol for creating graph structures comprising nodes and edges on the ledger. In the Metanet protocol the following definitions of node and edge are used:

* '''Metanet Node''' - A transaction using the Metanet protocol format.
* '''Metanet Edge''' - An input signature linking two Metanet nodes.

A Metanet node is a transaction that conforms to the Metanet transaction format specified in [https://bitcoinsv.io/wp-content/uploads/2020/10/The-Metanet-Technical-Summary-v1.0.pdf Metanet technical summary] document produced by nChain. The basic components of a Metanet transaction include a protocol flag, Metanet-specific data attributes, and any content data that is to be stored by a Metanet node transaction.

The protocol flag is a 4-byte [[hexadecimal]] prefix that signifies that a transaction is using the format of the Metanet protocol. The hexadecimal value of the prefix was chosen to be the hexademical encoding 0x4d455441 of the string 'meta' by [https://twitter.com/BitcoinAssn/status/1136232235798016001?s=20 public poll] on June 5th 2019.

The Metanet-specific data attributes of a Metanet node transaction include the following:

* '''<math>P_{node}</math>''' - the public key defining the node.
* '''<math>TxID_{node}</math>''' - the unique transaction ID of the node.
* '''<math>P_{parent}</math>''' - the public key defining a parent of the node.
* '''<math>SigP_{parent}</math>''' - a signature created using the private key associated with the public key defining a parent of the node.
* '''<math>TxID_{parent}</math>''' - the unique transaction ID of the parent of the node.

The Metanet-specific data attributes listed above are used collectively to define a Metanet node and its position within a larger graph structure of multiple Metanet nodes, known as a ''Metanet graph''.

It is possible that a node does not have any parents and such a node is termed a ''root node''. A root node will have null values for any <math>P_{parent}</math>, <math>SigP_{parent}</math>, and <math>TxID_{parent}</math> attributes, and can therefore use a valid signature from any public key in its input(s).

A Metanet transaction is defined as a transaction that contains an OP_FALSE OP_RETURN payload containing:

* The Metanet flag
[[File:Metanet_node.png|thumb|A Metanet node transaction.]]
* A node public key '''<math>P_{node}</math>'''
* A parent transaction ID '''<math>TxID_{parent}</math>''' (null if a root node).

In order to qualify as a Metanet-valid node, the transaction must also be signed by the public key corresponding to its parent '''<math>P_{parent}</math>'''.

Any content data and its encoding can be included following these core Metanet attributes in the OP_FALSE OP_RETURN payload. The Metanet protocol does not specify the use of any one scheme for content data and additional attributes, and any valued usage of the Metanet protocol attributes above constitute a Metanet node transaction.

A basic example of a Metanet node transaction that conforms to this format is shown in the diagram on the right.

The Metanet graph is formed by creating edges between parent Metanet nodes and child Metanet nodes. An edge is created between a parent and child by the creation and insertion of the signature '''<math>SigP_{parent}</math>''' in the child node, using the parent public key. [[File:Metanet_edge.png|thumb|The creation of a Metanet edge.]]

The fact that this signature is in a transaction input means that the signature itself may be validated by Miners. This means that attempts to spoof a Metanet node can be mitigated either by validating the signature explicitly or by confirming that the node is spending an appropriate previous output.

== Rules of the Metanet Protocol==

The Metanet protocol specifies a simple and extensible rule set for creating Metanet graphs and data structures. The base rule set is the following:

* Nodes are transactions.
* Edges are created by signatures.
* Each node is uniquely identified by the pair of attributes: '''<math>P_{node}</math>''', '''<math>TxID_{node}</math>'''.
* Each node must specify the node ID of itself and its parent: '''<math>ID_{node}</math>''', '''<math>ID_{parent}</math>'''.

The unique node identifier for a node is defined mathematically as '''<math>H(P_{node}||TxID_{node})</math>''', where '''<math>H()</math>''' is a cryptographic hash function.

Metanet graph structures may be created using this base rule set alone. It is also possible to impose additional rules to Metanet graph structures to achieve different properties for data structures.

A simple extension of the rule set is to impose the following [[constraint]]s:
[[File:Metanet_rules.png|thumb|A simple Metanet rule set.]]

* The in-degree of a node should be 0 (no parent) or 1 (one parent).
* The out-degree of a node should be a free parameter.

These additional rules allow domain-like structures to emerge as Metanet DAGs, which can be used to structure websites and file systems which inherit the permission structure of a Metanet graph.

Mnemonic

2022-04-26T00:54:01Z

Todd Price: Created page with "Assisting or intended to assist memory. A mnemonic will reduce a complex system to a simpler form like a rhyme or formula."

Assisting or intended to assist memory. A mnemonic will reduce a complex system to a simpler form like a rhyme or formula.

Brainwallet

2022-04-26T00:53:46Z

Todd Price:

Brainwallets are like the mnemonic seeds generated by hardware wallets, however, the human user generates the words themselves and memorises them without any written record.

The [[mnemonic]] seed/ passphrase is never written down. It is 'stored' in the holder's brain.

If the holder forgets the passphrase (or becomes incapacitated), the money is likely lost forever - not a very secure storage method.

Creating randomness in passphrase words is extremely difficult to do by hand, therefore security is again compromised.

It is possible to use a [[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP 39]] passphrase generator to get strong entropy/ randomness and optionally add a salt value for additional security, however storing anything in the human brain carries inherent risks.

Use a brainwallet at your own (high) risk.

For a detailed tutorial on complex brainwallet creation, see [https://craigwright.net/blog/bitcoin-blockchain-tech/how-to-make-a-brain-wallet/ this] article by [https://craigwright.net/about/#biography Dr Craig Wright].

Mining pool

2022-04-26T00:48:44Z

Todd Price:

A Mining Pool is a system of distributed hashing machines that are operating under instruction from a coordinating node to solve the proof of work hash puzzle.

The coordinating node delegates the work they are to perform in the form of a [[mining candidate]] and broadcasts the correct solution to other nodes on the network if one is found.

Mining pool

2022-04-26T00:48:28Z

Todd Price: Created page with "A Mining Pool is a system of distributed hashing machines that are operating under instruction from a coordinating node to solve the proof of work hash puzzle. The coordinat..."

A Mining Pool is a system of distributed hashing machines that are operating under instruction from a coordinating node to solve the proof of work hash puzzle.

The coordinating node delegates the work they are to perform in the form of a [[mining template]] and broadcasts the correct solution to other nodes on the network if one is found.

Difficulty

2022-04-26T00:47:25Z

Todd Price:

''See also: [[Target]]''

=== What is difficulty? ===

Difficulty is a measure of how difficult it is to find a hash below a given [[target]]. Difficulty answers the question: "how many times more difficult is it to mine a block now, compared with how difficult it was to mine the [[Genesis block|Genesis Block]]?". It has a close relationship with target but is not the same thing. Rather it has an inverse relationship where a higher difficulty implies a lower target value.

The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target.
[[Mining pool]]s also have a pool-specific share difficulty setting a lower limit for shares.

=== How often does the network difficulty change? ===

See [[Target|target]].

=== What is the formula for difficulty? ===
difficulty = difficulty_1_target / current_target

''target is a 256 bit [[big number]]''

''difficulty_1_target is the target used in the Genesis Block and represents a difficulty of 1.''

difficulty_1_target can be different for various ways to measure difficulty.
Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff").
The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (known as "bdiff").

===How is difficulty stored in blocks?===

Each block stores a packed representation in its block header (called [[Block hashing algorithm|Bits]]) for its actual [[hexadecimal]] [[target]]. The target can be derived from Bits via a predefined formula. For example, if the packed target in the block is 0x1b0404cb, the hexadecimal target is:
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff. To make a larger value you must shift it down one full byte. Also 0x008000 is the smallest positive valid value.

===How is difficulty calculated? What is the difference between bdiff and pdiff?===

The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

It should be noted that pooled mining often uses non-truncated targets, which puts "pool difficulty 1" at
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

So the difficulty at 0x1b0404cb is therefore:
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983 (bdiff)
And:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.669773817162 (pdiff)

Here's a fast way to calculate Bitcoin difficulty. It uses a modified Taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:

<source lang="cpp">
#include <iostream>
#include <cmath>

inline float fast_log(float val)
{
int * const exp_ptr = reinterpret_cast <int *>(&val);
int x = *exp_ptr;
const int log_2 = ((x >> 23) & 255) - 128;
x &= ~(255 << 23);
x += 127 << 23;
*exp_ptr = x;

val = ((-1.0f/3) * val + 2) * val - 2.0f/3;
return ((val + log_2) * 0.69314718f);
}

float difficulty(unsigned int bits)
{
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));
}

int main()
{
std::cout << difficulty(0x1b0404cb) << std::endl;
return 0;
}
</source>

To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:

<source lang="python">
import decimal, math
l = math.log
e = math.e

print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)
</source>

=== What is the current difficulty? ===
[https://whatsonchain.com/ Current difficulty]

=== What is the maximum difficulty? ===

There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).

The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately, it never will, so we're ok.)

In the case of Bitcoin (BSV) and Bitcoin Cash (BCH), the network's difficulty can rise by a maximum of 100% of the current difficulty in a single adjustment.

In the original implementation, still used by Bitcoin Core (BTC), the difficulty can rise by a maximum of 400% of the current difficulty in a single adjustment.

=== Can the network difficulty decrease? ===
Yes it can. See discussion in [[target]].

In the case of Bitcoin (BSV) and Bitcoin Cash (BCH), the network's difficulty can adjust downwards by up to 50% of the current difficulty in a single adjustment.

In the original implementation, still used by Bitcoin Core (BTC), the network's difficulty can adjust downwards by up to 75% of the current difficulty in a single adjustment.

=== What is the minimum difficulty? ===
The minimum difficulty, when the target is at the maximum allowed value, is 1. This is the difficulty of the [[Genesis block]].

=== What network hash rate results in a given difficulty? ===
The difficulty is adjusted every 2016 blocks based on the [[Block_timestamp|time]] it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty, is in proportion to the amount of time over or under two weeks, the previous 2016 blocks took to find.

To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is
0xffff * 2**208
and for difficulty D is
(0xffff * 2**208)/D

The expected number of hashes we need to calculate to find a block with difficulty D is therefore
D * 2**256 / (0xffff * 2**208)
or just
D * 2**48 / 0xffff

The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was
D * 2**48 / 0xffff / 600
over the previous 2016 blocks. This can be further simplified to
D * 2**32 / 600
without much loss of accuracy.

At difficulty 1, that is around 7 Mhashes per second.

At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found, the average network hash rate was
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.

==Related Links==

* See also: [[Target]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Difficulty under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Mining candidate

2022-04-26T00:41:47Z

Todd Price: Created page with "The Mining Candidate is the specified values of the block header's data fields which a node relays to the hashing machines for them to increment the nonce against for the proo..."

The Mining Candidate is the specified values of the block header's data fields which a node relays to the hashing machines for them to increment the nonce against for the proof-of-work process.

Getminingcandidate

2022-04-26T00:40:30Z

Todd Price:

''getminingcandidate'' or GMC is a Remote Procedure Call (RPC) available in the Bitcoin SV node software.

Its purpose is to provide mining software/pools with a suitable block [[Mining candidate|candidate]] for hashing in order to mine a block. In addition it is greatly decoupled from block size unlike its predecessor [https://wiki.bitcoinsv.io/index.php/GetBlockTemplate_interface GetBlockTemplate], meaning it can scale and support very large block sizes.

The way it supports blocks of very large sizes is by only providing a minimal set of data required for mining hardware to hash and generate a possible block solution. If a blocksolution is found it can be returned to the node software via the sibling RPC call ''submitminingsolution''.

GMCs predecessor ''getblocktemplate'' gave the call mining software more control, but in order to do this, it had to provide a full and complete dataset of the current block and pending transactions in the mempool. A Miner trying to mine large blocks must put a lot more strain on both the node software and RPC interface to transmit a record of every transaction that is in the mempool, often resulting in lack of memory and/or performance issues.

GMC removes this issue by only providing the mining software with a merkle proof of included transactions, rather than a complete listing, this lowers the amount of data to be produced and transmitted to log2(blocksize).

When the node software receives a GMC request it will respond with a [https://www.json.org/json-en.html JSON] representation of the current block candidate. A description of this response body is shown below.

===Response body of getminingcandidate===
<table>
<tr>
<th align="center">Variable</th>
<th align="center">Description</th>
</tr>
<tr>
<td align="center">[uuid] id</td>
<td align="center">The assigned id from Bitcoind. This must be provided with submitting a potential solution</td>
</tr>
<tr>
<td align="center">[hex string] prevHash</td>
<td align="center">Big Endian hash of the previous block</td>
</tr>
<tr>
<td align="center">[hex string] Coinbase (optional)</td>
<td align="center">Suggested coinbase transaction is provided. Miner is free to supply their own or alter the supplied one. Altering will require parsing and splitting the coinbase in order to splice in/out data as required. Requires Wallet to be enabled. Only returned when provide_coinbase_tx argument is set to true. Returns error if Wallet is not enabled</td>
</tr>
<tr>
<td align="center">[int32_t] version</td>
<td align="center">The block version</td>
</tr>
<tr>
<td align="center">[int64_t] coinbaseValue</td>
<td align="center">Total funds available for the coinbase tx (in Satoshis)</td>
</tr>
<tr>
<td align="center">[uint32_t] nBits</td>
<td align="center">Compressed hexadecimal difficulty</td>
</tr>
<tr>
<td align="center">[uint32_t] time</td>
<td align="center">Current block time</td>
</tr>
<tr>
<td align="center">[int] height</td>
<td align="center">The candidate block height</td>
</tr>
<tr>
<td align="center">[array] merkleProof</td>
<td align="center">Merkle branch/path for the block, used to calculate the [[Merkle root]] of the block candidate. This is a list of Little-Endian hex strings ordered from top to bottom</td>
</tr>
</table>

For a more technical breakdown of ''GetMiningCandidate'' and its implementation, see the protocol spec [https://github.com/bitcoin-sv-specs/protocol/blob/master/rpc/GetMiningCandidate.md here]

Minimum fee policy

2022-04-26T00:37:42Z

Todd Price: Created page with "The Minimum Fee Policy specifies a minimum fee for which a node will accept and or relay unconfirmed transactions. This rule is set differently by each node."

The Minimum Fee Policy specifies a minimum fee for which a node will accept and or relay unconfirmed transactions.

This rule is set differently by each node.

Micropayment

2022-04-26T00:34:49Z

Todd Price: Created page with "Micropayments are small transactions of a value less than a dollar but that may even be fractions of a cent. Fraction of a cent payments are sometimes referred to as nanopay..."

Micropayments are small transactions of a value less than a dollar but that may even be fractions of a cent. Fraction of a cent payments are sometimes referred to as [[nanopayments]].

Until Bitcoin, these transactions were typically too low to be offered by traditional payment processors.

Main Page

2022-04-26T00:33:21Z

Todd Price:

Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.

===Bitcoin===

'''Bitcoin''' is a peer to peer electronic cash system created by [https://craigwright.net/ Dr. Craig Wright] under the pseudonym [[Satoshi Nakamoto]]. It was first detailed in the [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.

Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds.

The leaderless structure of the network is viewed as a resolution to [[The Byzantine Generals Problem]] allowing disconnected entities to follow a common direction without centralised instruction. This solves several issues previously seen as unsolvable in distributed networks, including the problem of preventing [[Double-spending]] of coins.

===Applications===
Bitcoin is primarily a [[Payments in Bitcoin|payment system]] which supports peer to peer connection and [[Instant Transactions]]. Early in the [[History of Bitcoin]] payments required users to understand complicated technical details of Bitcoin's technological underpinnings to make transactions. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect and leverage the blockchain for the [[back-end]] of their applications.

Bitcoin also supports the development of [[Application layer protocol|application layer protocols]] which make use of [[Bitcoin Transactions]] as a transport layer for information exchange. Several Application layer protocols already exist for BitcoinSV - for more detail see [[Building on Bitcoin]]. [[The Metanet]] fuses Bitcoin's highly secure and instant [[Transaction fees|sub-cent transactions]] with onchain data storage and transferability enabling efficient and secure web usage. This will bring forth an Internet of Value where [[Micropayment]]s become a means to both access and monetize data.

Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[False Return]] scripts and other scripts that use [[Pushdata Opcodes]] to push data into Bitcoin transactions are creating new ways of recording data for public consumption. Bitcoin acts as a [[Timechain|timestamp server]] allowing data to be validated and referenced using transactions.

===Network===
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient.

Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].

===The Ledger===
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to the network. The ledger is formed as a [[wikipedia:Directed Acyclic Graph|Directed Acyclic Graph]] (DAG) where each transaction is a node. The graph starts at the [[Coinbase]] transaction of the [[Genesis block|first block ever found]] and via chains of [[Digital Signatures in Bitcoin|digital signatures]] maps out the entire history of valid exchange actions, allowing the tracing of all bitcoins back to their creation.

<div class="img-responsive">
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]
</div>

Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which [[compress]] the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.

Blocks form a second layer DAG called the [[Blockchain]] which is built by [[Mining|network miners]] in a competitive process. Each block forms a node in the graph with a single incoming edge from the block it is built upon. A block may have more than one outgoing edge in a case where multiple blocks were built upon it, but only one of those edges can become part of the longest chain of proof of work. A block without an edge to the longest chain of proof of work is called an [[Orphan Block]].

<div class="img-responsive">
[[File:Block_Chain.png|centre|alt=A chain of blocks]]
</div>

The structure of the block chain DAG means that there is a clearly traceable path back to the [[Genesis block|first block mined]]. Blocks are discovered just under every 10 minutes on average, with miners using a predefined mathematical algorithm to control the [[difficulty]] of the proof of work process to maintain that time frame.

Transactions can be exchanged peer to peer using [[Simplified Payment Verification]] (SPV) to manage trust. SPV involves sending accompanying information with a transaction input that proves it is from a transaction that has been timestamped on the ledger.

<div class="img-responsive">
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]
</div>

Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].
Payment channels allow users to conduct information exchange within valid Bitcoin transactions, only broadcasting a finalised transaction including the full value exchange to the mining network once the information transfer is complete.

Once a transactions is sent to the network, global consensus can be reached on the validity in less than 2 seconds. If a transaction is not accepted by any miners and added to a block template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.

===Transactions===
All [[Bitcoin Transactions]] are [[Payments in Bitcoin|payments]] of some kind. Transactions are written in a flexible [[Advanced_Bitcoin_Scripting|scripting language]] that is used to assign custodial control to each transaction [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.

Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.

<div class="img-responsive">
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]
</div>

The Bitcoin scripting language is [[wikipedia:Turing_completeness|Turing complete]], and can be used to create [[wikipedia:Turing_machine|Turing machines]] that use the Bitcoin ledger as a tape, writing to and reading from the transaction graph as needed.

The scripting language also includes opcodes that allow users to embed arbitrary data in transactions, providing for the creation of [[Application layer protocol|application layer protocols]] that use Bitcoin transactions as a [[wikipedia:Transport layer|transport layer]].

Rewards paid to miners for the creation of a block are inscribed in what is called a [[Coinbase]] transaction. This transaction has a specific format and is always the first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].

===Nodes and Mining===
The ledger is held on a [https://en.wikipedia.org/wiki/Distributed_networking distributed network] of nodes who use hash based [[Proof of Work]] to compete for the right to extend it and as a means to enforce network rules. The proof of work of each block in the longest chain of work is incorporated into its subsequent block to form the chain structure.

<div class="img-responsive">
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]
</div>

During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis and evaluates whether they are profitable to mine before putting them into a block template. Block templates are created by calculating the root of a [https://en.wikipedia.org/wiki/Merkle_tree Merkle tree] containing all of the transactions being mined. The order of transactions in the Merkle tree is not related to their position in the transaction DAG. As new transactions arrive, they are added to the tree, creating a new, updated template. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. A block is found when a miner successfully discovers a value that generates a hash less than the [[difficulty]] [[target]]. The miner must then propagate the new block to the rest of the network who must then build an additional 100 blocks on top of it before the winner can claim the block reward.

[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]

Nodes are operated by the [[Mining|Bitcoin mining enterprises]] who build the network. Bitcoin's economic incentives are structured such that for the nodes to be most profitable at building the ledger they must be as closely connected to other well performing nodes as possible. This leads to miners forming a [[Small World Network]] which trends towards a [[Nearly Complete Graph]] where each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].

As Bitcoin scales, the nodes who comprise the network will be variously compartmentalised into specialised hardware. These clustered systems will be distributed globally, each being placed in a location optimised for its task.

As enterprise organisations, Bitcoin miners must operate as legal entities within a given jurisdiction and as such are bound to the laws and legal processes that exist in that jurisdiction. Through this, miners can be compelled to enact certain rules or perform certain actions in order to comply with the law.

===Unit of account===
[[Satoshis]] are the ledger's native unit of account and 100,000,000 satoshis is abstracted to one bitcoin. Satoshis are held in script puzzles called [[UTXO|Unspent Transaction Outputs or UTXOs]]. These are [[VOUT|transaction outputs]] which are held by miners in a quick access database called the UTXO set. During the spending process, UTXOs being used in a transaction are consumed and the solution to their puzzle script is recorded in the transaction.

Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, the subsidy dissipates forcing the miners to find alternate revenue streams. The payment allows miners to finance their operations through the payment of goods and services in bitcoin, spreading it through the economy.

===Network rules===
Bitcoin operates on a fixed ruleset. So-called consensus rules include things such as the operation of the [[Opcodes used in Bitcoin Script|opcodes]] in Bitcoin Script, the rate at which new bitcoins are issued, the mathematical function used to calculate the [[target]] for the [[Difficulty]] algorithm and more. The protocol is agreed upon by the miners who control network operation.

There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed are put in place by miners who are incentivised to catch the largest profitable pools of transactions they can. Miners compete to offer better service to fee paying users by scaling their own capabilities.

===History===
[[Bitcoin until today|Bitcoin has a rich history]].

===Tools and Building on Bitcoin===
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.

The Metanet

2022-04-26T00:32:55Z

Todd Price:

[[File:post.png|thumb|The Metanet Ecosystem]]
'''The Metanet''' is the term given to a value-based internet built on the Bitcoin SV ledger. The Metanet can be used to refer to either of:

* The concept of value-based internet built on [[Main_Page|Bitcoin SV]].
* The [[Metanet_Protocol|Metanet Protocol]].

The Metanet was first [https://www.youtube.com/watch?v=MXpHHZqe6vI announced] as a concept by Dr. Craig Wright at the CoinGeek Week conference in London, on November 30th 2018.

The motivation for the Metanet, is the creation of a public ledger based internet that functions as an efficient value network, which has improved properties and [[The_Metanet#Capabilities|capabilities]] compared to the existing infrastructure of the Internet. The Metanet as a concept has since been widely adopted by the Bitcoin SV ecosystem and many protocols and applications have been built to implement the vision of a highly-connected internet for peer-to-peer content creation and monetisation.

==Core Principles==

The motivations for the Metanet are linked to well-known problems with the existing Internet and e-commerce, which include the following:

* Reliance on intermediaries for payments.
* Lack of a granular [[micropayment]] layer.
* Walled-garden applications and data silos.
* Concerns over data privacy and ownership for users.
* Prevalence of spam, trolling and bots in online social platforms.

The first two issues, relating to payment intermediaries and lack of micropayments, are addressed by the use of the Bitcoin SV network for simple payments. The Metanet aims to solve the remaining issues by combining online payments with [[immutable]] data stored on the Bitcoin SV public ledger.

The combination of payments and data both using the Bitcoin SV ledger as a universal source of truth, theoretically allow for a more equitable internet ecosystem in which:

* Information is attributed value.
* Quality is incentivised over quantity.
* The cost of dishonest behaviour (e.g. trolling) is increased.
* Users own their data.

==The Metanet Protocol==
[[File:Metanet_DAG.png|thumb|The Metanet Protocol]]

The [[Metanet_Protocol|Metanet protocol]] is a protocol for structuring data within the on-chain internet architecture of the Metanet. The Metanet protocol uses a graph data model to create on-chain data structures for Metanet applications, websites and use cases. The protocol allows users to store, distribute and monetise their data using its native permissions framework.

The Metanet protocol is a graph-based data structure protocol. The protocol uses the native directed acyclic graph (DAG) data model of the underlying Bitcoin SV ledger to create overlay DAG structures that exist natively within the ledger's own structure. The nature of digital signatures and transactions ensures there is a directionality to the edges between vertices in contrast to an [[acyclic graph]].

Metadata

2022-04-25T05:50:58Z

Todd Price: Created page with "Metadata is "data that provides information about other data", but not the content of the data, such as the text of a message or the image itself."

Metadata is "data that provides information about other data", but not the content of the data, such as the text of a message or the image itself.

MinerID

2022-04-25T05:50:05Z

Todd Price:

MinerId is a protocol that allows a Miner to embed information inside the [[Coinbase|coinbase transaction]] of each block won by a particular node, to allow all blocks it wins to be associated with a pseudonymous identity which the Miner can optionally associate with a real world identity.

==Description==

Currently, Bitcoin Miners can embed identity data on the Bitcoin ledger by using space in the malleable input fields of the [[Coinbase|coinbase]] transaction in blocks that they mine. However, this data is not always accurate and can be trivially forged/spoofed.

The MinerId protocol provides a way of ''cryptographically'' associating a block to a specific Miner's pseudo identity. A minerId is simply a public key from an ECDSA keypair. These keys are used to sign minerID [[metadata]] contained in a [[False Return]] output of the coinbase transaction in a block.

Use of ECDSA cryptography to sign minerId metadata (as opposed to generating unsigned arbitrary data) provides data non-repudiation, linking Miner identity to mined blocks in a reliable way.

Whilst the minerId protocol is a useful infrastructure tool for the Bitcoin SV network, '''it is not mandatory'''. It is a voluntary protocol providing a public key infrastructure for Bitcoin SV that Miners can use to secure additional services around the ledger.

===Definitions===

* '''MinerId''' - An ECDSA public key (based on [[secp256k1]] parameters) used by the Miner to identify themselves.
* '''VcTx''' - (Validity check transaction) A transaction that determines the validity of the minerId based on whether it is unspent (valid) or spent (invalid/revoked). The VcTx is a feature that allows a Miner to instantly revoke their minerId (if the private key is compromised for example). Naively, the Miner could add a field in the coinbase document specifying if the minerId is still valid or not. However, by doing that, the Miner would have to wait until they mine a block to revoke their minerId key. Using the VcTx, the Miner can at any time revoke the validity of their minerId key without needing to generate [[Proof of Work|proof of work]].
* '''Coinbase document''' - A formatted data packet in the OP_RETURN (provably unspendable) output in the Miner’s [[Coinbase| coinbase transaction]]. All Miner identity information is stored in this document.

===Security===

Ideally, the minerId (by extension of the coinbase transaction) should be specific to the block it is in. However, if this were enforced, it would create a causality dilemma (chicken/egg scenario) since the header cannot be finalised and signed by the minerId key without the hash of the coinbase transaction, which in turn, cannot be created until the minerId key is finalised.

By making the minerId specific to the block it’s mined in, we effectively bind the signature to the block it’s contained in. Without this binding, a malicious Miner could take the entire coinbase document and replay it in another block, potentially in a block that damages reputation e.g. an empty block that reduces network throughput. Because the block height is included in the coinbase document, the cost of replaying coinbase document data becomes as difficult as successfully forking the network (see [[Re-org]]), which is very expensive. This cost should be enough to drastically reduce the likelihood of this attack.

==Examples==

The minerId protocol has been supported by TAAL mining ltd. since 20th December 2019.

* https://whatsonchain.com/tx/17a8b9994f1e89855b34660ea1d17061ae65833f1ded395c4c6a72d2d98832a6

* https://whatsonchain.com/tx/d898e7f3c198cefccf99e6ec982786f25af62aa86d6bc56c66a611660bf04942

==See Also==

* Medium.com blog post - https://medium.com/@jadwahab/6578046ac88?

Block Explorer

2022-04-25T05:49:50Z

Todd Price:

A Block Explorer is an application that allows users to view and query data stored on the BitcoinSV ledger and network. Typically accessed through a web browser, Block Explorers allow users to view details of Bitcoin [[Block|blocks]], [[transactions]] and [[Address|addresses]]. Their primary function is to allow users to track network activity in real-time.

==Structure==
The structure of a typical Block Explorer is to have a mining client with a front end that pulls data from its own copy of the [[blockchain]] and presents it to users through a web interface.

In future it is expected that Block Explorers will develop their own tooling and client that can detect additional information that is not typically monitored by a mining client such as the emergence of a block race, transactions which the node is not set up to validate and more.

Real time information on both blocks and transactions is typically provided in addition to other information such as the history of a given Bitcoin address or a list of transactions containing particular [[metadata]].

===Block information===
The explorer provides data on all blocks that have been added to the ledger, and are usually updated within seconds of a valid block being discovered. This data shows:
*'''Block height:''' Number of blocks since the Bitcoin [[Genesis block]] was mined
*'''Age:''' Elapsed time between now and the timestamp that indicates when the block was discovered
*'''Transaction Count:''' number of transactions included in the block
*'''Fees:''' Aggregate value of all [[Transaction fees]] paid to the Miner by users
*'''Reward:''' Total Miner reward including transaction fees and [[block subsidy]]
*'''Mined by:''' Identity of the Miner or mining pool whose node mined this block
*'''Size:''' Size of the block as obtained by adding the sizes of each transactions included in the block

===Real time Transaction information===
In addition, the Block Explorer provides a full set of information regarding transactions that have either been mined into a block, or accepted into the Block Explorer's node client's mempool.

*'''[[Block]]:''' The hash of the block in which the transaction was mined (if the transaction has not yet been mined, the confirmation field is typically not shown)
*'''Status:''' If a transaction isn't mined, this field may show the transaction as '''Unconfirmed'''
*'''[[Block timestamp|Timestamp]]:''' The timestamp in the block header in which this transaction was mined (if the transaction has not yet been mined, the timestamp field is typically not shown)
*'''Version:''' The version of the protocol against which this transaction is to be validated
*'''Size:''' The size of the serialised transaction in bytes
*'''[[Confirmation|Confirmations]]:''' The number of blocks mined on top of the block containing the transaction (if the transaction has not yet been mined, the confirmation field is typically not shown)
*'''[[Transaction fees|Fee Paid]]:''' The total transaction fee paid by the spending party
*'''Fee Rate:''' The transaction fees paid by the spending party as a ratio of Satoshis/Byte which is the total fee paid divided by the size of the transaction
*'''[[Coinbase|Coinbase data]]:''' If the transaction is the coinbase transaction of a block, the explorer will typically show the coinbase text that the Miner has embedded in the transaction

In addition to these fields, the explorer will usually include other information about the transaction including the number of inputs and outputs, the values of those inputs and outputs, the scripts used to spend the inputs, and the new scripts created in the outputs. Most explorers will also offer the user different ways to view this information such as raw hex, interpreted Bitcoin script or in [[wikipedia:JSON|JSON]] format.

==Searchable Information==

The main function of Block Explorers is to allow users to search for data in the Bitcoin ledger and [[blockchain]]. This is typically performed using a search tool.

Typical search functions include:
* Transaction hash or [[TXID]]
* Block height
* Block hash
* [[Bitcoin address]]
* Transaction metadata

Typically, the explorer responds to a search with a page containing all the details about the subject of a search request.

==List of BitcoinSV explorers==
* https://whatsonchain.com
* https://bitcoinblocks.live
* https://blockchair.com
* https://coin.dance

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Block_chain_browser under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Merkle proof

2022-04-25T05:48:45Z

Todd Price:

A Merkle proof is the act of verifying an element exists within a set summarised by the [[Merkle root]].

The data element is hashed to create its [[leaf (node)|leaf node]] value, and then hashed with a provided set of the adjunct node values along the [[Merkle path]] back to the root.

If the same Merkle root is created as has been published previous, then it stands that the data element is be guaranteed to come from the same [[index]] in the same data set as in the earlier published instance.

For more information on the Standardised format for a Merkle proof see the published standard by the Technical Standards Committee here: https://tsc.bitcoinassociation.net/standards/merkle-proof-standardised-format/

Merkle proof

2022-04-25T05:48:11Z

Todd Price:

A Merkle proof is the act of verifying an element exists within a set summarised by the [[Merkle root]].

The data element is hashed to create its [[leaf (node)|leaf node]] value, and then hashed with a provided set of the adjunct node values along the [[Merkle path]] back to the root.

If the same Merkle root is created as has been published previous, then it stands that the data element is be guaranteed to come from the same [[index]] in the same data set as in the earlier published instance.

For information on the Standardised format for a Merkle proof see the Technical Standards Committee here: https://tsc.bitcoinassociation.net/standards/merkle-proof-standardised-format/

Merkle proof

2022-04-25T05:47:50Z

Todd Price:

A Merkle proof is the act of verifying an element exists within a set summarised by the [[Merkle root]].

The data element is hashed to create its [[leaf (node)|leaf node]] value, and then hashed with a provided set of the adjunct node values along the [[Merkle path]] back to the root.

If the same Merkle root is created as has been published previous, then it stands that the data element is be guaranteed to come from the same [[index]] in the same data set as in the earlier published instance.

For information on the Standardised format for a Merkle proof see the TSC here. https://tsc.bitcoinassociation.net/standards/merkle-proof-standardised-format/

Merkle proof

2022-04-25T05:46:47Z

Todd Price:

Merkle proof

2022-04-25T05:45:34Z

Todd Price:

Merkle proof

2022-04-25T05:45:13Z

Todd Price:

A Merkle proof is the act of verifying an element exists within a set summarised by the [[Merkle root]].

The data element is hashed to create its [[leaf (node)|leaf node value]], and then hashed with a provided set of the adjunct node values along the [[Merkle path]] back to the root.

If the same Merkle root is created as has been published previous. it stands that the data element is be guaranteed to come from the data set and at the same [[index]] as it was in the earlier published instance.

Merkle proof

2022-04-25T05:44:49Z

Todd Price: Created page with "A Merkle proof is the act of verifying an element exists within a set summarised by the Merkle root. The data element is hashed to create its leaf(node)|leaf node valu..."

A Merkle proof is the act of verifying an element exists within a set summarised by the [[Merkle root]].

The data element is hashed to create its [[leaf(node)|leaf node value]], and then hashed with a provided set of the adjunct node values along the [[Merkle path]] back to the root.

If the same Merkle root is created as has been published previous. it stands that the data element is be guaranteed to come from the data set and at the same [[index]] as it was in the earlier published instance.

Coinbase

2022-04-25T04:26:38Z

Todd Price:

'''Coinbase''' is the special name given to the first transaction in every block. These can also be called 'Generation Transactions'.

The winning Miner creates this special transaction as part of the block templating process.

A coinbase transaction follows the same format as a normal transaction, except:
* It has exactly one txin.
* This txin's prevout hash is 0000...0000.
* This txin's prevout [[index]] is 0xFFFFFFFF.
* The txin's prevout script is an arbitrary byte array which has historically been used by Miners to signal identity and pass messages from block winning nodes to the rest of the network.
* The sum of the values of all txout's cannot exceed the total of the [[Miner subsidy]] and the mining fees paid by all other transactions included in the block.

A part of the coinbase can also used as an 'extra nonce' during the block discovery process due to a single ASIC Miner being able to test more combinations than allowed for, in the 2^32 possible combinations that changing the nonce in the block header can create. The extra nonce field is incremented in the Coinbase transaction, which requires that a small number of hashes in the merkle tree are updated, changing the [[Merkle root]] in the [[block header]] allowing for a further 2^32 possible block hashes to be attempted.

A Coinbase transaction can have as many outputs attached as are needed by the miner. These can be used for second layer functions including:
*[[Merchant API]], otherwise known as [[MAPI]], which allows the winning Miner to provide a dynamically accessible transaction pricing service enabling users to request pricing and transaction broadcast services from miners on the network.
*[[MinerID]] also uses the Coinbase transaction to present information to the network such as node identity, MAPI access points and more. This data will use standard formats such that user wallets shall be able to read and parse the information, giving them up-to-date knowledge of which nodes are competing on the network and more.

Due to some early problems with blocks containing only a coinbase transaction with an identical coinbase text and outputs generating coinbase transactions with identical [[TXID|TXIDs]], miners agreed through consensus to begin enforcing [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 0034] as a [[Protocol|protocol rule]]. This change mandated that the block height value be specified in the first item of the coinbase transaction. Prior to this, the coinbase script size was between 2 and 100 bytes. Currently the minimum length is 4 bytes which is needed to hold the blockheight in a [[VarInt]]. The maximum value storable in 3 bytes is 16,777,215 so with the generating blocks at a rate of approximately 59,000 per year so if this level of network activity is sustained then from approximately the year 2,300 the minimum length of a coinbase script size will need to increase to 5 bytes.

Mining

2022-04-25T04:26:10Z

Todd Price:

== Introduction ==
'''Mining''' is the process where nodes in the Bitcoin [[Network]] assemble newly broadcast [[Bitcoin Transactions]] into a data structure called a [[block]]. Nodes then compete to append their block to the public [[Blockchain]] by repeatedly mutating the block's header data structure, usually by incrementing the nonce field, then hashing it in an attempt to find a value that satisfies a difficult [[Proof of Work|proof-of-work]].

When a node finds a valid proof-of-work hash for a block, it broadcasts the block to all nodes. Other nodes accept this block only if all the transactions in it are valid and have not yet been included in a block. Other nodes in the network then express their acceptance of the block by building upon it to create the next block in the chain.

Every block is [[Block timestamp|timestamped]] and references the hash of the block preceding it. Blocks form a backward reinforcing, timestamped chain – a [[Timechain]], the precursor to the term ‘Blockchain’.

The Blockchain structures itself in a manner that is computationally and economically impractical to modify by any one entity. Due to this, transactions included in the Blockchain are considered [[immutable]]. In addition to this quality, the Blockchain establishes an authoritative order of these transactions throughout the network by establishing which, out of any pair of conflicting transactions was seen first, thereby protecting users from [[Double-spending|attempts to re-spend coins]] that have already been spent elsewhere. This is the key innovation of mining and of Bitcoin.

=== Nodes ===
Nodes are entities which run software that carries out the mining functions above. Nodes communicate using a [[P2P Network]] with its own protocol, and are the authors of the Bitcoin ledger and enforcers of the [[protocol]] rules.

Interestingly, the Bitcoin whitepaper makes no reference to the term ‘Miner’ or the concept of ‘mining’. These terms cover the actions described in section 5 of the [http://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] which describes the responsibilities of nodes on the network.

It is possible to run the node client software without performing block assembly or proof-of-work. Such a setup can be used as an interface to the network for other systems such as block explorers, payment gateways and archives. Eventually it is expected that customised client software will be developed for each of these services so they will no longer be dependent on the node client to operate.

Computers that run a node client which do not perform proof-of-work cannot append new blocks to the Blockchain. This means they can neither express acceptance of valid blocks by working on extending them, nor reject invalid blocks by refusing to work on them. These computers exist as passive entities that follow the gatekeepers of the network, the Miners.

=== Mempool ===
Before a transaction can be timestamped in the Bitcoin [[Blockchain]] it needs to be received and validated by a Miner. If the Miner deems the transaction valid, they add the transaction to one of several [[Protocol#mempool|mempools]]. Mempools are temporary transaction stores and can be used to hold transactions grouped in different ways, such as transactions to be mined in the next block, transactions to watch, or transactions which cannot be mined due to an nLocktime/nSequence lock.

It is important to note every Miner has their own mempools and that mempools vary across Miners. It is also important to note that an individual transaction can be included in different mempools at the same time.

A Miner takes the transactions it intends to include in the next block and hashes them into a [[Protocol#Merkle_Trees|merkle tree]] structure, and includes the resulting [[merkle root]] within a candidate [[block header]]. The Miner then hashes this candidate block header, attempting to find a valid proof-of-work.

=== Hashing ===
A hash is a function that converts a string of data into a fixed length value that represents the original string, called the hash value. Every hash value is unique.

Hashing is a one-way function, meaning it is infeasible to determine what the input data is by looking at the hash produced from it. Conversely, it is trivial to run the same input data through the same hash function and reproduce the same hash. Because of this, a hash value of input data can be thought of as the digital fingerprint of that data. In Bitcoin mining, the input data is the 80-byte [[Block hashing algorithm|block header]].

The hashing algorithm used in Bitcoin mining is [[SHA-256]]. SHA-256 stands for Secure Hash Algorithm – 256 bit. Passing the same block header data through this algorithm will always output the same 256-bit number. However, if the header data is modified even by a single bit, the result will be a completely different and unrelated 256-bit number.

Bitcoin mining passes the block header data through the SHA-256 algorithm twice (SHA-256d).

=== Proof-of-work ===
Bitcoin uses a [[Proof of Work]] function based on the earlier work of [[hashcash]].

A Miner cannot create a new block without finding a valid proof-of-work hash, for the block header they are hashing. To be valid, the SHA-256d hash (which is just a number) of the block header must be less than another number, called the [[target]]. The target value is defined by the [[Block hashing algorithm|Bits]] field in the block header that is being hashed.

The target adjusts so that the average time it takes for the entire network to find a valid proof-of-work hash is ten minutes.

Because of the extraordinarily large SHA-256 target space, it is extremely unlikely that any given hash will be below the target. As a result of this, hashing entities invest large amounts of capital into specialised hashing hardware, along with the associated electricity costs in order to produce as many of these hashes as possible in a given time period. Therefore, the only way a Miner can append a block to the Block chain is through a substantial commitment of operational expenditure – proof-of-work.

=== Incentive ===
The first transaction in every block is called the [[Coinbase]] transaction. The Coinbase transaction is a special transaction which pays bitcoins to the Miner of the block. The Coinbase payment is made up of the [[Miner subsidy|subsidy]] amount and the sum of all [[transaction fees]] paid by transactions within the mined block.

== Competition ==

=== Propagation and validation ===
If a Miner finds a valid proof-of-work for the block header they are hashing, they immediately announce this by sending the entire block to other Miners. Meanwhile, they start working on finding the next block in the chain.

Competing Miners receive this block and immediately check that all transactions within the block, as well as the proof-of-work are valid. If the block is valid, they discontinue mining on top of the previous block and start working on hashing a new block header, building on the block just found by their competitor.

There are incentives at play here. First, winning 'Miner A' strives to get their winning block to all other Miners as quickly as possible. This reduces the possibility that competing 'Miner B' (who found a valid block at approximately the same time) propagates their block to some Miners before 'Miner A' could. This opens up the possibility that 'Miner A's' block, could later be [[Orphan Block|orphaned]] and the Coinbase reward rendered invalid and unusable by 'Miner A'. The degree of bandwidth and connectivity to other Miners can be seen as a competitive advantage and as such, the mining network tends toward a densely connected, small world structure with high bandwidth.

There also exists a competitive advantage in validating transactions. When validating a block, each transaction's inputs must be looked up in the miner's [[VOUT|UTXO]] set to check they are unspent and the amount in satoshis is correct. Additionally, each inputs locking and unlocking scripts need to be run by the Miner to assess whether each transaction is valid.

=== Rejected blocks ===
At any given point in time, two or more independent Miners may mine a block at the same time. In this situation, nodes can be in disagreement about which of these blocks should be the tip of the Block chain.

Miners always follow the longest chain they deem to be valid. Eventually another block will be found that builds on one of the competing chain tips. Miners then switch to this tip provided they consider it to be valid. As such, such scenarios are eventually resolved back to one persistent chain through the actions of the majority of hash power via [[Nakamoto Consensus]].

In this scenario, a block that doesn't end up forming part of the longest chain is rejected by the network and called an [[Orphan Block]]. An orphan block represents wasted effort on the behalf of a Miner and an incentive to invest in infrastructure in order to reduce the frequency of these events. However, orphans do not reduce the overall revenues of the Bitcoin system as the wasted work is not factored into the difficulty adjustment. Thus, if a certain percentage of hashing work is wasted due to the orphaned blocks, the difficulty will adjust downwards by a similar percentage, maintaining the same rate of valid block production overall. Additionally, the fee paying transactions in the orphaned block will still be valid and included in the competing block or its descendants.

Competing valid blocks are not the only way that blocks end up being rejected. Any miner can refuse to build on any block for any reason. Such an action by a particular Miner is only meaningful if the majority of Miners carry out the same action. It is through this mechanism that the mining network can establish consensus on variables that are Miner configurable - such as maximum block size. This is the basis of [[Nakamoto Consensus]]:

{{quote|1=''" They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism."''}}

== The mining ecosystem ==

=== Asic mining ===
An application-specific integrated circuit, or [[ASIC]], is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly more energy efficient than predecessor approaches to mining - using [[CPU]], GPU or FPGA.

=== Pooled mining ===
Pooled mining is the use of a block template allocation system that provides, distributed hashing infrastructure updated block headers against which they perform proof of work. This system of hash allocation to nodes is a primary part of [[Nakamoto Consensus]], in that individual operators of hash power can choose to re-allocate their hash to nodes, producing blocks that meet their expectations in terms of maximised profitability and adherence to the Bitcoin ruleset. Miners who distribute block templates that don't maximise profit, or which attempt to implement changed rule sets, risk the owners of the hash machinery they depend on re-deploying it to a different node on the network.

==== Stratum ====
Stratum is an open-source mining protocol used by many mining pools. Stratum facilitates coordination between the mining pool operator and individual mining machines.

==See also==
* [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Mining under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Payment Channels

2022-04-25T04:25:41Z

Todd Price:

''Payment Channels'' are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes methods for establishing, or opening a payment channel, updating the channel, and finalising, or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time.

Payment channels support extremely rapid transaction updates with only the final closing transaction being timestamped on the blockchain.

Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more.

==Properties==
*Payment channels can be opened and closed arbitrarily.
*Payment channels can be opened directly with the participating peers, without needing a third party.
*It is possible to open a payment channel with or without an on-chain action.
*Payment channels can be private or public.
*You can have many peers in a channel.
*You can add and remove peers from a channel.
*Payment channels are data conduits.
*Channels are typically closed with an on-chain payment, however an on-chain payment can be made outside the channel which causes it to update.

==Overview of the Mechanism==
A payment channel uses a transaction that has an [[nSequence]] that is less than 0xFFFFFFFF, and a nLocktime set to a time or block height in the future. The transaction can be updated many times between the peers until either, the nLocktime is reached, or nSequence is finalised and one of the parties transmits the transaction to the blockchain.

==Example - Streaming Movie==
The following goes through the sequence of opening, using, and closing a payment channel for the purposes of serving streamed content.

===STEP 1===
User browses catalog for titles to watch. Content can be on-chain or off-chain.

===Step 2===
User selects the content. At this point, there can be a few ways to manage the channel:
*In public via mining network.
*In private with pre-funded UTXO per channel.
*In private with separate channels for content purchase and service delivery per user.

===Step 3===
In this example, peers will use a timelocked UTXO in a public channel managed by Miners to serve the content.
For the sake of this example we will assume a single UTXO is being used. This UTXO goes into a double spend monitoring pool.

The viewer sends a transaction with the following output script to the provider to initiate the channel:

Where:
* Svn is the Viewer's nth [[iteration]] of the channel signature.
* Pv is the Viewer's pubkey.
* Hv is the Viewer's PKH.

* Spn is the service provider's nth iteration of the channel signature.
* Pp is the service provider's pubkey.
* Hp is the service provider's PKH.
* Hc0 is the hash of the [[merkle root]] of the content being selected.
* Hcn is the hash of each content frame with Hc1 being the hash of the first frame.
* Cn is the content frame with C1 being the first frame data.
* Hfm is the hash of a message the user can trigger to prematurely end or pause the stream.
* Fm is a message that the provider uses to end the stream.

The sequence no. for the input being spent is still 1.

The transaction iterates between the two scripts as as follows:

==Iteration 1==

The user signs the inputs they want to spend in, as payment using SIGHASH_ALL with the following outputs:

{| class="wikitable"
|-
! Script No.
! Purpose
! Script
! Amount
|-
| 1
| Iteration 1: Content Request
| Hc0 DROP DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG
| Price of first frame
|-
| 2
| Change
| Viewer's change script
| Change amount
|}

The Viewer also supplies the following data allowing the content provider to spend the payment channel output if the payment channel is closed:

*''Sv0 Pv'' where the signature is signed as SIGHASH_ANYONECANPAY | SIGHASH_NONE. The user can do this as the payment channel's current TXID can be generated allowing the user to sign the output against the most recent revision of the payment channel.

This would allow the service provider to close the channel by countersigning the tx and settling on the network, guaranteeing payment for the first frame.

The transaction pays out the price of the first frame to the service provider and the remainder is returned to the viewer as change. If the viewer cancels their session without watching, the transaction can still be processed on the network, and using the provided second signature the service provider can claim their money.

===Step 4===
The provider responds with a new version of the transaction that modifies the output as shown:

{| class="wikitable"
|-
! Script No.
! Purpose
! Script
! Amount
|-
| 1
| Iteration 2: First frame
| SHA256 Hc1 EQUALVERIFY DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG
| Price of second frame
|-
| 2
| Change
| Viewer's change script
| Change amount
|}

They also provide a new signature ''Sp0'' for this output, allowing the user to countersign and broadcast the previous iteration should they wish to close the channel.

When the user receives this new output, they sign the inputs against the updated content to indicate they have received the first frame and provide the streaming service with payment for the second frame. The amounts can be optimised for the service provider's fee model.

If the payment channel were closed, this output could be subsequently spent by providing the second packet of movie data as part of the input. This is not the ideal way for the output to be created on-chain, as there are higher transaction fees involved, but is done this way to allow both parties to acknowledge the progression through the content.

===Step 5===
The viewer completes the transaction as shown:

{| class="wikitable"
|-
! Script No.
! Purpose
! Script
! Amount
|-
| 1
| Iteration 3: Second frame
| SHA256 ''Hc2'' EQUALVERIFY DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG
| Price of second frame
|-
| 2
| Change
| Viewer's change script
| Change amount
|}
As in the previous iteration, they sign to indicate they have received the frame and provide the streaming service with payment for the next frame. This can be optimised for each service provider's fee model.

They also provide a new signature for this output, ''Sv1'', allowing the service provider to countersign should they need to close the channel. In this example, the keypairs being used don't need to change for each iteration, but they could.

===Step N===
The user can request that the provider close the channel. Streams can also be paused, or take place at any framerate, or even use larger transactions to move chunks at a time.
In this case the user is deciding to close it.

{| class="wikitable"
|-
! Script No.
! Purpose
! Script
! Amount
|-
| 1
| Iteration N: Final frame
| SHA256 Hfm EQUALVERIFY DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG
| Price of second frame
|-
| 2
| Change
| Viewer's change script
| Change amount
|}

The user puts the finish message hash at the front of the output. The streaming provider sees this and knows the customer wants to close the channel.
The user provides a new signature for this output, ''Svn''. This allows the streaming service provider to finalise the channel.

===Step N+1===

The provider broadcasts the final transaction and spends their payment with the following script:

''Svn Pv Spn Pp Fm''

In this way, rather than closing the transaction with a potentially large blob of content data at the front, just a short code need be used.

Merkle root

2022-04-25T04:22:55Z

Todd Price:

The hash value that summarises all data elements included in a [[Merkle Tree]].

As the leaf nodes are concatenated in pairs and hashed, the same occurs for all interior node values, whereupon the binary tree structure converge to a single root value.

Getminingcandidate

2022-04-22T05:37:50Z

Todd Price:

''getminingcandidate'' or GMC is a Remote Procedure Call (RPC) available in the Bitcoin SV node software.

Its purpose is to provide mining software/pools with a suitable block candidate for hashing in order to mine a block. In addition it is greatly decoupled from block size unlike its predecessor [https://wiki.bitcoinsv.io/index.php/GetBlockTemplate_interface GetBlockTemplate], meaning it can scale and support very large block sizes.

The way it supports blocks of very large sizes is by only providing a minimal set of data required for mining hardware to hash and generate a possible block solution. If a blocksolution is found it can be returned to the node software via the sibling RPC call ''submitminingsolution''.

GMCs predecessor ''getblocktemplate'' gave the call mining software more control, but in order to do this, it had to provide a full and complete dataset of the current block and pending transactions in the mempool. A Miner trying to mine large blocks must put a lot more strain on both the node software and RPC interface to transmit a record of every transaction that is in the mempool, often resulting in lack of memory and/or performance issues.

GMC removes this issue by only providing the mining software with a merkle proof of included transactions, rather than a complete listing, this lowers the amount of data to be produced and transmitted to log2(blocksize).

When the node software receives a GMC request it will respond with a [https://www.json.org/json-en.html JSON] representation of the current block candidate. A description of this response body is shown below.

===Response body of getminingcandidate===
<table>
<tr>
<th align="center">Variable</th>
<th align="center">Description</th>
</tr>
<tr>
<td align="center">[uuid] id</td>
<td align="center">The assigned id from Bitcoind. This must be provided with submitting a potential solution</td>
</tr>
<tr>
<td align="center">[hex string] prevHash</td>
<td align="center">Big Endian hash of the previous block</td>
</tr>
<tr>
<td align="center">[hex string] Coinbase (optional)</td>
<td align="center">Suggested coinbase transaction is provided. Miner is free to supply their own or alter the supplied one. Altering will require parsing and splitting the coinbase in order to splice in/out data as required. Requires Wallet to be enabled. Only returned when provide_coinbase_tx argument is set to true. Returns error if Wallet is not enabled</td>
</tr>
<tr>
<td align="center">[int32_t] version</td>
<td align="center">The block version</td>
</tr>
<tr>
<td align="center">[int64_t] coinbaseValue</td>
<td align="center">Total funds available for the coinbase tx (in Satoshis)</td>
</tr>
<tr>
<td align="center">[uint32_t] nBits</td>
<td align="center">Compressed hexadecimal difficulty</td>
</tr>
<tr>
<td align="center">[uint32_t] time</td>
<td align="center">Current block time</td>
</tr>
<tr>
<td align="center">[int] height</td>
<td align="center">The candidate block height</td>
</tr>
<tr>
<td align="center">[array] merkleProof</td>
<td align="center">Merkle branch/path for the block, used to calculate the [[Merkle root]] of the block candidate. This is a list of Little-Endian hex strings ordered from top to bottom</td>
</tr>
</table>

For a more technical breakdown of ''GetMiningCandidate'' and its implementation, see the protocol spec [https://github.com/bitcoin-sv-specs/protocol/blob/master/rpc/GetMiningCandidate.md here]

Block header

2022-04-22T05:37:25Z

Todd Price:

The block header is the first piece of information propagated by a node when it finds a valid block solution. Other nodes on the network can validate the node's hash solution and determine whether the proposed block warrants the further checking required to secure its place as the top-most link in the longest chain of valid proof of work.

A block header contains these fields:
{| class="wikitable"
|-
! Field
! Purpose
! Updated when...
! Size (Bytes)
|-
|Version
|Block version
|
|4
|-
|hashPrevBlock
|256-bit hash of the previous block header
|A new block comes in
|32
|-d
|hashMerkleRoot
|256-bit hash based on all of the transactions in the block
|An updated merkle tree is completed
|32
|-
|Time
|Current [[block timestamp]] as seconds since 1970-01-01T00:00 UTC
|Every few seconds
|4
|-
|Bits
|Current [[target]] in compact format
|The [[difficulty]] is adjusted (approx 2 weeks)
|4
|-
|Nonce
|32-bit number (starts at 0)
|A hash is tried (increments)
|4
|}

The body of the block contains the transactions. These are hashed only indirectly through the [[Merkle root]]. Because transactions aren't hashed directly, the proof of work needed to mine a block with 1 transaction takes exactly the same amount of effort as a block with 10,000, 10,000,000 or 10,000,000,000 transactions.

The format of target is a [[floating-point]] number encoded using a 3 byte mantissa with the leading 5 bytes as exponent. The number's range is within 2 256.

It is not possible for two nodes to be working on the same Merkle root because the [[Coinbase]] transaction is unique to that node, generating a different hash output. Every hash attempt made has the same chance of winning as every other hash calculated across the network.

==Endianess==
Note that the hash, which is a 256-bit number, has lots of leading zero bytes when stored or printed as a [[big-endian]] [[hexadecimal]] constant, but it has trailing zero bytes when stored or printed in [[little-endian]]. For example, if interpreted as a string and the lowest (or start of) the string address keeps lowest significant byte, it is little-endian.

Most block explorers display the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right).

Block hashing algorithm

2022-04-22T05:36:50Z

Todd Price:

Bitcoin mining uses a [[SHA-256]] hash based [[Proof of Work]] function. The algorithm requires the following parameters: a service string, a nonce, and a counter. In Bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the [[wikipedia:Merkle tree|Merkle tree]] of all transactions in the block, the current time, and the [[target]] of the proof of work function.

Bitcoin Miners commonly make use of two nonce fields:
# The Nonce field which is included in the block header
# The extraNonce field which is part of the [[Coinbase]] transaction

Each field includes a counter parameter that is relatively small (32-bits). The hash function cycles through all values of the Nonce field, testing each outcome of the hash function against the difficulty setting, then increments (or otherwise changes) the extraNonce field before going through all permutations of the Nonce again. Incrementing the extraNonce field entails recomputing the [[Merkle root|Merkle tree root]] as it modifies the hash of the Coinbase transaction.

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Block_hashing_algorithm under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Merkle root

2022-04-22T05:31:24Z

Todd Price: Created page with "The hash values that summarises all data elements included in a Merkle Tree."

The hash values that summarises all data elements included in a [[Merkle Tree]].

Merkle path

2022-04-22T05:30:58Z

Todd Price:

The path of values that connects a [[leaf (node)|leaf]] node to the [[Merkle root]].

Merkle path

2022-04-22T05:30:41Z

Todd Price:

The path of values that connects a [[leaf (node)|leaf]] node to the Merkle root.

Merkle path

2022-04-22T05:30:21Z

Todd Price: Created page with "The path of values that connects a leaf node to the Merkle root."

The path of values that connects a [[leaf (node)|leaf node]] to the Merkle root.

Simplified Payment Verification

2022-04-22T05:29:39Z

Todd Price:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a transaction recipient to prove that the sender has control of the source funds of the payment they are offering without downloading the full [[Blockchain]], by utilising the properties of [[Simplified_Payment_Verification #Merkle_Trees.2C_Merkle_Roots.2C_Merkle_Paths_and_Merkle_Proofs|Merkle proofs]]. This does not guarantee that the funds have not been previously spent, this assurance is received by submitting the transaction to the Bitcoin miners. However, in such a case the SPV proof acts as strong evidence of fraud backed by legally recognised digital signature technology.

SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.

===Advantages===
The advantages of using SPV are clear in terms of the volume of data required:

* a wallet can store '''all necessary block headers in around 50MB - this covers the entire block chain''' (as of January 2020, with 80 bytes per block and around 620,000 blocks in the chain). The total '''grows linearly''' at around 4MB per year (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block).

* contrast this with the '''hundreds of gigabytes''' which would be required to store the entire chain, if SPV were not being used.

* The size of the data required for the '''[[merkle path]]s''' is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

As explained in Section 8 of the [[Bitcoin whitepaper]]:
{{quote|1=''" ... [An SPV client] only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in ... }}

And in Section 7:
{{quote|1=''" ... A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year ..."''}}

===Approach===
There have been a lot of previous misunderstandings around SPV and peer-to-peer transacting. Previously, the custom had been for the sender of the payment to just broadcast the payment to the Bitcoin network nodes. The receiver of the payment would then need to somehow filter through all of the transactions coming onto the network for specific transactions relating to them (an extremely difficult task in of itself). Even if the sender sent the transaction to the receiver as well as the network nodes, the custom had been for the receiver to always wait for the transaction to be [[confirmation|confirmed]] at least 6 times whatever the transaction type, amount or situation.

The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the ledger through the network nodes. An analogy for this is a transaction done using cheque at a much faster speed. The customer hands the the signed cheque (transaction) to the merchant, who then banks or cashes the cheque (settles the transaction on chain). When/if the merchant is satisfied according to the situational risk of the transaction, then they can hand over the goods or services.

There is no such thing as absolute security, there is always a risk against the cost of being defrauded (which decreases exponentially as time goes by). If the transaction is only for a cup of coffee, then the merchant will be exposed to less risk than if the transaction is to buy a car for example, and they would behave differently. If selling a cup of coffee, they can satisfy themselves that the transaction they have received appears to be valid using the SPV process detailed above, and submit the transaction themselves to the network (or even to a trusted miner if using a [[Merchant API]]). Given that they will likely receive notification and proof of a fraud attempt within seconds, they will not want to maintain a copy of the entire ledger or even the [[UTXO]] set to check against, because the risk they face does not justify the cost. SPV is adequate just as an instant contactless payment without a pin number although arguably the security of SPV is far superior given that discovery of fraud attempts is rapid. Likewise, they will not want to detain their customer while they wait for 6 confirmations - it simply is not necessary - they have received a transaction which appears to be valid, and it has been accepted by the network without a double spend alert. This will probably be enough for them to risk the cost of the coffee.

===Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs===
A '''Merkle Tree''' is a structure used in computer science to validate data - see [https://en.wikipedia.org/wiki/Merkle_tree wikipedia definition] for more information.

The '''Merkle Root''' in a Bitcoin block is the hash contained in the [[Block_hashing_algorithm#Block_Header|block header]], which is derived from the hashes of all other transactions in the block.

A '''Merkle Path''' in SPV represents the information which the user needs to calculate the expected value for the Merkle root for a block, from their own transaction hash contained in that block. The Merkle path is used as part of of the Merkle Proof.

A '''Merkle Proof''' in SPV proves the existence of a specific transaction in a specific block (without the user needing to examine all the transactions in the Block). It includes the Merkle Root and the Merkle Path.

* To '''create''' a Merkle proof, a user or (or their wallet) simply needs the Merkle path of the transaction as well as the [[Block_hashing_algorithm#Block_Header|block header]] for a given block (80 bytes).

* To '''validate''' a proof, a user (or their wallet) only needs the chain of block headers (as opposed to the whole blocks themselves). I.e. they need their own copy of the [[block header]] of each block, that they know to be accurate. Using their own block header chain, together with the transaction (or its hash/id) they want to verify, as well as its Merkle proof (also sometimes referred to as an inclusion proof), a user can verify the transaction was time stamped in a specific block, without examining every transaction in that block.

An article in March 2019 entitled [https://craigwright.net/blog/bitcoin-blockchain-tech/merkle-trees-and-spv Merkle Trees and SPV] (Craig Wright, 2019) clarified some previous misunderstandings around SPV and transaction verification. The article included the following diagram which shows how transaction hashes can be related to the Merkle root in a block header:

[[File: Merkle_tree2.png|frameless|1000px|alt=Three transactions and the Merkle paths which can be used to relate them to blocks]]

===SPV Wallet===
An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct Bitcoin transactions and payments.

To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:
# <math>Transaction_0</math> - the transaction that contains the UTXO as an output,
# The Merkle path of <math>Transaction_0</math>
# The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
# <math>Transaction_1</math> - the transaction that spends the UTXO

To validate the information, a user computes the Merkle root from the Merkle path of <math>Transaction_0</math>. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that <math>Transaction_0</math> is in the chain.

=== Offline Payment ===
Note that by storing <math>Transaction_0</math> locally, a user will be able to sign <math>Transaction_1</math> offline, as any signature on <math>Transaction_1</math> requires the scriptPubKey (locking script) part from <math>Transaction_0</math>.

Ancestor Limit

2022-04-22T05:27:47Z

Todd Price:

In the first iteration of the Bitcoin software, bitcoind v0.1.0 handled the creation of blocks fairly simply. Once a second or so, the software would take a memory map of all the transactions it had received, check any new ones to ensure they met the minimum fee requirement set for the node and if so, add them to the block template which was basically an ordered list of valid transactions. It would then calculate a merkle tree from that set of transactions and build a block header to start doing proof of work upon.

Because of the arbitrary 1MB block size limit imposed on the software at a later time, the software was then optimized to select transactions for block building with the highest fee rates until the 1MB block size limit was filled. Due to this accounting and other policy based limitations, the software inefficiently added transactions to block templates.

This inefficiency manifested in a big way when creating long chains of descendant transactions prior to a block being found. Descendant transactions refers to transactions that are added to a node's [[mempool]] that are dependent on previous transactions that are also in that node's mempool. Because the older Bitcoin software was designed around 1MB blocks, situations arose where these long chains of transactions had to be split across multiple blocks.

Starting in October 2015, the BTC Core developers introduced a rule in bitcoin v0.12 to account for this inefficiency by limiting the number of descendants a coin could have to 25. This limit, also called the Ancestor Limit, rejected any transactions that violated this rule with error code 64: too-long-mempool-chain. Bitcoin SV Node v1.0.7 raised this default limit to 1000, and plan to remove the limit entirely soon. Since this restriction is miner policy, miners are free to raise this limit themselves as well.

[[File:ancestor_limit.gif|centre|alt=Ancestor Limit Performance Comparison for Bitcoin SV Node 1.0.7]]

In the above graphic, you can see the performance increase for long chain submission to the node software in v1.0.7.

Mediation

2022-04-22T05:27:14Z

Todd Price: Created page with "The attempt to settle a dispute through a neutral third party."

The attempt to settle a dispute through a neutral third party.

Maximum Acceptable Transaction Size Limit

2022-04-22T05:26:44Z

Todd Price:

A node configurable limit for the number of bytes in the serialised transaction.

Maximum Acceptable Transaction Size Limit

2022-04-22T05:26:14Z

Todd Price: Todd Price moved page Maximum Acceptable Transaction Size to Maximum Acceptable Transaction Size Limit

A standard local policy that configures the largest transactions that the software will propagate across the P2P network or include in a block. It needs to be lower than the network wide maximum transaction size consensus rule for it to have any effect.

Maximum Acceptable Transaction Size

2022-04-22T05:26:14Z

Todd Price: Todd Price moved page Maximum Acceptable Transaction Size to Maximum Acceptable Transaction Size Limit

#REDIRECT [[Maximum Acceptable Transaction Size Limit]]

Maximum Acceptable Transaction Size Policy

2022-04-22T05:25:38Z

Todd Price: Created page with "Is a standard local policy that configures the largest transactions that the software will propagate across the P2P network or include in a block. It needs to be lower than th..."

Is a standard local policy that configures the largest transactions that the software will propagate across the P2P network or include in a block. It needs to be lower than the network wide maximum transaction size consensus rule for it to have any effect.

Maximum Acceptable Transaction Size Limit

2022-04-22T05:25:04Z

Todd Price: Created page with "A standard local policy that configures the largest transactions that the software will propagate across the P2P network or include in a block. It needs to be lower than the n..."

Markup language

2022-04-22T05:09:40Z

Todd Price: Created page with "In computer text processing, a markup language is a system for annotating a document in a way that it is visually distinguishable from the content. It is only used to format..."

In computer text processing, a markup language is a system for annotating a document in a way that it is visually distinguishable from the content.

It is only used to format the text, so that when the document is processed for display, the markup language does not appear.

Markdown

2022-04-22T05:08:41Z

Todd Price:

Markdown is a lightweight [[markup language]] for creating formatted text using a plain-text editor.