Questions about InstantTX

[No_2]

When an InstantTX is initiated how are miners on the network notified that the output of a transaction already on the blockchain can only be spent by a transaction selected by a quorum of Masternodes? E.g. is a new block validation rule propagated across the network for the miners to follow?

Can an InstantTX reference a transaction which is in a miner's memory pool and not yet mined to a block in the way that transactions which have not yet been mined to a block can reference one another.

If there is a blockchain reorganisation because a longer chain is revealed to a part of the network is there a way to enforce the InstantTX is maintained. E.g. how long does the list of what InstantTX are valid remain cached with the Masternodes and miners?

How are master nodes remunerated for their services?

 

[Solarminer]

Posted my response here. Feel free to ask any followup questions.
https://bitcointalk.org/index.php?topic=421615.msg15261582#msg15261582

 

[No_2]

Thanks, will take a look there.

 

[UdjinM6]

When an InstantTX is initiated how are miners on the network notified that the output of a transaction already on the blockchain can only be spent by a transaction selected by a quorum of Masternodes? E.g. is a new block validation rule propagated across the network for the miners to follow?
...

To answer this let me take a step back and explain a bit how IX works. It's smth like this:
- wallet sends "txlock" message which internal structure is the same as normal "tx" - IX request
- all nodes on the network recognize such message and store it in a separate list - "request list"
- all nodes have deterministic way of figuring out some kind of masternode(MN) Rank for each given MN based on the blockhash of the last input
- having all this all nodes can find top10 MNs for current IX request, MNs that find themselves in top10 sign "txlvote" message - IX vote - and relay it to the network
- all nodes now can verify such messages and count them as 1 valid IX vote if everything is ok (MN is in node's top10 and signature is correct)
- when there is enough legit IX votes on some node it moves IX from "request list" to "lock list", if there is not enough votes in 5 minutes - lock request expires
- from this moment any other tx which has one of the locked inputs is recognized as invalid, blocks containing such txes are considered to be invalid too and rejected

...
Can an InstantTX reference a transaction which is in a miner's memory pool and not yet mined to a block in the way that transactions which have not yet been mined to a block can reference one another.
...

Currently that's not the option, all inputs must have at least 6 blockchain confirmations. Probably a good idea to support chained IXs though, needs more investigation/testing imo.

...
If there is a blockchain reorganisation because a longer chain is revealed to a part of the network is there a way to enforce the InstantTX is maintained. E.g. how long does the list of what InstantTX are valid remain cached with the Masternodes and miners?
...

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.

...
How are master nodes remunerated for their services?

MNs receive 45% of block reward, one MN at a time. They all stand in a queue 90% of a time and then there is last 10% which is probabilistic. Their reward is not tied to number of IX or DS they actually served, it's a reward for providing this service in general.

 

[No_2]

This is really helpful. Thanks.

Some questions about edge cases and related stuff:

1. From what I understand InstantTX (or Instant Send as it is now re-branded) is more about minimising the period of recipient uncertainty than sending funds instantly. Take this example: If a malicious entity is attempting to double spend a payment and broadcast two new transactions to different parts of the Dash network. One which has low latency to the recipient but with high latency to the majority of masternodes, and a second transaction doublespending the funds to a part of the network with low latency to the masternodes. Is it most likely that the master nodes would receive the doublespending transaction first and lock this in? If that happened the recipient would instantly see that they had not received their promised funds. Conversely in the unusual case where the first transaction is locked the user would see their promised funds sent to them instantly and the double spend transaction would be dropped by the network. Have I understood this correctly?

2. Can a transaction be broadcast and mined into a block before it's locked by the masternodes? I don't see this as violating anything above as it meets the requirements for reducing the period of uncertainty any way so it seems to only be a desirable edge case to me, assuming I've understood this correctly.

3. Am I correct in understanding that there are differences in Dash between normal transactions and instant transactions when broadcast to the network? Are there additional fees associated with InstantTX, and if so what are these used for?

4. Am I correct in assuming that chain reorganisation is possible on; if a longer chain turned up with a greater total amount of work? And therefore theoretically there is an edge case where a chain older than an hour (or 24 blocks, not sure which metric the network uses) is broadcast to the network and double spends one or more of the transactions in that chain?

5. Are there any technical differences between InstantTX and Instant Send or is it purely branding?

6. Where can I see the source code which deals with masternode selection for quorum formation, broadcasting of the lock list to the network and how payment is distributed to the masternodes?

Thanks again.

 

[UdjinM6]

...
1. From what I understand InstantTX (or Instant Send as it is now re-branded) is more about minimising the period of recipient uncertainty than sending funds instantly. Take this example: If a malicious entity is attempting to double spend a payment and broadcast two new transactions to different parts of the Dash network. One which has low latency to the recipient but with high latency to the majority of masternodes, and a second transaction doublespending the funds to a part of the network with low latency to the masternodes. Is it most likely that the master nodes would receive the doublespending transaction first and lock this in? If that happened the recipient would instantly see that they had not received their promised funds. Conversely in the unusual case where the first transaction is locked the user would see their promised funds sent to them instantly and the double spend transaction would be dropped by the network. Have I understood this correctly?
...

Well, theoretically that is a possible situation. But you also need malicious MNs to sign all inputs because legit one will refuse to sign locked input second time. So either first or second tx will not have signatures if majority of MNs are legit.

...
2. Can a transaction be broadcast and mined into a block before it's locked by the masternodes? I don't see this as violating anything above as it meets the requirements for reducing the period of uncertainty any way so it seems to only be a desirable edge case to me, assuming I've understood this correctly.
...

Locking takes 2-3 seconds and lock request expires if it wasn't successfully finished in 5 minutes. So yes, it's possible but if input is in tx that is mined then it's spent and locks doesn't matter, input itself will be invalid.

...
3. Am I correct in understanding that there are differences in Dash between normal transactions and instant transactions when broadcast to the network? Are there additional fees associated with InstantTX, and if so what are these used for?
...
5. Are there any technical differences between InstantTX and Instant Send or is it purely branding?
...

In master ix are pushed directly without using inv system iirc, in 12.1 we moved them to inv system too. That's why it needs extensive testing while in tesnet. Come join us there (see testing thread)
Yes, there are fees - 0.01 DASH minimum. This fee rate is way above normal fee rate so it also helps to incentivize miners to include such txes and moreover to include them first in case if we ever hit capacity limit for example.

...
4. Am I correct in assuming that chain reorganisation is possible on; if a longer chain turned up with a greater total amount of work? And therefore theoretically there is an edge case where a chain older than an hour (or 24 blocks, not sure which metric the network uses) is broadcast to the network and double spends one or more of the transactions in that chain?
...

With chain reorganization of 1 hour (that's what we currently use but I guess would be a good idea to change that to blocks) or 24 blocks it means network is under a huge attack so no transactions can be trusted at all - ix doesn't solve 51% attack completely, it just gives user more certainty in normal situation. As I mentioned already, we can extend this period to keep them more time, it's like second mempool basically, we can tweak it if there is a need i.e. if we would see that 24 block reorganization is possible (some ugly hashrate distribution for example), or just in case to increase security of ix a bit.

...
6. Where can I see the source code which deals with masternode selection for quorum formation, broadcasting of the lock list to the network and how payment is distributed to the masternodes?
...

Source code is on github https://github.com/dashpay/dash
Start from instantx.*, masternode.*, masternodeman.*, masternode-payments.*

 

[No_2]

1. Have I understood this correctly:

In InstantTX the quorum selection needs to be pseudo random, but retrospectively deterministically verifiable.

That is to say because the masternodes have self selected by depositing funds on the blockchain you can see which masternodes where available when for each block. To ensure the selection is pseudo random it is determined by a block header value (from the referenced input transaction 5 or more blocks deep already on the blockchain) which selects a quorum of masternodes from the available pool to oversee the InstantTX.

PoS is considered unsuitable for this because users with enough stake could influence the order of generation of blocks and their header values. Additionally the PoS block header values are a way smaller search space than then block header values for PoW.

2. Are there any technical differences between InstantTX and Instant Send or is it purely branding?

Thanks again for the above, very helpful.

 

[UdjinM6]

1. Have I understood this correctly:

In InstantTX the quorum selection needs to be pseudo random, but retrospectively deterministically verifiable.

That is to say because the masternodes have self selected by depositing funds on the blockchain you can see which masternodes where available when for each block. To ensure the selection is pseudo random it is determined by a block header value (from the referenced input transaction 5 or more blocks deep already on the blockchain) which selects a quorum of masternodes from the available pool to oversee the InstantTX.

PoS is considered unsuitable for this because users with enough stake could influence the order of generation of blocks and their header values. Additionally the PoS block header values are a way smaller search space than then block header values for PoW.
...

Well, yes we get both randomness and determinism from block hash of the last input + MN collateral hash. I'm not sure what you are trying to say by mentioning PoS though.

...
2. Are there any technical differences between InstantTX and Instant Send or is it purely branding?

Thanks again for the above, very helpful.

I already answered this one above... To put it simply - the principle and rules/params are the same but code was refactored.