[EMUNIE] One small step for transactions, one giant leap for crypto

[theprofileth]

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

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



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

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

[1714041531]

1714041531

[1714041531]

1714041531

[1714041531]

1714041531

[monsterer]

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?

[monsterer]

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?

[Fuserleer]

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?

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.

[monsterer]

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.

[Fuserleer]

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.

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.

[monsterer]

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.

How does the distribution use trust to increase fairness?

[Fuserleer]

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.

How does the distribution use trust to increase fairness?

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.

[monsterer]

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

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

[Fuserleer]

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

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

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.