Pages:
Author

Topic: DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?) - page 47. (Read 91144 times)

sr. member
Activity: 420
Merit: 262
+1, aslong as there is a technical path forward to achieve it.

This is not a technical post. This is shrilling.
legendary
Activity: 2142
Merit: 1010
Newbie
This is why all crypto currencies needs a single LCR with blocks.

Is it 99% again or 100% this time?
legendary
Activity: 2044
Merit: 1005
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.
legendary
Activity: 2142
Merit: 1010
Newbie
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.
sr. member
Activity: 420
Merit: 262
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.
legendary
Activity: 1008
Merit: 1007
Why? Coordinator node will give the same result for free. Honest miners is the same centralization but from another angle.

Marketing.
legendary
Activity: 2142
Merit: 1010
Newbie
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.
legendary
Activity: 1008
Merit: 1007
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.
legendary
Activity: 2142
Merit: 1010
Newbie

@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.
legendary
Activity: 1008
Merit: 1007
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.
legendary
Activity: 1008
Merit: 1007
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.
sr. member
Activity: 420
Merit: 262
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.
sr. member
Activity: 420
Merit: 262
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.
legendary
Activity: 2142
Merit: 1010
Newbie
Sorry CfB, monsterer forced me.

No need to sorry, keep it going this way, I'm preparing FAQ.
sr. member
Activity: 420
Merit: 262
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.
legendary
Activity: 1008
Merit: 1007
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.
sr. member
Activity: 420
Merit: 262
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.

1In 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.
legendary
Activity: 1008
Merit: 1007
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.
sr. member
Activity: 420
Merit: 262
When thinking about asynchrony for a DAG, note if everyone wants to transact simultaneously (i.e. decentralized), they will all like to reference the longest chain, so you will have every transaction on its own partition (they can't reference each other and they don't want to queue up in line). The incentives are aligned to diverge, not converge.

In the event where N users all chose to send a transaction at exactly the same time, you will get this effect, but I wouldn't expect it to be persistent and divergent. You'll likely get small sprouts of divergence followed by convergence again as synchrony is broken... That's my intuition, but it would need to be simulated really to see how bad it gets.

The pathological case you mention could be avoided simply by varying the POW sent with each transaction by a small amount every send.

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 so that the other transactions can see the update. Therefor they can't all stand in line. You seem to have no clue. I wish you would think more and post less.

How many global transactions will occur within that say few seconds. Sheesh.

Yes I do get frustrated when people don't grasp the most basic concepts and then I have already mentioned asynchrony several times but you haven't taken the effort to go think about it for a while until you realize why it is an issue.
jr. member
Activity: 59
Merit: 10
DECENTRALIZATION is a threat to the Corporations (and they are the government), thus if a DECENTRALIZED paradigm becomes popular, the government is going to attack it the same as they did Napster.

Thus if your block chain design is not truly permissionless, then you've accomplished nothing.

Ethereum, BitShares, etc are Napsters. Daniel can't figure out how to make something truly decentralized so he argues that we substitute politics and governance for
Pages:
Jump to: