Proverbs 9:8:

The coin days requirement should be reserved for usage by user option when there is an ongoing attack, as otherwise new users wont be able to trade.

you can't argue without insulting people

Alright cool.   I believe these problems are solvable.

Next question:  do you think you're the smartest person in the world and know everything?

Oh dear.  More walls of text.  I want to know what the ethereum paradox is.  Can someone explain it in 6 lines or less please?

---

0x8d1b4e41652eacec5715dc5c4833f6b713573de6 If you agree with me, please support a friend of mine in need.

(1) What you need to know is that Ethereum as it is currently designed can't scale just as Bitcoin can't scale, but the level of scaling which the current Ethereum can do is much less than even Bitcoin's current limitation because verification/validation of Serpent scripts takes more resources than verification/validation of ECDSA signatures.

(2) For both Bitcoin and Ethereum, this is not just an issue of block size limitation. The issue is that in order to scale, the mining becomes more centralized. I think you will should note that Bitcoin and all other major coins are entirely centralized already and on the precipice of failure (all of them! study my links!).

(3) Thus Ethereum proposed Casper which is a design that attempts to use sharding (a.k.a. partitions) to improve scaling decentralized. But I explained in this thread, that can't work. To reduce electricity consumption, Ethereum also proposed PoS-like consensus-by-betting with forfeitable deposits. PoS has known failure modes that violate Nash equilibrium.

(4) So the point of all this is that Ethereum and all the rest of the crypto coins have not yet solved the fundamental issue of decentralized consensus.

Blah blah blah. No one whose opportunity costs is $200,000 - $500,000 yearly wastes their time on your nonsense tiny bounty in a coin that doesn't have sufficient liquidity to short and in which the mining (i.e. Zerotime network) is controlled by the flock of delusion shills. (additionally the bounty is in VNL and I had explained before what is the point of finding a flaw then the bounty value will decline as well)

We focus on the technical analysis and how it will perform in the wild.

Your rebuttal is entirely nonsense (as it was in the past), but of course you retarded shills will continue on with your delusion.

Readers are smart enough to see who is the fool in this debate. Delude yourself as you wish. Piss into the wind and troll your shadow in your tiny circle-jerk with your cohort bag holding shills.

I remember in the summer the community gave you the chance to perform a double spend based on your accusations then that ZT was flawed. There was a bounty. You never accepted the offer

FTR I wasn't attacking you in any manner.  I was simply pointing out the absurdity of "the brace debate" when its used as a means to gauge someones abilities as a developer.

What the code does and its architectural structure, not how its formatted, should be the only real metric used to gauge abilities surely?

Still around still being supported by the same people. This thread did not do anything to em.

I already explained upthread that ZeroTime (even when it is not Sybil attacked) can't scale and even your own shill admitted it isn't trustworthy.

And I already explained that ChainBlender is another Dash-like nonsense anonymity design.

The 'John' is not at our level. Period.

Now you know why the community is ignoring you. And I will now ignore you as well. Enjoy your circle-jerk.

I already explained upthread that ZeroTime (even when it is not Sybil attacked) can't scale and even your own shill admitted it isn't trustworthy.

And I already explained that ChainBlender is another Dash-like nonsense anonymity design.

The 'John' is not at our level. Period.

Now you know why the community is ignoring you. And I will now ignore you as well. Enjoy your circle-jerk.

DDoS is not an analogy to jamming. Remember the party that goes first in your protocol locks up his funds (e.g. UXTO) for the period of the timeout refund (which is orders-of-magnitude greater delay than processing a DDoS packet and the attackers delay is asymmetrically orders-of-magnitude smaller) while waiting for the counter party to reciprocate. In bandwidth DDoS, the attacker must have enough bots to saturate the bandwidth of the victim, which is a significant resource. In malformed requests DDoS, the cost to the victim of verifying needs to the symmetric to the cost of the attacker to sign the request. I wrote a white paper about how DDoS can be ameliorated with proper design in the crypto currency setting. Please make sure you understand the relevance of the word 'asymmetry' of costs for the attacker versus the victim w.r.t. DoS.

Seems that running a DE in your original fee-based scheme (which I allege is broken) is quite simple as it only involves offering a payto address.

Sorry to be a pain, but really you should thank those who do peer review and help you from wasting your time. I'd really appreciate a more cordial and rational response. Getting irrationally upset at those who try to help you, is what the retards over in the Altcoin Discussion forum do, and I know you are too mature and do not possess that behavior. Please remember in the past when you made similar arguments about why proof-of-stake was not attackable, which ended up being wrong as evidenced by the current top-down governance of Nxt and Bitshares. Those of us who take the time to analyze and point out egregious flaws do it because we want correct solutions, not because we are haters. If those we help, hate back on us, the entire discussion forums descends into stupid noise. Please even if you have vested interests, still try to remain fair and rational. This is a scientific discussion, and let's not conflate it with other matters such as any investment you've already made in DE. I can't do my work in a rational, scientific way if I have to worry about each person's ego and vested interests that I might offend by writing rationally.

I didn't see where you could identify the attacker in your protocol without incurring any possibility of bailing out and jamming. Perhaps you can explain that more succinctly (without all the cut & choose employing Bitcoin op codes since I don't comprehend Bitcoin op codes thus I can't understand the cut & choose in the way you guys have explained it thus far, although I think I understand the concept which is to probabilistically reveal the preimage).

Any way, I was thinking about this more because I know you are invested in DE and I really want to help you find a solution. Of course I don't feel good about the situation where you are invested and it is fundamentally flawed. It is not like I get some great joy in finding flaws. I get great joy in finding solutions that don't have flaws. I can't help it that there is so much flawed work being done in the crypto currency realm. It is the nature of the beast, because crypto logic is complex and there are a lot hair-brained ideas being promulgated. For example, Blockstream's side-chains reduce the security to the weakest chain due to chain reorganizations and the fact that proof-of-work is probabilistic and thus never final (e.g. lie in wait long-con attack). Blockstream is even investing so much effort to push Segregated Witness which enables them to version the block chain with soft forks, thus it looks like a trojan horse so they can get the changes they want to enable this broken concept of side-chains. Speak these rational truths and many people get pissed off and posts get removed by the moderator.

Any way, I think I have thought of a solution for DE.

The key is to identify the attacker immediately so that all decentralized parties can apply my upthread blocking "Coin Days Destroyed" suggestion. The "Coin Days Destroyed" becomes the reference point that is signed by the owner of the resource, which thus apparently escapes from my generative essence conceptualization of the problem set.

So change to the protocol is the provider of the hash sends to the trade's counter party to sign it (hashed with the other party's UXTO address) so the counter party's UXTO can be identified. Then the hash provider (the potential jamming victim) posts this information in a timed refundable transaction to the block chain (spending to the payee contingent on releasing the hash). If the attacker never posts the reciprocal transaction on the other block chain, this enables anyone to identify that attacker and apply the Coin Days Destroyed filtering that I proposed upthread.

Note this eliminates the need for any fee. But I assume you can find some justification for a fee, such as perhaps keeping your source code for the DE app closed source and/or offering a centralized fee structure for matching orders, limit orders, etc.. You won't be able to steal funds, which afaik is the most significant advantage of DE over CE.

DDoS is not an analogy to jamming. Remember the party that goes first in your protocol locks up his funds (e.g. UXTO) for the period of the timeout refund (which is orders-of-magnitude greater delay than processing a DDoS packet and the attackers delay is asymmetrically orders-of-magnitude smaller) while waiting for the counter party to reciprocate. In bandwidth DDoS, the attacker must have enough bots to saturate the bandwidth of the victim, which is a significant resource. In malformed requests DDoS, the cost to the victim of verifying needs to the symmetric to the cost of the attacker to sign the request. I wrote a white paper about how DDoS can be ameliorated with proper design in the crypto currency setting. Please make sure you understand the relevance of the word 'asymmetry' of costs for the attacker versus the victim w.r.t. DoS.

Seems that running a DE in your original fee-based scheme (which I allege is broken) is quite simple as it only involves offering a payto address.

Sorry to be a pain, but really you should thank those who do peer review and help you from wasting your time. I'd really appreciate a more cordial and rational response. Getting irrationally upset at those who try to help you, is what the retards over in the Altcoin Discussion forum do, and I know you are too mature and do not possess that behavior. Please remember in the past when you made similar arguments about why proof-of-stake was not attackable, which ended up being wrong as evidenced by the current top-down governance of Nxt and Bitshares. Those of us who take the time to analyze and point out egregious flaws do it because we want correct solutions, not because we are haters. If those we help, hate back on us, the entire discussion forums descends into stupid noise. Please even if you have vested interests, still try to remain fair and rational. This is a scientific discussion, and let's not conflate it with other matters such as any investment you've already made in DE. I can't do my work in a rational, scientific way if I have to worry about each person's ego and vested interests that I might offend by writing rationally.

I didn't see where you could identify the attacker in your protocol without incurring any possibility of bailing out and jamming. Perhaps you can explain that more succinctly (without all the cut & choose employing Bitcoin op codes since I don't comprehend Bitcoin op codes thus I can't understand the cut & choose in the way you guys have explained it thus far, although I think I understand the concept which is to probabilistically reveal the preimage).

Any way, I was thinking about this more because I know you are invested in DE and I really want to help you find a solution. Of course I don't feel good about the situation where you are invested and it is fundamentally flawed. It is not like I get some great joy in finding flaws. I get great joy in finding solutions that don't have flaws. I can't help it that there is so much flawed work being done in the crypto currency realm. It is the nature of the beast, because crypto logic is complex and there are a lot hair-brained ideas being promulgated. For example, Blockstream's side-chains reduce the security to the weakest chain due to chain reorganizations and the fact that proof-of-work is probabilistic and thus never final (e.g. lie in wait long-con attack). Blockstream is even investing so much effort to push Segregated Witness which enables them to version the block chain with soft forks, thus it looks like a trojan horse so they can get the changes they want to enable this broken concept of side-chains. Speak these rational truths and many people get pissed off and posts get removed by the moderator.

Any way, I think I have thought of a solution for DE.

The key is to identify the attacker immediately so that all decentralized parties can apply my upthread blocking "Coin Days Destroyed" suggestion. The "Coin Days Destroyed" becomes the reference point that is signed by the owner of the resource, which thus apparently escapes from my generative essence conceptualization of the problem set.

So change to the protocol is the provider of the hash sends to the trade's counter party to sign it (hashed with the other party's UXTO address) so the counter party's UXTO can be identified. Then the hash provider (the potential jamming victim) posts this information in a timed refundable transaction to the block chain (spending to the payee contingent on releasing the hash). If the attacker never posts the reciprocal transaction on the other block chain, this enables anyone to identify that attacker and apply the Coin Days Destroyed filtering that I proposed upthread.

Note this eliminates the need for any fee. But I assume you can find some justification for a fee, such as perhaps keeping your source code for the DE app closed source and/or offering a centralized fee structure for matching orders, limit orders, etc.. You won't be able to steal funds, which afaik is the most significant advantage of DE over CE.

By this logic no cryptocoin would exist.
Instead of all out war all the time, maybe some sort of truce would be made? Why would everyone running a DE want to spend all that time attacking the other DE's just to get attacked back and then nobody's works. Seems like MAD.

I notice your attack scenarios are getting more and more convoluted as now the attacker needs to run a DE themselves to make it even a potential issue. So things are improving. It also might be possible to make it so the attacker wont be able to get their fee back, but no script for that yet.

However, you must have missed my post where it is possible to identify the attacker. It would be after the fact, but that allows a reputation system to be created and as long as people are careful about filling orders from newbies, there wont be much problems.

James

P.S. Using your logic, no central exchange would exist as they would all be Ddosing each other all the time. You dont need to pay exchange fees to Ddos an website.

Blockstream has over $60mil in funding to develop side chains. With Confidential Transactions coming to Bitcoin, do you think privacy-centered altcoins like XMR will suffer a decline in demand against new side chains?

Expert programmers that like braces on the next line use MOAR screens

lmao! It's these sweeping statements of assumption from you that really make me chuckle....yeah, sure, I only know Java [/sarcasm]

which wastes vertical space (expert programmers like to maximize the LOC they can view without scrolling). ... This sort of unnecessary structuralization of code is meaningful to junior programmers who think it works some kind of magic.

He sure loves to waste vertical space and make it appear his code has more LOC than it does! 3 line comments for 3 words. Makes me think he gets confused quickly if code is dense.

He is not at all using functional programming and instead creating procedures (i.e. have side-effects) which is known to produce spaghetti code (brittle code).

Throwing exceptions puts the program in a state of indeterminism!