Announcing DIP 22 - Making InstantSend Deterministic using Quorum Cycles

[thephez]

We're excited to announce the release of DIP 22, which details a mechanism for making InstantSend locks deterministically verifiable by adding quorum information to them. Currently InstantSend messages are ephemeral and only verifiable for a limited time. While the existing design is sufficient for core chain payments, the platform chain will benefit from the ability to verify InstantSend messages stored on it at any point in the future.

You can read the details about DIP 22 on GitHub. Thanks to @QuantumExplorer @UdjinM6 for their work on this one.

 

[xkcd]

• Pity about the loss of IsLock, IsdLock sounds random AF.
• Will this change mean that when my wallet receives a ISD locked TX and it was not started (open) and then I start it, the TX will show up on my transactions tab? Or will it only show up after it has been mined (current behaviour)?
• I am no techie, far from it, Ape here, but the whole approach reads 'klunky', is this the best way forward? Not even sure why isLock classic wasn't good enough for platform, no one else seems to have an issue with it (provided they are watching) which one would assume Platform always is.
• Can someone describe the theoretical attack that this change is supposed to thwart? You wouldn't be doing this otherwise, so are there conditions under which you think someone could manipulate Platform to credit their account with Evo tokens and recover/refund the DASH spent to create them?

 

[thephez]

• Pity about the loss of IsLock, IsdLock sounds random AF.

Fortunately there's only about 7 people in the world that look into the P2P messages closely enough to notice

• Will this change mean that when my wallet receives a ISD locked TX and it was not started (open) and then I start it, the TX will show up on my transactions tab? Or will it only show up after it has been mined (current behaviour)?

As far as I know, there will be no change in behavior in Dash Core or other wallets.

• I am no techie, far from it, Ape here, but the whole approach reads 'klunky', is this the best way forward? Not even sure why isLock classic wasn't good enough for platform, no one else seems to have an issue with it (provided they are watching) which one would assume Platform always is.
• Can someone describe the theoretical attack that this change is supposed to thwart? You wouldn't be doing this otherwise, so are there conditions under which you think someone could manipulate Platform to credit their account with Evo tokens and recover/refund the DASH spent to create them?

Someone else (one of the DIP authors) can surely provide a better answer. But here's my attempt to explain...
Core only cares if a tx was locked until it's in a block. 2 weeks or 2 years from now, Core doesn't need to be able to verify if a particular tx was locked or not.

Platform, on the other hand, stores the lock info on its chain as proof that the state transition creating credits was valid. If a malicious quorum was able to form, without the deterministic IS change it would be theoretically possible for the malicious quorum to create an alternate islock (this is mentioned briefly in the DIP) and attempt to create credits with it. With deterministic IS, this will be detectable/preventable because there will be a single quorum capable of creating an islock for a particular tx at a given time. Thus nodes syncing the platform chain will always be able to validate there hasn't been any funny business related to credit creation.

If this doesn't make sense, I probably explained it poorly and we'll need @QuantumExplorer to clarify

 

[xkcd]

If this doesn't make sense, I probably explained it poorly and we'll need @QuantumExplorer to clarify

Thanks Phez for that Ape friendly answer! I do wonder about the added computations for this, would it be significant? Signing and hashing would be fast, but I worry about sorting, what do your reckon, any impact?