1) Why is there no user-friendly way to know if my transaction is going to be auto-locked (has <=4 inputs), before sending it? This info could be useful. I'm asking for simple message, just like "gonna confirm instantly" or "will need a few minutes to confirm, check InstantSend box to force instant confirmation".
2) Am I right thinking that auto-locked txs are no different for a receiver than normal IS transactions? Thus, all wallets/exchanges which do not support IS will show that tx is unconfirmed, even if it is locked, right?
I still suggest that IX needs to be detached from the current mode of operation, as it makes the process sender-centric. The whole point of IX is to assure the
RECIPIENT that the TX can't bounce.
It should be possible for any observer holding memory pool to request a VIN lock on any TXID it sees, with total disregard to VIN ownership. A fee should be part of this. Anyone on the network can pay a fee and IX lock any current mempool TXID. This also means that the client initiating the message, which if malevolent, is clearly not going to help the rest of the network figure it out... So, removing the power from the sender takes the power to abuse the network out of the message initiator's hands altogether, since it simply wouldn't be managed that way anymore...
The worst case scenario, under the model I'm suggesting, is that a bad actor essentially becomes a generous humanitarian, paying fees to lock everyone else's TXes for them... Oh darn, not that... The Black Hat becomes a charity of his own funds...
This allows centralized, passive HD chasing wallets to request IX on any TX in it's HD chain, without needing to be directly coordinated with the node actually conducting the transaction. This would help large retailers.
But most importantly, NOT doing it this way leaves the vendor to wonder if the buyer is jerking them around. Waiting for confirmations is not an option at the checkout counter. It has to happen NOW, with certainty. While a bad actor may not be able to enact the exploits of other coins on DASH, he can still back up the line by deliberately not using IX and make DASH look bad in the eyes of the vendor...
If you're going to do this on-chain, it has to work every time. The only way to be assured of this, is that it not be in the hands of the sender. Off-chain and side-chain settlement systems, like lightning network, offer this assurance. DASH currently does not, in spite of having been the ones to invent the concept... That's rather embarrassing.
Right now, it's backwards.
At the very least:
IX needs to be recipient-centric, since it is the recipient which is meant to be assured of security. As it currently operates, this assurance is ambiguous and still exploitable by nuisance vector, even if not by transaction reversal vector or transaction failure vector. From a retail vendor's perspective, this nuisance vector could be a major deal breaker. The final operation of any POS transaction, the actual movement of funds, can't be monkey-wrenched in any way.
Making it open ended is just another bonus, as I see it...
@UdjinM6 has previously explained that the current mode of operation is a deeply-rooted technical limitation. I'm saying that's gotta change... It's a significant augmentation of how crypto-at-large has been operating since it's inception; but, so are masternodes... Which leads to PoSe for privileged mining, but I'm already straying off topic for a testnet thread...
I hope I don't come across as dismissive or antagonizing, as I know I may not be getting it.
