I dont think my argument is weak. I think my analyses of your design is 100% spot on correct. And I encourage you to go implement your design and find out how correct I am! Please do!
You continue to not mention the point I made about incremental validation overhead and accumulated propagation delay and its effect on orphan rate, especially when you have effectively decreased the block period to 15 seconds for the Finality phase Schelling point and 30 seconds for the Prepared block Schelling point.
And you continue to not relate that I also pointed as the transaction fees go to $50,000 with Lightning Networks Mt. Gox hubs dominating settlements in the 1 MB blocks (or pick any size you want which which does not spam the network with low transactions fees because the miners will never agree and unlimited block sizes drive the orphan rate up and break security), then active UTXO will shrink because most people cant afford to transact on-chain. Thus the MRU UTXO will be cached in L3 SRAM. And the block will have huge transactions and not many transactions. Thus your entire thesis about being I/O bound on transaction validation will also be incorrect.
You cant seem to pull all my points together holistically. Instead you want to try to cut a few of them down piece-meal out-of-context of all the points together.
I remain silent about the trolling part, I'm realising you can't help it and it is just unintentional behavior of a polemicist when things get too intense.
Let's take a look at technical part of your reply:
1- There is no incremental overhead, I've never mentioned any incremental increase/decrease (enforced by the protocol or by scheduled forks) in the proposed parameters including the relative difficulty of contribution shares . I have to confess, tho, I'm investigating this possibility.
Will keep you informed about the outcome which will not be a simple linear increase with network hashpower, anyway.
2- Also propagation delay won't accumulate even if we might increase (incrementally or suddenly) the driving factors behind the number of contribution shares because validation cost is and remains negligible for nodes. Remember? The client software is I/O bound and contribution share validation is cpu bound(I'll come to your new objection about it later).
3- I am not 100% against your analysis of lightning or in favor of it, I'm not that much interested or believer in LN as a scaling solution, but it won't help your position in this debate:
Your arguments:
You are
speculating that transactions will go off chain in the future and the main chain will be busy processing huge transactions produced by flush operations in LN nodes and at the same time network nodes will manage to keep the UTXO (its most Recently Used Part) in SDRAM and it helps them not to access HD frequently and so, they will be no more I/O bound (relatively) and this way the processing overhead of contribution shares begins to look more important and will become to be a bottleneck eventually. Right?
Answer:
- You are speculating TOO much here, my perception of LN and off chain solutions differs moderately
- Having MRU UTXO in SDRAM cache won't help that much, task would remain halted for RAM access and yet would access HD for page faults and most importantly for writing to UTXO after the block has been verified
- Also, a relative improvement to node's performance in validating full blocks is not a disaster, the number of blocks is the same as always
4- As of your expectation from me not to cutting your objections down to pieces is like asking me to troll against a troller. On the contrary I prefer to go more specific and resolve issues one by one. On the contrary you want keep the discussion in the ideological level, being optimistic or pessimistic about this or that trend or technology and so on, ... I think in the context of making assessments about a proposed protocol my approach is more practical and useful.
I specifically mentioned order-of-magnitude readjustments in the future. There you go again twisting my words and being disingenuous.
Firstly, doubling or tripling the number of shares don't make significant problem in terms of share validation costs, it is yet a cpu bound process, some very low profile nodes may require $200 or so to buy a better processor, in the worst case.
Youre ignoring that I argued that your thesis on transaction validation bounded validation delay will also change and the validation of the shares will become incrementally more relative. And that taken together with the 15 second effective Schelling points around which orphaning can form. Youre not grokking my holistic analyses.
there will be no order-of-magnitude (=exponential like tens or hundreds of times? ) increase to the network hash power in foreseeable future and I did you a favor not to simply rejecting this assumption, instead I tried to address more probable scenarios like 2 or 3 times increase in next 2-3 years or so.
Although it is good to see the big picture and take cumulative effects in consideration, but it won't help if you have not a good understanding of each factor and its importance.
You are saying like :
look! there are so many factors to be considered isn't this terrifying? No! This is not terrifying as long as we could be able to isolate each factor and understand it deeply, instead of being terrified or terrifying people by it.