Bitcoin Wiki - User contributions [en]

Merchant API

2020-01-27T16:11:48Z

David Watson:

The Merchant API is a new development in Bitcoin, planned to be introduced in 2020.

The API will enable merchants accepting Bitcoin transactions to get all of the assurance they need to be able to accept transactions on a 'zero confirmation' basis (see [[Confirmation]]). Merchants will be able to find out in advance (even before broadcasting a transaction) what transaction fee is required by miners to mine it.

As explained by Steve Shadders in [https://youtu.be/WDuvYp77tJU?t=2126 Steve Shadders Discusses the Bitcoin SV (BSV) Tech Pillars - Bitstocks Podcast Ep. 7] at 36m 12s:

{{quote|"If you can broadcast a transaction to miners and then get a response from them a second later, to say that they've accepted the transaction, then the 'zero conf' problem largely goes away".}}

It also allows miners to put user based fee policies in place. See [https://www.yours.org/content/the-dawn-of-the-age-of-competitive-mining-1cc8d831dc34 The dawn of the age of competitive mining] (Steve Shadders, yours.org, October 2019)

2020-01-21T17:12:42Z

David Watson:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify that a transaction is in the [[Block chain]] without downloading the full chain.

To '''create''' a Merkle proof, a user or (or their wallet) simply needs the '''[[Block_hashing_algorithm#Block_Header|block header]]''' for a given block (80 bytes) and the '''Merkle path''' within that block of the transaction they need to validate. Together, these two items will be sufficient to prove that a given transaction exists in the chain at a given block height.

To '''validate''' a proof, a user (or their wallet) only needs the 80 byte header for the block where the transaction appeared. They don't need all of the transactions within block (which could be very large). By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.

===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 at 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 paths''' is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

===Approach===
An article in March 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. Previously, the custom had been for the person receiving a payment to poll the block chain repeatedly, to confirm that their transaction had reached a certain depth (say 6 blocks deep). Dr Wright stated that this was unnecessary:

{{quote|
In contrast, the present invention requires that the necessary SPV check be performed on a transaction’s inputs '''prior to its broadcast''' [emphasis added]. The shift in emphasis greatly reduces the burden and traffic on the network in dealing with invalid transactions.

A second important paradigm in the existing [i.e. the prior] SPV system is that an SPV client must '''query full nodes''' [emphasis added] on the network to obtain the Merkle path required for the SPV check ... SPV checks that '''remove such burden on the network''' [emphasis added], by stipulating the lightweight Bitcoin client where users keep, maintain, or at least have access to their own copies of Merkle paths pertinent to the unspent transaction outputs owned by them, '''allow Bitcoin to scale'''. [emphasis added]
}}

The article referenced above 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]]

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

===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>.

Template:Quote

2020-01-21T17:02:57Z

David Watson:

Simplified Payment Verification

2020-01-21T17:00:46Z

David Watson:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify that a transaction is in the [[Block chain]] without downloading the full chain.

To '''create''' a Merkle proof, a user or (or their wallet) simply needs the '''[[Block_hashing_algorithm#Block_Header|block header]]''' for a given block (80 bytes) and the '''Merkle path''' within that block of the transaction they need to validate. Together, these two items will be sufficient to prove that a given transaction exists in the chain at a given block height.

To '''validate''' a proof, a user (or their wallet) only needs the 80 byte header for the block where the transaction appeared. They don't need all of the transactions within block (which could be very large). By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.

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

* a wallet only needs around '''50MB to store the block headers for the entire block chain''' (as at January 2020, with 80 bytes per block and around 620,000 blocks in the chain). This '''grows linearly''' with each block mined (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block, so we can expect it to grow at around 4MB per year.)

* 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 paths''' is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

===Approach===
An article in March 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. Previously, the custom had been for the person receiving a payment to poll the block chain repeatedly, to confirm that their transaction had reached a certain depth. Dr Wright stated that this was unnecessary and said as follows:

{{quote|
In contrast, the present invention requires that the necessary SPV check be performed on a transaction’s inputs '''prior to its broadcast''' [emphasis added]. The shift in emphasis greatly reduces the burden and traffic on the network in dealing with invalid transactions.

A second important paradigm in the existing [i.e. the prior] SPV system is that an SPV client must '''query full nodes''' [emphasis added] on the network to obtain the Merkle path required for the SPV check ... SPV checks that '''remove such burden on the network''' [emphasis added], by stipulating the lightweight Bitcoin client where users keep, maintain, or at least have access to their own copies of Merkle paths pertinent to the unspent transaction outputs owned by them, '''allow Bitcoin to scale'''. [emphasis added]
}}

The article referenced above 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]]

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

===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>.

2020-01-17T09:29:31Z

David Watson:

[[Special:UserLogin|Temporary log in link]]

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

'''Bitcoin''' is a peer to peer cash system created by [https://craigwright.net/ Dr. Craig Wright] under the pseudonym [[Satoshi Nakamoto]] and released as open-source software in 2009. It does not rely on a central server to process transactions or store funds. The leaderless structure of the network famously solves [[The Byzantine Generals Problem]] allowing disconnected entities to follow a common direction without a centralised authority. New Bitcoins are issued to miners as rewards for winning a contest to extend the ledger. Over time the competition awards coins in decreasing amounts, using an algorithm which will see the last new coins created in around 2140.

The Bitcoin ledger is held on a distributed network of nodes who compete with each other to extend it by finding [[Block|blocks]]. Nodes are operated by [[Mining|Bitcoin miners]] who build the network and are incentivized to be directly connected to as many of the other block winning miners as possible to ensure blocks they discover are accepted as fast as possible. This leads to miners forming a [[Small World Network]] which trends towards a [[Nearly Complete Graph]] where all miners are connected to all other miners. Miners receive transactions from peers and from other miners on the network and propagate them to make all other known miners aware of every new transaction. This defeats the double spending problem ensuring that global consensus can be reached on the validity of a transaction within roughly 2 seconds. The miners use hash based proof of work to compete for the right to extend the ledger, and as a means to vote on the network rules.

Bitcoins are the ledger's native unit of account. The base unit of exchange is [[Satoshis]] and 100,000,000 satoshis is referred to as one Bitcoin. Satoshis are held in script puzzles called [[UTXO|Unspent Transaction Outputs or UTXOs]]. These are outputs from [[Bitcoin Transactions]] 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.

Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the Bitcoin public ledger by miners. The ledger is built in blocks which are discovered every 10 minutes on average and linked together forming a [[Block chain]]. The ledger is structured as a [[wikipedia:Directed Acyclic Graph|Directed acyclic graph]] (DAG) allowing the history of all Bitcoins to be traced back to the [[Coinbase]] transactions where they were created. Transactions can be exchanged peer to peer, allowing them to be modified in payment channels however once they have been committed to the ledger they are [[Irreversible Transactions|recorded immutably]] and their record cannot be removed.

The Bitcoin protocol defines the scripting language that is used to define transactions, the formatting of transactions and blocks, the rate at which new bitcoins are issued as rewards for adding to the ledger, and the mathematical rules outlining the target for the difficulty algorithm which tries to keep the network generating new blocks at an average rate of 10 minutes each. The protocol is agreed upon by the miners who control network operation. After the [[Genesis upgrade]], miners will remove almost all limit based rules from the protocol enabling them to compete to offer better service to fee paying users by scaling their own capabilities.

[[Bitcoin until today|Bitcoin has a rich history]] and has been [[Attacks on Bitcoin|attacked]] in many ways since its inception.

The following pages look at the concepts outlined above in greater detail.
#[[Bitcoin Transactions|Transactions]]
#[[Block|Blocks]]
#[[The Bitcoin Network]]
#[[Mining and Consensus]]
#[[Wallets and key management]]
#[[Payments in Bitcoin|Making and receiving Bitcoin Payments]]

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

=Quick Links=

{| class="wikitable" style="width: 700px;"
|- style="vertical-align:top; text-align:center;"
! Techniques
! Application Layer Protocols
! Products and Tools
|- style="vertical-align:top; text-align:center;"
| [[Advanced Bitcoin Scripting]] [[Digital Signatures (ECDSA)]] [[Payment Channels]] [[R-Puzzles]] [[SVAlias]] [[The Metanet]] 
| [[GearSv]] [[Run]] [[Tokenized]] [https://github.com/unwriter/B B://], [https://planaria.network/@1KuUr2pSJDao97XM8Jsq8zwLS6W1WtFfLg C://], [https://planaria.network/@1G3BpTyEK6xF4LaQTHqdFBBaVxYHZzts4M D://], [http://bcat.bico.media/ BCAT] etc 
| [[ElectrumSV]] [https://handcash.io Handcash] [https://moneybutton.com Moneybutton] [[Nakasendo]] [[Planaria]] [[Relay]] 
|}

Main Page

2020-01-17T09:25:08Z

David Watson:

[[Special:UserLogin|Temporary log in link]]

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

'''Bitcoin''' is a peer to peer cash system created by [https://craigwright.net/ Dr. Craig Wright] under the pseudonym [[Satoshi Nakamoto]] and released as open-source software in 2009. It does not rely on a central server to process transactions or store funds. The leaderless structure of the network famously solves [[The Byzantine Generals Problem]] allowing disconnected entities to follow a common direction without a centralised authority. New Bitcoins are issued to miners as rewards for winning a contest to extend the ledger. Over time the competition awards coins in decreasing amounts, using an algorithm which will see the last new coins created in around 2140.

The Bitcoin ledger is held on a distributed network of nodes who compete with each other to extend it by finding [[Block|blocks]]. Nodes are operated by [[Mining|Bitcoin miners]] who build the network and are incentivized to be directly connected to as many of the other block winning miners as possible to ensure blocks they discover are accepted as fast as possible. This leads to miners forming a [[Small World Network]] which trends towards a [[Nearly Complete Graph]] where all miners are connected to all other miners. Miners receive transactions from peers and from other miners on the network and propagate them to make all other known miners aware of every new transaction. This defeats the double spending problem ensuring that global consensus can be reached on the validity of a transaction within roughly 2 seconds. The miners use hash based proof of work to compete for the right to extend the ledger, and as a means to vote on the network rules.

Bitcoins are the ledger's native unit of account. The base unit of exchange is [[Satoshis]] and 100,000,000 satoshis is referred to as one Bitcoin. Satoshis are held in script puzzles called [[UTXO|Unspent Transaction Outputs or UTXOs]]. These are outputs from [[Bitcoin Transactions]] 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.

Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the Bitcoin public ledger by miners. The ledger is built in blocks which are discovered every 10 minutes on average and linked together forming a [[Block chain]]. The ledger is structured as a [[wikipedia:Directed Acyclic Graph|Directed acyclic graph]] (DAG) allowing the history of all Bitcoins to be traced back to the [[Coinbase]] transactions where they were created. Transactions can be exchanged peer to peer, allowing them to be modified in payment channels however once they have been committed to the ledger they are [[Irreversible Transactions|recorded immutably]] and their record cannot be removed.

The Bitcoin protocol defines the scripting language that is used to define transactions, the formatting of transactions and blocks, the rate at which new bitcoins are issued as rewards for adding to the ledger, and the mathematical rules outlining the target for the difficulty algorithm which tries to keep the network generating new blocks at an average rate of 10 minutes each. The protocol is agreed upon by the miners who control network operation. After the [[Genesis upgrade]], miners will remove almost all limit based rules from the protocol enabling them to compete to offer better service to fee paying users by scaling their own capabilities.

[[Bitcoin until today|Bitcoin has a rich history]] and has been [[Attacks on Bitcoin|attacked]] in many ways since its inception.

The following pages look at the concepts outlined above in greater detail.
#[[Bitcoin Transactions|Transactions]]
#[[Block|Blocks]]
#[[The Bitcoin Network]]
#[[Mining and Consensus]]
#[[Wallets and key management]]
#[[Payments in Bitcoin|Making and receiving Bitcoin Payments]]

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

=Quick Links=

{| class="wikitable" style="width: 700px;"
|- style="vertical-align:top; text-align:center;"
! Techniques
! Application Layer Protocols
! Products and Tools
|- style="vertical-align:top; text-align:center;"
| [[Advanced Bitcoin Scripting]] [[Digital Signatures (ECDSA)]] [[Payment Channels]] [[R-Puzzles]] [[SVAlias]] [[The Metanet]] 
| [[GearSv]] [[Run]] [[Tokenized]] [https://github.com/unwriter/B B://], [https://planaria.network/@1KuUr2pSJDao97XM8Jsq8zwLS6W1WtFfLg C://], [https://planaria.network/@1G3BpTyEK6xF4LaQTHqdFBBaVxYHZzts4M D://], [http://bcat.bico.media/ BCAT] etc 
| [[ElectrumSV]] [https://handcash.io Handcash] [https://moneybutton.com Moneybutton] [[Nakasendo]] [[Planaria]] [[Relay]] 
|}