Quote from: Schnibble on April 01, 2017, 10:03:45 PM

These people aren't running full nodes.

Yes they are. A full node is a node which fully validates every single block and transaction that it receives. Blocksonly nodes are still full nodes, they fully validate every single block and transaction it receives. In fact, as an outside observer, you would absolutely not be able to tell whether someone is in blocksonly mode or not. There is no indication that they are not just a regular node.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

They would not be able to temporarily reject undesirable block but still can validate it.
In a good way this node should be considered as misbehaving node unless it reported to all connected nodes that have an intention to evict transactions.

Many people run blocksonly nodes because it significantly reduces the bandwidth requirements for running a full node. You would completely make it impossible for people to run full nodes in a low bandwidth mode such as blocksonly. This is not something that we want to do as some people may not have the resources to run a non-blocksonly full node but also want the security and privacy afforded by a full node.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

I don't assume that. I've proposed to make them required to keep and relay all transactions.

How do you enforce that? How do you prevent someone from making a ton of super low fee transactions just to spam up mempools and take up more memory, at some point causing nodes to crash? If you require every single transaction to be kept, then you open up an entirely new attack vector.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

I don't assume that. Miners can adjust their delay parameter as much as needed.

What the hell does that mean? As you described it earlier, the "delay parameter" is a consensus rule. You can't just "adjust a consensus rule" as you are proposing without causing invalid blocks.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

minTxRelayFee parameter becomes part of the consensus and cannot be higher than 20 satoshies/byte

How do you enforce that? minTxRelayFee will still be part of node policy. How do you enforce that the minTxRelayFee is no higher than 20 sat/byte. Furthermore, suppose someone were to spam up the mempool with transactions that are 20 sat/byte so much that nodes crash because the mempools are too big. Now what? Additionally, Bitcoin Core currently implements a floating minTxRelayFee because it prevents such crashes. It limits the mempool to a certain size and bumps up the minrelayfee as it gets fuller.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

Not invalid, just undesirable.

Suppose Miner A was malicious and got lucky. They made a block which instead of awarding them 12.5 BTC as the subsidy, awarded them 125000000000 BTC as the subsidy. Now what? Everyone is just going to follow along that chain and let that miner have the 125000000000 BTC because he just got lucky and other miners were SPV mining?

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

No. The worst possible thing that could occur is acceptance the undesirable block consisting of spam.

I'm not talking about spam. I'm talking about a miner who awards themselves a massive amount of Bitcoin in the block subsidy. Or creates a bunch of transactions which spends UTXOs that they normally are not allowed to spend thus stealing coins.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

The worst possible thing that could occur is acceptance the block consisting of spam. But nobody will mine on top of invalid (or undesirable) blocks unless 51% attack is performed...

With SPV mining, a 51% attack is not necessary. Forks have happened before where SPV miners (which consist of >51% of the network as most large pools do this) have mined on top of invalid blocks and in fact made that chain longer than the valid chain until the pool operators intervened and switched the pool back to the valid chain.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

Why do you think so? What about 1MB block size limit rule?

The block size limit is a consensus rule. A standardness rule applies to transactions, and is defined by the IsStandard function in the Bitcoin Core source code. That standardness rules are not the same as consensus rules is not just something I think, but is by definition a local node policy, as defined by the reference implementation. There is no such thing as a standard block, only that there are non-standard transactions, which can still be valid and will be accepted by all full nodes if included in a block.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

If node violates some mandatory rule and for example sets minTxRelayFee parameter to 30 sat/byte it should be considered as misbehaving node, unless it reported to all connected nodes that have an intention to evict transactions.

How would you know? How would you enforce this? Local node policies (including standardness rules) are not broadcast among nodes and even if they were, can be easily faked.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

It is enough to always come to consensus. Miners just need to adjust their delay parameter.

As I said earlier, standardness rules are not the same as consensus rules.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

My proposal assumes hard fork, so miners/pools/SPV servers will have to update their soft.

Regardless of what type of fork this is, SPV mining will still happen and is still a problem. Those two are completely unrelated things.

Quote from: Schnibble on April 01, 2017, 10:03:45 PM

No. The worst possible thing that could occur is acceptance the undesirable block consisting of spam.

No, the worst possible thing that could happen is the acceptance of a completely invalid block. Except under your proposal, such an invalid block can and will be accepted.