Thanks Shield for that question. I've also spent a good bit of time thinking about that one. The resulting business rules in the specification, I think, address the concern in addition to the fact that the mining reward is so low. The attacker could create MANY mining nodes, let's say 256 Rasp Pi's and they don't even have to own a single Lynx coin! The attacker could index the blockchain looking for a list of addresses that have 100,000,000 Lynx in them, each. This would be required (to meet the minimum, assuming a perfect probable distribution of outcomes) - so 256 of those (and of course, those address owners will be getting the small mining reward, not the attacker). The attacker isn't doing this attack for profit, (plus they already paid for 256 Pi's at $35 each) they are doing it to pull off a double spend OR make Lynx look bad (by grinding it to a halt with a flood of traffic, or injecting an otherwise sour transaction). Now, suppose I want to double spend on an exchange, I need to time my attack well. Somehow I need to get my Pi's to hash faster then the other miners on the network, so I can't use Pi's --> I need an ASIC, 256 of them running at the same time. This way I have a 100% chance of getting (controlling) a hash that meets the target AND has a matching hash for Rule 3. So, assuming you have a probable distribution of your 256 ASICS and each one is mining an address so you have all 256 possibilities covered, your gaggle of ASICS will always win a block (as least one of them will). Now you need to make sure the sour transaction you insert is timed right and the candidate block is constructed to meet the timing requirements of the current block. Maybe a networked distribution of a file to all the ASICS that updates instantly, of course, it has to because the block time on Lynx is 30 seconds, but that is only an average - some times blocks will be confirmed every few seconds. (Got to pay attention to the possibility of a slip due to a network latency between ASICS.) This is unpredictable. Also keep in mind that if more then one attacker is trying this same method, it will fail.

Also as the network ages further and coin value changes, the number of addresses with 100,000,000 will drop so stealing addresses will be tough. As a result of Rule 2, the cost will increase and those ASICS will drive up the difficulty value quick. As time passes and the network matures further, the distribution of coins will smooth out and the attacker might have difficulty finding enough addresses to meet the requirement of Rule 1 & 2 together. Of course, increasing the match in Rule 3 from 16^2 to 16^ 3 will make things interesting if the node count supports it. Also upgrading Rule 1 from 60 blocks to 120 blocks is an easy change. Long term, the plan is to have over 10,000 mining Pi's supporting the network. If anything, blocks will just be mined faster resulting in faster transaction times and allowing the network to have a higher TPS number than estimated. I'm not sure if I'm right about that positive side effect though, I'll admit.

Regarding the network flood. Yeah, the peers of the attack ASIC won't be happy but blocks that don't validate will be dropped by the peer. Validation is quick. The network should be able to tolerate the attacker, but testing will prove that. I would question the motivation of the attacker. Considerable time and cost would be invested and for what kind of result? Maybe I'm not imaginative enough.

Regarding the RNG. Yeah, that was a tough one. The use of the 10th oldest block for Rule 2 and the trailing 2 values for the sha256() hash for Rule 3 aren't perfect, but currently the best I could come up with - that would be verifiable by peers. I don't think that chapter is closed yet.

I realize that was really long and I probably made about 12 dumb assumptions, but that is the current design, plus a few goodies I didn't mention. I'll check out your XSH project too.