[neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin?

[illodin]

We are talking about what sort of design should we all support that can scale up and be used by millions of users. That is our goal right?

Yes! And please don't take my "defending" of DASH as anything else than being curious of the current shortcomings as the attack vectors presented didn't seem to make sense to me but now it's getting above my paygrade and all I can add for now is noise so I will stop.

I have to understand the problem before I can appreciate the solution. So we have work to do. You to create the solution, and the laymen like me to learn to understand it.

[TPTB_need_war]

The attack I described for the Finney attack didn't even require conflicting InstantX announcements, rather the conflicting announcement of the transaction being spent on the block versus on the instantx permissioned masternode. Even if InstantX are prelocked to a specific masternode, it must be possible to unlock the funds back to the general UTXO otherwise that would be a risk of losing funds to a masternode that refuses to sign. So thus the Finney attack can just unlock the funds in that case to create the double-spend of the InstantX transaction (by unspending it). No matter how it is designed, it can be attacked. I don't even need to know which way it is designed. I can reason it is flawed in any way.

If the lock can't be acquired within 20 seconds iirc it will lapse. Can't find a link to back my memory though. And I don't know how and by whom it is canceled either.

I was too lazy to go re-read the InstantX paper, so I was saying that Finney attack would work even if Dash was designed such that it required pre-assigning UTXO to specific set of masternodes via a block chain transaction. But I checked again and Dash doesn't require an enabling block chain transaction because it uses a deterministic algorithm to select the set of masternodes that must sign the instant transaction (this is called a "lock"):

https://www.dash.org/instantx/

You can see the paper doesn't even explain anything about how to distinguish between the conflicting block chain transaction and the locked instant transaction, because as smooth and I have explained, propagation is not something that can be guaranteed to be consistent for all P2P nodes.

Thus as I wrote upthread, the mining nodes can disagree about the ordering of the conflicting block chain transaction and the locked instant transaction. Once they disagree, they can never agree again. You have a fork with some honest miners on one fork and other honest miners on the other fork. The merchant loses the funds on one of the forks. Do this enough times, and you fork the coin as many times as you want to end up with a coin that has 1000 competing forks, lol. That would be really funny. I'd like to do that attack on Dash just for the Lolz.

Don't think only of the merchant (payee). Think of the consistency of the block chain.

It's starting to get too complex for me for now, I guess I'll need to draw a picture of a forking network to understand the implications. Thanks for being patient with me and trying to explain.

It is as simple as no one (including the merchant and the honest mining nodes) can be sure which of the conflicting block chain transaction and the locked instant transaction occurred first. If we stipulate that everyone must wait 10 seconds before making a decision (i.e. meaning any conflict within the 10 second window causes both to be rejected) so that the instant transaction can propagate to more nodes, then the attacker can wait until 9.999 seconds to release his conflicting block announcement thus some of the nodes will reject both and some of the nodes will accept the instant transaction. Thus disagreement and a fork. If you don't provide any window then the attacker can release his block at same time, thus same result of ambiguity and a fork result.

This is what I was explaining to monsterer the prior day about the edge of any window/period being an attack vector if all chains aren't merged. I figured out how to solve that issue. It is fundamental and Dash is flawed.

The same issue occurs when the deterministic algorithm for selecting the quorums changes the quorum. Then there can be ambiguity (between two orphaned chains) in terms of which quorum is active for propagation. There is an inconsistency between what is happening with propagation and what is happening on the block chain. This ordering ambiguity for propagation is the reason we needed PoW in the first place, otherwise we could just use propagation and discard PoW (which is the reason that other designs such as eMunie, VanillaCoin, etc are probably flawed although I can't comment on eMunie yet because the design is still somewhat inaccessible to me).

but now it's getting above my paygrade and all I can add for now is noise so I will stop.

You can understand it. I just need to explain it better. I am quite sleepy again already so my eludication capability is tailing off accordingly.

[TPTB_need_war]

If my prior explanation was confusing, let me explain it carefully one more time.

On typical PoW coins such as Bitcoin, Monero, etc, a Finney attack is when a miner finds a block solution that contains a double-spend, but waits to announce it after the 0-confirmation transaction was already accepted by the merchant, thus the merchant loses the money because the 0-confirmation transaction ends up being included later in the block chain. That only works if the merchant accepts the 0-confirmation transaction.

On Dash the situation is much worse because Dash guarantees to the merchant that an InstantX transaction is confirmed. So the attacker can release the block with the double-spend at the same time the InstantX transaction is confirmed, and there will be randomized ambiguity about which of the two events occurred first since both will propagate over the network and some mining nodes will see one or the other first as the two competing choices propagate at the same time over the P2P network. This is not even factoring in any Sybil attack on propagation by the attacker which isn't typically necessary to make the attack work (but can also be used to amplify the harm of the attack if desired).

This is a major flaw because all mining nodes are required by the InstantX protocol to reject any block chain that contains the opposite ordering as compared to the ordering the node's observed on the propagation. Thus when mining nodes disagree about ordering of this (as they are required by the protocol to do!), they will partition into two forks, refusing to mine the fork of the other fork. These are totally honest miners forced to disagree with each other due to a flawed InstantX protocol. It is really hilarious. This is the kind of technical design error made by amateur who refuses to follow standard peer view and open source protocols (which would prevent such an egregious design flaw) that is utterly embarrassing and should be enough to make Dash the laughing stock of the crypto world.

One might propose to fix this by forcing all mining nodes to wait some specified number of seconds or minutes or hours (choose one it doesn't matter) for the propagation of the InstantX transaction. If there is any conflicting block during this required wait, then both transactions are invalid. For the simpleton mind, that seems to solve the problem because the attacker can't attain a double spend, because the merchant will wait for this required duration. But for the clever mind, you realize there is still a flaw because the attacker can just wait to announce his block right at the edge of that wait duration, so then mining nodes will have randomly different observations as to whether both are invalid or whether the InstantX transaction is valid. So then the same result that the block chain is forked. This is very counterintuitive to most people. Because they think you can just choose the InstantX transaction if the wait duration is long enough. But the protocol can't be ambiguous and it must be specific.

Realize that each time the block chain is forked this way, it will randomly split the mining nodes into two more forks. So the number of forks will be 2^N where N is the number of times the attack was employed. Do the attack 100 times, and you'll have 2¹⁰⁰ = 1,267,650,600,000,000,000,000,000,000,000 forks or the number of mining nodes as the number of forks which ever is less. In other words, perform this attack just a few times and you can make all the mining nodes mine separate chains all by their lonesomes. The attacker can then spend his coins on every fork, i.e. multiplying the money supply by 1,267,650,600,000,000,000,000,000,000,000 .

Lol.

Am I the only person who finds that incredibly funny? A designed feature to force all mining nodes to mine alone masquerading as an instant confirmation feature. Lol. I still can't stop laughing.

Dash supporters you might want to find a rock to hide under about now, because there are more flaws coming...

Take away is don't go messing with Satoshi's design if you haven't expended an immense amount effort to make sure you haven't opened Pandora's box.

Edit: I was just informed that Tacotime raised this forking attack issue in the past. I remember some publicity long ago about InstantX being flawed. If anyone can point me to Tacotime's post, I will add a link to it here. I would also like to read his explanation to see if there are any differences in our conceptualization of it.

[illodin]

On Dash the situation is much worse because Dash guarantees to the merchant that an InstantX transaction is confirmed. So the attacker can release the block with the double-spend at the same time the InstantX transaction is confirmed, and there will be randomized ambiguity about which of the two events occurred first since both will propagate over the network and some mining nodes will see one or the other first as the two competing choices propagate at the same time over the P2P network.

Feeling tired and stupid, but if a miner sees the block first, and starts mining on top of that, but a few seconds later receives the IX lock message, why would he ignore the lock and keep on mining a block that will get rejected if he happens to find the solution and publish it?


EDIT: found this:

If a miner decides to mine a chain a few blocks long, that includes a conflicted transaction, then somehow gets the lock after his blocks are accepted, once the lock is formed the chain will be flagged as invalid and removed at instantx.cpp:117.

[TPTB_need_war]

On Dash the situation is much worse because Dash guarantees to the merchant that an InstantX transaction is confirmed. So the attacker can release the block with the double-spend at the same time the InstantX transaction is confirmed, and there will be randomized ambiguity about which of the two events occurred first since both will propagate over the network and some mining nodes will see one or the other first as the two competing choices propagate at the same time over the P2P network.

Feeling tired and stupid, but if a miner sees the block first, and starts mining on top of that, but a few seconds later receives the IX lock message, why would he ignore the lock and keep on mining a block that will get rejected if he happens to find the solution and publish it?

So your proposal for a protocol is that miners don't care about what they receive first, they only care that when they see an InstantX transaction, this overrides any conflicting transaction already on their version of the block chain. So thus you've just proposed that InstantX should be a double-spend feature enabling any one to double spend their transactions after they've been confirmed on the block chain.

If you instead proposed that the InstantX only overrides if it is within ____ seconds (minutes or hours, just pick one) of the new block solution, then choose InstantX. The same problem of miners having different observations on that ordering applies, because the attacker can control when he sends the InstantX transaction in order to increase the likelihood of there being conflicting propagation observations by different mining nodes.

Don't feel this makes you a stupid, because these errors are only going to be caught by either an expert on block chain tech or a non-expert who has expended a lot of time thinking about the issues (when they are not tired).

I am okay with you playing devil's advocate and trying to find a flaw in my logic. Don't feel bad about that. As long as it is not redundant and we are illuminating the issue more fully, then I am in favor of the discussion.

Note if anyone feels I have an error in this logic, please point it out.

EDIT: found this:

If a miner decides to mine a chain a few blocks long, that includes a conflicted transaction, then somehow gets the lock after his blocks are accepted, once the lock is formed the chain will be flagged as invalid and removed at instantx.cpp:117.

Oh great so InstantX can be used to perform double-spends. Excellent. You just discovered a new attack. This is the first case I stated above.

[TPTB_need_war]

I guess it is intended for low value casual payments like buying coffee. No exchanges accept it afaik.

Rather like accepting a transaction at 0 confirmations... except it gives merchants a false sense of greater security which is actually really bad in general.

Exactly. And that has nothing to do with masternodes lying. It can be done with a Finney attack as I have explained in detail in my past few prior posts.

Now I will address your and smooth's orthogonal point about masternodes lying.

Since you can only spend on one quorum (or for instant x, then one designed masternode set), then it is normally impossible to double-spend.

The double-spend risks comes from the holes in their design that I enumerated in my prior post(s).

I don't see how it's impossible at all. If I own a majority of masternodes, I can do whatever I like with my quorums and it doesn't just result in a 'no quorum achieved' it can result in double spends at 0 confirmations. Like I said before, if the system is designed to wait until 1 block has passed (in order to observe the quorum results), then you might as well throw it all away and just use POW?

In the event that masternodes do create a conflicting locks, then PoW blocks will resolve the conflict. I don't really understand how a merchant is supposed to rely on this, since a conflicting lock can be discovered after the merchant has accepted the supposedly "confirmed by IX" payment.

Realize that normally masternodes can't lie because it is deterministically determined which masternodes can lock which transactions. All the masternodes can do is sign the lock or not sign the lock.

Some masternodes could attempt to sign locks which they are not designated to sign, but the PoW block chain would never honor these locks and would not put them in the block chain. And payees can do this same verification before accepting the InstantX transaction.

If these masternodes attempt to lie about whether these locked transactions are well formed or are double-spends, this will be verified by every mining node, so the masternodes can't cheat. But the cost of this, is that verification of every transaction is still done by every mining node. So Dash Evolution is not a block chain scaling design.

[illodin]

So your proposal for a protocol is that miners don't care about what they receive first, they only care that when they see an InstantX transaction, this overrides any conflicting transaction already on their version of the block chain. So thus you've just proposed that InstantX should be a double-spend feature enabling any one to double spend their transactions after they've been confirmed on the block chain.

Oh great so InstantX can be used to perform double-spends. Excellent. You just discovered a new attack. This is the first case I stated above.

Yes, but you still need to get lucky and have 6 out of 10 masternodes to sign (vote for) the conflicting lock. How many blocks the protocol allows to rewind I don't know, but the more blocks it allows the more chances you have to control those 6.

[monsterer]

Realize that normally masternodes can't lie because it is deterministically determined which masternodes can lock which transactions. All the masternodes can do is sign the lock or not sign the lock.

Some masternodes could attempt to sign locks which they are not designated to sign, but the PoW block chain would never honor these locks and would not put them in the block chain. And payees can do this same verification before accepting the InstantX transaction.

Remember we are talking about 0 confirmations here, there is no POW evidence at this point, all that exists is mempool evidence. Payees might well be able to do that verification, but that's not in the protocol.

If I own a majority of masternodes, there is a greater than 50% chance that any one of my nodes will get picked by the deterministic selection process, so they can indeed lie with a high probability of success.

[TPTB_need_war]

So your proposal for a protocol is that miners don't care about what they receive first, they only care that when they see an InstantX transaction, this overrides any conflicting transaction already on their version of the block chain. So thus you've just proposed that InstantX should be a double-spend feature enabling any one to double spend their transactions after they've been confirmed on the block chain.

Oh great so InstantX can be used to perform double-spends. Excellent. You just discovered a new attack. This is the first case I stated above.

Yes, but you still need to get lucky and have 6 out of 10 masternodes to sign (vote for) the conflicting lock. How many blocks the protocol allows to rewind I don't know, but the more blocks it allows the more chances you have to control those 6.

Go back to the context in which we were raising this issue, which is that attacker can hold the Finney block hidden before announcing it near to or about the same time as launching the InstantX transaction. You proposed that the PoW miners would always prefer the InstantX lock notice even if they receive it after the Finney block announcement, so the implied premise was the masternodes had already approved the InstantX transaction. With this new post, your implied point is that if the PoW nodes choose a large enough time window in which they prefer the InstantX lock notice over the Finney block announcement, then the attacker would have to announce his Finney block so far in advance that the Finney block would have propagated to the masternodes and they would be lying if they approved the InstantX lock.

But the flaw in your proposal is that there is no way to prove anything about propagation. Thus there is no way to prove the masternodes lied or didn't lie. And without the ability to prove, then there is ambiguity over who is telling the truth and thus there is no way to blacklist, ignore, filter, or remove the offenders.

For example there could be some masternodes which are always participating in double-spends, but there would be no way to prove that those masternodes are cheating. Some nodes may claim to have seen evidence of cheating where the Finney block announcement arrived sufficiently much before (sooner than) the InstantX lock notice to constitute cheating of the involved masternodes, but that node can't confirm that its observation of propagation is the same one that every other node saw (nor can it confirm its perspective of propagation is even the "correct" one because all propagation is relativity thus there is no "correct" story about observation of propagation... there is only inconsistency ... and this is precisely why PoW was necessary in the first place). If you must attempt some voting scheme to overcome this ambiguity (e.g. Railblocks' flawed design), then you've lost the instant confirmation and you've incurred the flaws of consensus-by-voting which made it necessary for Satoshi to introduce PoW as a solution to decentralized consensus problem.

There is another problem with "proof-by-propagation" that monsterer and I were discussing upthread, which is that miners who were not online when the propagation occurred have no way of verifying which set of claimed observations is correct. There is no consensus objectivity neither in real-time nor persistent.

So once again you end up with chaos and forking, because even honest nodes will have no 100% verifiable way to know who is telling the truth and who is not. If the mining nodes follow your rule exactly, then the Dash can be overcome with ongoing double-spends and no way to filter out the bad masternodes (except by some centralized human intervention which is the then politics and not decentralized technology).

In contrast to for example an invalid cryptographic signature can be verified valid or invalid, differences in propagation can't be mathematically proven valid or invalid.

Without the ability to issue what Wuille and the Bitcoin devs are recently naming "fraud witness proofs", then the "segregated witness" strategy (which is what Dash is doing incorrectly) is not secure and unambiguous. And this is why I have stated that Wuille, Gregory Maxwell, and the others who are thinking "segregated witness" can be grafted onto to Bitcoin are in for some big surprises because they will definitely have flaws if they attempt to. Because they don't have my invention which is the only way consistency can be obtained with a segregated witness design. And if they attempt to merge my invention while also allowing transactions to be sent directly to the block chain, they will still incur ambiguities and flaws. Good luck if they think they can radically change Bitcoin's block design faster than I can get to launch and add millions of users.

[monsterer]

But taking the model of "honest" staking at face value, at 49% you can only hope to maintain control for a limited number of blocks. At 50%+, you control the chain forever. That's clearly more than 4% increase.

Why is that the case? Even if it were the case, it might just be a terminating condition and not imply that the entire relationship was superlinear.

e.g. according to this tool for calculating the amount of blocks you forge over 332 days given your stake:

https://www.mynxt.info/forging_calculator.php

The relationship is linear:

Code:

stake,forged blocks
1000,1
10000,13
100000,132
1000000,1327
10000000,13273
100000000,132732
1000000000,1327326

Over a period of 332 days, there are 478080 total blocks generated, so you would win 100% of the generate blocks somewhere between a stake of 10% and 100% of total supply. Interpolating, that puts full control at 360182803 NXT which is 36% of supply

So, this implies that NXT is actually vulnerable to a 36% attack.

[TPTB_need_war]

Realize that normally masternodes can't lie because it is deterministically determined which masternodes can lock which transactions. All the masternodes can do is sign the lock or not sign the lock.

Some masternodes could attempt to sign locks which they are not designated to sign, but the PoW block chain would never honor these locks and would not put them in the block chain. And payees can do this same verification before accepting the InstantX transaction.

Remember we are talking about 0 confirmations here, there is no POW evidence at this point, all that exists is mempool evidence. Payees might well be able to do that verification, but that's not in the protocol.

If I own a majority of masternodes, there is a greater than 50% chance that any one of my nodes will get picked by the deterministic selection process, so they can indeed lie with a high probability of success.

Lying doesn't help a masternode in terms of a transaction which is mathematically invalid, e.g. spends non-existent UTXO or spends more than the value of a UTXO.. Such lying can be provable detected by any full node observer.

However, there was an Alzheimer/grandpa moment of being too sleepy to finish what I had realized upon awakening yesterday wherein I had written you were correct about other attacks from masternodes. The statement above was just a locally (not holistically) logical statement to make on some aspect before I slept, but the original more systemically holistic thoughts I had from the morning had been lost by that time where I was too sleepy to process thoughts. When I awoke today, I remembered my logic which I didn't get to write down yesterday because the discussions got so (beneficially) sidetracked and then I got sleepy.

After reading the points I make to illodin in the prior post about inability to prove propagation ordering, the issue is precisely that there is no way to prove the ordering of announcements from masternodes. So even though masternodes can only approve InstantX transactions which they are deterministically authorized to approve, the flaw is that any conflicts that arise due to relative ordering can't be proven to be the fault of any of the involved masternodes.

A contrived example is paying to an address from an InstantX transaction and spending from that address in another InstantX transaction. It can't be proven that the second transaction was issued after the first, thus it can't be proven whether it was an invalid transaction. That particular example can't be fixed by requiring all UTXO payees of InstantX transactions to be blocked until after the next block confirmation, because again nothing can be proven from propagation about what should and shouldn't be blocked.

The challenge is to think of an example where it results in ambiguity about double-spending (which could either admit a double-spend or forking). Can you think of an example other than the Finney attack example I was discussing with illodin?

[monsterer]

The challenge is to think of example where it results in ambiguity about double-spending (which could either admit a double-spend or forking). Can you think of an example?

1. If I own a majority of masternodes, I have a greater than 50% chance of getting deterministically selected to confirm an instant X transaction lock
2. I submit an instant X transaction to a merchant
3. My masternodes confirm the lock on the transaction
4. Merchant accepts deposit and takes irreversible action at 0 confirmations
5. I double spend the payment in another instant X transaction which also happens to hit my masternodes
6. My masternodes dump the previous lock and report this new one as valid
7. Due to propagation delays, there is now ambiguity about which lock is valid
8. Probable fork occurs, or a double spend is achieved

Take 50% and scale it down to whatever proportion you like, the probability of this being successful is proportional to my number of masternodes.

[TPTB_need_war]

5. I double spend the payment in another instant X transaction which also happens to hit my masternodes

Impossible. In order for an InstantX transaction to be locked, a majority of the eligible masternodes for that UTXO must sign the lock. Thus there are not enough remaining eligible masternodes to sign the same UTXO again. (If Dash doesn't actually work this way I described, then it should be fixed to work this way.)

Afaics, what you are describing can only be done at the juncture where the deterministic eligibility calculation is updating (every N blocks or so). I had already written upthread about the flaw that is the ambiguity due to competing orphaned chains that straddle that eligibility update.

[monsterer]

5. I double spend the payment in another instant X transaction which also happens to hit my masternodes

Impossible. In order for an InstantX transaction to be locked, a majority of the eligible masternodes for that UTXO must sign the lock. Thus there are not enough remaining eligible masternodes to sign the same UTXO again. (If Dash doesn't actually work this way I described, then it should be fixed to work this way.)

What defines eligibility?

Indeed, why wouldn't the same set of masternodes be eligible to sign the same UTXO? Unless there is some magical, permanent evidence that I have already signed the previous UTXO, the exact same set of nodes will be eligible to sign it multiple times within any deterministic eligibility window.

[TPTB_need_war]

5. I double spend the payment in another instant X transaction which also happens to hit my masternodes

Impossible. In order for an InstantX transaction to be locked, a majority of the eligible masternodes for that UTXO must sign the lock. Thus there are not enough remaining eligible masternodes to sign the same UTXO again. (If Dash doesn't actually work this way I described, then it should be fixed to work this way.)

What defines eligibility?

Indeed, why wouldn't the same set of masternodes be eligible to sign the same UTXO?

If they've already authorized a transaction spending some UTXO output, then that output can't be spent again. It is already spent. The next transaction will be mathematically invalid.

You could claim that it is unprovable which authorization was first, but it is provable that the masternodes who sign more than once (regardless which one they signed first) are lying and thus must be penalized.

You are correct though that even though the masternodes could be penalized, the damage would already be done in terms of the ambiguity over which of the liar InstantX transactions is the first one and which is the invalid one. So what protocol rule could be employed at the PoW block chain level to avoid a fork?

You raise one of the issues that I had to solve in my design and which any "segregated witness" design must solve. That is why I stated yesterday that you were correct. That is how to order when lying occurs, because per above even detecting that lying occurred and proving who was involved, is not necessarily enough to prevent ambiguity and forking of the block chain. The protocol must be specific and deal with this case. I am just now recovering my logic that was fresh in my mind yesterday (experiencing a dull mind today).

So the protocol rule would have to be something that attempted to discard both of the InstantX transactions that haven't yet been confirmed in the block chain, because we know it is impossible prove anything consistent for consensus about propagation ordering until there is a PoW confirmation. Which is exactly the rule Dash employes:

Clients would be tasked with clearing out conflicting locks and possibly reversing attacker transactions. This would only happen in a case where an attacker submitted multiple locks to the network at once and the network formed consensus on one but not the other.

If no consensus is reached, standard confirmation will be required to assure that a transaction is valid.

But if you discard transactions, that is an attack on payees (and perhaps even on payers that were not colluding with the masternodes). And there is ambiguity for such a rule because of orphaned chains and because timing of propagation is orthogonal to perhaps multiple simultaneous realities of multiple chains (all but one of which will eventually be orphaned but we don't know which one yet). Thus there is no objectivity. Consensus would be what ever the longest chain decided to do. But if other honest mining nodes disagree with the ambiguous decision of the longest chain, then there is a fork.

So yes the lack of ordering in masternode announcements adds to my assertion "Dash has more holes than Swiss cheese" that I wrote yesterday.

Masternodes could indeed wreck havoc. The InstantX white paper shows some math that claims an adversary needs 2/3 of the masternodes to attain 1.72% chance of controlling the majority of each InstantX authorization. I think this math may be flawed. Can you whip up the correct probability math quickly or should I?

https://www.dash.org/instantx/

[TPTB_need_war]

[...]Masternodes could indeed wreck havoc. The InstantX white paper shows some math that claims an adversary needs 2/3 of the masternodes to attain 1.72% chance of controlling the majority of a single quorum. I think this math may be flawed. Can you whip up the correct probability math quickly or should I?

https://www.dash.org/instantx/

I see the flaw in Dash's math:

Probabilities of attack can be calculated by the chance of a masternode being selected as the winning node for a given block (1/1000). To subvert the system an attacker would require operating all ten masternodes that won a given election

The attacker only needs less than 10 of the of masternodes which are eligible to authorize an InstantX lock for a specific UTXO. Because if InstantX requires all 10 masternodes to authorize (which I believe is what the white paper implies), then the attacker can block (i.e. jam) InstantX 65% of the time with only 1/10 of the masternodes! With 50% of the masternodes, the attacker could jam the InstantX 99.9% of the time. There is the 50% attack. This is probably why for Evolution, Evan changed the requirement to a simple majority (or some N-of-M) of each eligible quorum.

Dash's flawed math in the InstantX paper incorrectly assumes the attacker needs all 10 of the eligible masternodes.

Thus if the attacker owns 50% of the masternodes, the attacker has at least the 6/10th majority in 38% of the InstantX transactions and also can block (jam) the InstantX transactions 62% time with only at least a 5/10ths minority. Thus the attacker can attack 38 + 62 = 100% of the time. There is the 50% attack again. And Evan erroneously claimed that Evolution eliminates the 50% attack.  

That is the hypergeometric distribution.

https://en.wikipedia.org/wiki/Hypergeometric_distribution
http://math.stackexchange.com/questions/422414/probability-of-selecting-q-red-balls-from-m-red-balls-and-n-blue-balls

So enter here:

http://stattrek.com/online-calculator/hypergeometric.aspx
 

Population size:	1000 masternodes
Number of successes in population:	500 adversarial, colluding masternodes
Sample size:	10 eligible masternodes
Number of successes in sample (x):	6 needed for a majority

I don't think anyone has the incentive to buy up 50% of the masternodes to do the other attacks (actually the attacks could be achieved somewhat infrequently with a much smaller % of the masternodes, e.g. with 10% of the masternodes every 666th UTXO could be jammed and every 10,000th UTXO could be spent as many times as desired).

[smooth]

You could claim that it is unprovable which authorization was first, but it is provable that the masternodes who sign more than once (regardless which one they signed first) are lying and thus must be penalized.

There is no mechanism for doing that in InstantX.

If you do create such a mechanism, its security is very difficult to correctly (in a global sense) reason about due to the large game/small game issues form Szabo's post (similar issues are raised, though somewhat glossed over, in Meni Rosenfeld's paper about Bitcoin double spending). But if really do want such a system there may be no alternative.

[TPTB_need_war]

You could claim that it is unprovable which authorization was first, but it is provable that the masternodes who sign more than once (regardless which one they signed first) are lying and thus must be penalized.

There is no mechanism for doing that in InstantX.

If you do create such a mechanism, its security is very difficult to correctly (in a global sense) reason about due to the large game/small game issues form Szabo's post (similar issues are raised, though somewhat glossed over, in Meni Rosenfeld's paper about Bitcoin double spending). But if really do want such a system there may be no alternative.

Smooth's point is that in a "segregated witness" block chain design where ordering of confirmations can be ambiguous due to the inability to prove propagation, then any threat of a penalty (e.g. confiscating a deposit) against a provably fraudulent instant confirmation node (which is a masternode in Dash) would be futile because for example the attacker who is in control of that fraudulent node could have shorted the coin and thus be profiting on the attack more than the cost of the penalty.

I agree smooth that is entirely correct. And it guarantees eventual failure for any "segregated witness" design that is vulnerable to double-spending and using only penalties to hope to disincentivize such attacks.

Fortunately I discovered the solution to foil such attacks and double-spend threads in my instant confirmation design. I am contemplating whether I should describe all the details of my design now or wait. I think I better wait, else Evan @ Dash might try to copy me and claim it was his own.

But suffice it to say that the confirmations have to be provably ordered even without being confirmed with PoW.   That is sort of tricky statement I have made, because we know that any ordering that is not confirmed by PoW is not consensus consistent. But again I already explained to monsterer how I can assure consensus (and remove the 50% attack and reduce electricity cost to a miniscule level!) as long as there are no ambiguous double-spend conflicts. They key word is in red color obviously.

Now I say let's bring this design to market pronto! And conquer the world.

[TPTB_need_war]

But taking the model of "honest" staking at face value, at 49% you can only hope to maintain control for a limited number of blocks. At 50%+, you control the chain forever. That's clearly more than 4% increase.

Why is that the case?

Because the power-law distribution applies in any winner-take-all paradigm, which by definition is what a single chain requires.

We can't say the threshold level is specifically at 49% or even that it is abrupt. It depends on the relative distribution of resources the rest of the network wastes defending against the power-law distributed. We need to convolve the opposing cumulative distribution functions.

The reason I am able to eliminate the 50% attack in my design is because I eliminate the winner-take-all from the longest chain by including all chains (as I explained to you upthread, which was my published discovery since 2014).

I am now teaching Satoshi. (see my head expanding, lol)

[smooth]

Smooth's point is that in a "segregated witness" block chain design where ordering of confirmations can be ambiguous due to the inability to prove propagation, then any threat of a penalty (e.g. confiscating a deposit) against a provably fraudulent instant confirmation node (which is a masternode in Dash) would be futile because for example the attacker who is in control of that fraudulent node could have shorted the coin and thus be profiting on the attack more than the cost of the penalty.

Yes smooth that is entirely correct. And it guarantees eventual failure for any "segregated witness" design that is vulnerable to double-spending and using only penalties to hope to disincentivize such attacks.

I don't know if your narrowing of the general problem to a specific instance (shorting to profit on an attack) is sufficient. It may be, but it is difficult to enumerate external incentives. For example, in Meni's paper it is pointed out that an attacker can double spend against multiple merchants simultaneously which makes it difficult to reason about the "cost" of double spending attacks (in terms of burned hash rate for a minority attacker). That doesn't directly apply here (because locks are specific to a UTXO), but still other external attacks probably exist.

This is why the problem statement of satoshi that assumes <50% (or 30% or whatever -- I will get to that) is important. Because if that condition is well-satisfied, then the system is unconditionally secure. The exponential difficulty of multiple-confirmation attacks make them quickly implausible for any finite payoff. Double spending is impossible up to an exponential difficulty, as is jamming.

As an aside, the difference between 50% or 30% or 25% or whatever selfish mining thresholds might exist doesn't really matter because security in satoshi's design is greatly reduced if mining is concentrated at all, even well under 50%. In satoshi's paper he gives an example of a 45% attacker which would require waiting 340 confirmations for "just okay" security (even though his assumed threshold is 50%). Nobody does that.

I have a strong feeling the most secure cryptocurrency will eventually solve this problem with some method of keeping mining decentralized (enough). Maybe that is impossible (as you claim due to economies of scale, state capture, etc.), maybe not. But I have doubts about any other approach. I'll wait for your white paper though.