An anti-DoS system which provides additional service for peers which perform proof of work.
==Definitions==
* '''POW''' : a proof of work using some arbitrary algorithm, such as SHA256
* '''challenge''' : a problem in the form of a POW specification and other data
* '''solution''' : a set of inputs which solve a given challenge
* '''free connection slot''' : an inbound connection slot that does not require POW
* '''POW connection slot''' : an inbound connection slot that requires POW
* '''SPH''' : Special Purpose Hardware, such as an ASIC chip
* '''GPH''' : General Purpose Hardware, such as a desktop computer
* '''Work''' : A measurement of optimized average resources (clock cycles, memory, ...) required to perform a single attempt at solving a given POW algorithm on GPH
==Motivation==
The Bitcoin network has a maximum number of inbound and outbound connections (125).
It is trivial and relatively cheap to flood the network with connections via dummy
nodes. Such an attack would result in (1) nodes evicting some other nodes in order to
facilitate the new connection, and (2) nodes' ability to connect to each other being
severely hampered. In this state, the network is vulnerable to e.g. a Sybil attack.
While the network is under pressure as in the above case, nodes could allow incoming
connections anyway by requiring that the incoming peer performs some form of proof
of work, to prove that they are not simply spamming the network. This would severely
ramp up the costs of a Sybil attack, as the attacker would now have to perform proof
of work for each node, beyond the free slots.
However, using the "standard" double-SHA256 POW algorithm in use by Bitcoin nodes to
generate blocks means attackers can use special-purpose hardware to greatly accelerate
the POW solving process. To counter this, the proof weight would have to be raised,
but this would mean standard nodes would need to solve unacceptably costly challenges
for simple operation. Therefore, a different proof of work which is arguably less
sensitive to special-purpose hardware implementations is introduced. As this is not
consensus sensitive, additional POW algorithms may be added in the future.
==Specification==
A peer that supports Proof of Work Rate Limiting defines two maximums:
* max connections, from which the maximum inbound connections is calculated as <code>nMaxConnections - (nMaxOutbound + nMaxFeeler)</code>
* POW connection slots, which define how many of the above inbound connections require a POW challenge
The peer must interpret two new network peer message types, <code>challenge</code> and <code>solution</code>.
In addition, the network handshake sequence must be altered slightly to facilitate the exchange of challenges and/or solutions:
* when a node connects, it may send a <code>solution</code> message prior to the <code>version</code>
* if it does, and
** the solution satisfies the local node, it is given a connection, but if
** the solution does not satisfy the local node (unknown, wrong, ...), a new <code>challenge</code> is sent and the connection is closed
* if it does not, and it is marked as needing to do POW, a <code>challenge</code> is sent and the connection is closed
This means nodes will be disconnected after receiving the challenge. It is then up to the individual nodes whether they
solve the challenge and reconnect, or discard it and find a different peer (or wait for the peer to have an open free slot).
===POW Identifiers===
There are two POW identifiers currently. When a new identifier is introduced, it should be added with an increment of 1
to the last identifier in the list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should
retain its place in the list indefinitely.
{|class="wikitable"
! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status
| 1..4 || target || uint32 || Difficulty target, in the form of a compact size (like nBits in blocks).
|-
| 5 || nonce_size || uint8 || Size of nonce in bytes; must be 0 (no nonce), 4 (uint32) or 8 (uint64)
|-
| 6..9 || nonce_offset || uint32 || Location of nonce value in target
|-
| 10.. || payload_length || varint || Length of the input data
|-
| .. || payload || byte array || Input data
|}
Solution format:
{|class="wikitable"
! Range !! Field Name !! Data Type !! Description
|-
| 0.. || nonce || uint32/64, or data || Nonce value that satisfies challenge; for zero-byte nonces, this is variable data that is appended to the challenge payload before hashing
|}
Note: SHA256 works in two "modes".
# One is where the task is to insert a nonce into an existing data block so that the hash of the data block matches a given target; this is the conventional block proof of work behavior.
# The other is where the whole or parts of the data chunk are given as input (a "big nonce"). In this case, the internal nonce size is zero bytes, and the task is simply to check whether the hash of the data matches the target. If it does not, there is no way to find a solution except by getting different input from the generator (a successor algorithm). This mode is used when SHA256 is a predecessor to another algorithm.
Additional notes:
* The initial nonce value (when present) for finding a suitable digest should be randomized, or a challenger may deliberately pick a challenge with "poor" outcomes to fool a node into spending more than predicted time solving.
====cuckoo-cycle====
Properties:
{|class="wikitable"
! Property !! Value
|-
| Solution probability || <code>~1.0</code> for sizeshift=28, proofsize-min:-max=12:228
| 1 || sizeshift || uint8 || Size shift; must be equal to 28, but may be variable in the future
|-
| 2..3 || proofsize-min || uint16 || Minimum number of edges in cycle; must be even and greater than or equal to 12 (recommended: 12)
|-
| 4..5 || proofsize-max || uint16 || Maximum number of edges in cycle; must be even, greater than or equal to proofsize-min, and smaller than or equal to 254 (recommended: 228)
|-
| 6 || payload_length || varint || Length of the input data; must be 76, but may be variable in the future
|-
| 7.. || payload || byte array || Input data
|}
Solution format:
{|class="wikitable"
! Range !! Field Name !! Data Type !! Description
|-
| 0..3 || nonce || uint32 || Nonce which is appended to challenge payload to form solution graph
|-
| 4..171 || edges || uint32 array || 42 values which identify each of the 42 edges in the cycle
|}
Additional notes:
* The initial nonce value used for finding a graph with a suitable solution should be randomized, or a challenger may deliberately pick a challenge with "poor" outcomes to fool a node into spending more than predicted time solving.
* Further information on the recommended challenge parameters can be found here: http://bc-2.jp/cuckoo-profile.pdf
===Purpose Identifiers===
There is only one Purpose Identifier currently. In the future, more Purpose Identifiers could be added for at-DoS-risk operations,
such as bloom filters. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the
list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should retain its place in
the list indefinitely.
{|class="wikitable"
! ID !! Purpose Name !! Description !! Status
|-
| 1 || connect || Establish peer to peer connection || Active
|}
===Challenges===
Challenges consist of one or several chained POW identifiers with accompanying parameters, as well as indicators for the purpose of the challenge,
and a signature that lets the node verify the challenge authenticity.
After creating a challenge, the node signs it, delivers it to the peer, then discards it.
When a node provides a solution to a challenge, the node verifies the signature and adds the challenge hash to a list of solved
challenges along with its expiration time. This list is pruned on each insertion, removing any expired challenges.
If nodes needed to keep track of unsolved challenges, an attacker could hypothetically swarm a node, causing a DoS by having it generate so many
challenges that it runs out of memory and crashes.
By signing and discarding challenges, a node only has to retain challenges that were solved, and which have not yet expired, effectively DoS-
protecting the node via the challenges themselves.
===The <code>challenge</code> message type===
A challenge consists of four parts: the POW specification, a purpose identifier, an expiration date, and a signature.
The POW specification contains a list of tuples containing a POW identifier and corresponding POW parameters.
* Each POW identifier specifies a POW algorithm (see POW Identifiers)
* The POW parameters define the inputs and requirements of the POW algorithm
* The purpose identifier specifies the purpose of the challenge (see Purpose Identifiers)
* The expiration date is a UNIX timestamp indicating when the challenge expires
* The signed content should contain a signature of the hash <code>SHA256(SHA256(pow-count || pow-id || pow-params || ... || purpose-id || expiration))</code>, i.e. the hash of the entire challenge except for the signature length and data.
{|class="wikitable"
! Field Size !! Description !! Data type !! Description
|-
| 1 byte || pow-count || uint8 || Number of POW algorithms in the range [1..255]
|-
| 4 bytes || pow-id || uint32 || The POW algorithm to solve the problem with
|-
| ? || pow-params || ? || The POW parameters and payload
|-
| ... || ... || ... || pow-id and pow-params for algorithms 2 and beyond
|-
| 4 bytes || purpose-id || uint32 || The purpose of the challenge
| ? || sign-len || varint || The length of the signature
|-
| ? || sign || byte array || The signature data
|}
For POW specifications with a pow-count > 1, the output of the succeeding POW algorithm will be appended to the input of the predecessor for all POW algorithms except the last one.
Normally mid-layer (all but the last) POW algorithms have a zero-length input. Example implementing sha256(cuckoo-cycle):
{|class="wikitable"
! Range !! Field Name !! Value !! Comment
|-
| 0 || pow-count || 2 || Two POW algorithms
|-
| 1..4 || pow-id || 1 || sha256
|-
| 5 || pow-params (config_length) || 9 ||
|-
| 6..9 || pow-params (target) || 0x207fffff || Resulting hash must be <= the compact hash 0x207fffff*
|-
| 10 || pow-params (nonce_size) || 0 || No nonce
|-
| 11..14 || pow-params (nonce_offset) || 0 || --
|-
| 15..18 || pow-params (payload_length) || 0 || 0 byte input (turns into 32 byte input from successor)
To avoid other nodes dropping our challenges due to early expiration, we use a fairly generous expiration based on the pressure value
<pre>
expiration = date() + 600 * (1 + pressure)
</pre>
which means the expiration is 10 minutes for the weakest challenge, and gradually rises to 20 minutes for the hardest one.
===Establishing Difficulty Parameters===
The difficulty setting for the network should change based on connection slot availability. The amount of pressure
on the network in the sense of connection slot availability is proportional to the number of established connections
over the number of total available connections. This can be locally approximated by a node to the number of
local connections compared to the local connection maximum.
In other words, the network pressure can be approximated by any node as <code>connections / max</code> and the difficulty
can be based on e.g. <code>(connections - free) / pow_slots</code>.
The challenge difficulty parameters can be set based on this, where 0.0 means "low pressure" and 1.0 means
"maximum pressure". The <code>GetPressure</code> method below gives 0.0 at 67 connections (for a 50 POW slot set up), and hits the 1.0 mark at <code>(nMaxConnections - nMaxOutbound - nMaxFeeler)</code>, incrementing by 0.02 for each new connection:
<pre>
int nMaxInbound = nMaxConnections - (nMaxOutbound + nMaxFeeler + nPOWConnectionSlots);
An example of difficulty for a SHA256(Cuckoo-Cycle) specification would be based on a desired probability of a random SHA256 digest matching a given target:
<pre>
prob_target = 1 / (1 + pressure^2 * 15)
</pre>
This would result in probability targets according to the table below, for varying pressures (where the pressure is in the range [0..1]):
{|class="wikitable"
! pressure !! prob_target !! solution time sha256(cc)
|-
| 0.0 || 1.00 || 00:45
|-
| 0.1 || 0.87 || 00:51
|-
| 0.2 || 0.63 || 01:11
|-
| 0.3 || 0.43 || 01:45
|-
| 0.4 || 0.29 || 02:32
|-
| 0.5 || 0.21 || 03:32
|-
| 0.6 || 0.16 || 04:46
|-
| 0.7 || 0.12 || 06:13
|-
| 0.8 || 0.09 || 07:54
|-
| 0.9 || 0.08 || 09:48
|-
| 1.0 || 0.06 || 11:55
|-
|}
==Cuckoo Cycle==
Cuckoo Cycle[1] is a "graph-theoretic proof-of-work system, based on finding small cycles or other structures in large random graphs."
It is memory hard, which greatly increases the complexity and cost of producing dedicated (special purpose) hardware, an ideal property for an anti-DoS system.
The implementation specifics of the algorithm are beyond the scope of this BIP, but the github repository[2] has several reference implementations in various languages.
==Compatibility==
This proposal is backward compatible. Non-supporting peers will ignore the <code>challenge</code> message
and be disconnected, as if they hit the peer connection limit as normal.
