• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Some questions on the whitepaper...

K

karasako

New member
Hi all,

On DASH's whitepaper on section 2.2 Deterministic Ordering the pseudocode mentions nBlockHeight and the comment says: "get the hash of this block". Which block is that... the one that was just mined?

How many masternodes are selected to form a quorum?

How often does the quorums change?

Thanks in advance.
 
Thank you for the suggestion. Great videos. The sub-quorums comprise of 10 masternodes.

But it says that the randomness comes from the hash of a block. It doesn't say which block (or I missed it..).

Btw, should I be asking those questions in another part of the forum?

Cheers
 
No no, here is cool. The dev and tech section might get a straight answer instead of some RTFM troll with a link to a bunch of videos but the forum's fairly quiet so general will get more coverage ;)
+1 to the "Great vids", I didn't watch though them for ages because I was expecting the usual happy-crappy "New to Bitcoin" type vids but they get straight to the good stuff. As far as I remember the selection is done using the hash of the previous block but I'll have to double check that, I'm pretty sure it's mentioned in the vids but it's easy to miss, there's a hell of a lot to digest in them.

Btw, I'm not on it but from what I hear the public Dash slack is a good place to get quick answers to questions, ymmv but it might be worth signing up there too:
EDIT: Retracted, after recent events I can't recommend signing up to it.
 
Last edited:
When you get an answer, please post it here. I've been trying to figure out the same thing for a while now. White paper, wiki, videos, no luck.
 
I just read "Transaction Locking and Masternode Consensus: A Mechanism for Mitigating Double Spending Attacks"

It does not seem to be explicitly stated but I think it uses the last mined block's hash for the randomness/entropy of determining the new 10 masternodes that will form the sub-quorum. It has to be publicly known anyway since all nodes independently calculate the MNs.

I assume it is indeed the last mined block. Please someone correct me if that is wrong.

For an instantX transaction to succeed the sub-quorum needs to be unanimous. If it isn't, the instantX fails and we fallback to the block confirmations.
e.g. if 8 nodes say invalid but 2 nodes say valid... the tx is cancelled.

Are the 2 suspicious nodes punished in any way?

I have some more questions:

If one of the sub-quorum MNs has connection problems, will that invalidate the instantX tx? What is the timeout value before we consider the MN inaccessible (ie. is a no-answer and invalid answer)?
If 1-2 nodes are inaccessible (they timed out) can the sub-quorum go on, saying we have 8/8... it is good enough, so let's not cancel the instantX tx... or does a timeout cancel the instantX tx.

We can take it even further:
Since we know the involved MNs... isn't it possible to DDoS 1 or 2 of them to cancel instantX txs? Cannot an attacker keep on doing this to virtually invalidate the instantX functionality?

Thank you
 
Current-blck-height minus first-input-block-height provides a positive integer. I'm still looking for some documentation on how that number is used to determine which block's hash will be used for entropy.
 
karasako said:
Aha! Thank you! So the answer is max-block-height minus the first-input's-block-height.

Thus, each instantX tx will use a different sub-quorum!

This makes the attack I described above more difficult... but still possible I believe...esp. if timeouts mean cancelling the tx.
Click to expand...

...+4. Inputs must have at least 6 confirmations so the proof of work hash (providing the entropy) will be from the block -2 or lower from the current height. It's more than a year since I went over any of this and I'd forgotten how complicated it was, you could only really attack if you know what inputs are going to be spent and even then it will always fail back to a regular transaction. That's the theory anyway and it's been gone over quite thoroughly but if you can find any potential weaknesses I've no doubt the devs would be really appreciate it.
 
stan.distortion said:
...+4. Inputs must have at least 6 confirmations so the proof of work hash (providing the entropy) will be from the block -2 or lower from the current height. It's more than a year since I went over any of this and I'd forgotten how complicated it was, you could only really attack if you know what inputs are going to be spent and even then it will always fail back to a regular transaction. That's the theory anyway and it's been gone over quite thoroughly but if you can find any potential weaknesses I've no doubt the devs would be really appreciate it.
Click to expand...

Correct, +4.

But you will always know the inputs.. they are part of the instantX tx that is propagated. And true, it falls back to a regular transaction but an intricate DDoS could force most/all instantX tx to become regular diminishing the great benefit that DASH offers to, say, merchants.

Also, it is of importance if there is a timeout and if the sub-quorum would accept a 8/8 decision. Btw, a timeout would also delay the instantX tx considerably.

IronVape said:
Current-blck-height minus first-input-block-height provides a positive integer. I'm still looking for some documentation on how that number is used to determine which block's hash will be used for entropy.
Click to expand...

This positive integer is the block, of which the hash is used. It is the "nBlockHeight" in the pseudocode explaining the rest of the process in DASH's main whitepaper. See the CalculateScore function.
 
Have you had a look at the code? The annotation is probably the best place to look to understand what's going on at that kind of level:
https://github.com/dashpay/dash/blob/master/src/instantx.h
https://github.com/dashpay/dash/blob/master/src/instantx.cpp

If you're not familiar with c++ but find yourself following the code I'd suggest looking into ctags early on as it makes it much easier to follow but the annotation explains a lot without needing any coding knowledge. There are no delays in receiving and processing IS locks and they don't cause much overhead, iirc each MN can handle about 100 a second so there's very little chance of detecting an IS transaction and attacking the relevent MNs before it's processed. Sheer brute force over 4k+ MNs is always a possibility but hiding the MN IPs could prevent even that and apparently it's possible.
 
I haven't looked at the code yet. It will probably be the most time-consuming option so it is my last (although best) resort.

The attacker would be running at least one MN so he/she would know as soon as other MNs of the IS tx and thus the new 10 nodes of the sub-quorum. I believe that there is time for the attack, albeit not much incentive since it will "harass" only one IS tx.

Just being pedantic I guess.

Thanks again for the answer @stan.distortion .
 
@stan.distortion
@karasako
This line "... To garantee choosing a block that was generated after the input was created...", is causing me confusion.
If we imagine a blockchain with a current block height of 200, and an input transaction from block #150, the block used for entropy would be #50, which would be before the input was created.

What am I missing?
Thanks.
 
Last edited:
Jeysus, you made me look through the code again and it weirds me out for a while, nothing wrong with it but it's a bit like it's been written in feet and inches and I'm thinking in metric, needs a mental gearchange.

The relevant line is here if you're interested:
https://github.com/dashpay/dash/blob/master/src/instantx.cpp#L235

The chainActive.Tip()->nHeight just finds out what's the current block and nTxAge comes in just a few lines up on 222 and uses GetInputAge to find out how old the block with the input transaction is. So it's subtracting the age of the input from the current block height, ie. it gives the block height of the input, block 150 in your example and then adds 4 so the proof of work hash from block 154 would be the one used.

EDIT: It seems overly-complicated but there will be a good reason for it, there will be a more convenient function somewhere to just say "gimmie the block for this input" but all the important bits I've gone through are like that, they define exactly what they need.
 
Last edited:
Thank you @stan.distortion I see it now. So the formula is:
Current_ chain_height minus input_transaction_depth plus 4.
200 - 50 + 4.
And the result will always be equal to input_height plus 4.
Thank you very much I will be better able to explain it to others now!
 
karasako said:
Is the Bitcoin's new features being merged to DASH?

e.g. Is Segwit going to be incorporated?
Click to expand...

That's actually quite a thought provoking question. I'm practically certain it will because it was decided some time ago to keep the first tier in sync with Bitcoins codebase to both benefit from Bitcoins development and allow Bitcoin based projects to be easily ported to Dash. Simple enough so far but Dash is completely sidestepping the blocksize issue with something on the second tier called DashDrive, basically a distributed storage system that allows the masternodes to share all kinds of data including the blockchain. It gives a crazy amount of storage (potentially exabytes ) but I don't know what kind of changes would be needed in the Bitcoin codebase to use it. I'm guessing none, that each client will use it just like regular disk space and the second tier will manage data consistency as new blocks propagate but I'd imagine building it into the client would be simpler, should be interesting to see how it works out.
 
You must log in or register to reply here.
Back
Top