I was the wrong side of a "couple" of glasses of Saturday Riocha when I made those posts originally so I apologise if they sounded over assertive, all the same I still think there's something reassuring about having the mining network do the confirmations and for them to take a bit of time.
Look at it this way. Think of the masternode / blockchain configuration as a client-server architecture. The blockchain/miners are the server and the masternode network the client.
Right now, there is an elegant delineation of responsibility where ththe "client" and "server" are reasonably independent. Also, the mining process is the aspect of the architecture that provides consensus AND buries transactions in the blockchain. I just thought that making the masternode network responsable for confirmations would create a nasty coupling between these two that may be regretted. And for what ? To save a few minutes off the confirmation time ?
If a need emerges for such urgency then it's a nice card to have up your sleeve but I can see as many problems as benefits from making it the default configuration of the Darkcoin architecture - namely it departs from the classic proof or work convention.
But as mentioned, I may not have a full enough understanding of what's proposed to properly jusge.
Got it, I now see where the misunderstanding is. Here is the thing, Masternodes and InstanX, won't be replacing mining in any way or changing traditional transaction confirmation. Normal block confirmation still happens just like it does now, and there is mining and blocks are mined and transactions are confirmed every 2.5 mins. InstanX and transaction locking is a warranty that the transaction will be mined and there will be no double spends, so the people involved with the transaction don't have to wait for the blocks to be mined, they can leave the premises with their goods after 20secs once the transaction lock is in place, the transaction will still be mined in the next block after a couple of minutes, the transaction lock (Instant X) just guarantees that will happen. The way we are thinking about InstantX right now, there is a transaction lock after 20 seconds, the person can leave with their groceries at that point, after a couple of minutes the transaction is confirmed in the blockchain and after a number of blockchain confirmations the transaction lock from InstantX is released. As you can see the transaction lock is an additional layer, a warranty.
Now having said that, having a transaction lock whose duration can be adjusted is very powerful in other applications. You can put a transaction lock that lasts for several normal block confirmations, so instead of facilitating a quick transaction you can produce a delayed transaction for a different application. You pay someone for something but you dont want that person to be able to spend those coins half an hour later. You want the transaction to be locked for a week so you can see that the car they sold you is in good condition. Now the transaction is not reversible, after the week the person will be free to spend the coins, but at least it gives you time so if after a day testing your new used vehicle you find a major problem you have time to go to their place and kick their ass as you know your money has not been moved yet. So paying in a delayed fashion where you can control the locking time, will have a lot of applications too.