Quote from: achow101 on April 02, 2017, 07:39:10 PM

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.

I was speaking strictly in terms of how SPV mining works today, under today's rules.

Quote from: achow101 on April 02, 2017, 07:39:10 PM

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.

No, he has not, however without EC being applicable to only certain rules, the OP's proposal would have too many technical flaws to even be considered.

Quote from: achow101 on April 02, 2017, 07:39:10 PM

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.

Yes, in the case of the OP's proposal, to use EC would result in chaos because nodes would be broadcasting potentially conflicting transactions, and more importantly, miners would be building on top of potentially several blockchains, which would lead to frequent reorgs. You could even have multiple reorgs within a reorg.

I would be more comfortable with a consensus rule change so that transactions must have a tx fee rate above a certain amount (with no exceptions >.<), and EC in regards to block size only. The reason for this is because there is a higher chance there would be a "business" reason to create a larger block (eg the miners are clearing a spam attack backlog, or a backlog that results as a result of some other temporary reason), than to create a block that violates transaction ordering rules. I also suspect that the miners would mostly be on the same page about a pending "large" block, so they would not try to orphan said block, and there would not be many reorgs because of large blocks as opposed to the large number of reorgs that would result from the OP's proposal.