Quote from: Schnibble on April 02, 2017, 04:36:29 PM

Actually, node requires to be connected at least with one node that relays all desireable transactions.

Even if they are connected to a node that relays all "desireable" transactions, that does not necessarily mean that the node will have all of those transactions stored somewhere in order to properly validate a block. It needs to be able to lookup that a transaction was in its mempool for at least X seconds, and if it doesn't have a mempool, then this is impossible.

Quote from: Schnibble on April 02, 2017, 04:36:29 PM

They still can use their wallets in blocksonly mode. But what's the point if it doesn't receive transactions?

A blocksonly wallet still receives transactions when they come in a block, i.e. the transactions have confirmed. You are reducing the security of people running blocksonly nodes as they are trusting that blocks that they receive are valid with regards to the transactions inside of them being in the mempool at least X seconds.

Quote from: Schnibble on April 02, 2017, 04:36:29 PM

The chain becomes valid anyway, when it receives two or three valid blocks. Also we can simply bypass this rule for some time after the launch.

No, bypassing the rule for some time after the proposal deploys is not going to help at all. New nodes don't just come online after a proposal activates; nodes are being restarted all the time and this rule will force a node which just started to reject the blocks because it doesn't have a populated mempool to begin with.

Quote from: Schnibble on April 02, 2017, 04:36:29 PM

Yes. But it is not a miners' problem. Actually, I doubt whether node even without additional delay can receive full block before small transaction. Furthermore, given that transactions are relayed before.

A node can most certainly receive a block before transactions are received. There is no stipulation that blocks cannot be sent before transactions (it's asynchronous). A newly started node with NO MEMPOOL is not likely to receive the transactions that are included in a block if the block is found shortly after the node starts up. Furthermore, new nodes don't populate their mempools with the transactions in the mempool's of other nodes. Nodes only relay a transaction once, right after they receive and validate it.

Quote from: Schnibble on April 02, 2017, 04:36:29 PM

Malicious miner will generate a lot of orphan blocks before that happens.

Even so, it is an attack that is entirely possible and potentially has huge payout.

Quote from: Schnibble on April 02, 2017, 04:36:29 PM

Anyway, the worst possible thing that could occur is acceptance the undesirable block consisting of spam. The best chain is selected only when it meets the consensus rules.

No, you don't seem to grasp the idea that ALLOWING INVALID BLOCKS MEANS THAT MALICIOUS THINGS CAN BE DONE. Your proposal allows the absolute worst possible thing that can happen in Bitcoin, allowing an invalid block become completely valid. By allowing invalid blocks, you are allowing blocks completely circumvent the consensus rules. What part of that do you not understand? Do you not understand that invalid blocks include more than just being larger than the block size limit?

Quote from: Quickseller on April 02, 2017, 07:33:13 PM

The miners who engage in "SPV" mining will only mine on top of an unvalidated block for as long as it takes them to validate the block. These miners are relying on the valid economic assumption that it is not economical to build/broadcast an invalid block, and it will cost a troll miner much more to broadcast an invalid block than it would cost the rest of the network to build upon an invalid block for only as long as it takes to determine that said block is invalid. It would cost a troll miner roughly 13.5-14BTC to broadcast an invalid block, while it would cost 90% of the network collectively between ~.6BTC-~.62BTC to build on top of that block for the amount of time it takes to figure out it is invalid.

Not necessarily. As I mentioned earlier, an invalid block can be invalid in many ways. It is possible that a miner could make an invalid block which has a massive payout, such as changing the block subsidy to 1250000000000 BTC for that block. Even though the consensus rule is that coinbases need to have 100+ confirmations before they can be spent, this is an invalid block, so consensus rules go out the window. They can make a block which has that huge reward and make and include a transaction which spends that reward to an exchange address thus once they get their invalid block considered valid, they can cash out and make a ton of money to recover their costs.

Quote from: Quickseller on April 02, 2017, 07:33:13 PM

OP - You are describing something very similar to EC (emergent consensus). It should be important to point out that only certain consensus rules are subject to EC in your proposal, otherwise the miners will be able to make *all* the rules, which is probably not something that is desirable.

Has OP stipulated that his "temporarily invalid" block thing is only applicable to certain consensus rules? He has not mentioned that explicitly thus far in this conversation, and it was not mentioned in the OP when I first responded to it.

Quote from: Quickseller on April 02, 2017, 07:33:13 PM

I would also point out that not all nodes' clocks are on the exact same time (when converted to GMT), so it would be difficult to determine if a transaction has in fact been in a miner's mempool for at least 15 seconds prior to broadcasting a block that confirmed said transaction, so I don't think it would be possible for a node that had received a transaction at the exact same time as the miner to validate the miner had the transaction in it's mempool for at least 15 seconds. Also, as achow101 pointed out (somewhat), if a node receives a transaction 5 seconds prior to receiving a block that includes said transaction, they believe said block is invalid -- this is however resolved by your EC clause.

But waiting for the EC clause to take effect takes time, and this case is a usability issue. Suppose you received a transaction, and that transaction is included in a block. But you perceive that block as invalid because some other transaction in that block was received less than 15 seconds before you received the block, so you mark it as invalid. This is can make Bitcoin less easy to use as some users won't know that their transaction has actually confirmed since the wallet considers the block it was confirmed in to be invalid until ~30 minutes after the confirmation. In fact, a miner could perpetually prevent the EC clause from taking effect for a specific node by always broadcasting an old transaction (i.e. one that was discarded by being older than 1 hour, as was mentioned previously) shortly before broadcasting the block including it. You could do this an effectively take nodes offline for a while.