Quote from: luv2drnkbr on July 07, 2017, 04:41:40 PM

I'm sure it's already been dealt with or is being dealt with, and I am hoping somebody can link me to the most recent advances in that regard, so I can get all caught up.

Yes, to the extent it was any real concern at all it already dealt with by moving compact blocks up ahead of segwit, and they're now ubiquitously deployed.

To reiterate the concern: Peter Todd expressed the thought that segwit might make it a greater gain to SPY mine by fetching the witness data separately thus reducing the amount of data that needed to be sent in order to figure out what transactions were in a block. E.g. instead of fetching 2MB of data they would send 750K of non-witness data. The concern is that a miner could produce a block with invalid spends and SPV clients would accept it and miners that aren't validating the chain will extend that invalid chain and the SPV wallet will see two confirmations; and that this optimization would make it somewhat more attractive for miners to mine without validating.

To avoid even this narrow concern: We pulled the development of compact blocks ahead of segwit. With compact blocks the block is represented by a 6 byte witness-tx-id hash (equivalent to the old txids in that they hash everything including the witness) per transaction in the block. So the optimization that PT suggested above turns into a pessimization: Instead of sending a 30kb compact block you'd need to send a 750kb witness stripped block, which is 25 times larger (thus would take much more time to transfer instead of less).

I think it was always a pretty fringe argument-- if miners want to SPY mine and include transactions they could just communicate bloom filters of the txins they are spending between their spy mining buddies (and even commit them to blocks and validate them, if they like)-- and that works generically, segwit or not, and much much better than sending the witness data would have done (80 byte header + 3k filter, rather than a 750k witness stripped block).

But there was some merit in the point that one thing was already built and running on all nodes and the other not; thus pulling CB ahead of segwit instead of after seemed like a good way of making sure that the default protocol choices weren't ones that favored spy mining. And as you note, nodes already drop invalid blocks harmlessly... the only exposed parties are SPV wallets getting ripped off by malicious miners, but they're already thoroughly exposed to that by the existing SPY mining today, segwit doesn't make a difference there. Most of the hashpower is already validationless mining so they'll already extend an invalid block. Worse, most (all?) of the spv wallets just show a binary "confirmed" at one confirmation so they're already maximally vulnerable and the validationless mining hardly exacerbates their existing insecurity.

I think it would be great to get more general protection against validationless mining in the protocol. Unfortunately, miners and the developers of forks are aggressively against doing so. Short of a UASF for it, which I doubt there is political will for, esp with fork developers arguing that validationless mining is _good_ we wont likely get any unless/until it turns out to be an actual issue. (And then if it were an actual issue you can expect Peter Todd's softfork suggestion would be deployed as a USAF ASAP). Regardless, segwit no longer makes it any worse.

I also find much the recent scaremongering on this to be highly disingenuous; Bitcoin Classic implemented blindly mining off just relayed headers and relaying headers without validating them; and only dropped it because their implementation was crashy. BU has implemented having nodes skip signature validation _entirely_ if the timestamp in the block header added by the miner of the block is too old. Yet it is the same people who created these validation bypasses that are suddenly so concerned about an obscure corner case that was fixed a long time ago. Similarly, the BU people support the Bitcoin.com mining poll which engages in spy mining, and I believe they wrote its pool software. Doubly so because many of the same parties which are "so concerned" are both paid by and aggressively support the same miners that _today_ engage in spy mining. ( I don't say this to criticize you, I get that you're just picking up on claims people circulating; I'm specifically talking about the executives of the Bitcoin "Unlimited" corporation and the developers of Bitcoin Classic). They don't just fail to complain about the widely deployed validationless mining but actively participate and facilitate it themselves. But suddenly they're oh so concerned about a really obscure and outdated argument about segwit.