https://wiki.bitcoinsv.io/api.php?action=feedcontributions&feedformat=atom&user=Owen+VaughanBitcoin Wiki - User contributions [en]2026-05-29T17:20:42ZUser contributionsMediaWiki 1.33.0https://wiki.bitcoinsv.io/index.php?title=The_Bitcoin_Network&diff=2465The Bitcoin Network2020-05-06T13:10:39Z<p>Owen Vaughan: </p>
<hr />
<div>The Bitcoin network is a made up of one (and only one) type of node that is defined in section 5 of the white paper. These nodes are often referred to as miners and are characterised by an ability to produce valid blocks, distribute them to their peers (other nodes), and validate blocks they receive. Nodes are responsible for upholding the consensus mechanism of the system based on block publication and proof-of-work. There is no other definition of a node in the Bitcoin network.<br />
<br />
* A node constructs, distributes and validates blocks<br />
<br />
Old nodes may drop off the network and new nodes may join at any time. There is no hierarchy in the process of block distribution or validation, making the network truly peer-to-peer. Nodes are incentivised to maintain a high degree of connectivity with other nodes. This means that the network topology is that of a nearly complete graph. At any one time there are typically less than ten nodes that publish the majority of blocks.<br />
<br />
[[File:nearly_complete_graph.png|thumb|300px|centre|An example of the bitcoin network with six nodes. The topology is that of a nearly complete graph.]]<br />
<br />
Bitcoin nodes also validate and propagate transactions. Transactions enter the network through users of the system. The users themselves are outside the Bitcoin network and interact with one or more Bitcoin nodes through client software.<br />
<br />
* A user interacts with nodes through client software<br />
<br />
An example of a user may be a service provider, storage entity, propagation entity, autonomous agent (smart contract), or a wallet belonging to a person or business. Note that the users do not play a role in the production, distribution or validation of blocks on the Bitcoin network. Therefore, they are not involved in the consensus process.<br />
<br />
The direct connection between users for the purpose of sending a transaction does not necessarily mean that they are part of any network. However, there may exist complex user networks that are separate to the Bitcoin network. A user may be a node on their own network whilst being a client on the Bitcoin network. Such networks may be thought of as being overlaid on top of the Bitcoin network. User networks may be peer-to-peer or hierarchical in structure, for example service providers and consumers. These user networks may be layered on top of one-another in such a way that they form a [[Bitcoin Layered Networks|Bitcoin-Layered Network]].<br />
<br />
There is no requirement for a Bitcoin node to be made up of a single machine. A node may be made up of several different linked systems including routing, database and processing modules. However, there is no such thing as an archival or transaction propagation node on the Bitcoin network.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=The_Bitcoin_Network&diff=2462The Bitcoin Network2020-05-05T14:35:56Z<p>Owen Vaughan: </p>
<hr />
<div>The bitcoin network is a made up of one (and only one) type of node that is defined in section 5 of the white paper. These nodes are often referred to as miners and are characterised by an ability to produce valid blocks, distribute them to their peers (other nodes), and validate blocks they receive. Nodes are responsible for upholding the consensus mechanism of the system based on block publication and proof-of-work. There is no other definition of a node in the bitcoin network.<br />
<br />
* A node constructs, distributes and validates blocks<br />
<br />
Old nodes may drop off the network and new nodes may join at any time. There is no hierarchy in the process of block distribution or validation, making the network truly peer-to-peer. Nodes are incentivised to maintain a high degree of connectivity with other nodes. This means that the network topology is that of a nearly complete graph. At any one time there are typically less than ten nodes that publish the majority of blocks.<br />
<br />
Bitcoin nodes also validate and propagate transactions. Transactions enter the network through users of the system. The users themselves are outside the bitcoin network and interact with one or more bitcoin nodes through client software.<br />
<br />
* A user interacts with nodes through client software<br />
<br />
An example of a user may be a service provider, storage entity, propagation entity, autonomous agent (smart contract), or a wallet belonging to a person or business. Note that the users do not play a role in the production, distribution or validation of blocks on the bitcoin network. Therefore, they are not involved in the consensus process.<br />
<br />
The direct connection between users for the purpose of sending a transaction does not necessarily mean that they are part of any network. However, there may exist complex user networks that are separate to the bitcoin network. A user may be a node on their own network whilst being a client on the bitcoin network. Such networks may be thought of as being overlaid on top of the bitcoin network. User networks may be peer-to-peer or hierarchal in structure, for example service providers and consumers. These user networks may be layered on top of one-another in such a way that they form a [[Bitcoin Layered Networks|Bitcoin-Layered Network]].<br />
<br />
There is no requirement for a bitcoin node to be made up of a single machine. A node may be made up of several different linked systems including routing, database and processing modules. However, there is no such thing as an archival or transaction propagation node on the bitcoin network.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Under_Construction&diff=2451Under Construction2020-05-03T19:22:00Z<p>Owen Vaughan: </p>
<hr />
<div>The page you are looking for is under construction! Please check back soon<br />
<br />
Click back in your browser to go back to where you were or click [[Main Page|HERE]] to go back to the main page.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Under_Construction&diff=2450Under Construction2020-05-03T19:21:52Z<p>Owen Vaughan: </p>
<hr />
<div>The page you are looking for is under construction! Please check back soon<br />
<br />
Click back in your browser to go back to where you were or click [[Main Page|HERE]] to go back to the main page.<br />
<br />
Test</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=2449Nearly Complete Graph2020-05-03T13:19:48Z<p>Owen Vaughan: </p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph relative to the size of the graph. <br />
<br />
== Mathematical Definition ==<br />
<br />
Consider a graph with vertices <math>v</math>, edges <math>e</math>, and genus <math>g</math>.<br />
<br />
Calculate<br />
<br />
:<math> X = (e - 3v + 6)/6 </math>.<br />
<br />
Let <math>\lceil X \rceil</math> denote the smallest integer greater than or equal to <math>X</math>. All graphs satisfy Euler's lower bound <br />
<br />
:<math> g \geq \lceil X \rceil</math> .<br />
<br />
For complete graphs <math> g =\lceil X \rceil</math> and the bound is saturated. <br />
<br />
One may start with a complete graph and remove <math>p</math> edges such that the remaining graph satisfies <br />
* Euler's lower bound is saturated <math> g =\lceil X \rceil</math><br />
* The graph is connected<br />
Let <math> NC(n) </math> denote the maximum number of possible edge removals from the complete graph <math>K_n</math> such that the above two properties hold no matter which edges are removed. A graph with <math>n</math> vertices is ''nearly complete'' if it can be obtained by removing <math> p \leq NC(n) </math> edges from the complete graph <math>K_n</math>.<br />
<br />
==References==<br />
* [https://link.springer.com/article/10.1007/BF01836527 ''The genus of nearly complete graphs-case 6'', Jonathan L. Gross, Aeq. Math. 13, 243–249 (1975) doi:10.1007/BF01836527]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=The_Bitcoin_Network&diff=2249The Bitcoin Network2020-02-19T12:36:47Z<p>Owen Vaughan: </p>
<hr />
<div>The Bitcoin SV mining network is the collection of nodes running the Bitcoin SV client software [https://github.com/bitcoin-sv/bitcoin-sv/] and actively create new blocks. Layers are built on top of the core mining network that consist of other types of nodes. These may correspond to service providers, users, smart contracts, mining pools and applications that interact with, and support, the core mining network. <br />
<br />
==Actors in the Bitcoin SV Network==<br />
* '''Miner''' - A node that validates and propagates transactions, and adds new blocks to the blockchain by finding proof of work solutions.<br />
* '''Service provider''' - A node that serves blockchain data to users and/or propagates transactions to the mining core on behalf of users. For example, such a node may collect and serve all transactions containing a particular OP_RETURN protocol flag. This data may be obtained by users sending it to the service provider directly, or there may be an agreement with one or more mining nodes to propagate such transactions to the service provider.<br />
* '''User''' - A node that can create and broadcast new transactions. A user can interact with the mining core through [[Simplified Payment Verification|SPV]] controls. This means that they can send transactions to a mining core node, ask a core node if a transactions has been accepted in its mempool/candidate block, ask for the Merkle proof of a transaction that has been mined in a block, and ask for an up-to-date list of block headers.<br />
* '''Smart contract''' - A node with a pre-defined set of states which can be altered by receiving a transaction. The smart contract itself may be able to broadcast transactions in response to a change of state. A lightweigth smart contract has [[Simplified Payment Verification|SPV]] connectivity to the mining core, and should receive transactions directly from users. An enterpise level smart contract may have an agreement with a subset of mining nodes to propagate transactions to the smart contract that trigger a change of state.<br />
<br />
== Messages ==<br />
<br />
Bitcoin SV uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin SV is fully able to use ports other than 8333 via the -port parameter. IPv6 is [https://bitcointalk.org/index.php?topic=81378.0 supported] with all versions later than Bitcoind/Bitcoin-Qt v0.7. <br />
<br />
* ''version'' - Information about program version and block count. Exchanged when first connecting.<br />
* ''verack'' - 'Version Acknowledgement'. Sent in response to a version message to acknowledge that the peer is willing to connect.<br />
* ''addr'' - List of one or more IP addresses and ports.<br />
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.<br />
* ''getdata'' - Request a single block or transaction by hash.<br />
* ''merkleblock'' - Request a filtered block using the inventory type MSG_MERKLEBLOCK. Normally used to communicate transaction data to an SPV client.<br />
* ''getblocks'' - Request an ''inv'' of all blocks in a range.<br />
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.<br />
* ''tx'' - Send a transaction. This is sent only in response to a ''getdata'' request.<br />
* ''block'' - Send a block. This is sent only in response to a ''getdata'' request.<br />
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.<br />
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).<br />
* ''mempool'' - Requests TXIDs of transactions that the receiving node has validated but has not appeared in a block.<br />
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP Transactions|IP transaction]].<br />
* ''alert'' - Send a network alert.<br />
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.<br />
* ''pong'' - the pong message replies to a ping message, proving to the pining node that the ponging node is still responsive.<br />
* ''notfound'' - Reply to a 'getdata' message which requested an object not available for relay. <br />
* ''reject'' - Informs the receiving node that one of it's previous messages has been rejected.<br />
* ''sendheaders'' - Indicates that the node prefers to receive new block announcements via 'headers' as opposed to 'inv' messages.<br />
* ''feefilter'' - Tells the receiving peer not to send any transactions that do not meet the specified fee rate.<br />
* ''sendcmpct'' - Indicates that a node is wiling to receive new block announcements via 'cmpctblock' message rather than an 'inv'. <br />
* ''cmpctblock'' - Contains a 'CBlockHeaderAndShortTxIDs' object providing a header and list of short txids.<br />
* ''getblocktxn'' - Block transactions request used to request a list transaction by specifying their indexes and block hash.<br />
* ''blocktxn'' - Block transaction message provides the transactions requested by a 'getblocktxn' message.<br />
* ''protoconf'' - Sent after 'verack' message, regardless of the peer's protocol version.<br />
<br />
<br />
More information and in-depth technical information is in the [https://github.com/bitcoin-sv/bitcoin-sv/blob/a64b6a349a68207477ec8848c9c8c025d249fe35/src/protocol.h Protocol Specification].<br />
<br />
== Connection ==<br />
<br />
To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.<br />
<br />
The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).<br />
<br />
You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. ''addr'' messages often contain only one address, but sometimes contain up to 1000. This is most common at the beginning of an exchange.<br />
<br />
== Standard relaying ==<br />
<br />
When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers ask for or relay transactions only if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.<br />
<br />
Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.<br />
<br />
Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.<br />
<br />
Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by one of the people with the private key), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.<br />
<br />
== Initial block download ==<br />
<br />
At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.<br />
<br />
== Thin SPV Clients ==<br />
<br />
Simplified Payment Verification was introduced as part of the Bitcoin whitepaper. [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037] introduced support for thin or lite clients by way of Simple Payment Verification. SPV clients do not need to download the full block contents to verify the existence of funds in the blockchain, but rely on the chain of block headers and bloom filters to obtain the data they need from other nodes. This method of client communication allows high security trustless communication with full nodes, but at the expensive of some privacy as the peers can deduce which addresses the SPV client is seeking information about. <br />
<br />
The desktop wallet [https://electrumsv.io/ ElectrumSV] works in this fashion using the Python library [https://github.com/kyuupichan/bitcoinX/tree/master/bitcoinx bitcoinX] as their foundation. [https://www.moneybutton.com/ Moneybutton] on the other hand uses [https://github.com/moneybutton/bsv Javascript Bitcoin SV library] for client communication.<br />
<br />
== Bootstrapping ==<br />
<br />
You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.<br />
<br />
Bitcoin has three methods of finding peers.<br />
<br />
=== Addr ===<br />
<br />
The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.<br />
<br />
Bitcoin SV comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.<br />
<br />
The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to connect only to a specific node.<br />
<br />
=== DNS ===<br />
<br />
Bitcoin SV looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the default seeding mechanism, as of v0.6.x and later.<br />
<br />
=== IRC ===<br />
<br />
As-of version 0.6.x of the Bitcoin client IRC bootstrapping is no longer enabled by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. The information below is accurate for most versions prior.<br />
<br />
Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.<br />
<br />
== Heartbeat ==<br />
<br />
If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.<br />
<br />
If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.<br />
<br />
== See Also ==<br />
<br />
* [[Peer-to-Peer Network Architecture]]<br />
* [[Transaction Pools]]<br />
* [[Protocol|Protocol Specification]]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Network 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.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=The_Bitcoin_Network&diff=2248The Bitcoin Network2020-02-19T12:34:00Z<p>Owen Vaughan: </p>
<hr />
<div>The Bitcoin SV mining network is the collection of nodes running the Bitcoin SV client software [https://github.com/bitcoin-sv/bitcoin-sv/] and actively create new blocks. Layers are built on top of the core mining network that consist of other types of nodes. These may correspond to service providers, users, smart contracts, mining pools and applications that interact with, and support, the core mining network. <br />
<br />
==Actors in the Bitcoin SV Network==<br />
* '''Miner''' - A node that validates and propagates transactions, and adds new blocks to the blockchain by finding proof of work solutions.<br />
* '''Service provider''' - A node that serves blockchain data to users and/or propagates transactions to the mining core on behalf of users. For example, such a node may collect and serve all transactions satisfying a particular OP_RETURN protocol flag. This data may be obtained by users sending it to the service provider directly, or there may be an agreement with one or more mining nodes to propagate such transactions to the service provider.<br />
* '''User''' - A node that can create and broadcast new transactions. A user can interact with the mining core through [[Simplified Payment Verification|SPV]] controls. This means that they can send transactions to a mining core nodes, ask a core node if a transactions has been accepted in its mempool/candidate block, ask for the Merkle proof of a transaction that has been mined in a block, and ask for an up-to-date list of block headers.<br />
* '''Smart contract''' - A node with a pre-defined set of states which can be altered by receiving a transaction. The smart contract itself may be able to broadcast transactions in response to a change of state. A lightweigth smart contract has [[Simplified Payment Verification|SPV]] to the mining core, and should receive transactions directly from users. An enterpise level smart contract may have an agreement with a subset of mining nodes to propagate transactions to the smart contract that trigger a change of state, similar to a service provider node.<br />
<br />
== Messages ==<br />
<br />
Bitcoin SV uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin SV is fully able to use ports other than 8333 via the -port parameter. IPv6 is [https://bitcointalk.org/index.php?topic=81378.0 supported] with all versions later than Bitcoind/Bitcoin-Qt v0.7. <br />
<br />
* ''version'' - Information about program version and block count. Exchanged when first connecting.<br />
* ''verack'' - 'Version Acknowledgement'. Sent in response to a version message to acknowledge that the peer is willing to connect.<br />
* ''addr'' - List of one or more IP addresses and ports.<br />
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.<br />
* ''getdata'' - Request a single block or transaction by hash.<br />
* ''merkleblock'' - Request a filtered block using the inventory type MSG_MERKLEBLOCK. Normally used to communicate transaction data to an SPV client.<br />
* ''getblocks'' - Request an ''inv'' of all blocks in a range.<br />
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.<br />
* ''tx'' - Send a transaction. This is sent only in response to a ''getdata'' request.<br />
* ''block'' - Send a block. This is sent only in response to a ''getdata'' request.<br />
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.<br />
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).<br />
* ''mempool'' - Requests TXIDs of transactions that the receiving node has validated but has not appeared in a block.<br />
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP Transactions|IP transaction]].<br />
* ''alert'' - Send a network alert.<br />
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.<br />
* ''pong'' - the pong message replies to a ping message, proving to the pining node that the ponging node is still responsive.<br />
* ''notfound'' - Reply to a 'getdata' message which requested an object not available for relay. <br />
* ''reject'' - Informs the receiving node that one of it's previous messages has been rejected.<br />
* ''sendheaders'' - Indicates that the node prefers to receive new block announcements via 'headers' as opposed to 'inv' messages.<br />
* ''feefilter'' - Tells the receiving peer not to send any transactions that do not meet the specified fee rate.<br />
* ''sendcmpct'' - Indicates that a node is wiling to receive new block announcements via 'cmpctblock' message rather than an 'inv'. <br />
* ''cmpctblock'' - Contains a 'CBlockHeaderAndShortTxIDs' object providing a header and list of short txids.<br />
* ''getblocktxn'' - Block transactions request used to request a list transaction by specifying their indexes and block hash.<br />
* ''blocktxn'' - Block transaction message provides the transactions requested by a 'getblocktxn' message.<br />
* ''protoconf'' - Sent after 'verack' message, regardless of the peer's protocol version.<br />
<br />
<br />
More information and in-depth technical information is in the [https://github.com/bitcoin-sv/bitcoin-sv/blob/a64b6a349a68207477ec8848c9c8c025d249fe35/src/protocol.h Protocol Specification].<br />
<br />
== Connection ==<br />
<br />
To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.<br />
<br />
The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).<br />
<br />
You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. ''addr'' messages often contain only one address, but sometimes contain up to 1000. This is most common at the beginning of an exchange.<br />
<br />
== Standard relaying ==<br />
<br />
When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers ask for or relay transactions only if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.<br />
<br />
Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.<br />
<br />
Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.<br />
<br />
Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by one of the people with the private key), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.<br />
<br />
== Initial block download ==<br />
<br />
At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.<br />
<br />
== Thin SPV Clients ==<br />
<br />
Simplified Payment Verification was introduced as part of the Bitcoin whitepaper. [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037] introduced support for thin or lite clients by way of Simple Payment Verification. SPV clients do not need to download the full block contents to verify the existence of funds in the blockchain, but rely on the chain of block headers and bloom filters to obtain the data they need from other nodes. This method of client communication allows high security trustless communication with full nodes, but at the expensive of some privacy as the peers can deduce which addresses the SPV client is seeking information about. <br />
<br />
The desktop wallet [https://electrumsv.io/ ElectrumSV] works in this fashion using the Python library [https://github.com/kyuupichan/bitcoinX/tree/master/bitcoinx bitcoinX] as their foundation. [https://www.moneybutton.com/ Moneybutton] on the other hand uses [https://github.com/moneybutton/bsv Javascript Bitcoin SV library] for client communication.<br />
<br />
== Bootstrapping ==<br />
<br />
You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.<br />
<br />
Bitcoin has three methods of finding peers.<br />
<br />
=== Addr ===<br />
<br />
The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.<br />
<br />
Bitcoin SV comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.<br />
<br />
The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to connect only to a specific node.<br />
<br />
=== DNS ===<br />
<br />
Bitcoin SV looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the default seeding mechanism, as of v0.6.x and later.<br />
<br />
=== IRC ===<br />
<br />
As-of version 0.6.x of the Bitcoin client IRC bootstrapping is no longer enabled by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. The information below is accurate for most versions prior.<br />
<br />
Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.<br />
<br />
== Heartbeat ==<br />
<br />
If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.<br />
<br />
If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.<br />
<br />
== See Also ==<br />
<br />
* [[Peer-to-Peer Network Architecture]]<br />
* [[Transaction Pools]]<br />
* [[Protocol|Protocol Specification]]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Network 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.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Peer-to-Peer_Network_Architecture&diff=2233Peer-to-Peer Network Architecture2020-02-19T11:15:02Z<p>Owen Vaughan: </p>
<hr />
<div>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]. <br />
<br />
==Bitcoin as a Peer-to-Peer Network==<br />
<br />
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 has 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.<br />
<br />
==Peer-to-Peer Architecture and the Bitcoin Scalability Dispute==<br />
<br />
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. <br />
<br />
On the 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 to 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.<br />
<br />
==References==<br />
1. Rüdiger Schollmeier, 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).</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Peer-to-Peer_Network_Architecture&diff=2232Peer-to-Peer Network Architecture2020-02-19T11:14:51Z<p>Owen Vaughan: </p>
<hr />
<div>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]. <br />
<br />
==Bitcoin as a Peer-to-Peer Network==<br />
<br />
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 has 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.<br />
<br />
==Peer-to-Peer Architecture and the Bitcoin Scalability Dispute==<br />
<br />
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. <br />
<br />
On the 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 to 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.<br />
<br />
<br />
==References==<br />
1. Rüdiger Schollmeier, 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).</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Metanet_Protocol&diff=2229Metanet Protocol2020-02-19T11:10:18Z<p>Owen Vaughan: </p>
<hr />
<div>[[File:Metanet_graph.png|thumb|A typical Metanet graph.]]<br />
<br />
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 blockchain. The Metanet protocol can be used to replicate file systems, internet domains, ownership structures and code repositories on the blockchain.<br />
<br />
There are tools available to [[Metanet_Protocol#Writing Metanet Graphs|write]] and [[Metanet_Protocol#Reading Metanet Graphs|read]] Metanet graphs, and a growing a range of [[Metanet_Protocol#Usage|projects]] that use the Metanet protocol to structure their application data.<br />
<br />
==Node and Edge Structure==<br />
<br />
The Metanet Protocol is a protocol for creating graph structures comprising nodes and edges on the blockchain. In the Metanet protocol the following definitions of node and edge are used:<br />
<br />
* '''Metanet Node''' - A transaction using the Metanet protocol format.<br />
* '''Metanet Edge''' - An input signature linking two Metanet nodes.<br />
<br />
A Metanet node is a transaction that conforms to the Metanet transaction format specified in [https://nchain.com/app/uploads/2019/06/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. <br />
<br />
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.<br />
<br />
The Metanet-specific data attributes of a Metanet node transaction include the following:<br />
<br />
* '''<math>P_{node}</math>''' - the public key defining the node.<br />
* '''<math>TxID_{node}</math>''' - the unique transaction ID of the node. <br />
* '''<math>P_{parent}</math>''' - the public key defining a parent of the node.<br />
* '''<math>SigP_{parent}</math>''' - a signature created using the private key associated with the public key defining a parent of the node.<br />
* '''<math>TxID_{parent}</math>''' - the unique transaction ID of the a parent of the node.<br />
<br />
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''. <br />
<br />
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).<br />
<br />
A Metanet transaction is defined as a transaction that contains an OP_FALSE OP_RETURN payload containing:<br />
<br />
* The Metanet flag<br />
[[File:Metanet_node.png|thumb|A Metanet node transaction.]]<br />
* A node public key '''<math>P_{node}</math>'''<br />
* A parent transaction ID '''<math>TxID_{parent}</math>''' (null if a root node).<br />
<br />
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>'''.<br />
<br />
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.<br />
<br />
A basic example of a Metanet node transaction that conforms to this format is shown in the diagram on the right.<br />
<br />
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.]]<br />
<br />
The fact that the appearance of this signature is in a transaction input means that the signature itself is validated by miners. This means that only valid Metanet child nodes can appear on the blockchain, and any spoofing attempts will be considered invalid.<br />
<br />
<br />
== Rules of the Metanet Protocol==<br />
<br />
The Metanet protocol specifies a simple and extensible rule set for creating Metanet graphs and data structures. The base rule set is the following:<br />
<br />
* Nodes are transactions.<br />
* Edges are created by signatures.<br />
* Each node is uniquely identified by the pair of attributes: '''<math>P_{node}</math>''', '''<math>TxID_{node}</math>'''.<br />
* Each node must specify the node ID of itself and its parent: '''<math>ID_{node}</math>''', '''<math>ID_{parent}</math>'''.<br />
<br />
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.<br />
<br />
Metanet graph structures may be created using this base rule set alone. It is also possible to impose additional rules to Metanet graph structures in order to achieve different properties for data structures.<br />
<br />
A simple extension of the rule set is to impose the following constraints:<br />
[[File:Metanet_rules.png|thumb|A simple Metanet rule set.]]<br />
<br />
* The in-degree of a node should be 0 (no parent) or 1 (one parent).<br />
* The out-degree of a node should be a free parameter.<br />
<br />
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 permissioning structure of a Metanet graph.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=The_Metanet&diff=2223The Metanet2020-02-19T11:01:47Z<p>Owen Vaughan: </p>
<hr />
<div>[[File:post.png|thumb|The Metanet Ecosystem]]<br />
'''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:<br />
<br />
* The concept of value-based internet built on [[Main_Page|Bitcoin SV]].<br />
* The [[Metanet_Protocol|Metanet Protocol]].<br />
<br />
The Metanet was first announced as a concept by Dr. Craig Wright at the [https://www.youtube.com/watch?v=MXpHHZqe6vI CoinGeek Week] conference in London on November 30th 2018. <br />
<br />
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.<br />
<br />
==Core Principles==<br />
<br />
The motivations for the Metanet are linked to well-known problems with the existing Internet and e-commerce, which include the following:<br />
<br />
* Reliance on intermediaries for payments.<br />
* Lack of a granular micropayment layer.<br />
* Walled-garden applications and data silos.<br />
* Concerns over data privacy and ownership for users.<br />
* Prevalence of spam, trolling and bots in online social platforms.<br />
<br />
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. <br />
<br />
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:<br />
<br />
* Information is attributed value.<br />
* Quality is incentivised over quantity.<br />
* The cost of dishonest behaviour (e.g. trolling) is increased.<br />
* Users own their data.<br />
<br />
==The Metanet Protocol==<br />
[[File:Metanet_DAG.png|thumb|The Metanet Protocol]]<br />
<br />
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.<br />
<br />
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.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Small_World_Network&diff=2221Small World Network2020-02-19T10:51:13Z<p>Owen Vaughan: </p>
<hr />
<div>A small-world network is a network in which most nodes are not directly connected, but where the neighbors of any given node are likely to be neighbors of each other and most nodes can be reached from every other node by a small number of hops or steps. Specifically, a small-world network is defined to be a network where the typical minimum distance L between two randomly chosen nodes (the minimum number of steps required) grows proportionally to the logarithm of the number of nodes N in the network, that is:<br />
<br />
:<math>L \propto \log N</math><br />
<br />
The economic incentives of mining drives node operators to form a "Small World Network" which we refer to as the Bitcoin Core Network. The typical distance between any two nodes in the Bitcoin Core Network is just 1.3. <br />
<br />
This property is emergent over time as miners learn how to optimise the network topology over time to create more efficient communication between nodes. This memory function leads to the Core Network forming what is known as a "giant node". This giant node becomes more and more densely connected over time, trending towards a [[Nearly Complete Graph]]. The giant node forms the center of a [[Mandala Network]] that is what all peers on the Bitcoin network connect to.<br />
<br />
A video representation of the Bitcoin network forming a highly connected mesh can be seen [file: here]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=2220Main Page2020-02-19T10:44:10Z<p>Owen Vaughan: </p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [[Bitcoin whitepaper|Bitcoin white paper]] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The [[Genesis block|first block]] was mined on the 3rd of January 2009.<br />
<br />
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. <br />
<br />
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 on the network<br />
<br />
===Applications===<br />
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.<br />
<br />
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 Micropayments become a means to both access and monetize data.<br />
<br />
Applications which make use of the immutable nature of the [[Block_chain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasingly 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.<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all transactions that have ever been timestamped on 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.<br />
<br />
[[File:Chain_of_Signatures.png|frame|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of an ordered list of [[TXID|transaction hashes]] and a [[Block hashing algorithm#Block_Header|header]] which includes the root generated by hashing the listed transactions into a [[wikipedia:Merkle tree|Merkle tree]], a timestamp, a reference to the block it builds upon and the means to validate the [[Proof of Work]] needed for other miners to accept the block as valid.<br />
<br />
Blocks form a second layer DAG called the [[Block chain]] 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 becomes 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]].<br />
<br />
[[File:Block_Chain.png|frame|centre|alt=A chain of blocks]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Simplified_Payment_Verification.png|frame|centre|alt=Simplified payment verification]]<br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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, it does not become part of the ledger.<br />
<br />
===Transactions===<br />
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 output via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses '[[UTXO|coins]]' as inputs and spends them into a new set of coins as [[VOUT|outputs]]. When coins are spent in a transaction they are destroyed.<br />
<br />
[[File:Transaction.png|frame|centre|alt=Transaction inputs and outputs]]<br />
<br />
The Bitcoin scripting language can be used in a way that is [[wikipedia:Turing_completeness|Turing complete]], creating a [[wikipedia:Turing_machine|Turing machine]] that uses the Bitcoin ledger as a tape, reading to and writing from the transaction graph as needed.<br />
<br />
The script 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]].<br />
<br />
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 last transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 vote on [[Network|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.<br />
<br />
[[File:Proof_of_Work.png|frame|centre|alt=A chain of hash based proof of work]]<br />
<br />
During the mining process, a node gather transactions from the network 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. 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.<br />
<br />
[[File:Merkle tree.png|frame|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 all miners are connected to all other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming a [[Mandala Network]]. In this shell network, peers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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. This can include the freezing or transferring of bitcoins stored on the ledger, or the rejection of transactions or blocks that try to spend bitcoins identified as proceeds of crime.<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are issued by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, the 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed are 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]] and has been [[Attacks on Bitcoin|attacked]] in many ways since its inception. For example, at the time of writing, certain other groups are wrongly using the 'Bitcoin' name to refer to their own projects. The most famous of these uses a software implementation known as 'Bitcoin core' with tokens from the ledger traded as 'BTC' [[Bitcoin until today|(more information)]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=2218Main Page2020-02-19T10:23:46Z<p>Owen Vaughan: </p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [[Bitcoin whitepaper|Bitcoin white paper]] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The [[Genesis block|first block]] was mined on the 3rd of January 2009.<br />
<br />
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. <br />
<br />
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 on the network<br />
<br />
===Applications===<br />
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 however developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect.<br />
<br />
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 Micropayments become a means to both access and monetize data.<br />
<br />
Applications which make use of the immutable nature of the [[Block_chain|Bitcoin Ledger]] to store and retrieve data are increasingly emerging. [[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.<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all transactions that have ever been timestamped on 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.<br />
<br />
[[File:Chain_of_Signatures.png|frame|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of an ordered list of [[TXID|transaction hashes]] and a [[Block hashing algorithm#Block_Header|header]] which includes the root generated by hashing the listed transactions into a [[wikipedia:Merkle tree|Merkle tree]], a timestamp, a reference to the block it builds upon and the means to validate the [[Proof of Work]] needed for other miners to accept the block as valid.<br />
<br />
Blocks form a second layer DAG called the [[Block chain]] 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 becomes 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]].<br />
<br />
[[File:Block_Chain.png|frame|centre|alt=A chain of blocks]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Simplified_Payment_Verification.png|frame|centre|alt=Simplified payment verification]]<br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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, it does not become part of the ledger.<br />
<br />
===Transactions===<br />
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 output via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses '[[UTXO|coins]]' as inputs and spends them into a new set of coins as [[VOUT|outputs]]. When coins are spent in a transaction they are destroyed.<br />
<br />
[[File:Transaction.png|frame|centre|alt=Transaction inputs and outputs]]<br />
<br />
The Bitcoin scripting language can be used in a way that is [[wikipedia:Turing_completeness|Turing complete]], creating a [[wikipedia:Turing_machine|Turing machine]] that uses the Bitcoin ledger as a tape, reading to and writing from the transaction graph as needed.<br />
<br />
The script 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]].<br />
<br />
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 last transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 vote on [[Network|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.<br />
<br />
[[File:Proof_of_Work.png|frame|centre|alt=A chain of hash based proof of work]]<br />
<br />
During the mining process, a node gather transactions from the network 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. 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.<br />
<br />
[[File:Merkle tree.png|frame|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 all miners are connected to all other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming a [[Mandala Network]]. In this shell network, peers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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. This can include the freezing or transferring of bitcoins stored on the ledger, or the rejection of transactions or blocks that try to spend bitcoins identified as proceeds of crime.<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are issued by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, the 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed are 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]] and has been [[Attacks on Bitcoin|attacked]] in many ways since its inception. For example, at the time of writing, certain other groups are wrongly using the 'Bitcoin' name to refer to their own projects. The most famous of these uses a software implementation known as 'Bitcoin core' with tokens from the ledger traded as 'BTC' [[Bitcoin until today|(more information)]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Mandala_Network&diff=914Mandala Network2020-01-07T09:37:03Z<p>Owen Vaughan: </p>
<hr />
<div>Mandala networks refer a family of networks are fast and cost-effective yet robust against failures and attacks. They are built up in layers, or ''shells/generations'', and their name derives from their visual similarity to Mandala images.<br />
<br />
They are defined by construction in [1] as a mathematical graph with certain rules for the distribution of nodes and edges in each shell, and how they connect to nodes in the shell below. They are characterised by being<br />
* Ultra-small-world<br />
* Highly sparse<br />
<br />
In the basic method for construction, Mandala networks are characterised by three paramaters <math>(n_1, b, \lambda)</math>, where <math>n_1</math> is the number of nodes in the first generation, <math>b</math> is the number of new nodes added to each node in subsequent shells, and <math>\lambda</math> is the number of connections between nodes in the same shell (other than the first shell). The choice of these parameters determines a ''type'' of Mandala network, where a unique Mandala network is determined by type and total number of shells <math>g</math>. <br />
<br />
In the first shell there are <math>n_1</math> nodes that form a connected graph. A second shell is created by connecting each node in the first shell with <math>b</math> nodes in the second shell, and connecting each node in the second shell to <math>\lambda</math> nodes in the second shell. This method is used to create a third shell where, in addition, each node is also connected to its ancestor node in the first shell. This process can be repeated itaratively to create <math>g</math> shells. Because each node is connected directly to a node in the first shell, and each node in the first shell is directly to another node in the first shell, the maximum shortest path length between nodes is 3.<br />
<br />
If the number of nodes in each shell is labelled by <math> n_i </math> then the total number of nodes on the network is given by<br />
<br />
<math>N = \sum_{i=1}^{g} n_i </math>.<br />
<br />
Due to the symmetry of the construction, the mean shortest path length is given by<br />
<br />
<math>\langle l \rangle = \sum_{i=1}^{g} n_i \phi_i </math><br />
<br />
where <math>\phi_i </math> is the sum of the shortest path lengths connecting a node in the <math>i</math>-th shell with all other nodes in the network. It can be shown that <br />
<br />
<math>\langle l \rangle = \alpha + \frac{O(N)}{N^2}</math><br />
<br />
where <math>\alpha</math> is a constant which may be determined for each network. It can be shown that <math>1 \leq \alpha < \frac{8}{3}</math>, where <math> \alpha \to \frac{8}{3}</math> as <math>N \to \infty</math>.<br />
<br />
== References ==<br />
[https://www.nature.com/articles/srep09082 (1) ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et al. Sci Rep 5, 9082 (2015) doi:10.1038/srep09082]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Mandala_Network&diff=913Mandala Network2020-01-07T09:35:14Z<p>Owen Vaughan: </p>
<hr />
<div>Mandala networks refer a family of networks are fast and cost-effective yet robust against failures and attacks. They are built up in layers, or ''shells/generations'', and their name derives from their visual similarity to Mandala images.<br />
<br />
They are defined by construction in [1] as a mathematical graph with certain rules for the distribution of nodes and edges in each shell, and how they connect to nodes in the shell below. They are characterised by being<br />
* Ultra-small-world<br />
* Highly sparse<br />
<br />
In the basic method for construction, Mandala networks are characterised by three paramaters <math>(n_1, b, \lambda)</math>, where <math>n_1</math> is the number of nodes in the first generation, <math>b</math> is the number of new nodes added to each node in subsequent shells, and <math>\lambda</math> is the number of connections between nodes in the same shell (other than the first shell). The choice of these parameters determines a ''type'' of Mandala network, where a unique Mandala network is determined by type and total number of shells <math>g</math>. <br />
<br />
In the first shell there are <math>n_1</math> nodes that form a connected graph. A second shell is created by connecting each node in the first shell with <math>b</math> nodes in the second shell, and connecting each node in the second shell to <math>\lambda</math> nodes in the second shell. This method is used to create a third shell where, in addition, each node is also connected to its ancestor node in the first shell. This process can be repeated itaratively to create <math>g</math> shells. Because each node is connected directly to a node in the first shell, and each node in the first shell is directly to another node in the first shell, the maximum shortest path length between nodes is 3.<br />
<br />
If the number of nodes in each shell is labelled by <math> n_i </math> then the total number of nodes on the network is given by<br />
<br />
<math>N = \sum_{i=1}^{g} n_i </math>.<br />
<br />
Due to the symmetry of the construction, the mean shortest path length is given by<br />
<br />
<math>\langle l \rangle = \sum_{i=1}^{g} n_i \phi_i </math><br />
<br />
where <math>\phi_i </math> is the sum of the shortest path lengths connecting a node in the <math>i</math>-th shell with all other nodes in the network. It can be shown that <br />
<br />
<math>\langle l \rangle = \alpha + \frac{O(N)}{N^2}</math><br />
<br />
where <math>\alpha</math> is a constant which may be determined for each network. It can be shown that <math>1 \leq \alpha < \frac{8}{3}</math>, where <math> \alpha \to \frac{8}{3}</math> as <math>N \to \infty</math>.<br />
<br />
<br />
<br />
== References ==<br />
[https://www.nature.com/articles/srep09082 (1) ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et al. Sci Rep 5, 9082 (2015) doi:10.1038/srep09082]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Mandala_Network&diff=899Mandala Network2020-01-06T16:44:02Z<p>Owen Vaughan: </p>
<hr />
<div>Mandala networks refer a family of networks are fast and cost-effective yet robust against failures and attacks. They are built up in layers, or ''shells/generations'', and their name derives from their visual similarity to Mandala images.<br />
<br />
They are defined by construction in [1] as a mathematical graph with certain rules for the distribution of nodes and edges in each shell, and how they connect to nodes in the shell below. They are characterised by being<br />
* Ultra-small-world<br />
* Highly sparse<br />
<br />
In the basic method for construction, Mandala networks are characterised by three paramaters <math>(n_1, b, \lambda)</math>, where <math>n_1</math> is the number of nodes in the first generation, <math>b</math> is the number of new nodes added to each node in subsequent shells, and <math>\lambda</math> is the number of connections between nodes in the same shell (other than the first shell). The coice of these parameters determines a ''type'' of Mandala network, where a unique Mandala network is determined by type and total number of shells <math>g</math>. <br />
<br />
In the first shell there are <math>n_1</math> nodes that form a connected graph. A second shell is created by connecting each node in the first shell with <math>b</math> nodes in the second shell, and connecting each node in the second shell to <math>\lambda</math> nodes in the second shell. This method is used to create a third shell where, in addition, each node is also connected to its ancestor node in the first shell. This process can be repeated itaratively to create <math>g</math> shells. Because each node is connected directly to a node in the first shell, and each node in the first shell is directly to another node in the first shell, the maximum shortest path length between nodes is 3.<br />
<br />
If the number of nodes in each shell is labelled by <math> n_i </math> then the total number of nodes on the network is given by<br />
<br />
<math>N = \sum_{i=1}^{g} n_i </math>.<br />
<br />
Due to the symmetry of the construction, the mean shortest path length is given by<br />
<br />
<math>\langle l \rangle = \sum_{i=1}^{g} n_i \phi_i </math><br />
<br />
where <math>\phi_i </math> is the sum of the shortest path lengths connecting a node in the <math>i</math>-th shell with all other nodes in the network. It can be shown that <br />
<br />
<math>\langle l \rangle = \alpha + \frac{O(N)}{N^2}</math><br />
<br />
where <math>\alpha</math> is a constant which may be determined for each network. It can be shown that <math>1 \leq \alpha < \frac{8}{3}</math>, where <math> \alpha \to \frac{8}{3}</math> as <math>N \to \infty</math>.<br />
<br />
<br />
<br />
== References ==<br />
[https://www.nature.com/articles/srep09082 (1) ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et al. Sci Rep 5, 9082 (2015) doi:10.1038/srep09082]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Mandala_Network&diff=898Mandala Network2020-01-06T16:41:56Z<p>Owen Vaughan: </p>
<hr />
<div>Mandala networks refer a family of networks are fast and cost-effective yet robust against failures and attacks. They are built up in layers, or ''shells/generations'', and their name derives from their visual similarity to Mandala images.<br />
<br />
They are defined by construction in [1] as a mathematical graph with certain rules for the distribution of nodes and edges in each shell, and how they connect to nodes in the shell below. They are characterised by being<br />
* Ultra-small-world<br />
* Highly sparse<br />
<br />
In the basic method for construction, Mandala networks are characterised by three paramaters <math>(n_1, b, \lambda)</math>, where <math>n_1</math> is the number of nodes in the first generation, <math>b</math> is the number of new nodes added in each shell, and <math>\lambda</math> is the number of connections between nodes in the same shell (other than the first shell). The coice of these parameters determines a ''type'' of Mandala network, where a unique Mandala network is determined by type and total number of shells <math>g</math>. <br />
<br />
In the first shell there are <math>n_1</math> nodes that form a connected graph. A second shell is created by connecting each node in the first shell with <math>b</math> nodes in the second shell, and connecting each node in the second shell to <math>\lambda</math> nodes in the second shell. This method is used to create a third shell where, in addition, each node is also connected to its ancestor node in the first shell. This process can be repeated itaratively to create <math>g</math> shells. Because each node is connected directly to a node in the first shell, and each node in the first shell is directly to another node in the first shell, the maximum shortest path length between nodes is 3.<br />
<br />
If the number of nodes in each shell is labelled by <math> n_i </math> then the total number of nodes on the network is given by<br />
<br />
<math>N = \sum_{i=1}^{g} n_i </math>.<br />
<br />
Due to the symmetry of the construction, the mean shortest path length is given by<br />
<br />
<math>\langle l \rangle = \sum_{i=1}^{g} n_i \phi_i </math><br />
<br />
where <math>\phi_i </math> is the sum of the shortest path lengths connecting a node in the <math>i</math>-th shell with all other nodes in the network. It can be shown that <br />
<br />
<math>\langle l \rangle = \alpha + \frac{O(N)}{N^2}</math><br />
<br />
where <math>\alpha</math> is a constant which may be determined for each network. It can be shown that <math>1 \leq \alpha < \frac{8}{3}</math>, where <math> \alpha \to \frac{8}{3}</math> as <math>N \to \infty</math>.<br />
<br />
<br />
<br />
== References ==<br />
[https://www.nature.com/articles/srep09082 (1) ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et al. Sci Rep 5, 9082 (2015) doi:10.1038/srep09082]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Mandala_Network&diff=736Mandala Network2019-12-31T15:32:19Z<p>Owen Vaughan: </p>
<hr />
<div>A Mandala network refers a family of networks that allow for fast communication and are cost-effective yet are robust against failures and attacks. They are built up in layers (or ''shells'') and their name derives from their visual similarity to Mandala images.<br />
<br />
They are defined by construction in [ref Sampaio et al] as mathematical graph with certain rules for the distribution and connectedness (or ''degree'') of the nodes and edges in each shell. They are characterised by being<br />
* Ultra-small-world<br />
* Highly sparse<br />
<br />
In the basic method for construction, Mandala networks are cahracterised by three paramaters (''n_1'', ''b'', ''lambda''). Here ''n_1'' is the number of nodes in the first generation, ''b'' is the number of new nodes added to each external shell, and ''lambda'' is the scale factor. Once these parameters have been chosen, a Mandala network is uniquely determined by the total number of shells ''g''. The total number of nodes in each shell is labelled n_i and total number of nodes on the network is given by<br />
<br />
N = Sum i=1 to g n_i .<br />
<br />
In the first shell the nodes form a connected graph. A subsequent shell is created where each node is connected to its ancestor and to other nodes in the same shell. This process is repeated creating multiple shells. The degree of each node at the ith shell in a network with a total of ''g'' shells is given by<br />
<br />
Kig = b lambda^{g-i} + (i-1)<br />
<br />
The mean shortest path length is given by<br />
<br />
<l> = alpha + O(N)/N^2<br />
<br />
where alpha is a constant which may be determined for each network. Note that alpha > 1 as only in the case of a connected graph do we have alpha = 1.<br />
<br />
<br />
<br />
== References ==<br />
* [https://www.nature.com/articles/srep09082 ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et al. Sci Rep 5, 9082 (2015) doi:10.1038/srep09082]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=735Nearly Complete Graph2019-12-31T12:40:09Z<p>Owen Vaughan: </p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph relative to the size of the graph. <br />
<br />
== Mathematical Definition ==<br />
<br />
Consider a graph with vertices ''v'', edges ''e'', and genus ''g''.<br />
<br />
Euler's lower bound is defined to be<br />
<br />
''X'' = (''e'' - 3''v'' + 6)/6 .<br />
<br />
If a graph is complete then ''g'' is equal to the lowest integer greater than or equal to ''X''. Consider a number ''p'' such that the removal of any set of ''p'' or fewer edges from a complete graph yields a connected graph with ''g = X''. The maximum value of ''p'' is denoted by ''NC(v)''. <br />
<br />
A graph with vertices ''v'' is said to be ''nearly complete'' if it can be constructed by starting with a complete graph with the same number of vertices and removing up to ''NC(v)'' edges.<br />
<br />
<br />
==References==<br />
* [https://link.springer.com/article/10.1007/BF01836527 ''The genus of nearly complete graphs-case 6'', Jonathan L. Gross, Aeq. Math. 13, 243–249 (1975) doi:10.1007/BF01836527]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Mandala_Network&diff=734Mandala Network2019-12-31T12:35:17Z<p>Owen Vaughan: Created page with "== References == * [https://www.nature.com/articles/srep09082 ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et..."</p>
<hr />
<div>== References ==<br />
* [https://www.nature.com/articles/srep09082 ''Mandala Networks: ultra-small-world and highly sparse graphs'', Sampaio Filho, C., Moreira, A., Andrade, R. et al. Sci Rep 5, 9082 (2015) doi:10.1038/srep09082]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=733Nearly Complete Graph2019-12-31T12:31:33Z<p>Owen Vaughan: </p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph. <br />
<br />
== Mathematical Definition ==<br />
<br />
Consider a graph with vertices ''v'', edges ''e'', and genus ''g''.<br />
<br />
Euler's lower bound is defined to be<br />
<br />
''X'' = (''e'' - 3''v'' + 6)/6 .<br />
<br />
If a graph is complete then ''g'' is equal to the lowest integer greater than or equal to ''X''. Consider a number ''p'' such that the removal of any set of ''p'' or fewer edges from a complete graph yields a connected graph with ''g = X''. The maximum value of ''p'' is denoted by ''NC(v)''. <br />
<br />
A graph with vertices ''v'' is said to be ''nearly complete'' if it can be constructed by starting with a complete graph with the same number of vertices and removing up to ''NC(v)'' edges.<br />
<br />
<br />
==References==<br />
* [https://link.springer.com/article/10.1007/BF01836527 ''The genus of nearly complete graphs-case 6'', Jonathan L. Gross, Aeq. Math. 13, 243–249 (1975) doi:10.1007/BF01836527]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=732Nearly Complete Graph2019-12-31T12:16:52Z<p>Owen Vaughan: </p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph.<br />
<br />
<br />
What follows is a mathematically precise definition of a nearly complete graph.<br />
<br />
Consider a graph with vertices ''v'', edges ''e'', and genus ''g''.<br />
<br />
Euler's lower bound is defined to be<br />
<br />
''X'' = (''e'' - 3''v'' + 6)/6 .<br />
<br />
If a graph is complete then ''g'' is equal to the lowest integer greater than or equal to ''X''. Consider a number ''p'' such that the removal of any set of ''p'' or fewer edges from a complete graph yields a connected graph with ''g = X''. The maximum value of ''p'' is denoted by ''NC(v)''. <br />
<br />
A graph with vertices ''v'' is said to be nearly complete if it can be constructed by starting with a complete graph with the same number of vertices and removing up to ''NC(v)'' edges.<br />
<br />
<br />
==External Links==<br />
* [https://link.springer.com/article/10.1007/BF01836527 The genus of nearly complete graphs-case 6, Jonathan L. Gross, 1975]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=731Nearly Complete Graph2019-12-31T12:12:29Z<p>Owen Vaughan: </p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph.<br />
<br />
<br />
What follows is a mathematically precise definition of a nearly complete graph.<br />
<br />
Consider a graph ''G'' with vertices ''v'', edges ''e'', and genus ''g''.<br />
<br />
Euler's lower bound is defined to be<br />
<br />
''X'' = (''e'' - 3''v'' + 6)/6 .<br />
<br />
If a graph is complete then ''g'' is equal to the lowest integer greater than or equal to ''X''. Consider a number ''p'' such that the removal of any set of ''p'' or fewer edges from a complete graph yields a connected graph with ''g = X''. The maximum value of ''p'' is denoted by ''NC(v)''. It depends only on the vertex number.<br />
<br />
A graph with vertices ''v'' is nearly complete if it can be constructed by starting with a complete graph with the same number of vertices and removing up to ''NC(v)'' edges.<br />
<br />
<br />
==External Links==<br />
* [https://link.springer.com/article/10.1007/BF01836527 The genus of nearly complete graphs-case 6, Jonathan L. Gross, 1975]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=678Nearly Complete Graph2019-12-30T16:09:24Z<p>Owen Vaughan: </p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph.<br />
<br />
<br />
What follows is a mathematically precise definition of a nearly complete graph.<br />
<br />
Consider a graph ''G'' with vertices ''v'', edges ''e'', genus ''g'', and faces ''f''.<br />
<br />
Euler's lower bound is defined to be<br />
<br />
''X'' = (''e'' - 3''f'' + 6)/6 .<br />
<br />
If a graph is complete then ''g'' is equal to the lowest integer greater than or equal to ''X''. Consider a number ''p'' such that the removal of any set of ''p'' or fewer edges from a complete graph yields a connected graph with ''g = X''. The maximum value of ''p'' is denoted by ''NC(v)''. It depends only on the vertex number.<br />
<br />
A graph with vertices ''v'' is nearly complete if it can be constructed by starting with a complete graph with the same number of vertices and removing up to ''NC(v)'' edges.<br />
<br />
<br />
==External Links==<br />
* [https://link.springer.com/article/10.1007/BF01836527 The genus of nearly complete graphs-case 6, Jonathan L. Gross, 1975]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Nearly_Complete_Graph&diff=677Nearly Complete Graph2019-12-30T16:06:35Z<p>Owen Vaughan: Created page with "A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be o..."</p>
<hr />
<div>A graph is a collection of vertices and edges. A graph is complete if there is an edge connecting every vertex to every other vertex. A graph is nearly complete if it can be obtained by removing a small number of edges from a complete graph.<br />
<br />
<br />
What follows is a mathematically precise definition of a nearly complete graph.<br />
<br />
Consider a graph ''G'' with vertices ''v'', edges ''e'', genus ''g'', and faces ''f''.<br />
<br />
Euler's lower bound is defined to be<br />
<br />
''X'' = (''e'' - 3''f'' + 6)/6 .<br />
<br />
If a graph is complete then ''g'' is equal to the lowest integer greater than or equal to ''X''. Consider a number ''p'' such that the removal of any set of ''p'' or fewer edges from a complete graph yields a connected graph with ''g = X''. The maximum value of ''p'' is denoted by ''NC(v)''. It depends only on the vertex number.<br />
<br />
A graph with vertices ''v'' is nearly complete if it can be constructed by starting with a complete graph with the same number of vertices and removing up to ''NC(v)'' edges.<br />
<br />
<br />
==External Links==<br />
* [https://link.springer.com/article/10.1007/BF01836527}</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Block&diff=632Block2019-12-18T15:00:36Z<p>Owen Vaughan: </p>
<hr />
<div>Bitcoin transaction data is immutably recorded by miners into files called '''blocks'''. Blocks can be thought of as the individual pages of a city recorder's record book (where changes to title to real estate are recorded) or a stock transaction ledger. Each block references the previous block that it was built upon allowing the record of history to form a linear sequence over time, known as the [[block chain]]. New transactions are constantly being processed by [[Mining|miners]] into new blocks which are added to the end of the chain. As new blocks are added to the tip of the chain, blocks are [[Confirmation|buried deeper and deeper]] and become [[Proof_of_Work|harder]] to change or remove, forming part of the Bitcoin network's security model. <br />
<br />
===Block structure===<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Description<br />
! Size<br />
|-<br />
|Magic no<br />
|value always 0xD9B4BEF9<br />
|4 bytes<br />
|-<br />
|Blocksize<br />
|number of bytes following up to end of block<br />
|4 bytes<br />
|-<br />
|Blockheader<br />
|[[Block hashing algorithm| consists of 6 items]]<br />
|80 bytes<br />
|-<br />
|Transaction counter<br />
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]<br />
| 1 - 9 bytes<br />
|-<br />
|[[Bitcoin_Transactions|transactions]]<br />
|the (non empty) list of transactions<br />
|<Transaction counter>-many transactions<br />
|}<br />
<br />
==Description==<br />
Each block contains, among other things, the [[Block timestamp|current time]], a record of some or all recent [[Bitcoin_Transactions|transactions]], and a reference to the block that came immediately before it. It also contains an answer to a hash puzzle which is unique to each block. The [[Block hashing algorithm]] requires that miners pre-build their block candidate before trying to solve the puzzle. New blocks cannot be submitted to the network without the correct answer - the process of "[[mining]]" is essentially the process of competing to be the next to find the answer that "solves" the current block. The hash puzzle in each block is [[difficulty|difficult]] to solve, but once a valid solution is found, it is very easy for the rest of the network to confirm that the solution is correct. There are multiple valid solutions for any given block - only one of the solutions needs to be found for the block to be solved.<br />
<br />
As a reward for building and performing work on a block and successfully propagating it to the network, the winning miner awards themselves the [[block subsidy]] and any [[Transaction fees]] that have been included in the transactions. The winning miner pays this reward out to themselves in the first transaction in the block which is known as a generation transaction, or a [[coinbase]] transaction. The number of [[Bitcoin|Bitcoins]] generated per block started at 50 per block and is halved every 210,000 blocks (about four years). Currently over 18 million coins have been created and the block subsidy has halved twice, dropping to 12.5 Bitcoins per block.<br />
<br />
When Bitcoin transactions are broadcast to the [[network]] by the sender, nodes who compete to build blocks collect the transactions and add them to the block they are working to solve. Miners' incentive to include transactions in their blocks is the attached [[Transaction fees]].<br />
<br />
The [[difficulty]] of the mathematical problem is automatically adjusted by the network, such that it targets a goal of solving an average of 6 blocks per hour. In the original design this rate was adjusted every 2016 blocks which is around 2 weeks. Currently (November 2019) the BitcoinSV network follows a [[DAA]]. <br />
<br />
Because each block contains a reference to the prior block, the collection of all blocks in existence can be said to form a chain. However, it's possible for the chain to have temporary splits - for example, if two miners arrive at two different valid solutions for the same block at the same time, unbeknownst to one another. The peer-to-peer network is designed to resolve these splits within a short period of time, so that only one branch of the chain survives.<br />
<br />
The client accepts the 'longest' chain of blocks as valid. The 'length' of the entire [[block chain]] refers to the chain with the most blocks at the required difficulty.<br />
<br />
==See Also==<br />
<br />
* [[Protocol#"block" messages|Protocol rules - "block" messages]]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Satoshis&diff=629Satoshis2019-12-18T14:30:13Z<p>Owen Vaughan: </p>
<hr />
<div>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 pseudonymous author of the 2008 Bitcoin whitepaper.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=G&diff=625G2019-12-18T14:16:21Z<p>Owen Vaughan: </p>
<hr />
<div>The symbol ''G'' refers to a distinguished point on the secpt256k1 elliptic curve known as the ''generator'' or ''base'' point. <br />
<br />
Using elliptic curve point addition, one may add ''G'' to itself over and over again to form the sequence <br />
<br />
''G'', ''G'' + ''G'' = 2''G'', ''G'' + ''G'' + ''G'' = 3''G'', ... <br />
<br />
and eventually every point on the elliptic curve will be generated in this sequence. <br />
<br />
<br />
<br />
In compressed form ''G'' is given by:<br />
<br />
''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
<br />
and in uncompressed form it is:<br />
<br />
''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
<br />
The order of ''G'' and the cofactor are:<br />
<br />
*''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
*''h'' = 01<br />
<br />
The order ''n'' is the number of times ''G'' must be added to itself to get the identity. The cofactor ''h'' = 1 tells us that moreover ''n'' is the order of the entire group of elliptic curve points, and therefore ''G'' is a generator of this group.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Secp256k1&diff=586Secp256k12019-12-13T10:55:38Z<p>Owen Vaughan: /* See also */</p>
<hr />
<div>[[File:Secp256k1.png|thumb |This is a graph of secp256k1's elliptic curve ''y<sup>2</sup> = x<sup>3</sup> + 7'' over the real numbers. Note that because secp256k1 is actually defined over the field Z<sub>p</sub>, its graph will look like random scattered points, not anything like this.]]<br />
<br />
'''secp256k1''' refers to the parameters of the elliptic curve used in Bitcoin's public-key cryptography, and is defined in ''Standards for Efficient Cryptography (SEC)'' (Certicom Research, http://www.secg.org/sec2-v2.pdf). Bitcoin SV uses secp256k1 with the [[ECDSA]] algorithm. <br />
<br />
secp256k1 was almost never used before Bitcoin became popular, but it is now gaining in popularity due to its several advantageous properties. Most commonly-used curves have a random structure, but secp256k1 was constructed in a special non-random way which allows for especially efficient computation. As a result, it is often more than 30% faster than other curves if the implementation is sufficiently optimized. Also, unlike the popular NIST curves, secp256k1's constants were selected in a predictable way, which significantly reduces the possibility that the curve's creator inserted any sort of backdoor into the curve.<br />
<br />
=== Technical details ===<br />
<br />
As excerpted from ''Standards'': <br />
<br />
The elliptic curve domain parameters over F''<sub>p</sub>'' associated with a Koblitz curve secp256k1 are specified<br />
by the sextuple T = (''p,a,b,G,n,h'') where the finite field F''<sub>p</sub>'' is defined by:<br />
* ''p'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F<br />
* = 2<sup>256</sup> - 2<sup>32</sup> - 2<sup>9</sup> - 2<sup>8</sup> - 2<sup>7</sup> - 2<sup>6</sup> - 2<sup>4</sup> - 1<br />
<br />
The curve ''E'': ''y<sup>2</sup> = x<sup>3</sup>+ax+b'' over F''<sub>p</sub>'' is defined by:<br />
* ''a'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
* ''b'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007<br />
<br />
The base point G in compressed form is:<br />
* ''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
and in uncompressed form is:<br />
* ''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
Finally the order ''n'' of ''G'' and the cofactor are:<br />
* ''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
* ''h'' = 01<br />
<br />
=== Properties ===<br />
<br />
* secp256k1 has characteristic ''p'', it is defined over the prime field ℤ<sub>''p''</sub>. Some other curves in common use have characteristic ''2'', and are defined over a binary Galois field ''GF(2<sup>n</sup>)'', but secp256k1 is not one of them.<br />
* As the ''a'' constant is zero, the ''ax'' term in the curve equation is always zero, hence the curve equation becomes ''y<sup>2</sup> = x<sup>3</sup> + 7''.<br />
<br />
== See also ==<br />
<br />
* [https://github.com/bitcoin-sv/bitcoin-sv/tree/d9b12a23dbf0d2afc5f488fa077d762b302ba873/src/secp256k1] (libsecp256k1 implementation in Bitcoin SV)<br />
<br />
[[es:Secp256k1]]<br />
<br />
[[Category:Technical]]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Secp256k1&diff=585Secp256k12019-12-13T10:52:38Z<p>Owen Vaughan: </p>
<hr />
<div>[[File:Secp256k1.png|thumb |This is a graph of secp256k1's elliptic curve ''y<sup>2</sup> = x<sup>3</sup> + 7'' over the real numbers. Note that because secp256k1 is actually defined over the field Z<sub>p</sub>, its graph will look like random scattered points, not anything like this.]]<br />
<br />
'''secp256k1''' refers to the parameters of the elliptic curve used in Bitcoin's public-key cryptography, and is defined in ''Standards for Efficient Cryptography (SEC)'' (Certicom Research, http://www.secg.org/sec2-v2.pdf). Bitcoin SV uses secp256k1 with the [[ECDSA]] algorithm. <br />
<br />
secp256k1 was almost never used before Bitcoin became popular, but it is now gaining in popularity due to its several advantageous properties. Most commonly-used curves have a random structure, but secp256k1 was constructed in a special non-random way which allows for especially efficient computation. As a result, it is often more than 30% faster than other curves if the implementation is sufficiently optimized. Also, unlike the popular NIST curves, secp256k1's constants were selected in a predictable way, which significantly reduces the possibility that the curve's creator inserted any sort of backdoor into the curve.<br />
<br />
=== Technical details ===<br />
<br />
As excerpted from ''Standards'': <br />
<br />
The elliptic curve domain parameters over F''<sub>p</sub>'' associated with a Koblitz curve secp256k1 are specified<br />
by the sextuple T = (''p,a,b,G,n,h'') where the finite field F''<sub>p</sub>'' is defined by:<br />
* ''p'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F<br />
* = 2<sup>256</sup> - 2<sup>32</sup> - 2<sup>9</sup> - 2<sup>8</sup> - 2<sup>7</sup> - 2<sup>6</sup> - 2<sup>4</sup> - 1<br />
<br />
The curve ''E'': ''y<sup>2</sup> = x<sup>3</sup>+ax+b'' over F''<sub>p</sub>'' is defined by:<br />
* ''a'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
* ''b'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007<br />
<br />
The base point G in compressed form is:<br />
* ''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
and in uncompressed form is:<br />
* ''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
Finally the order ''n'' of ''G'' and the cofactor are:<br />
* ''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
* ''h'' = 01<br />
<br />
=== Properties ===<br />
<br />
* secp256k1 has characteristic ''p'', it is defined over the prime field ℤ<sub>''p''</sub>. Some other curves in common use have characteristic ''2'', and are defined over a binary Galois field ''GF(2<sup>n</sup>)'', but secp256k1 is not one of them.<br />
* As the ''a'' constant is zero, the ''ax'' term in the curve equation is always zero, hence the curve equation becomes ''y<sup>2</sup> = x<sup>3</sup> + 7''.<br />
<br />
== See also ==<br />
<br />
* [https://bitcoin.stackexchange.com/questions/21907/what-does-the-curve-used-in-bitcoin-secp256k1-look-like What does secp256k1 look like] (Bitcoin stack exchange answer by Pieter Wuille)<br />
* [https://github.com/bitcoin-sv/bitcoin-sv/tree/d9b12a23dbf0d2afc5f488fa077d762b302ba873/src/secp256k1] (libsecp256k1 implementation in Bitcoin SV)<br />
<br />
[[es:Secp256k1]]<br />
<br />
[[Category:Technical]]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=G&diff=539G2019-12-12T16:01:26Z<p>Owen Vaughan: </p>
<hr />
<div>The symbol ''G'' refers to a distinguished point on the secpt256k1 elliptic curve known as the ''generator'' or ''base'' point. <br />
<br />
Using elliptic curve point addition, one may add ''G'' to itself over and over again to form the sequence <br />
<br />
''G'', ''G'' + ''G'' = 2''G'', ''G'' + ''G'' + ''G'' = 3''G'', ... <br />
<br />
and eventually every point on the elliptic curve will be generated in this sequence. <br />
<br />
<br />
<br />
In compressed form ''G'' is given by:<br />
<br />
''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
<br />
and in uncompressed form it is:<br />
<br />
''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
<br />
This particular choice of ''G'' is chosen to be secure against attacks when used in the context of public key cryptography.<br />
<br />
<br />
The order of ''G'' and the cofactor are:<br />
<br />
*''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
*''h'' = 01<br />
<br />
The order ''n'' is the number of times ''G'' must be added to itself to get the identity. The cofactor ''h'' = 1 tells us that moreover ''n'' is the order of the entire group of elliptic curve points, and therefore ''G'' is a generator of this group.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=G&diff=538G2019-12-12T15:58:44Z<p>Owen Vaughan: </p>
<hr />
<div>The symbol ''G'' refers to a distinguished point on the secpt256k1 elliptic curve known as the ''generator'' or ''base'' point. <br />
<br />
Using elliptic curve point addition, one may add G to itself over and over again to form the sequence <br />
<br />
''G'', ''G'' + ''G'' = 2''G'', ''G'' + ''G'' + ''G'' = 3''G'', ... <br />
<br />
and eventually every point on the elliptic curve will be generated in this sequence. <br />
<br />
<br />
<br />
In compressed form ''G'' is given by:<br />
<br />
''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
<br />
and in uncompressed form is:<br />
<br />
''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
<br />
This particular choice of ''G'' is chosen to be secure against attacks when used in the context of public key cryptography.<br />
<br />
<br />
The order of ''G'' and the cofactor are:<br />
<br />
*''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
*''h'' = 01<br />
<br />
The order ''n'' is the number of times ''G'' may be added to itself to get the identity. The cofactor ''h'' = 1 tells us that ''n'' is the order of the group of elliptic curve points, and therefore ''G'' generates the entire group.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=G&diff=537G2019-12-12T15:50:59Z<p>Owen Vaughan: </p>
<hr />
<div>*G refers to a distinguished point on the secpt256k1 elliptic curve known as the ''generator'' or ''base point''. <br />
<br />
Using elliptic curve point addition, one may add G to itself over and over again to form the sequence *G, *G + *G, *G + *G + *G, ... . Eventually every point on the elliptic curve will be generated in this sequence. Although this property is true for any point on the elliptic curve, the particular choice of *G is chosen to be secure against attacks when used in the context of public key cryptography.<br />
<br />
<br />
<br />
*G in compressed form is:<br />
<br />
*G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
and in uncompressed form is:<br />
<br />
*G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
<br />
The order *n of *G and the cofactor *h are:<br />
<br />
*n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
*h = 01<br />
<br />
The order *n is the number of times *G may be added to itself to get the identity. This generators a subgroup of the group of elliptic curve points, and the fact that the cofactor *h of this subgroup is 1 tells us that this subgroup is the whole group, i.e. *G generates the entrie group.</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=G&diff=536G2019-12-12T15:44:07Z<p>Owen Vaughan: </p>
<hr />
<div>G refers to a distinguished point on the secpt256k1 elliptic curve known as the ''generator'' or ''base point''. <br />
<br />
Using elliptic curve point addition, one may add G to itself over and over again to form the sequence G, G + G, G + G + G, ... . Eventually every point on the elliptic curve will be generated in this sequence. Although this property is true for any point on the elliptic curve, the particular choice of G is chosen to be secure against attacks when used in the context of public key cryptography.<br />
<br />
<br />
<br />
G in compressed form is:<br />
<br />
*G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798<br />
and in uncompressed form is:<br />
<br />
*G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8<br />
Finally the order n of G and the cofactor are:<br />
<br />
*n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141<br />
*h = 01</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=SIGHASH_flags&diff=535SIGHASH flags2019-12-12T15:13:14Z<p>Owen Vaughan: </p>
<hr />
<div>A SIGHASH flag is used to indicate which part of the transaction is signed by the [[Digital Signatures (ECDSA) | ECDSA signature]]. The mechanism provides a flexibility in constructing transactions. There are in total 6 different flags that can be added to a digital signature in a transaction. <br />
<br />
{| class="wikitable"<br />
|-<br />
! Flag<br />
! Value<br />
! Functional Meaning<br />
|-<br />
| SIGHASH_ALL<br />
| 0x00000001<br />
| Sign all inputs and outputs<br />
|-<br />
| SIGHASH_NONE<br />
| 0x00000002<br />
| Sign all inputs and no output<br />
|-<br />
| SIGHASH_SINGLE<br />
| 0x00000003<br />
| Sign all inputs and the output with the same index<br />
|-<br />
| SIGHASH_ALL <nowiki>|</nowiki> ANYONECANPAY<br />
| 0x00000081<br />
| Sign its own input and all outputs<br />
|-<br />
| SIGHASH_NONE <nowiki>|</nowiki> ANYONECANPAY<br />
| 0x00000082<br />
| Sign its own input and no output<br />
|-<br />
| SIGHASH_SINGLE <nowiki>|</nowiki> ANYONECANPAY<br />
| 0x00000083<br />
| Sign its own input and the output with the same index<br />
|}<br />
<br />
<br />
The table below illustrates what is signed and what is not signed in a more granulated detail by an ECDSA siganture in the Input 1 in a transaction.<br />
<br />
{| class="wikitable"<br />
|-<br />
|<br />
| ALL<br />
| NONE<br />
| SINGLE<br />
| ALL <nowiki>|</nowiki> ANYONECANPAY<br />
| NONE <nowiki>|</nowiki> ANYONECANPAY<br />
| SINGLE <nowiki>|</nowiki> ANYONECANPAY<br />
|-<br />
| Version<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Locktime<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Input 1 outpoint<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Input 1 scriptSig<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
|-<br />
| Input 1 sequence number<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Input 2 outpoint<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
|-<br />
| Input 2 scriptSig<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
| No<br />
|-<br />
| Input 2 sequence number<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
|-<br />
| Output 1<br />
| Yes<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| Yes<br />
|-<br />
| Output 2<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
|}<br />
<br />
Note that the version number and locktime are always signed, and the scriptSigs are never signed.<br />
<br />
<br />
SIGHASH flags are useful when constructing smart contracts and negotiable transactions in payment channels. <br />
<br />
<br />
Use Case 1 - Crowdfunding<br />
<br />
Using ALL <nowiki>|</nowiki> ANYONECANPAY allows a transaction to have a fixed output or fixed outputs while keep the input list open. That is, anyone can add their input with their signature to the transaction without invalidating all existing signatures.<br />
<br />
<br />
Use Case 2 - Blank Check<br />
<br />
Using NONE allows any miner to add their desired outputs to the transaction to claim the fund in the input.<br />
<br />
<br />
Use Case 3 - Modular Transaction<br />
<br />
Using SINGLE <nowiki>|</nowiki> ANYONECANPAY modularises a transaction. Any number of these transactions can be combined into one transaction. <br />
<br />
==References==<br />
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/sighashtype.h</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=394Elliptic Curve Digital Signature Algorithm2019-11-15T11:24:15Z<p>Owen Vaughan: /* See also */</p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [[BIP 0032]]. In Bitcoin, someone with the private key that corresponds to funds on the [[blockchain]] can spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). ['''OV Comment 1''']{This integer is used as a co-ordinate on an elliptic curve and used to find its own unique path through the math to the public key.}<br />
* public key: ['''OV Comment 2''']{A number that corresponds to a private key}, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
['''OV Comment 3''']<br />
<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]</div>Owen Vaughanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=393Elliptic Curve Digital Signature Algorithm2019-11-15T11:22:17Z<p>Owen Vaughan: </p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [[BIP 0032]]. In Bitcoin, someone with the private key that corresponds to funds on the [[blockchain]] can spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). ['''OV Comment 1''']{This integer is used as a co-ordinate on an elliptic curve and used to find its own unique path through the math to the public key.}<br />
* public key: ['''OV Comment 2''']{A number that corresponds to a private key}, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
['''OV Comment 4''']<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]</div>Owen Vaughan