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

[VultureFund]

Sorry for interfering in this IQ+160 conversation.

I have a suggestion for you guys. Why don't you work together?

I'm sure it would be a beastly combination that would make great successes.

A cold and scarce in words genious from bielorrusia, together with a fucking crazy genious that appears he's gonna explode anytime.

Man, I would invest my fortune in that team!!

[1714950604]

1714950604

[1714950604]

1714950604

[1714950604]

1714950604

[TPTB_need_war]

Publish your technical rebuttal.

So it's 99%, ok.

Publish your rebuttal. What is taking you so long? You don't know the answer. I did this discussion in real-time with no forethought/study on Iota. Surely you can match me on speed of rebuttal.

(Careful with clever snide shit. I'm good at that too).

[TPTB_need_war]

I have a suggestion for you guys. Why don't you work together?

What is the odds of that given we can't even have a cordial discussion.

[VultureFund]

Publish your technical rebuttal.

So it's 99%, ok.

Publish your rebuttal. What is taking you so long? You don't know the answer. I did this discussion in real-time with no forethought/study on Iota. Surely you can match me on speed of rebuttal.

(Careful with clever snide shit. I'm good at that too).

Well, I'm not an IQ+160 like you, but I think CfB has already answered you multiple times...

[Come-from-Beyond]

Publish your rebuttal. What is taking you so long? You don't know the answer. I did this discussion in real-time with no forethought/study on Iota. Surely you can match me on speed of rebuttal.

I don't want to create a precedent. If you claim something then it's you who is supposed to prove, not the others who are supposed to prove the opposite.

[TPTB_need_war]

I just finished scanning the attack models in the white paper. They do not address the attack I am presenting which revolves around issuing double-spends very quickly after only a few transactions have confirmed the double-spend. The point is not to actually accomplish a double-spend, but to orphan honest transactions and do this over and over and over again. The white paper's models don't apply because the attacker can quickly influence which chain is the longest with minimal PoW since the conflicting chain is also so short. Even if the payers follow the chosen policy rule of Iota, afaics they are still subject to this attack. Again the problem is there is no clock. Thus there is no reference point as to which of the chains should be the valid one. There is an ambiguity. As long as that ambiguity falls close to the normal latency, then it is impossible to even detect the difference from propagation. And doing any detection from propagation would require centralization any way since a DAG doesn't store propagation data.

I am describing a jamming attack.

Remember I was the first one to explain in gmaxwell's CoinJoin thread that his idea for blacklisting jamming wouldn't work because the entire point of anonymity mixing is you can't blacklist UTXO.

I think I presented a new attack which you did not consider when you designed this.

It sucks. But I am a damned debugger.

[Come-from-Beyond]

I just finished scanning the attack models in the white paper. They do not address the attack I am presenting which revolves around issuing double-spends very quickly after only a few transactions have confirmed the double-spend. The point is not to actually accomplish a double-spend, but to orphan honest transactions and do this over and over and over again.

In Iota approved transaction hashes are not included into the signed part. Anyone can re-issue a transaction to make it reference another part of the tangle (more likely the beneficiary will do that). So if you create a double-spend very soon then only few transactions will need to redo the PoW (5 second work for a single notebook). If you wait longer to send the 2nd (double-spending) transaction then the 1st one will be adopted by the network and the 2nd will be ignored. Check formula (9) of http://188.138.57.93/tangle.pdf to get hard numbers for different conditions.

[monsterer]

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.

Why do you think that? GOODA and GOODB have no reason to be orphaned, they are valid and do not depend on DSPEND, except for sequencing.

[TPTB_need_war]

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.

Why do you think that? GOODA and GOODB have no reason to be orphaned, they are valid and do not depend on DSPEND, except for sequencing.

Come on man. This is noise. At least understand first the white paper. You are completely lacking an understanding of how Iota works. The payers have to decide which chains not to reference when there are conflicting double-spends. If they stop referencing a chain, those transactions already on that chain get orphaned. I shouldn't have to explain the basic concepts of Iota to you. That is what the white paper is for.

If they are orphaned they don't continue to build more cumulative PoW, thus they are probabilistically unconfirmed. Please do not forget one of the most basic facts of a DAG (or even a block chain!) which is that it is the SUCCEEDING PoW that adds to the weight, not the preceding.

Remember confirmation in a DAG is never absolute. It is always a relative probability. The payee has to access the risk. When the main chain(s) are moving forward and the others are not, we say they are orphaned.

[monsterer]

Come on man. This is noise. At least understand first the white paper. You are completely lacking an understanding of how Iota works. The payers have to decide which chains not to reference when there are conflicting double-spends. If they stop referencing a chain, those transactions already on that chain get orphaned. I shouldn't have to explain the basic concepts of Iota to you. That is what the white paper is for.

If they are orphaned they don't continue to build more cumulative PoW. Please do not forget one of the most basic facts of a DAG (or even a block chain!) which is that it is the SUCCEEDING PoW that adds to the weight, not the preceding.

I'm not talking about Iota specifically here, I'm talking about any DAG or tree of chained transactions with POW.

If Iota is orphaning chains by discarding double spends, then this is a big design flaw. I maintain that you don't need to orphan minority chains containing double spends at all in a DAG, or tree of work - by doing so you throw away work, which is against a fundamental tenant of efficient consensus design.

[TPTB_need_war]

Come on man. This is noise. At least understand first the white paper. You are completely lacking an understanding of how Iota works. The payers have to decide which chains not to reference when there are conflicting double-spends. If they stop referencing a chain, those transactions already on that chain get orphaned. I shouldn't have to explain the basic concepts of Iota to you. That is what the white paper is for.

If they are orphaned they don't continue to build more cumulative PoW. Please do not forget one of the most basic facts of a DAG (or even a block chain!) which is that it is the SUCCEEDING PoW that adds to the weight, not the preceding.

I'm not talking about Iota specifically here, I'm talking about any DAG or tree of chained transactions with POW.

If Iota is orphaning chains by discarding double spends, then this is a big design flaw. I maintain that you don't need to orphan minority chains containing double spends at all in a DAG, or tree of work - by doing so you throw away work, which is against a fundamental tenant of efficient consensus design.

Please go study. Please don't make me put you on ignore. I am really get annoyed that you are writing noise and haven't even digested the basic concepts of a DAG.

How do you know they won't be double-spent later. Duh. That is the entire point of building a long chain of cumulative PoW so the confirmation is probabilistically more assured. I already wrote this in the prior post.

[monsterer]

Please go study. Please don't make me put you on ignore. I am really get annoyed that you are writing noise and haven't even digested the basic concepts of a DAG.

Prove me wrong. I will happily concede.

[Come-from-Beyond]

How do you know they won't be double-spent later. Duh. That is the entire point of building a long chain of cumulative PoW so the confirmation is probabilistically more assured. I already wrote this in the prior post.

So you didn't like Markov Chain Monte Carlo described in Iota paper or saw a flaw in it?

[TPTB_need_war]

How do you know they won't be double-spent later. Duh. That is the entire point of building a long chain of cumulative PoW so the confirmation is probabilistically more assured. I already wrote this in the prior post.

So you didn't like Markov Chain Monte Carlo described in Iota paper or saw a flaw in it?

I skipped deep understanding of it and just noted it was for defeating lie-in-wait attack chains. I understand what you are getting at now (as it promotes referencing in real-time not historically), but then we will go off whether the game theory is going to hold that all payers and payees will adhere to that forced selection rule and I am confident I can find a game theory that says they won't be able to (because it attempts to violate the CAP theorem).

The game theory analysis of a DAG is very, very intense. I am not going to be able to do it all today.

Yet I am very confident the design will fail due to CAP. It is just a matter of searching for the flaw.

I will reply to your other post next.

You know that once it is popular, the research scientists are going to dig much deeper than I am. The odds of this surviving all peer review are slim at best. Very, very risky design. But then again I think you can cash out well before then.

I want to produce a design that can be easily shown to be sound. Because I want to build trust quickly. For me this DAG is a gimick (and extremely complex). It has no advantages over my design afaics and a DAG won't afaik do instant transactions (as in < 1 second) unless there are a few trusted servers coordinating all propagation and can't prevent the money from shrinking to 0 asymptotically.

[Come-from-Beyond]

It has no advantages over my design afaics and a DAG can't do instant transactions (as in < 1 second) and can't prevent the money from shrinking to 0 asymptotically.

Do you hint that you found a way to do instant transactions? Does it use quantum cryptography?

[TPTB_need_war]

It has no advantages over my design afaics and a DAG can't do instant transactions (as in < 1 second) and can't prevent the money from shrinking to 0 asymptotically.

Do you hint that you found a way to do instant transactions? Does it use quantum cryptography?

Nothing that exotic. But yes afaics I can do them with some mild caveats in a block chain design. By instant, I mean as fast as server can receive, sign, and propagate a transaction.

The key breakthrough was realizing the users can control the unprofitable PoW, same as in your design (but hey I had that idea since 2014 I just didn't put it all together until recently). So a little bit of centralization is actually still decentralization, because the users can move at any time. I suppose a DAG can be similar. I just fear the crazy complexity of attack modes and selection rules in a DAG. I prefer something easier to analyze.

[TPTB_need_war]

I just finished scanning the attack models in the white paper. They do not address the attack I am presenting which revolves around issuing double-spends very quickly after only a few transactions have confirmed the double-spend. The point is not to actually accomplish a double-spend, but to orphan honest transactions and do this over and over and over again.

In Iota approved transaction hashes are not included into the signed part. Anyone can re-issue a transaction to make it reference another part of the tangle (more likely the beneficiary will do that).

The delay in my response is due to trying to think of a flaw that is enabled by not signing referenced hashes. I am debugging Iota in real-time today. Attempting to demonstrate to Fuserleer what he is up against, so hopefully he can learn some mutual respect is the best way to proceed.

The means the same transaction can appear every where as spam unless you redo the PoW. I read below you redo the PoW.

So how is this not a jamming attack then? You are forcing users to redo work. The attacker can use botnets. So then you will need to farm PoW out to centralized ASICS, so  now you've become centralized same as Bitcoin.

No matter which direction you go, you will end up at centralization.

I told you I been analyzing these things for months and months. Only my design will be able to solve this problem of keeping the PoW with the users and not falling to centralization.

So if you create a double-spend very soon then only few transactions will need to redo the PoW (5 second work for a single notebook). If you wait longer to send the 2nd (double-spending) transaction then the 1st one will be adopted by the network and the 2nd will be ignored. Check formula (9) of http://188.138.57.93/tangle.pdf to get hard numbers for different conditions.

[Come-from-Beyond]

I just fear the crazy complexity of attack modes and selection rules in a DAG. I prefer something easier to analyze.

The code of Iota is pretty simple, so... https://en.wikipedia.org/wiki/Kolmogorov_complexity

[TPTB_need_war]

I just fear the crazy complexity of attack modes and selection rules in a DAG. I prefer something easier to analyze.

The code of Iota is pretty simple, so... https://en.wikipedia.org/wiki/Kolmogorov_complexity

You know that doesn't apply. The complexity is in the external entropy of the game theory.

[Come-from-Beyond]

The means the same transaction can appear every where as spam unless you redo the PoW. I read below you redo the PoW.

So how is this not a jamming attack then? You are forcing users to redo work. The attacker can use botnets. So then you will need to farm PoW out to centralized ASICS, so  now you've become centralized same as Bitcoin.

No matter which direction you go, you will end up at centralization.

If transaction propagation is fast then you have to release the doublespending transaction very soon invalidating work of only a few other transactions. If transaction propagation is slow then only few other transactions will reference your transactions (because majority will see none of your transactions). Looks like you can fool only a little part of nodes in any case. A botnet won't help, when Iota hits IoT industry even several botnets will barely take 1% of total hashpower. In addition, Iota doesn't use Bitcoin topology, it mimics meshnets making it impossible to connect to majority of the nodes to conduct attacks easier.