Topic: [EMUNIE] One small step for transactions, one giant leap for crypto (Read 5626 times)

Service nodes that have a ledger can be delegates yes.

Service nodes without a ledger (running light) can not be delegates, but they still acquire endorsements and earn trust for supply (and fee) payouts.

And a service node is a delegate? Just want to get my understanding of the different nodes in your system right.

Simple math.

Economics takes the total amount of trust allocated over the period since the last supply increase, then allocates a portion of that new supply to the service nodes as per their accrued trust over that period.

Accrued Trust / Allocated Trust = % Of New Supply

New supply is split 50/50, one half goes to service nodes, the other half goes to balance holders.

Balance holder payout is similar but is of the function Mean Period Balance / Total Existing Supply = % Of New Supply

Without the endorsements/trust, service nodes could not be paid fairly for the work they do.

How does the distribution use trust to increase fairness?

Heh don't think for a moment I didn't consider things like staking to select delegates and act as a barrier to entry.  The problem is that implementing staking introduces further complexity as the endorsement/trust model is still required to achieve fair distribution of new supply.

The issue is simply that all of the things that Bitcoin/block chains lack...scalability, speed, fairness of distribution etc....are not easy problems to solve, especially for mainstream.  If they were, then I'm sure that Satoshi was plenty smart enough to see these solutions immediately and incorporate a design that solved them.

Complex problems sometimes require solutions that aren't as simple as one may like, so instead ensure they are as simple as can be and spend time pursuing that mantra.

A lot of the components in eMunie are used in more than one place, with no "special case" functionality to support the multiple roles, thus overall complexity actually reduces due to component reuse.  

The consensus is by far the most complicated component in the system, yet to me it seems elegant and simple and can explain the basics of it in a few sentences or a single diagram.  That probably comes from being about to see the full picture with all the detail, and its on me to provide that same clarity over time to all of you.

Hmmm, this all sounds extraordinarily complicated with all these special cases.

Here is something to consider, feel to ignore it, it's just an idea:

Make delegates election purely stake based - so take the set of N delegates who have the most bonded stake.

This gives you the same constant attack cost as using the trust decay system you have at the moment (from what I understand of it, anyway) and has the advantage of being much, much easier to simulate or reason about.

Yes that can happen, but that is just the same as (n/m)-1 failures.

It would be highly unlikely though, akin to all a bunch of Bitcoins miners (a couple of pools?) going offline, transactions then take much longer to be confirmed.

I have considered it though, perhaps for example some attacker has a rare occurrence majority of his nodes in the delegate set (leaving aside the difficulty of these attacks ), notices and decides "Hey, lets screw this up!" and turns off all his nodes.

That then results in greater than (n/m)-1 failures so those transactions will fail...there are 2 mechanisms to defend against this activity.

First of all, if there is a period where transactions are not obtaining a majority consensus, the delegate selection mechanism switches for a short period of time.  Instead of delegates being the most recently endorsed, it switches to also include the delegates with the heaviest weight.

Delegates with the heaviest weights will have a high likelihood of being constantly online (they have to be to have the heaviest weight)...this should be sufficient to get things moving again quickly, then the delegate selection can switch back the more "random" mode of operation.

Secondly, it is quite trivial to detect nodes that are in the delegate set but are not voting on transactions as expected.  These nodes can be omitted from future delegate sets for a period of time.

Finally I did consider having a "end of the world" list of super delegates that the network can refer to in the most dire of circumstances, but I'm not sure if I like that idea, or if it will be required as the likelihood of all delegates, both recent and weighted, being offline is slim to none IMO.  Also, the larger the network grows, the more unlikely this becomes.

The delegate election process:

If delegates get elected and then disappear all within the period allocated for consensus, doesn't that represent a DOS if this happens to a majority?

I'm moving this conversation here, because it's more relevant...

Can we talk about how a node syncs with the network? How do they know who to trust, how can they validate blocks are genuine?

It doesn't take a sock puppet to call bullshit just saying

There is nothing like a developer using sockpuppet accounts to push their agenda to inspire trust. Lol



Don't even try to deny it.....

There's nothing like a reasoned argument...and that is certainly nothing like one!

I don't care if you are fucking Satoshi. Coming out with lines like inflationary supply isn't theft....a inflationary supply is fucking the definition of theft. Inflation by definition is theft and inflation by definition is increasing the money supply...If we want this system we can use fiat and the FED...dick.


People love to sound smart and say Bitcoin is inflationary but that's a BS argument. Bitcoin has a limited supply.....just like Gold has a limited supply, that's the point. the fact it is in the process of distributing that fixed supply is NOT the point.

So, these bootstrap nodes, where do they come from, are they a fixed set?

There is a ledger, not a single chain.  The ledger is of n channels, which contain past transactions for that channel arranged as a tree.

IF you were to join and be presented with a 2 ledgers to sync from the genesis transaction, only one would be valid.  That would be the ledger where the first transactions are voted for by the bootstrap nodes.

So you can't have 2 ledgers to start with, unless all operators of the bootstrap nodes have signed the first transactions in both (which they wont)

So there is a chain of history? Which is it, I'm confused?

Ok, so assuming there is a chain, and I am a syncing node just joining the network for the first time AND I am presented with two different chain histories, how do I know which one to pick?

Close enough yes.

There is a history of states for syncing & auditing purposes, but only the current state of the ledger is referenced when appending/voting on new transactions.

If you are syncing from a historic point, say if you were offline, then your node would request the state actions you are missing, and action them to get to the same state as everyone else.  

Every historic action results in a new local current state of the ledger, then you apply the next one.  The actions have to be applied in sequence for you to successfully sync to the same state as everyone else because of the determinism.

If any of the presented actions cant be applied, because they were tampered with for example, your sync stops at that point until you have a state that you can apply and continue.

Ahhhh, right. Ok, so there is no chain (or history) at all, just the current state? And said state is only valid if the majority of the current N node endorse it?

Aren't we just going full circle again here? 

The endorsements guard against forks, because future transactions reference them so as to confirm. 

If someone changes some/all the endorsements in a copy of the ledger (its not a chain), in an attempt to present a "fork", those modified transactions wont validate because the hashes of the transactions will not verify against the signature.

The "fork" is junk, because no one can validate it, the ledgers of nodes trying to sync to it wont add a single transaction from it, so there is no choice to make.

A fork is only possible if you can change history, which is what you are suggesting here.  However, ledger history can not be changed due to the deterministic nature of who gets to vote, and the difficulty in modifying past endorsements which govern that.

Malleability isn't the problem - if I am a node which is syncing with the network and I'm presented with two different forks of the chain, how do I select between them?