Topic: One proposal for hindering antisocial blocks (Read 1624 times)

Actually I've considered that alternative from time to time. A very low (long run < 1%/y) inflation rate is basically just as good as zero inflation, with the added benefit of replacing lost coins. The main problem is that there's no guarantee that the block reward will be enough to pay for mining, but similarly there is no guarantee that it won't completely pay for mining and make tx fees basically superfluous. That would require predicting the future market price for BTC, the cost of a future mining rig, the number of rigs required to handle the future tx throughput, which you'd also need to predict, and so on.

The same limitations of multiple, unpredictable variables makes it somewhere between difficult and impossible to make any determinations about efficient mining incentives. The major advantage to being able to predict something like that is that then you could charge a standard fee rate or no fees and basically every tx could still be verified by the next block. Given that "change" can't be spent till at least 1 confirmation (I assume anyway), the time consideration can become a major bottleneck for the use value of BTC.

DeathAndTaxes, what you are describing is simply called a split chain and these problems arise with any big protocol change, and there are numerous ways of addressing them. But you are right, it's pointless to discuss that in this topic, I simply mentioned that as a possibility and how that would connect to the proposal in this topic.

Nothing would stop him from creating his own transactions.  But he still has to distribute them to his nodes, and even one transaction would be much more data than he is distributing now.  Also, the data he needs now he can get from a variety of public sources.

While anything can happen you will never get 70% to 80% of miners to support it.  Notice I said 70% not 50.001%.  While technically you could fork the chain with any amount of support (even 1%) a 50% split would likely be the death of Bitcoin.  The original and modified forks would both exist, people would have coins in both forks and when sending coins they would need to specify which Bitcoin they were talking about.  Some exchanges/merchants might support "new Bitcoin" and some "old Bitcoin" and some would support both.  Users would have differing values in each chain and those supporting one side would see no value in the other resulting in massive selling. 

It would be beyond chaos, and the negative PR alone would be catastrophic.

It won't happen.  Even many miners who would support it in theory won't support it for the massive disruptions it would cause.  Discussion it is just pointless.

I am suggesting it, and some other people seem to have the same idea. And it can happen, that's ultimately up to the miners. Protocol changes have been done before. But that's really not the topic here, I just said that if that was to be done, the miners would not need that much freedom and the proposal discussed here would work even better.

He is talking about keeping the subsidy.  Miners would have to include free transactions because they were paid by the subsidy, not by fees.

This is actually the best reason I've ever seen suggested for potentially keeping the subsidy.  But I still don't think it is a good idea, and I don't think it'll gain any traction.

Nobody (I guess you are?) is even suggesting block reward will be kept constant.  The fixed # of coins is a cornerstone of Bitcoin.  Changing that now (even if desirable) will never happen.

I guess I wasn't clear enough , sorry
by this
I mean of course that the block reward is kept constant. (That we do take this protocol change in the future.)

I think 20% is too much -- in regards to what is needed to ensure a miner is doing his job versus the autonomy desired by miners.  As mentioned before, there only needs to be enough tx required that the rogue miner has to start paying attention to other tx on the network:  it sounds like he's not paying attention to any of them: 0%.  If he has to start paying attention an including any of them, he might as well include all of them.  Problem solved.

Well not actually solved yet:  but my point is there's a very low threshold for what is needed to get him to start paying attention.

EDIT: on second thought, what's stopping him from just creating 20 tx per block himself and broadcasting them, just to make sure he can meet the X% req't?  Seems like we might accidentally encourage the rogue miners to start adding bloat just to get around the rule (which might be easier than starting to pay attention).

Ok this doesn't make any sense.  As block reward declines the need for miners to exclude unprofitable tx becomes even MORE not less important.  

To combine your the two underlined portions, so hypothetically when the block subsidy is 0 BTC miners should be required to include all tx.  Even if they are mostly 0 fee?  If miners must include all tx (even those w/ no fee) why would any user include a fee?  The simple answer is they won't and thus both block subsidy and fees will be roughly ~0.

So when block subsidy is 0 and fees are 0 how will the network remain secure?

Your proposal looks like it just might work, I see no obvious holes in this.

About

The most important reason for why miners would want any autonomy of decision is for later days when their revenue will come from the transaction fees instead of block rewards. Then they must have the power to only include transactions that have enough fees.

But if the percentage of transcations that are needed to be included in order for the block to be valid is set pretty low (like 20%)(which will be enough to fix the problem), the miners would still have the freedom to not include 60-70% of all transactions, and obviously only choose the best paying ones, so it could still work!


I also think that keeping the block rewards constant for all eternity is beneficial in many ways and is going to be discussed more and more when we get near it's planned elimination, and if that is how it is done (that we do change the protocol to keep block reward for all eternity), the miners will not need that much freedom, they will just have to include all the transactions they see. A way to think about this is that instead of each transaction paying a small amount to the miners, the whole community pays to them through constant block rewards and thus a very slow inflation rate. This is even more logically correct, because the mining is not only beneficiary for the people transferring bitcoins right now, but also to the people keeping bitcoins, because mining causes all the bitcoins being more secure and more stable, thus helping even people sitting on bitcoins.


Still, I think it is too early to be implementing anything like this, but it is certainly beneficial to start the process of evaluating this thing as a community.


This is absolutely a requirement of course, but even there would be small errors now and then - they would get eaten up by the fact that those blocks become temporarily blocked. So even if a small percentage of miners would get some block wrong sometime, the whole thing would figure itself out at the next block, in the true decentralized spirit . No permanent damage.

Yes, got it. The subnet is to strong and doesn't rely on the nodes.

That wouldn't do anything.  What matter is will another miner build upon a "anti-social" block.  If all non-mining nodes agree that a block is anti-social but all miners build upon it then the distinction is useless.

Finding the nodes of other major miners isn't that difficulty and one could simply send their anti-social blocks directly to other major miners.
There is no such thing as broadcast power.

I am not sure if it really is necessary to give new rules *to miners*. Instead I would love to give *the non-mining nodes* a more sustaining role by their role as relay. Those shall not broadcast "antisocial" blocks and by this miners would have to arrange with with nodes which could help to solve the imbalance between these two roles in the network. This way to harm the network you not only need 50% hashing-power but also 50% broadcast-power as security.

There's an interesting dynamic here... the system only needs to be effective at the beginning to clean up what is there and prevent future abuses.  After the system reaches steady-state, it would be as if it wasn't there -- no one would bother building anti-social blocks anymore, and the logic would remain unused (assuming it's calibrated to only handle the most anti-social cases).  As kjj said, it only needs to be enough to make it easier to follow the rules than work around it.  I think that's a low threshold to meet, and you could set the algorithm to have basically zero-false alarm rate for regular miners.

As twobitcoins said, it is purely, financially negative to follow this rule unless 100% of other honest miners are following it.   But it seems like three conditions at least make the theory plausible:

(1)  isAntiSocial() algorithm is very reliable -- I don't want to discuss the details of this, but I think it's very feasible to separate out the two classes of blocks:  social and anti-social -- which means you could very reliably classify them.
(2)  The logic required for the botnet to get around it would be harder than the rules to just operate honestly. 
(3)  The network well-connected and efficient enough that if 100% of honest miners implement the logic, that that 99%+ of them will also agree on isAntiSocial for each new block -- thus the cost to them of improving the network costs them less than 1% of their mining rewards -- perhaps an efficient network is worth 1% of their total income...

On point number three -- in a nominal scenario, the negative impact to their mining rewards is only transient:  if the system is effective, anti-social blocks will stop happening, and then it will become irrelevant.  On the other hand, if it really is a botnet, then the operator really doesn't care.  His botnet produces only 20% valid blocks (because miners will accept empty blocks that were found quickly), but he's still making a ton of money from it for zero cost.  Perhaps it's worth it to him to implement the honest logic so that he can up it to 80%, but maybe he won't...

Miners have a financial incentive to make sure their blocks are accepted so they get paid.  This proposal tries to use that incentive to force miners to include transactions, but it ignores the impact of that incentive on miners who must decide whether or not to reject blocks that contain too few transactions.

As a miner, if I choose to ignore the longest chain because it contains too few transactions and I instead build a block parallel to that chain, I face the risk that someone else may build on the other chain instead of mine, invalidating my block.  If I instead build a good, transaction-containing block on top of the longest chain, I can avoid that risk.  Therefore, I am unlikely to choose to participate in the proposed scheme, and if code that implements the scheme is added to the standard client, I am likely to disable it for my mining operation.

I also think this is not really true:


Because of the risk of generating an orphaned block, the only time it is safe to reject a block is if you can be sure that almost everyone else will also reject it.  It's not enough to have a majority (as with a change like P2SH).  Even if 90% of miners will reject a particular block, choosing to reject that block yourself will result in wasted work 10% of the time.  The system can only work if everyone follows the same rules.  It seems nearly impossible to get such a system off the ground.  Any proposal must address these incentive issues.

I like the general idea of this proposal.  To me, it sounds like it's a very simple two steps:

(1) Create black-box algorithm isAntiSocial(newBlock, currMemPool); returns true or false.
(2) Only build on top of blocks that return false from (1)  (not antisocial)

Number (2) means that if we are a miner and we see an anti-social block extending our current longest chain, we will continue building on the previous block and just ignore it.  If someone builds on top of that with a non-anti-social block, then we will switch to it.   In the end it, doesn't really matter which block a miner builds off of, he doesn't get any more or less generation fees.  The only thing he's doing is leading the invalidation of blocks of a miner that isn't doing its job.

One big problem I see with this is that all nodes have conflicting interpretations of how many confirmations a given transaction has, and now when you have a chain of 3 anti-social blocks and then someone builds a non-anti-social block on top of it, your node instantly accepts it as having four confirmations.  Is it a problem?  Probably not, but I haven't thought too much about it.

It certainly could be confusing, as nodes can't actually agree on this metric (though, how important is the metric?).  Forget the black&white case of some nodes producing empty blocks, and other nodes producing "normal" blocks.  Perhaps the anti-social blocks still include some transactions, just not many, and half the network decides social and the other half decides anti-social.  Then new blocks come in extending it, which leads to a new fragmentation of the network.  You've now got miners all different levels:  some are working to extend block X, some extending X+1, some X+2... and the node working on X will create a block that the X+1 and X+2 nodes don't recognize as the longest chain and simply ignore -- dramatically increasing the probability that miners end up with invalid blocks. 

Perhaps there's even a way to trick nodes into believing certain things as a form of attack.  You feed them lots of transactions to change the makeup of their memory pools so that they are likely to view more blocks as anti-social and then subsequently produce lots of blocks that end up being invalid.

I support everything said above.  Here are some initial thoughts for more refined social acceptability policies:

---

Proposal 1) "blocks must include ($p percent - $o offset) of all pending transactions as measured by fees".

$p can be a low number (say, 10%), and $o could be 5, to give miners benefit of the doubt when there are few transactions available.  If many blocks pass with miners only including the minimum 10%, the backlog will grow.

Since the 10% includes the backlog, they are still guaranteed to eventually be included - they have a minimum 10% chance each block; and transactions paying higher fees will be processed faster since they're more valuable for meeting the quota.  Free transactions are processed only at the whim of miners.

---

Proposal 2)  "blocks must include ($p percent - $o offset) of all pending transactions as measured by $scoring_algorithm".

An  example scoring algorithm might be: $transaction_score = (0.001 + $transaction_fees) * $time_transaction_has_waited.

The 0.001 ensures that even free transactions will be cleared eventually; scaling by the time the transaction has waited means that minimum-fee transactions will eventually become valuable enough to clear.

---

Generally I am trying to create as little economic disturbance to the system while still enforcing some minimum inclusion.  The downside to both of the above is the $o offset will create a brief window after each new block (assuming it includes 100%) where Mystery (or anyone) can generate null blocks.  With the example 10% and 5 offset, null blocks would be valid until there are at least 50 fee-paying transactions available (assuming equal fees).  This is likely overly-conservative.  Different values or a less linear relationship (for instance, setting $o to the number of txes seen in the last 10 seconds instead of a static 5) may work better.

Since no protocol change is required, any miner can set their own values or even their own algorithm.  A heterogeneous policy would likely create a smoother response to miners' include policies, but it increases the risk of a blockchain split.  These effects should be modeled.

Edit: One additional rule may be: "all blocks must include at least one previous transaction".  It wouldn't help in a DOS situation (the miner can generate some junk transactions), but it does help with the Mystery situation: it would require miners to actually have a copy of previous blocks.  I'm on the fence whether this is a good idea or not.

I would like this thread to discuss only this one proposal for hindering empty block mining.  We already have two threads full of speculation about who is mining the empty blocks, and brainstorming other ideas for stopping them.  I'd prefer that this not become a third.





The two main objections to my proposal are:

1.  It would cause forks, which would be bad.  I think that I've addressed this sufficiently.  It will indeed cause local forks, but those forks will not be global, and will not persist any more than the forks we already have.

2.  Miners would lose quite a bit of autonomy over which transactions they include.  Sadly, this is true, and is actually the entire point of the proposal.  But, the community at large is paying for the work done.  I think that we have the right to set standards for the quality of work which we will accept.

My proposal also has some less obvious advantages.

1.  It requires no new protocol and no new centralized authority.  Each node can make the decision to defer an incoming block based on the data it has locally.

2.  Each node would be able to set their own policy.  The network would reflect something like an average of the policies of all miners.