• en
    • it
    • ru
Type anywhere to search

Bitcoin, due to its conceptual nature of an online trading system based on a mechanism of
decentralized consent, use as peer-to-peer network architecture for which the set
of the nodes is not hierarchically structured and the communication between a pair of nodes
it must not be mediated by a central host (server). All nodes of the network are connected in one
knit structure (mesh) flat and beyond a recovery the services offered by the network contribute to it
providing system capacity.
The term “bitcoin network” refers to the set of nodes that apply to the bitcoin P2P protocol. over
Bitcoin’s P2P protocol has other communication protocols, such as Stratum or the protocols for
the mining pools, running in the nodes of subnets connected to the bitcoin network through the server gateway
that run the bitcoin P2P protocol (for example the mining pool are organized according to one
centralized structure and individual mining stations
bitcoins but interface through the central host server). In the key terminology al
bitcoin system the set of all the components that make up the system (nodes, mining pool, wallet
mobile) is called “extended network”.
P2P bitcoins are the same, they can have different roles depending on the
functionality that supports supporting. The supported features are as follows:
1) routing
2) blockchain database
3) mining
4) service portfolio
Each node in the network must support the routing function (by running the protocol
P2P of bitcoins or alternatives seen previously). The nodes containing a complete copy of the
blockchains are called full nodes (which can be displayed independently by a transaction
search in your local copy of the blockchain). Some nodes do not have a complete copy
payment and simplified payment
verification (SPV) and are called lightweight (or SPV node) nodes. The nodes that support the
Mining features are known of data mining and specialized hardware hardware for
compete in the resolution of the proof-of-work algorithm at the base of the mining process. They
they can also be full node nodes if they have a complete copy of the blockchain or can
be nodes organized in a mining mine (in this case only the central server of the mining structure
he wears a complete copy of the blockchain). Nodes that support portfolio functionality
(wallet) are very light and liked the individual users who own a
bitcoin address.
In addition to the main node types of the bitcoin P2P protocol, there are servers and nodes that execute
other protocols, such as mining pool protocols and light client access protocols for
access reported.
The nodes of the network can therefore be classified into:
1) Reference client (core bitcoin): controls a portfolio, a competitor copy of the blockchain and a
routing node that runs the bitcoin P2P protocol.
2) Complete blockchain node: contains a competing copy of the blockchain and a routing node
running the bitcoin P2P protocol.
3) Miner only: Check a mining function, a competing copy of the blockchain and a
routing node that runs the bitcoin P2P protocol.
4) Lightweight portfolio: contains a portfolio and a routing node that runs the P2P protocol of
5) Protocol pool server: connects the nodes that do not execute the protocol to the bitcoin P2P network
P2P of bitcoins (nodes of tin or Stratum mines). In the case they are the central server of one
centralized mining structure (mining pool)
6) Mining nodes: controls a mining function and executes a routing protocol
suitable for mining pools. They do not have a copy of the blockchain.
7) Stratum lightweight portfolio: integrates a portfolio and a routing node that runs the protocol
So the bitcoin network is a decentralized network structure that interconnects thousands of
heterogeneous nodes in the functionalities they support and in the use of the different access protocols to


Network discovery

When a new node is started it must discover other bitcoin nodes on the network for
participate in it. To start this process, a new node must discover at least one node
existing on the network and connect. The geographical location of the other nodes is irrelevant (the type of
bitcoin network is not geographically defined). Therefore every existing bitcoin node can be
selected randomly.
To connect to a known peer, a node initializes a TCP connection, usually from the
port 8333 (the default port used by bitcoin clients) or an alternative port if expected. One time
Once the connection is established, the node will start a “handshake” process by sending a version message
containing the following basic identification information:
1) protocol-version: a constant that defines the version of the bitcoin P2P protocol supported by the
2) NlocalService: list of local services supported by the node, currently only NODE_NETWORK upload nTime: current time
3) addrYou: IP address of the remote node as seen from the current node
4) addrMe: IP address of the local node, seen from the local node
5) subver: type of software running on this node
6) BestHeight: block height of the block chain of this node
The peer node responds with verack to accept and establish a connection, and optionally sends the
his version message if he wants to reciprocate the connection and connect as a peer.
A node running the bitcoin client for the first time has no knowledge of the network and
requires an access method that returns the IP address of at least one node in the network for
initialize the connection. In particular, the node sends a DNS query to a DNS seed (DNS server
that provide a list of IP addresses of Bitcoin nodes). Some of these DNS seeds provide a
static list of IP addresses for stable bitcoin listening nodes and are implementations
Customs of BIND (Berkeley Internet Name Daemon). They return a random subset
from a list of bitcoin node addresses collected by a long-term crawler or bitcoin node. The
Bitcoin Core client contains the names of the five different DNS seeds.
Once one or more connections are established, the new node will send an addr, message
containing its own IP address, to the nodes with which it has established a connection. The latter
they will, in turn, forward the addr message to the nodes with which they are connected, ensuring that the
just connected node becomes well known and better connected.
Also, the newly attached node can send getaddr to its “neighbors” asking them to return a
list of IP addresses of other peers. In this way a node can find peers to connect and
advertise its existence on the network to facilitate other nodes to find it.
A node must connect to a couple of different peers in order to establish different paths in the bitcoin network
because the paths are not reliable (the nodes are not always active). The bootstrap process requires
the connection with a single node which will forward to the requesting node a list of known peers
(nodes with which it has established connections previously). During his activity on the net a
node hardly exceeds the two simultaneous connections. In the eventuality the known paths do not
were more passable the node can always repeat the bootstrap process looking for paths
alternative access to the network. If there is no traffic on a connection, the nodes periodically
they will send messages to keep the connection. If a node has not communicated on a connection
for more than 90 minutes, it will be disconnected and a new peer will be searched. Thus the network rules


Full node

The complete nodes are those that maintain a complete copy of the blockchain. In the early years of
Bitcoin all the nodes were complete and currently the Bitcoin Core client is a complete blockchain node.
In recent years, however, new forms of bitcoin clients have been introduced that do not maintain one
complete blockchain but run a lighter version.
A full node blockchain can independently and authoritatively verify every transaction without
resort or rely on any other node or source of information. The full node blockchain is based on the
network to receive updates on new blocks of operations, which then verifies and incorporates into the
own local copy of the blockchain.
The first thing a full node will once have connected to peers will be to try to build one
complete blockchain. If this is a node running the bitcoin client for the first time
will know only one block, the genesis block, which is incorporated in a static way in the client software.
Starting from block 0 the new node will have to download hundreds of thousands of blocks for the
synchronization with the network and the reconstruction of the blockchain.
The blockchain synchronization process has as a first step the sending of the version message
(version message) which contains the BestHeight field that identifies the maximum blockheight of the
local version of the blockchain (obviously in case the node is connected for the first time
to the network this parameter will have value 0). The node will analyze the response version message of the peers
with which he established a connection, thus being able to compare the number of blocks of the
blockchain they have. In particular, the nodes involved in a connection will exchange
a getblocks message containing the hash of the top block in its local blockchain copy.
One of the two nodes will be able to identify the hash just received as corresponding to a
previous block deducting that its local version of blockchain is longer. The latter
identify the first 500 blocks to be shared with the other node and send the corresponding hash
through an inventory message. Once the inventory message is received, the node that owns one
less recent copy of the blockchain will request missing block data through a message
GetData containing the corresponding blockhash of the block requested.
The process of comparing local copies of blockchain with its peers is implemented every time
a full node disconnects from the network. It does not matter if the offline period is a few minutes or months, the
first operation that the full node operates as soon as it reconnects to the network is the synchronization of the
blockchain through the exchange of messages getblocks, inventory message and GetData.


Nodes di Simplified Payment Verification

Not all nodes have the ability to keep a complete copy of the blockchain. Many bitcoins
clients have been implemented to run on devices with stringent limitations in terms
storage space and computational capabilities such as smartphones, tablets and embedded devices.
These clients use a method known as simplified payment verification (SPV) to operate
without keeping a complete copy of the blockchain, and are called SPV client or lightweight
client. In recent years, SPV nodes have become the most common nodes of the bitcoin network and are
especially used for individual users’ bitcoin wallets.
SPV nodes download only the block headers and not the transactions they include and do not have,
therefore, a complete view of the UTXOs that are available to be spent. The verification system
simplified payment verification uses communication with full node to obtain information
necessary to verify the transactions.
To get the block headers an SPV node uses a getheaders message to which the full
receiver node responds with a list of 2000 blockheaders per message (the process is essentially the
same as that used by a full node to get the complete blocks). The verification method
simplified referencing a transaction according to the depth of the block that contains it in the chain
blockchain (deep) and not to its height (blockheight). A full node that wants to verify one
transaction as not spent generates a transaction database from the block that contains it
up to the genesis block being able to independently verify if the transaction in question has been spent
previously. The SPV nodes do not have the transaction history contained in the blocks but I know them
only the headers of the latter. They, through a merkle path that require a full node,
verify the presence of a transaction in a given block in the chain. The depth of the
block (the number of successive blocks validated and attached to the blockchain) from indications about the
validity of the transactions contained in it as a double spend attack (validation of a block
containing a double spend transaction) requires an increasing computational power to grow
of the number of blocks to be invalidated. Generally an SPV node recognizes a valid one
transaction contained in a block with a minimum depth of 6.
The simplified payment verification, even if it allows the nodes to verify the validity of a transaction
although they do not have a complete view of the blockchain, it presents some problems
linked to the need for support by a full node (the node that performs the simplified verification
delegates its trust to a third party which may not operate properly). The full node can
operate a denial-of-service against SPV nodes that require simplified support
payment verification not informing the latter of the presence of the specific transaction in one
specific blocking by nullifying the verification process (in general it could also “lie” about the
presence of a particular transaction in a block, but the SPV node knows the merkle root of the
block and can independently verify the validity of the merkle path received from the full node).
This verification system introduces privacy issues because lightweight nodes are generally
wallet nodes of individual users who request verification for transactions coming (or direct) to
own bitcoin address. Therefore the full support nodes can know the association IP address
bitcoin address violating system policies (bitcoin is based on the anonymity of users).
In this regard, since the introduction of the SPV nodes, bitcoin has provided a system, known as
Boom Filters, which allows you to maintain the privacy of users who run a lightweight client
for access to the network.


Filters di Bloom

A bloom filter is a probabilistic search filter that allows a description of a pattern of
desired search without the exact specification of the pattern itself, by introducing an efficient system
of privacy protection for lightweight bitcoin clients. It is, in fact, used by the SPV nodes for
requests for matching to full nodes for specific transactions without disclosing exactly the addresses
desired in the request.
An SPV node initializes a bloom filter as empty and in that state the filter contains none
search pattern. The requesting node will produce a search list starting from the bitcoin addresses
present in your wallet producing a search pattern for each address, inserting the latter
inside the bloom filter that will transmit to the full nodes to which it is connected. Generally the pattern
search is the bitcoin address itself and the corresponding transactions will be of the pay-to-public-key- type
hash (P2PKH).
A bloom filter is implemented as an array of variable size containing N binary digits
and M hash functions. The hash functions are such that an integer in the range is returned as output
of values ​​[1, N] and are generated deterministically (for each node that supports the function of
searching through the bloom filters to a specific input will correspond to the same output being the
same hash function used). The choice of the value of the parameters N and M changes the accuracy
and the level of privacy offered by the search system. Let’s examine a practical example of a bloom filter
having N = 16 and M = 3. The filter will be composed of an array of binary values ​​with a size of 16 and from
three hash functions that produce a value output in the interval [1.16].
The bloom filter, as mentioned earlier, is initially empty which means the array of values
binaries is initialized to zero. For each search pattern that you want to insert in the filter it is given in
input to a hash function (selected in turn) which will return an integer value between 1 and
16. The corresponding bit field (position of the binary array with index equal to the output of the
hash function) is post to the value 1.

Once the bloom filter is constructed, the SPV node forwards it to the full nodes with which it is connected as
search parameter for the getData. The full node that receives the request tests each transaction output
through the bloom filter to select the output set required by the requesting SPV node. Then
transmit blockheaders of the blocks containing the desired transaction outputs and a merkle
path for every requested transaction, through a merkleblock message. The SPV node can
constantly update the transmitted bloom filter by adding search patterns through the
message filteradd and may even decide to completely empty the filter by transmitting the message


Credits: Andrea Mineo

  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam

21st april 2014 2:13am
Hello there
Did you check out Pages framework ?
Its an awesome chat

Press enter to search :D

Pages Search Results