DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)

[monsterer]

Asynchrony will always be the case. It can't be an exceptional case. How can you get the world's transactions to all stand in line in a queue without a centralized server.

It is not when they send, it is when they begin composing their transaction. There is a latency between the time they start that, and the transaction has propagated. Therefor they can't all stand in line. You seem to have no clue. I wish you would think more and post less.

The case you outlined above is only possible when N users simultaneously compose a transaction with the same DAG state. In order for this to be divergent this would need to happen over and over, and I just don't see that being very likely.

Even if this pathological case does cause divergence, like I say, you just vary the POW with each composition and it will reduce the probability of this occurring greatly.

[TPTB_need_war]

Asynchrony will always be the case. It can't be an exceptional case. How can you get the world's transactions to all stand in line in a queue without a centralized server.

It is not when they send, it is when they begin composing their transaction. There is a latency between the time they start that, and the transaction has propagated. Therefor they can't all stand in line. You seem to have no clue. I wish you would think more and post less.

The case you outlined above is only possible when N users simultaneously compose a transaction with the same DAG state. In order for this to be divergent this would need to happen over and over, and I just don't see that being very likely.

Even if this pathological case does cause divergence, like I say, you just vary the POW with each composition and it will reduce the probability of this occurring greatly.

It is a statistical phenomenon. The math is in the white paper. You won't get some cleanly ordered scenario such as you are are diagramming. Instead we must use probability to model it. And my point remains that it is impossible to force a strategy on the payers unless you use centralized servers. When you analyze the game theory of what they do decentralized, your simple graphs make no sense. The payers can't know what all the other payer's are doing before those transactions appear on the DAG. There isn't one consistent global state at any given point in time. CfB please do correct me if I make an incorrect statement.

1. But it may not always be unambiguous or other reasons that they can't do what you think they are incentivized to do. MUST is not the same as incentive. Be very careful in analyzing the details of consensus designs.

¹In fact, the author's feeling is that the tip approval strategy is the most important ingredient for constructing a tangle-based cryptocurrency. It is there that many attack vectors are hiding. Also, since there is usually no way to enforce a particular tip approval strategy, it must be such that the nodes would voluntarily choose to follow it knowing that at least a good proportion of other nodes does so.

[monsterer]

It is a statistical phenomenon. The math is in the white paper. You won't get some cleanly ordered scenario such as you are are diagramming. Instead we must use probability to model it. And my point remains that it is impossible to force a strategy on the payers unless you use centralized servers. When you analyze the game theory of what they do decentralized, your simple graphs make no sense. The payers can't know what all the other payer's are doing before those transactions appear on the DAG. There isn't one consistent global state at any given point in time.

As transaction frequency increases, the likelihood of branches increases with it due to propagation delays; this is exactly the same problem as in blockchains - when you decrease the block frequency, orphan rate increases.

However, in a DAG, this situation is different because each branch is not an orphan, so what you end up with is several parallel chain heads, which mitigate the problem since the likelihood of any one single chain head being picked to be extended by all participants decreases linearly with the number of heads.

[TPTB_need_war]

It is a statistical phenomenon. The math is in the white paper. You won't get some cleanly ordered scenario such as you are are diagramming. Instead we must use probability to model it. And my point remains that it is impossible to force a strategy on the payers unless you use centralized servers. When you analyze the game theory of what they do decentralized, your simple graphs make no sense. The payers can't know what all the other payer's are doing before those transactions appear on the DAG. There isn't one consistent global state at any given point in time.

As transaction frequency increases, the likelihood of branches increases with it due to propagation delays; this is exactly the same problem as in blockchains - when you decrease the block frequency, orphan rate increases.

However, in a DAG, this situation is different because each branch is not an orphan, so what you end up with is several parallel chain heads, which mitigate the problem since the likelihood of any one single chain head being picked to be extended by all participants decreases linearly with the number of heads.

And therefor double-spends can't be unambiguous. There is no way to just remove the double-spend from the chain as in your nonsense chart in the other thread. Thus the payers will unlikely reference any chain with a conflicting double-spends. So you can shut the entire Iota down by spamming the chains with double-spends. Because the latency is not zero between the time transactions are constructed and they are globally recorded on the DAG!

Why would payers risk referencing a chain that has a conflicting transaction since due to latency it is impossible to know which one will be the longest. You can't just wait a while because there is no clock on the chain to know how long you have waited! Yet you can't prevent some payers from referencing the transaction before it is recognized as a double-spend, due to the latency in the system. So transactions get orphaned.

There is the flaw. Done.

Only way around it is to use a centralized server to dictate policy.

Sorry CfB, monsterer forced me.

[Come-from-Beyond]

Sorry CfB, monsterer forced me.

No need to sorry, keep it going this way, I'm preparing FAQ.

[TPTB_need_war]

Sorry CfB, monsterer forced me.

No need to sorry, keep it going this way, I'm preparing FAQ.

The only solution is to have a server running a clock and payers trust their transaction policy to a server. But then all such servers need to coordinate else there is random ambiguity again.

It always comes back to centralization.

[TPTB_need_war]

You can't just wait a while because there is no clock on the chain to know how long you have waited!

The payer can't just wait a while either because he can't know if his view is consistent with every other payer if his perspective is decentralized.

You say waiting works, but the attacker can add transactions to both double-spends to make the chains equal length.

There is no solution.

[monsterer]

And therefor double-spends can't be unambiguous. There is no way to just remove the double-spend from the chain as in your nonsense chart in the other thread.

I'm still at a loss for why you think the double spend must be physically removed? It remains in place, simply not getting applied because its invalid. All other non-derivative chained transactions are processed normally.

I don't agree with your assessment.

[monsterer]

You say waiting works, but the attacker can add transactions to both double-spends to make the chains equal length.

That's completely irrelevant. Both chains are valid, excepting for the double spend itself, so it doesn't matter at all.

[Come-from-Beyond]

@Come-from-Beyond

Are any of these concerns related to the special "coordinator" node?

No. The role of the coordinator is to protect Iota until it gets enough hashing power against people like Luke-Jr.

[monsterer]

No. The role of the coordinator is to protect Iota until it gets enough hashing power against people like Luke-Jr.

Rather than having checkpoints, I would instead pay some honest miners to do the job for you; I think that'll work more cleanly and appear less centralised.

[Come-from-Beyond]

Rather than having checkpoints, I would instead pay some honest miners to do the job for you; I think that'll work more cleanly and appear less centralised.

Why? Coordinator node will give the same result for free. Honest miners is the same centralization but from another angle.

[monsterer]

Why? Coordinator node will give the same result for free. Honest miners is the same centralization but from another angle.

Marketing.

[TPTB_need_war]

Carrying on, if the rule on double-spends in order to defend against the attack I described is that all double-spends are invalid (since I have already shown the game theory that it is impossible to conclude which one has more weight[1]), the attacker can introduce double-spends at any time to reverse historical transactions. Thus the coin would be entirely untrustworthy and thus that rule can not be chosen.

We can't use time, remember there is no clock and no time. The only metric we have is cumulative PoW weight.

[1] In case my elucidation upthread was not clear, the more general flaw is that when a double-spend appears there is no way to know which of the chains will end up having the most weight. The attacker for example could continue appending transactions to the shorter chain. The honest payer has no incentive to risk it and will just choose to reference chain which has no conflict. Thus the attacker has all the PoW resources on the chains with double-spends. Iota's white paper makes the assumption that the honest payers will follow a different rule, but why would they follow a rule which pits them against the PoW resources of the attacker? They have no way to know how much resources the attacker has. Also they have no way to know how long ago the attacker precomputed a chain and is hiding it in wait. A few attacks by powerful adversaries will teach payEEs that they do not accept transactions from conflicting chains. The generalized description of the flaw is in addition the natural latency case of the flaw I described upthread.

But the key point is that due to latency (or the attacker just delays issuing the double-spend slightly), there will be some honest transactions on the tips of the double-spends. Thus the attacker can jam Iota because no payers will reference those transactions so they become orphaned. I haven't computed what level of PoW resources the attacker needs to effectively jam all transactions under the game theory assumption I outlined.

monsterer continues making the nonsense the that following transactions are not invalidated by the double-spend (DSPEND -> GOODA -> GOODB), but that is not the point. They become orphaned. Is there something not clear about the different meaning of those two words, orphaned and invalidated.

The fundamental problem is a DAG has no reference point. This is why all crypto currencies needs a single LCR with blocks. I await Fuserleer's design.

My early opinion is Iota's white paper makes assumptions that are not realistic. I will need to spend more time on it to be more forceful in my conviction.

[Come-from-Beyond]

Marketing.

Noone outside of BTT cares about centralization. Bitcoin had a single pool controlling 51+% at least twice. Did it change anything? I doubt. We target the real world, not BTT. Once Iota matures it will become decentralized naturally. Before that it's fine with coordination.

[sidhujag]

Marketing.

Noone outside of BTT cares about centralization. Bitcoin had a single pool controlling 51+% at least twice. Did it change anything? I doubt. We target the real world, not BTT. Once Iota matures it will become decentralized naturally. Before that it's fine with coordination.

+1, aslong as there is a technical path forward to achieve it.

[Come-from-Beyond]

This is why all crypto currencies needs a single LCR with blocks.

Is it 99% again or 100% this time?

[TPTB_need_war]

+1, aslong as there is a technical path forward to achieve it.

This is not a technical post. This is shrilling.

[TPTB_need_war]

This is why all crypto currencies needs a single LCR with blocks.

Is it 99% again or 100% this time?

Publish your technical rebuttal.

[Come-from-Beyond]

Publish your technical rebuttal.

So it's 99%, ok.