Questions about InstantSend
- Thread starter Elmo
- Start date
camosoul
Well-known member
This is not a new idea.
When IX was originally invented, it was often said that making all TXes into IXes was the ultimate end goal.
We don't know if that's the case anymore. We don't know what the plan is. Right now, IX is busted and deliberately disabled. I'm not clear if the Dear Leaders even care anymore...
Essentially, IX was meant to give RECIPIENTS assurance that there would be no double-spend, and the money would actually be theirs. No need to sit around waiting for the ledger to run double-duty as TX security; blocks/confirmations. But, since it is enabled or disabled at will by the sender, the recipient doesn't really get any assurance, and it's use is discouraged by charging the sender a fee, undermining the flow of operations entirely, from the recipient's perspective.
Someone intending a double-spend attack against a seller can simply not use IX. The vendor may not understand the technicalities, and get burned. If the vendor is smart enough to notice that IX wasn't used, the attempted double-spend attacker can simply say "Opps, I didn't mean it." and we have no way to know if they really did just try to rip someone off, or if it was a mistake... They can keep hunting for a victim with no way to detect them. How hard do you think it'll be to find a clueless sales clerk? Not hard. DASH will be blamed for a lot of lost money. Even if they're smart enough to know this means they need to wait for blocks now.... You going to physically detain a customer for 15 minutes? Hold up the line? Since this was likely an attempted double-spend attacker, they're going to have a rant and complain planned out because they know this is the plan... DASH sets up a total cluster fuck for vendors. It monkey-wrenches the whole process even if it works!
VIN (b)locks, and VIN (b)lock requests, need to be handled in a completely different way than they are now. I've been told many times "but that's not how IX works." Yeah. I know. I'm describing how IT NEEDS TO CHANGE TO BE USEFUL. I know full well that's not how IX works; that's the effing problem!
This flawed perspective of implementation is broken and makes the feature unusable even when functional...
When IX was originally invented, it was often said that making all TXes into IXes was the ultimate end goal.
We don't know if that's the case anymore. We don't know what the plan is. Right now, IX is busted and deliberately disabled. I'm not clear if the Dear Leaders even care anymore...
Essentially, IX was meant to give RECIPIENTS assurance that there would be no double-spend, and the money would actually be theirs. No need to sit around waiting for the ledger to run double-duty as TX security; blocks/confirmations. But, since it is enabled or disabled at will by the sender, the recipient doesn't really get any assurance, and it's use is discouraged by charging the sender a fee, undermining the flow of operations entirely, from the recipient's perspective.
Someone intending a double-spend attack against a seller can simply not use IX. The vendor may not understand the technicalities, and get burned. If the vendor is smart enough to notice that IX wasn't used, the attempted double-spend attacker can simply say "Opps, I didn't mean it." and we have no way to know if they really did just try to rip someone off, or if it was a mistake... They can keep hunting for a victim with no way to detect them. How hard do you think it'll be to find a clueless sales clerk? Not hard. DASH will be blamed for a lot of lost money. Even if they're smart enough to know this means they need to wait for blocks now.... You going to physically detain a customer for 15 minutes? Hold up the line? Since this was likely an attempted double-spend attacker, they're going to have a rant and complain planned out because they know this is the plan... DASH sets up a total cluster fuck for vendors. It monkey-wrenches the whole process even if it works!
VIN (b)locks, and VIN (b)lock requests, need to be handled in a completely different way than they are now. I've been told many times "but that's not how IX works." Yeah. I know. I'm describing how IT NEEDS TO CHANGE TO BE USEFUL. I know full well that's not how IX works; that's the effing problem!
This flawed perspective of implementation is broken and makes the feature unusable even when functional...
Last edited:
