This is a design idea for the PoW connection slots (BIP-154).
I am mostly looking for feedback on the approach, and not so much on the quality of the code itself, at this point (but code feedback is of course also appreciated).
Does this seem like a reasonable approach?
In order to make the probability target (nBits-style) more intuitive to generate based on an expected probability, two functions were added to arith_uint256 -- SetProbabilityTarget(pt) and GetProbabilityEstimate().
The former will set the arith_uint256 to a difficulty approximately equal to pt, i.e. if pt = 1.0 (100% probability), the result will be 0b1111... and if pt = 0.5 (50%), the result will be 0b01111... and so on.
The latter will do the inverse, i.e. take the arith_uint256 value as a difficulty target and return a probability that a random hash will be lower than the target.
A new set of classes in pow/pow.h/cpp which serve as the parents for all the proof of work algorithms (contained in the powa:: namespace).
The powa::challenge class is a container for challenges offered by peers, and powa::solution is a container for solutions to challenges.
powa::callback is used to ping-back solvers when a solution was found. There's a helper-class powa::callback_proxy which is used when an instance needs to use itself as the callback (as opposed to creating a new instance and handing ownership over to the prover).
powa::pow is the base algorithm class inherited by the algorithm implementations, and finally powa::powchain is a simple wrapper for chaining algorithms together (e.g. sha256(cuckoo-cycle)).
Origin: https://github.com/tromp/cuckoo
This commit is purposefully left as closely resembling the original source as possible, although some tweaks have been put in (in particular namespace embedding). A separate commit adapts it for the Bitcoin codebase.
A new set of classes specifically targeting anti-DoS via POW in src/ados.h/cpp in the ados:: namespace.
ados::offer is an offered service provided for solving a POW challenge, including expiration and purpose according to BIP-154.
ados::callback extends powa::callback as a general-purpose anti-DoS callback.
ados::connection_challenge is an ados::callback specialization which retains a CAddress taken from a CNode which is connected to with the given challenge/solution when/if solved.
There are also a number of helper functions:
- ados::begin_solving() takes an offer and an investment (number of ticks) and will attempt to solve the offer in the background
- ados::expected_solution_time(o) gives an estimate in seconds on how long it would take on average to solve the challenge in the offer
- ados::solvable(o) returns a bool on whether the given offer's challenge is considered solvable within the time constraints
- ados::challenge_peer(peer, purpose, pressure) constructs and sends a challenge to peer for the given purpose; pressure determines the difficulty of the challenge, and is in the range [0..1]
- ados::check_solution(o) takes an offer and checks if its given solution is a valid solution to the contained challenge
A new nPOWConnectionSlots ivar is added to connection options and fRequirePOW is added to CNode.
The logic upon incoming connections for evictions is changed to (1) include a fRequirePOW bool which defaults to false and is set to true if the number of inbound connections exceeds nMaxInbound - nPOWConnectionSlots, and (2) to attempt eviction if the number of inbound exceeds nMaxInbound. Assuming the connection is accepted, fRequirePOW is set in the node as appropriate.
CConnman::OpenNetworkConnection has an added ados::offer which, if set, is inserted into the newly connected node and subsequently sent before the version message.
NetMsgType::SOLUTION and NetMsgType::CHALLENGE are added and handled in net_processing, and NODE_DOSPROT is added as bit 5 (note: this needs to be explicitly defined probably in BIP-154).
Makes use of e.g. CSHA256 instead of openssl, as well as numerous fixes and clean ups of unused stuff.
Note: Still using a built-in siphash instead of the available one, which should probably be addressed.
Consider making it possible for Bitcoin miners (that some of us have lying around) to help generate some form of these proofs, if it isn't already possible to do so.
@midnightmagic Most Bitcoin miners are only able to do SHA256(SHA256) proofs -- someone could pose such a challenge if they wanted to and it could theoretically be used with e.g. a USB miner, but I don't know how frequent that will be. A key reason why Cuckoo Cycle was included is because it does not give users with miners an advantage (as this would give attackers an opportunity to DDoS with help of some HW miners).
HW miners are only owned by Bitcoin miners. Otherwise, botnets will simply be the empowered ones and normal people will not -- PoW demonstrates investment in Bitcoin mining, much like the PoW of the blockchain itself. :)