...
Just from knowing a little about database tuning and ram vs. disk-backed memory, I have always wondered if people have make projections about performance of the validation process under different scenarios and whether they can/will become problematic. One think I've always wondered if it would be possible to structure transactions such that they would load validation processes to heavily on queue, and particularly if it is common case to push more and more data out of the dbcache. Any thoughts on this that can be quickly conveyed?
Most of the thought has just been of the forum "The utxo set size needs to be kept down" with an emphasis on the minimum resources to run a full node over the long term. The database itself has n log n behavior, though if the working set is too large the performance falls off--and the fall of is only enormous for non-SSD drives. Maybe the working set size is owed more attention, but my thinking there is that user tolerance for resource consumption kicks in long before thats a serious issue.
When you talk about "would it be possible" do you mean an attack? It's possible to construct a contrived block today that takes many minutes to verify, even within the 1MB limit; though a miner that did that would mostly be hurting themselve unless they had some arrangement with most of the hashpower to accept their block.
Thanks for the input. Yes, as an attack. Say, for instance, one primed the blockchain with a lot of customized high-overhead transactions over a period of time. Then, when one wished to create a disruption, take action on all of them at once thereby upsetting those who were doing real validation.
The nature of the blockchain being what it is, I see an attack being most productive at creating a period of unusability of Bitcoin rather than a full scale failure (excepting a scenario where secret keys could be compromised through a flaw in the generation process which would, of course, be highly devastating.)
I was unaware that even today it would be possible to formulate transactions of the verification complexity that you mention. It would be interesting to know if anyone is watching the blockchain for transactions which seem to be deliberately designed this way.