Topic: QoS for bitcoind (Read 1659 times)

It is better than not having a node at all.

Even when throttled, the node will still forward blocks that are less than 30 days old and inform peers of the 2nd highest block that it knows about.

This means that peers will fall at most 1 block behind the chain if they only connected to the network through a throttled node.


What exactly is your concern?  The worth case is that the node consumes one connection from a "full node".  SPV clients already do that anyway and this node is actually mostly contributing (up to the bandwidth limit).

In general nodes should not implement this type of restriction as it has the potential to affect the integrity of the network.

However an individual node could implement this custom version of bitcoind, so that the node can still make a contribution to the network although it might not be 100% contribution all the time.

An easier method is to have a script that shuts down your bitcoind "bitcoin-cli stop", once your specified bandwidth runs out. This way you can run a standard node without any degradation of service right up to the point where you simply turn it off.

I didn't do much more with this, since there seemed to be very little interest.


Exactly, it restricts maximum upload burst bandwidth and also total bandwidth over 48 hours.

I think this is a bandwidth QoS not for transactions.  This is to allow people to run bitcoind and be sure that it won't use too much network bandwidth.

This raises a lot of questions. If the BTC network had to institute a QoS protocol that would make small transactions stop being processed. If we had QoS for the BTC network, all miners and nodes would eventually only pick up and confirm transactions that would have higher fees. Transaction who haven't paid fees would never be processed...

Sorry to necro this but is there a PR for this?

I coded a basic QoS patch.

There are 2 limits, an upload burst limit and a daily limit.

One sets a burst bandwidth.  It averages over 2 seconds.  The other is measured in GB per day and it is averaged over 2 days.

Someone with 200GB per month and 20mbps might set the limits to 2GB per day and 5mbps.  That would guarantee that they never go over either of their limits.

When out of bandwidth, sending is halted until the token buckets re-fill.

When low on bandwidth, the node will stop sending old blocks (more than 30 days old) and delay informing peers about new blocks received (by 1 block period).  This reduces the bandwidth that the node serves until the rings have recovered.

With headers first, this should work reasonably well.  It already has the code to handle a node which doesn't send blocks.  If a peer is delaying the initial sync, then the peer is disconnect and another node is tried.

This is not what banscore is for. Banscore is for gratuitous misbehavior.  It is not very effective against denial of service attacks since the attacker can simply use a botnet or proxy network-- which can easily given them connections from tens or hundreds of thousands of addresses.

If I'm understanding the OP correctly, then you are trying to develop a way to prevent malicious nodes from spamming the network and essentially DoSing a home node and shutting it down because of the bandwidth cap. If this is the case, then something has already been implemented to prevent this kind of spam, it is the banscore. Each node is given a banscore by its peers, and if the score is above a certain threshold, the peer will disconnect and refuse connections from that node. I'm not sure how the banscore is calculated, but it can stop spamming from one node.

The current rule is that anyone who asks for historical block data is send the blocks. 

Hostile nodes could make it harder for new nodes to connect by trying to drain the bandwidth of QoS nodes.


I think ASICS are sufficiently hard coded that even a tiny change to the hash would make them useless.

The token could be formatted as a block header but with all the fields other than the previous pointer and merkle root set to zero.

It is likely that any byte array that doesn't have 80 bytes cannot be ASIC mined.  Swapping the endianess of the output is another option.

The server could send a challenge for each block requested.

B = block hash
N = 32 byte nonce
S = salt (per peer)
M = bit mask
R = rotation
T = target

rotate(SHA256(B XOR N XOR S) XOR M, R) < T

The server could increase difficulty as it runs out of spare bandwidth.

A node could connect to 8 peers and ask for blocks from the peer with the highest T (lowest difficulty).

I'm not clear who needs to create the hash-cash "token" - do you mean any node that connects to you that is not an already known peer (i.e. new incoming connections)?

In any case I do think it could be a useful anti-spam idea (and more inline with the original purpose of hash-cash).

I'd suggest that the algorithm be different to the standard PoW one though otherwise the "proof" will be of little issue to existing ASIC hardware.

A deterrent for running a bitcoind node on a home connection is the potential network bandwidth usage.

A hostile node could connect to your node and send lots of data.  For example, they could send addr messages over and over.  This would consume your monthly allowance.

Assuming 1MB blocks, a full node should receive one and have to forward it to one other node (on average).  This is 2MB every 10 mins.  Additionally, the node should receive the transactions that went into the block in advance.  This is another MB every 10 mins.

That gives 3MB in 10 mins or 18MB per hour.  Setting the full node to 50MB per hour maximum would likely cover reasonable usage.  That gives 36GB per month.  That is lower than many data caps, so would be safe if it could be guaranteed.

A simple hard cap of 36GB per month would prevent bitcoind from prioritizing.

A bitcoin node can mostly control how much bandwidth it uses.  The only exception is if a peer sends unsolicited data to the node. 

The highest priority for a node is to keeping synced to the chain.  Second to that is getting new transactions, since that allows verification of blocks faster.

An peer that sends any of the following could get a bandwidth "credit"
  block header messages that extend the main chain
  blocks on the main chain that weren't already known
  transactions that are accepted into the memory pool

It probably should include anything that is solicited.  If you ask for a block from 2 peers, you shouldn't hold it against the slower peer if they send you what you asked for.

SPV clients that have a single transaction in a block require a path of around 10 hashes.  That gives 320 bytes plus 250 bytes for the transaction.  That is 570 bytes per block and few people would have a transaction rate that high.  That gives 57 bytes per minute, which is 140MB per month.  If a node had 100 peers, then that gives 14GB per month extra.

300MB per peer per month for all messages excluding block updates seems reasonable.

The reject message could be updated to allow nodes to indicate refusal due to bandwidth usage.

This doesn't account for initial sync though.  With pruning that is less of a concern, since a node will be able to say that it doesn't store historical blocks. 

A sybil attack safe initial sync is hard to do.  New nodes could create hash-cash "tokens" to prevent spam.