Bitcoin Wiki - User contributions [en]

Payment Channels

2020-05-05T13:03:10Z

Daniel:

''Payment Channels'' are a mechanism where two or more parties can directly and trustlessly exchange and update a transaction. The mechanism includes methods for establishing, or opening, a payment channel, updating the channel, and finalizing, 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 confirmed in 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 typically uses a transaction that has an [[nSequence]] that is less than 0xFFFFFFFF. The transaction can be updated many times between the peers until the 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==

{| 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 input script:

*''Sv0 Pv''

which would allow the service provider to countersign the tx and settle 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

===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
|}
In this iteration, they sign to indicate they have received the first frame and provide the streaming service with payment for the second frame. This can be optimized for each service provider's fee model.

They also provide a new signature ''Sp0'' for this output, allowing the user to countersign should they need to close the channel.

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

{| class="wikitable"
|-
! Script No.
! Purpose
! Script
! Amount
|-
| 1
| Iteration 2: First 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 optimized 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 provide a new signature for this output, ''Svn''. This allows the streaming service provider to finalise the channel.

===Step N+1===
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.

The provider signs the transaction and solves the puzzle 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.

Payments in Bitcoin

2020-05-05T12:44:40Z

Daniel:

The term ''payments'' in a Bitcoin context generally refers the process of a purchaser paying for a good or service from a vendor. Payments are an important aspect of Bitcoin and it is crucial that comprehensive standards exist that enable parties and software systems to process payments in ways that cover a wide variety of use cases.

There are several standards defined for Bitcoin SV that cover methods of requesting and performing payments.

==BIP270==
[https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a streamlined version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70 Payment Protocol] introduced in 2013. It is a protocol for communication between a payment host (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables:
* Improved user experience
* Simpler wallet infrastructure
* Multiple outputs
* Improved security against man-in-the-middle attacks

BIP270 is designed for wallets that use [[Simplified Payment Verification]] to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer directly between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).

This BIP is an optimisation of BIP70. Changes include:
* Moves all signature exchange and validation to the communication later (usually HTTPS)
* Add multiple outputs
* A library optimised for peer to peer transaction management

==BSVAlias==
[[BSVAlias]] is a set of standards for using email type identities with Bitcoin SV, with making and receiving payments as one of its first use-cases.

[[Paymail]] is the first practical implementation of BSVAlias.

==Payment Channels==
[[Payment Channels]] are a mechanism where two or more parties can directly and trustlessly exchange and update a transaction. The mechanism includes methods for establishing, or opening, a payment channel, updating the channel, and finalizing, 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 confirmed in 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.

==Legacy Payment Protocols==
Many of the legacy payment protocols used a mechanism where the payer is asked to broadcast a transaction to the network and the payee would scan the network for relevant transactions, rather than handling the transaction directly peer-to-peer as with [[Simplified_Payment_Verification|SPV]]. This mechanism does not scale when transaction volume increases and is inefficient.

===IP to IP payments===
The original version of the Bitcoin node client had the facility to conduct IP to IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the Payee's client and request a public key for the payment to be addressed to.
This payment method had valid security concerns but rather than addressing these concerns the mechanism was removed.
New payment processes are in development which draw from this original idea, and will allow network peers to interact securely using cryptographically verified IP addresses.

===BIP21===
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP21] has been one of the predominant means of making mobile payments in Bitcoin throughout it's history. Almost all QR codes based payment gateways used within Bitcoin are or are an extension of BIP21. BIP21 itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers).

===BIP70===
[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] was a payment protocol for reaching out to receivers using an extension of BIP21 that added a URL. The URL directed the device to reach out to a server which would provide it a script or address linked to the QR code.

Payments in Bitcoin

2020-05-05T12:25:53Z

Daniel:

The term ''payments'' in a Bitcoin context generally refers the process of a purchaser paying for a good or service from a vendor. Payments are an important aspect of Bitcoin and it is crucial that comprehensive standards exist that enable parties and software systems to process payments in ways that cover a wide variety of use cases.

There are several standards defined for Bitcoin SV that cover methods of requesting and performing payments.

==BIP270==
[https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a streamlined version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70 Payment Protocol] introduced in 2013. It is a protocol for communication between a payment host (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables:
* Improved user experience
* Simpler wallet infrastructure
* Multiple outputs
* Improved security against man-in-the-middle attacks

BIP270 is designed for wallets that use [[Simplified Payment Verification]] to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer directly between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).

This BIP is an optimisation of BIP70. Changes include:
* Moves all signature exchange and validation to the communication later (usually HTTPS)
* Add multiple outputs
* A library optimised for peer to peer transaction management

==BSVAlias==
[[BSVAlias]] is a set of standards for using email type identities with Bitcoin SV, with making and receiving payments as one of its first use-cases.

[[Paymail]] is the first practical implementation of BSVAlias.

==Payment Channels==
Any transaction that has both an [[nLocktime]] in the future and an [[nSequence]] that is less than 0xFFFFFFFF is not finalised, and potentially from a [[Payment Channels|payment channel]].
The transaction can be updated once, or many times between peers until either nSequence is finalised or nLocktime runs out and one of the parties transmits the transaction to the blockchain.
Payment channels are useful for streaming data, operating a sequence of events or operating with a live dataset in applications such as gaming and more.
Payment channels have been unavailable since the early versions of Bitcoin and have been re-enabled since the [[Genesis upgrade]], enabling many potential use cases.

==Legacy Payment Protocols==
Many of the legacy payment protocols used a mechanism where the payer is asked to broadcast a transaction to the network and the payee would scan the network for relevant transactions, rather than handling the transaction directly peer-to-peer as with [[Simplified_Payment_Verification|SPV]]. This mechanism does not scale when transaction volume increases and is inefficient.

===IP to IP payments===
The original version of the Bitcoin node client had the facility to conduct IP to IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the Payee's client and request a public key for the payment to be addressed to.
This payment method had valid security concerns but rather than addressing these concerns the mechanism was removed.
New payment processes are in development which draw from this original idea, and will allow network peers to interact securely using cryptographically verified IP addresses.

===BIP21===
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP21] has been one of the predominant means of making mobile payments in Bitcoin throughout it's history. Almost all QR codes based payment gateways used within Bitcoin are or are an extension of BIP21. BIP21 itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers).

===BIP70===
[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] was a payment protocol for reaching out to receivers using an extension of BIP21 that added a URL. The URL directed the device to reach out to a server which would provide it a script or address linked to the QR code.

Transaction Pools

2020-05-05T08:45:45Z

Daniel:

A ''transaction pool'' or ''mempool'' is a data structure containing the set of transactions that are unconfirmed but have been validated by a transaction processor (or ''miner''). Transactions are stored in a node's transaction pool prior to inclusion in a block.

==Transaction Pools in Bitcoin SV==

A bitcoin [[Mining| node]] stores bitcoin transactions that have been validated but not mined. It can be thought of as a staging area for transactions prior to their inclusion in a [[block chain|block]]. When creating a new block to mine, miners will gather transactions from their transaction pool using the rpc command ''getminingcandidate'' or the older ''getblocktemplate'' to construct a candidate block. Similarly, when receiving a block, a validator can speed-up the validation process if the [[TXID|transactions IDs]] match the transaction IDs in the validator's transaction pool. The transaction pool data is used extensively by block explorers, wallet servers and other Bitcoin SV related web services [https://jochen-hoenicke.de/queue/#3,24h].

==Secondary Transaction Pools and Genesis==

The [[Genesis upgrade| Genesis]] upgrade to Bitcoin SV introduced a taxonomy within the transaction pool aimed at improving efficiency for transaction validators and miners.

* '''Primary Transaction Pool''' - transaction pool containing transactions that meet the criteria to be included in a block (including the ''minimum transaction fee'')

* '''Secondary Transaction Pool''' - transaction pool for transactions that are do not meet the criteria to be included in a block, but may meet another transaction processors criteria (such as having below the ''minimum transaction fee'' limit but above the network-wide ''minimum relay fee'' limit). These transactions could eventually be included in another transaction processor's block and therefore should be stored to ensure fast [[Mining| block validation]] and optimize network performance.

A further discussion of configurable minimum fee policy can be found here [https://bitcoinsv.io/2019/11/24/on-the-future-of-bitcoin-transaction-fees/].

==See Also==

* [[Confirmation]]

==References==

* [1] https://jochen-hoenicke.de/queue/#3,24h
* [2] https://bitcoinsv.io/2019/11/24/on-the-future-of-bitcoin-transaction-fees/

Satoshis

2020-04-30T14:25:25Z

Daniel:

A '''satoshi''' is the smallest division of a bitcoin and the base unit of exchange on the Bitcoin SV network. There are 100,000,000 satoshis in 1 bitcoin. The unit is named after [[Satoshi Nakamoto]], the author of the 2008 Bitcoin whitepaper.

Satoshis are represented as integers where 1 satoshi is the smallest unit of exchange on the Bitcoin ledger.

"Bitcoins" are a human construct, as all values in Bitcoin are treated as integers quantities of Satoshis, rather than decimal bitcoin fractions in the protocol.

The table below provides information on how many Satoshis in a Bitcoins, depending on their quantity:
{| class="wikitable"
|-
! Satoshi !! BSV
|-
| 1 || 0.00000001
|-
| 10 || 0.0000001
|-
| 100 || 0.000001
|-
| 1 000 || 0.00001
|-
| 10 000 || 0.0001
|-
| 100 000 || 0.001
|-
| 1 000 000 || 0.01
|-
| 10 000 000 || 0.1
|-
| 100 000 000 || 1
|}
Thus, '''1 Satoshi = 0.00000001 Bitcoin'''.

==Satoshis and the Miner Subsidy Schedule==

The total number of satoshis in existence is approximately 2.1 x 1015 (21 million BSV), and they are distributed at a mathematically predictable rate using the [[Miner subsidy|miner subsidy]] formula. The miner subsidy, which began at 50 newly minted bitcoins per block, is scheduled to divide in 2 every 210,000 blocks, approximately every 4 years. At the time of the 6th halvening (approximately 2032) the miner subsidy will fall below 1 BSV to 78125000 satoshis (0.78125 BSV).

By the time of the 31st halvening (approximately the year 2136) the miner subsidy will be reduced to 1 satoshi and in the year 2140 (block no. 6,720,000) the subsidy will finish marking the final distribution of satoshi tokens onto the ledger.

==See Also==
* [[Coinbase]]
* [[Miner subsidy]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Satoshi_(unit) 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.

BSVAlias

2020-04-30T08:41:27Z

Daniel:

BSVAlias is a family of related standard protocols that enable the use of email style addresses for Bitcoin SV. Services that implement these protocols can be run by a domain owner or through a third party.

The goals of BSVAlias are:

*User friendly payments
*Permissionless implementation
*Self hosting
*Automatic discovery process
*PKI infrastructure (IPV4)
*Security
*Extensibility

[[Paymail]] leverages BSVAlias into a set of protocols that allows BSV wallets to receive payments using email addresses as handles.

The protocols allow for flexibility in capabilities and implementation.

==Service Discovery==
The Service Discovery Process is split into two phases:
#Host Discovery
#Capability Discovery

===Host Discovery===
Host Discovery is a DNS based lookup of the responsible host for a given BSVAlias. One practical implementation that exists today is Paymail, in which the host is identified through the domain attached to the receiving party's paymail address which is in standard email format (e.g. user@domain.tld).

BSVAlias can be:
#Self hosted
#Hosted using 3rd party providers (done using a DNS SRV record)

This makes BSVAlias compatible with the internet infrastructure we have today.

===Capability Discovery===
Once the host has been identified, the sending party must learn its supported features.

This is in the format of a machine readable (JSON) document which is placed on the host web server in the .well-known folder:

https://<target>:<port>/.well-known/bsvalias

Capabilities of a host are not necessarily reflected in an individual account.

==References==
1. BSVAlias specification - https://bsvalias.org/

BSVAlias

2020-04-29T09:50:27Z

Daniel:

BSVAlias is a set of standards assembled to make it simple for individual domains to incorporate wallet services. These services can be run by the domain or through a third party.

The goals of BSVAlias are:

*User friendly payments
*Permissionless implementation
*Self hosting
*Automatic discovery process
*PKI infrastructure (IPV4)
*Security
*Extensibility

[[Paymail]] leverages BSVAlias into a set of protocols that allows BSV wallets to receive payments using email addresses as handles.

The protocols allow for flexibility in capabilities and implementation.

==Service Discovery==
The Service Discovery Process is split into two phases:
#Host Discovery
#Capability Discovery

===Host Discovery===
Host Discovery is a DNS based lookup of the responsible host for a given BSVAlias. The only practical implementation that exists today is Paymail, in which the host is identified through the domain attached to the receiving party's paymail address which is in standard email format (e.g. user@domain.tld).

BSVAlias can be:
#Self hosted
#Hosted using 3rd party providers (done using a DNS SRV record)

This makes BSVAlias compatible with the internet infrastructure we have today

===Capability Discovery===
Once the host has been identified, the sending party must learn its supported features

This is in the format of a machine readable (JSON) document which is placed on the host web server in the .well-known folder:

https://<target>:<port>/.well-known/bsvalias

Capabilities of a host are not necessarily reflected in an individual account.

==References==
1. BSVAlias specification - https://bsvalias.org/

The Metanet

2020-04-29T08:50:57Z

Daniel:

[[File:post.png|thumb|The Metanet Ecosystem]]
'''The Metanet''' is the term given to a value-based internet built on the Bitcoin SV blockchain. 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 an on-chain 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 blockchain-based internet for peer-to-peer content creation and monetization.

==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 blockchain for simple payments. The Metanet aims to solve the remaining issues by combining online payments with immutable data stored on the public Bitcoin SV blockchain.

The combination of payments and data both using the Bitcoin SV blockchain 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 monetize their data using its native permissioning 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 blockchain to create overlay DAG structures that exist natively on-chain.

Peer-to-Peer Network Architecture

2020-04-29T08:44:16Z

Daniel:

Peer-to-Peer computing or networking is a distributed application network architecture that shares resources amongst the participants. Participants are called nodes and are said to form a Peer-to-Peer network [1]. A distributed network architecture is classified as a "Pure" Peer-to-Peer if the removal of any single, arbitrarily chosen, node will not result in the loss of network service.

==The Bitcoin Peer-to-Peer Network==

Formally, the Bitcoin network is a Pure Peer-to-Peer network built on top of the internet. In the early days of Bitcoin the network had a flat topological structure, in which users were capable of running full nodes that could perform all of Bitcoin's main functions: transaction creation, transaction validation and [[Mining |mining]] (see [https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html bitcoinv0.1]). However, as the network has grown, the requirements needed to perform each function on the network have evolved creating a necessity for nodes to specialize. Currently, the 3 main functions of the Bitcoin system are, in general, performed by separate actors within the ecosystem. Transaction creation is done by [[Simplified Payment Verification|SPV]] wallets. Transaction validation is done by the Bitcoin SV node client software and mining is a separate function performed using purpose built mining software.

==Peer-to-Peer Architecture and the Bitcoin Scalability Dispute==

Peer-to-peer is a term often misused and misunderstood, partly due the philosophical significance of ''decentralization'' which is seen as a key feature of blockchain technology. It has also been at the heart of disputes within the Bitcoin community that have lead to contentious forks that have split the Bitcoin blockchain on two occasions as well as generally delayed the development of the technology.

The role of transaction validation and mining cannot be [[Attacks on Bitcoin|dominated by a single entity]] as the network would cease to provide any cryptographic or game theoretic advantages over existing centralized digital money systems. However, one of the main barriers to scaling is the extreme waste caused by forcing all users to perform all Bitcoin functions. Whilst it is true that engineering trade-offs between decentralization and scalability have to be made, it is the firm belief of the Bitcoin SV community that scalability can be achieved through specialization whilst maintaining strong security and decentralization.

==References==
1. Rüdiger Schollmeier, [https://www.researchgate.net/publication/3940901_A_Definition_of_Peer-to-Peer_Networking_for_the_Classification_of_Peer-to-Peer_Architectures_and_Applications A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications], Proceedings of the First International Conference on Peer-to-Peer Computing, IEEE (2002).

Peer-to-Peer Network Architecture

2020-04-29T08:32:32Z

Daniel:

Peer-to-Peer computing or networking is a distributed application network architecture that spreads workload between peers. Peers are equally privileged, participate equally in the application and are said to form a peer-to-peer network of nodes [1].

==Bitcoin as a Peer-to-Peer Network==

Formally, Bitcoin is a peer-to-peer network built on top of the internet. In the early days of Bitcoin the network had a flat topological structure, in which users were capable of running full nodes that could perform all of Bitcoin's main functions: transaction creation, transaction validation and [[Mining |mining]] (see [https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html bitcoinv0.1]). However, as the network has grown, the requirements needed to perform each function on the network have evolved creating a necessity for nodes to specialize. Currently, the 3 main functions of the Bitcoin system are, in general, performed by separate actors within the ecosystem. Transaction creation is done by [[Simplified Payment Verification|SPV]] wallets. Transaction validation is done by the Bitcoin SV node client software and mining is a separate function performed using purpose built mining software.

==Peer-to-Peer Architecture and the Bitcoin Scalability Dispute==

Peer-to-peer is a term often misused and misunderstood, partly due the philosophical significance of ''decentralization'' which is seen as a key feature of blockchain technology. It has also been at the heart of disputes within the Bitcoin community that have lead to contentious forks that have split the Bitcoin blockchain on two occasions as well as a general slow-down in the development of the technology.

On one hand the role of transaction validation and mining cannot be [[Attacks on Bitcoin|dominated by a single entity]] as the network would cease to provide any cryptographic or game theoretic advantages over existing centralized digital money systems. However, one of the main barriers to scaling is the extreme waste caused by forcing all users to perform all Bitcoin functions. Whilst it is true that engineering trade-offs between decentralization and scalability have to be made, it is the firm belief of the Bitcoin SV community that scalability can be achieved through specialization whilst maintaining strong security and moderate decentralization.

==References==
1. Rüdiger Schollmeier, [https://www.researchgate.net/publication/3940901_A_Definition_of_Peer-to-Peer_Networking_for_the_Classification_of_Peer-to-Peer_Architectures_and_Applications A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications], Proceedings of the First International Conference on Peer-to-Peer Computing, IEEE (2002).

Satoshi Nakamoto

2020-01-06T13:42:22Z

Daniel:

:''For the unit, see [[Satoshis]].''

'''Satoshi Nakamoto''' is the pseudonym used by the author of the [https://bitcoin.org/en/bitcoin-paper Bitcoin Whitepaper], creator of Bitcoin and original Bitcoin client.

Satoshi Nakamoto is an amalgamation of Japanese monk Tominaga Nakamoto and Ash Ketchum - the Pokémon trainer.

The word Satoshi is Ash in Japanese. A light-hearted play on this word is Ash Ketchum. A more serious reference to Ash/ Satoshi was a cover picture of The Economist which depicted a phoenix rising from the ashes. Bitcoin began rising when the traditional financial system was crumbling and falling.

Satoshi Nakamoto is better known as [https://craigwright.net/about/#biography Dr Craig Wright].

Craig effectively went offline in January 2011, with no public involvement in the Bitcoin project. He spent some years in the private sector and did some humanitarian work. Craig did not like what Bitcoin had become, how it was being (mis)used for nefarious and dreadful criminal activities. In 2016 Craig returned to put Bitcoin back on track and to fulfill his vision.

==Satoshi's Identity==
Craig registered copyright for the Bitcoin Whitepaper with the [https://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?SC=Author&SA=Wright%2C%20Craig%20Steven%2C%201970%2D&PID=-LD5kwbSKWlbnDgVMK1jvxRknze-&BROWSE=1&HC=2&SID=6 US Copyright Office] and was awarded the rights to both the Bitcoin whitepaper entitled "Bitcoin, a peer to peer electronic cash system" and for the Bitcoin client software itself.

In late 2019 Craig delivered testimony in US federal court that confirmed he was the person behind the Satoshi Nakamoto pseudonym, designed the system and wrote the whitepaper. He has also begun releasing digital copy of documents purported to be from pre-2009 which relate to Bitcoin which he is using to establish his identity as creator in a libel case in the UK.

==Some interesting quotes==
<blockquote>Like it or not, I am Satoshi.</blockquote>

<blockquote>It's very attractive to the libertarian viewpoint if we can explain it
properly. I'm better with code than with words though.</blockquote>

P2P Network

2019-09-18T07:30:00Z

Daniel: /* Malicious Peers */

Currently, for practical purposes, any software that interacts with Bitcoin will need to either communicate using the P2P Network Protocol, or interface with another system that communicates using the P2P Network Protocol. This is a practical issue not a consensus rule. This is needed because the P2P Network Protocol is the mechanism that existing miners use to announce and distribute new blocks.

== P2P Block Propagation ==
This topic refers to how nodes propagate new blocks across the network. It’s specific to new blocks, not downloading old blocks.
There are three mechanisms:
#Original - the original method with inv and getdata
#Headers
#Compact Blocks - an optimisation that has been around for a while

Other techniques exist too: Bitcoin Unlimited on the BCH network has implemented Graphene which is a refinement of the Compact Blocks method and not covered here.

Nodes on the P2P network start by assuming the Original method. If at some point a node sends the setheaders message to its peer, then it is expecting the Headers method to be used. If it sends the sendcmpct message, then it is expecting the Compact Blocks to be used. The Bitcoin SV Node implementation always tries to use Compact Blocks.

Block propagation initiates when the node updates it’s copy of the blockchain. This could be because the node has had a new block submitted to it by mining equipment, or it could be because it has received a new block over the P2P network and validated the block.

=== Original Block Propagation Mechanism ===
This is the original and default mechanism and all nodes are expected to be able to use this mechanism.

When the blockchain is updated with a new tip, the node sends out a block inv message to all of its peers which contains the block id (the hash of the block). The peers check this message and will request the block from the node with the getdata message if they need the block.

Note that the node will only send the inv message to the peers which it thinks do not yet have the block. If a peer has already sent an inv message for the same block to the node, then the node concludes that the peer already has the block so it does not bother sending the inv message to that peer. This is an optimization performed by the Bitcoin SV Node software and is not strictly required.

This mechanism causes the peer to download the entire block from the node. This is quite wasteful since the majority of the block is transaction data and its very likely that peer already has most of the transactions, which is why the Compact Blocks technique was added.

=== Headers Block Propagation Mechanism ===
This was a modification of the Original mechanism. Its a minor change. Instead of sending an inv message to its peers, a node will instead send a header message, which contains the information from the block header (which does not include the list of transactions). This will provide more data for the node to make a decision about whether it wants to obtain the block or not.

=== Compact Blocks Propagation Mechanism ===
As noted above, the problem with the original mechanism is that it sends a lot of data that the peer probably already has. Compact Blocks was designed to avoid this.

When activated, the node will send a cmpctblock message instead of the inv message (Note: I need to check this, this would be a bit wasteful if the peer already had the block). This message contains the block header, the list of transactions in the block, and the full transactions that the node expects that the peer does not already have (such as the coinbase transaction). The recipient will then check for transactions it does not already have and request those.

It’s a bit more complicated than that, but that is the main idea. It actually uses “short ids”, which are shortened forms of the transaction ids.

The specification for Compact Blocks is in [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP-0152].

== Malicious Peers ==
Software implementations often implement a “banning” technique to mitigate against Denial of Service type attacks by peers.