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

What you just wrote is ambiguous. There are so many details that are unspecified, that I can't even place those words into an overall context. I will not proceed to apply more effort to analyzing something where I am not given a clear and complete specification.

I am not going to read that primer again because it is the same writing style of being very verbose but doesn't clearly specify the design.

For example, agreed upon by whom? Recorded how? How is that agreement provable in a Byzantine fault compliant manner, etc.

Software is about details. Details matter.

Can you remind me why I need to generate a bunch of transactions in order to be an eligible validating node?

  high horses.....btw you speak to people in a much more condescending manner.  Quite a shitty feeling isnt it

The record of voting power is agreed upon simultaneously with the transactions, as the endorsements are within the transactions.

If you come to a consensus on transactions you also come to a consensus on the voting power at that time, and who can vote in the future as a matter of course.

I really don't see how that is not clear from the example, and I'm especially dumbfounded that its still elusive to you if consider the content of the primer which is much clearer, even without the changes I've made published yet.

Unless you are burning the fees, they can be gamed to so there no net resource consumed.

The energy burned for doing some communication and signing operations may be insignificant compared to the gains of gaming the system.

We don't know the data structure in which these are record and details of how Byzantine faults are overcome. It is impossible to analyze like this.

I can't analyze this piecemeal like this. I need the entire model and details. I suggest we stop this, but feel free to carry on if you all want. I will probably stop responding to Fuserleer until he produces something holistically comprehensible.

Its no different here, except you have expend fees too to create the transactions as well as energy.

Cost depends on the volume of transactions the network is currently producing, and your act of producing spam transaction can elevate the cost further.

A simple breakdown using 100tx/s of network load as the numbers are easy:

The base fee at this load is $0.01, so the network is spending $1 per second on fees.  You therefore also need to create an additional 100 tx/s to be certain that you have the majority of endorsement power, and endorse your own nodes while creating these transactions.  You therefore have to spend $1 per second on fees, plus whatever energy requirements to create 100 tx/s.  

You'll also need a shit ton of nodes to endorse, as no matter how much endorsement weight a node might have, that only gets you into the vote...once there you have 1 vote with the same weight as everyone else.  Even if you have 50% of endorsing power and direct it at 1 node, everyone honest in the network is endorsing many nodes between them so at 100 tx/s of load, there will be quite a few nodes voting on outcomes.  

All these nodes to endorse will cost to operate, and at 100tx/s you could perhaps get away with running 2-3 virtual nodes per 1 physical box at most without issue.

Sudden increases of transactional activity hike up the fee price, and is know as the load fee.  Its unnatural and easily detected if transactions suddenly spike so your very act of producing spam transactions increases the cost to you considerably while the cost to everyone making regular transactions in a few cents at most. An extra 100 tx/s would bring the load fee to $0.04 making the cost of each transaction $0.05.

You'd have to sustain this load for 30 minutes for the endorsement weights to be mature enough to get in on the action, which would by that point have cost you $9,000+ in fees at this load.

If you do it over the long term and do it steady, then while you might bypass the load fee activating, you're having to pay long term to dupe the network into thinking the load it is seeing is normal....and your historic endorsement weight has no bearing on voting in conflicts anymore, as I've said, a few times.

At lower network loads the base fee is higher, so that the cost to attack it in fees is roughly the same no matter the load.

So are you trying to say that endorsements are some form of a voting reputation power? How is this measured and by whom, because one of the problems in consensus is determining what is the truth, and even the record of the voting power can have a Byzantine fault. You see I need a holitistic map because I (attempt to) think all of all the variables. You are throwing away information, which is why you think it is simple and thus don't see your flaws or at least you haven't articulated all the information I need to analyze it.

You are not of superior intellect to deserve to talk condescendingly to me.


Yeah but again you don't provide a holistic understanding. How do they get chosen, how is it recorded, what does this endorsement metric do and how, etc..

You probably have put it in your mind that I am just against you and that I am not open-minded. But that is your own problem. I am not thinking that way. I am trying to load your model in my head, but you are not providing sufficient information.

And you accuse me of being impatient. See how quickly you become impatient when you have to rapid fire posting.

See. Walking in my shoes now.

Come off your high horse next time and understand it is stressful to explain and discuss a lot and especially rapid fire.

Final attempt

* A is making transactions, B, C and D are vying for endorsements and all have a connection to A.

B, C, D are other nodes, just like A

* It is the role of the endorsed nodes to vote on what the current state of the ledger should be, and the state with the maximum votes wins.  

Reason for B, C, D existence

No it isn't. This is a critical difference between POW and all other designs; owning a majority of POW hashing power gives you the ability to attack the network, *but* you have to expend energy to actually do it, and that changes everything.


What does it cost my majority of nodes, then?

Not to me. I have no overall conceptual map of what is being done.

Draw me an overview and then it will click in. Otherwise I have to go try to figure out why you have these B, C, D nodes in the first place. What their role is systemically. Etc..

You accuse me of being disrespectful, now look at the way you are acting.

Just because the holistic design is clear in your mind, it is so different than any design I have studied, I don't even have any clue what these various nodes are for and what the overall map of the objective is and how it all fits together.

Ridiculous, you're just being obtuse.  Its perfectly clear what is being endorsed and why.

Thats a moot point, if you own the majority of nodes in any system you can do whatever you like.


I fail to see how you came to the conclusion that it is zero, when I posted upthread that the primary determiner of vote eligibility was now the most recent endorsements you had received, and not the overall long term amount.

Therefore if you want to vote on the outcome of a conflict, you MUST of done work and been endorsed recently.  Historic weight with this change is no longer a factor, so the long term con as you put it is gone.

If you want to Sybil your way to eligibility, then you must constantly be acting as A, C and D and creating the majority of transaction in the network.  As soon as you stop, you lose any advantage you had.

I have no idea of the context and application of what is being endorsed and why. My brain works very holistically. I load the entire model at once in my head. I need to be able to see it visually in my head.

You need to start with an overview of what you are doing holistically. Otherwise I essentially have to reverse engineer what you are doing which is very painstaking. You shouldn't make me work so hard. I am the reader.

This is basically the same way that instant-X and zerotime work; there are a set of deterministically selected nodes which vote at the same time on 0 confirmation transactions, majority vote wins.

But of course, this fails completely under sybil attack (I know you said not to mention it, but unfortunately we cannot talk about consensus without it). If I own a majority of validating nodes I can do anything I like: come to a majority consensus on transaction A, then double spend with transaction B by dropping all record of A from my nodes and coming to a 2nd consensus. Or I can completely freeze the chain by censoring all transactions, etc.

Now lets talk about the cost of this attack - in instant-x and zerotime, this cost is a simple constant in the amount of stake you own. In emunie, afair, this cost is completely zero, because of the long con attack.

Really?  So you don't understand the English definition of endorsing something?  That is you give it your backing, or vouch for it?

As I said, if you can't understand such a simple example as that, then I can't help you anymore.

I would wait for an actual working implementation in FLOSS code that can be peer reviewed together with a proper technical paper that is also subject to peer review.

The key distinction is LCR has a verifiable (provable) record of the history. So then there is no ambiguity about what happened. The community can then sort out the rest. This will be a key point when I discuss my design shortly.

I fear a voting design means we can't even prove anything. It becomes one big glob of trusting a black box of opaque real-time events that erased history (I will search for a YouTube from Barbara Liskov which makes a point analogous to this...and edit this post shortly).

That is what I mean by mathematical data structure.

Edit: Liskov makes the point that GOTO statement and self-modifying code means you can't reason about the program and especially ex post facto when debugging. A voting design seems analogous.

Can anyone understand what Fuserleer wrote? None of makes any sense to me.

Fuserleer can't you do more clear technical writing than that? Surely it makes sense to you, but it reads like gibberish to me. You don't even define what an endorsement is and does. You just assume all these things in your head are in our head. I can't extract it from your prose.

Another flaw in Satohi's design:

The challenges are fairly simple and are to ensure that nodes have the data they claim, and are providing the service they claim to in an honest manner.

For example, if node D was advertising that he was acting as a ledger resource, nodes don't have any real way to know if the ledger information he is serving up is legit, they wont know if its valid until they receive it.

This isn't a huge problem, as the act of node D sending out incorrect ledger information is more of a hindrance (it wont validate so requesting nodes have to go elsewhere) than anything else, but we want to limit the endorsement of dishonest nodes as much as possible.

Basically, A would present a challenge to D requesting some information that is public, and only if D was doing the job he claims would he have that information and provide the correct solution.  

It could be something as mundane as sending the merkle root hash for all transactions on the 25th December 2015.  If D is providing a ledger service, he should have that information and be able to provide the hash.  A then compares D's solution to his, if they match D is likely honest.

D will never know directly if he sent the correct solution to A, at best he can guess that he did if he gets an endorsement soon after.