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

Cripes is that all you eMunie shrills can do is play politics in a what was a serious thread.

Release a fucking white paper that is properly elucidated.

A ledger doesn't necessarily group events into blocks. Duh.

Don't worry he will have flaws. And I will be there to shred his white paper as pay back for this shit you are doing.

Now bye. Carry on with your pitiful shrilling.

I don't know what your native language is, but when someone tells me its a "ledger" that means its a chain of events by definition (e.g. checkbook running balance) with a beginning and ending balance.  How could you not interpret that as block-like?

You must not have a basic grasp of finance to understand that simple language.

https://en.wikipedia.org/wiki/Ledger

Hey politically motivated asshole.

I only said your design can't work if it doesn't have blocks.

I also said I can't analyze that which you don't provide all the details for. This is the first time I have heard anything about ledger states being record in a data structure that mimicks a chain. Again if there is no chain, there is no provable history, which was my other point about a likely flaw.

I knew that if you didn't provide all the details, then you would play a political hide & seek game to try to compare our egos.

Fuck off. You will not accomplish anything. I guarantee it. There is your challenge. Now go prove me wrong.

The challenges are constant and will not span voting sessions.  At minimum you'll receive at least 1 challenge per voting session.  If you are connected to a number of nodes, then you'll get at least 1 challenge from each connected node for that voting session (you'll also be sending challenges to the same connections).

In your 10,000 example above, you'd have to process at least 10,000 challenges per voting session, and you still only get 1 vote in that session per "node".

Each voting session will generally last between 30-60 seconds depending on whats happening network wide and if there are any conflicts.

One last farting shot so the ignoramuses here can ponder respecting those who are smarter than they are.

Decentralized Proof-of-Work Ordering

Some decentralized databases such as cryptocurrencies or smart contracts require consensus on the ordering of events.

Bitcoin provides consensus on ordering with a Bzyantine fault tolerance of up to 50% of the network proof-of-work hashrate, or as low as 33% due to the economic advantage of selfishly mining the block chain rewards. Bitcoin employs proof-of-work puzzles to identify whom is authorized to produce the next block of events and consensus is the longest chain of blocks which contains the greatest cumulative proof-of-work difficulty.

Consuming a resource such as proof-of-work to produce a chain of event blocks is necessary to disambiguate conflicting events in competing chains by choosing the longest chain. Otherwise there would be unresolvable conflict over which of the conflicting events is valid.

Given a longest chain rule consensus, block periods of events are required because otherwise for example in a DAG there is a divergent proliferation of unmergeable chains induced by conflicting events, e.g. cryptocurrency double-spends. One need only graph some complex scenarios to visualize this effect. In any other attempt to consume a resource to prove a consensus on ordering of events that does not use a longest chain rule, irreconcilable ambiguities will proliferate due to lack of a globally consistent rule for disambiguating double-spends. Globally in this context refers to the fact that nodes of a decentralized network will disagree about the order in which events arrived because propagation can not be made consistent.

This paper analyzes the flaws in Bitcoin's algorithm which:

* effectively make it centralized over time
* limit scalability and transaction rate
* cause an irresolvable tension over the ideal block data size
* induce a Tragedy of the Commons on the economics of funding mining
* deny instant confirmations
* allow less than 50% Byzantine fault tolerance (due to selfish mining)

I propose a new design to resolve all these issues that retains the core principle of a proof-of-work block chain.

Yeah theres much to discuss yet, though I might make a specific eMunie related thread and copy out all the best bits so as not to ruffle any feathers.

What frequency do the challenges arrive? They might be too infrequent to deter an attack, but if you require them with each vote then they are synchronised exactly with the control they affect and they make the attack get very expensive very quickly.

Phew, ok I'm glad you are finally getting a fully picture.  Was that not obvious in the primer doc though, or from the earlier example?  What was missing?  And don't say a full technical doc I should be able to explain the crux of this in a few sentences and if I can't I want to know why.

I considered that actually, but I determined that it was more efficient this way and could see no adverse problems.  Could you expand on your concern?

Agree.  I was rather enjoying the discourse as well.

Sad that some can't seem to see the forest without a quantum-level view of the trees.

I was going to give you some insight into why blocks of the form you speak of are unneeded, but apparently public discussions are "stupid shit"....so I've lost interest.

heh

It's a pity that this discussion, which was one of the better ones on bct for some time, has come to this end.
I still haven't read it all, but it seemed to be very auspicious.

I bet a buck TPTB makes one more comment on BTT in the next 3 hours.  Any takers?  I'd gladly pay that just to be wrong and not have his endless "I'm done talking" posts.   Then I can enjoy reading the Socratic posts that make mental progress.

Translation:

It doesn't solve it because there are no blocks, thus there are ambiguities same as for Iota. You will never get around this fundamental. Never. Not in a 1000 years. Mark my word.

Ok, that goes some way toward solving the problem... IMO, the votes themselves should be the work, otherwise the frequency with which the challenges arrive might not be sufficient to prevent the sybil problem.

What exactly do you want to know? :|

I'm a little confused.

A presents a challenge to B.  B has to spend CPU time to solve it and present the solution to A.  The problems are not trivial and will result in B spending CPU time solving it.  These problems could be anything from a simple hash target like Bitcoins, to more exotic work challenges that consider a number of data sets.

If B has too many connections open, he will get more challenges than he can process and will not be able to provide the results in time.  Should A decide to make a transaction before B has provided the solution, B will not be eligible for an endorsement.

Why should I compete with your noise? What is my incentive to reveal my secrets any way? Like you or anyone is really going to help me code it.  

I have already demonstrated that I can analyze the flaws better than anyone else who is commenting here.

You had plenty of time to present it, you didn't, your choice

Have a good evening.