sr. member
Activity: 420
Merit: 262
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/
legendary
Activity: 1008
Merit: 1007
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.
sr. member
Activity: 420
Merit: 262
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.
legendary
Activity: 1008
Merit: 1007
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.
sr. member
Activity: 420
Merit: 262
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?
legendary
Activity: 1008
Merit: 1007
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.phpThe relationship is linear: 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 supplySo, this implies that NXT is actually vulnerable to a 36% attack.
sr. member
Activity: 420
Merit: 262
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.
legendary
Activity: 1008
Merit: 1007
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.
hero member
Activity: 966
Merit: 1003
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.
sr. member
Activity: 420
Merit: 262
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.
sr. member
Activity: 420
Merit: 262
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.
hero member
Activity: 966
Merit: 1003
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.
|
