Solar, I don't mind you having an opinion, but I do take issue when you post assumptions as fact.
If blocks do get full, InstantX transactions will start to be unlocked.
100% completely and utterly false. IX locks are mempool entries same as transactions. They don't get flushed until the transaction gets written into a block, regardless of how many blocks that takes.
And, your disappointment is simply impatience. The very last sentence of the proposal states:
If approved, a proper development, testing and deployment process would start before it reaches production. Lets give Dash room to grow.
The process is already happening, there's just no need to implement it anytime soon.
Hey Moo. There is more too it than just being impatient. I think most people thought that proposal would happen quickly, not waiting 2 years for Evolution. And if this was the only issue with Dash, it would be a pretty minor issue.
This is from the initial release post here:
https://www.dash.org/forum/threads/v0-11-1-instantx-release.3923/Transaction locks are lost when restarting the client and only last for an hourSo if there are enough transactions that have fees higher than the InstantX fee, and blocks are kept full for an hour, the lock will be released and transaction unlocked.
When Evan put up that proposal, it's ONLY purpose was to show how fast Dash can get consensus. We won't need extra space for at least another 3 years unless we are suddenly so successful, we're all wondering if we're having a wet dream. We BARELY make a dent in any block. Why this issue should bother you, I can't understand! I think it used to be that block size was needed to reserve space for entries. I don't know if that's still the case. But if you have each block with 1 MB of space, it grows quickly. If you reserve 2 MB of space, the block size grows doubly fast. I heard block sizes are now flexible, but I'm not sure that's the case. If not, then our 4X transaction space is already growing far faster than Bitcoin's and it's all empty space! I hope that's not the case, and that we actually have flexible block sizes, but I believe that's why there is a block size, and we simply inherited it.
And I can see MooCow being correct, that having too much wiggle room with nothing in there might create attack vectors. I don't know how exactly, but in programming, you want to keep things well fitted and efficient.
As far as transaction locks go, those usually clear up with the very next block. But if that proves not to be enough, as Udjin said
here, "Successfully locked inputs are kept in "lock list" for 1 hour i.e. 24 blocks on average which should be enough imo but I'm sure we can easily extend this if there is a need or some research saying that this is not enough."