Topic: A World of Trust – eMunie Consensus Primer - page 6. (Read 7372 times)

Most of your follow up post I would just be re-iterating what I already had said which is pointless time waste for us both. I agree that for discussions getting down to the edge cases levels you are heading, I think it best to wait until more detailed documentation has been produced as I'm sure it will address your concerns and challenges that a high level for the masses overview can not.

However, I would like to raise the comment quoted above with you.  I'm going to try to provide a clear and simple statements, not to insult your intelligence, but so that I can be sure it is clear to all reading too.

For a Sybil attack targeted towards propagation disruption, I stand by the fact that to be successful, the attacker has to isolate a large majority of nodes from everyone else for the following reasons.

#1 All of his nodes need to be connected to each other to ensure that the double spend is propagated to his own nodes as quickly as possible to ensure he can deliver them to the target nodes rapidly.  The more hops his double spend has to take over his own nodes, the less likely he will be of success.

#2 These nodes should have as many connections as possible to honest nodes at all ends of the network to ensure that the double spend he is presenting is done so quickly and distributed evenly.

#3 Hindering the above somewhat is the fact that he can only put so many nodes behind 1 IP with a finite amount of connections before that connection is saturated with traffic, both natural network traffic and his own.  If the connection is saturated, then it will reduce his ability to propagate his double spend quickly and efficiently.

#4 Do not forget the fact that when you present your double spend transaction, if you push that too quickly to slower regions of the network, the nodes there are more likely not to have all of the dependencies required to validate it.  It will get throw away and not reconsidered for validation again for a short period of time even if you represent it.  If then it sees the first transaction, and now has the dependencies available, that first transaction will be accepted instead of yours and counter-signed.

#5 I'll iterate this again as people generally seem to consider only theory and not practicalities too.  The window of opportunity to do this is VERY short!  The double spend has to be presented to all the nodes it need to be to achieve a majority within a few seconds of the first so as not to be at a severe disadvantage.

#6 The only way to guarantee success is to isolate every node from every other node except yours, which is extremely hard and extremely unlikely.  If you could do the impossible, then you don't have to worry about the duration it takes to do it and the factors above, as all the nodes have no idea about the first genuine transaction in the first place.  Even if they did, they could not then broadcast counter-signatures that pledge weight to that transaction as you could prevent it.

This attack discussed here gets harder as the network grows, as you need more of your own nodes to cover the ever increasing number of honest nodes.

Finally, all anyone has to do to be 100% sure that they have not been a victim of this or any other attacks is wait a minute or so before releasing goods/services etc, no one has a problem doing this with BTC.

Also no one seems to have an issue that BTC can be attacked in a number of ways, because a lot of it is pure theory and the likelihood of someone doing it is extremely small.

Running a node must be profitable in order to attract users to maintain the network? So, you can assume that an attacker could also be profitable, by definition?

Do you really need 200 VMs to pretend to be 200 nodes? Can't you just have a bank of 200 IP addresses on one box?

Well yes, but to get a general understanding of the consensus at a high level you don't, which is what this very first document is intended for.

I mention multiple times that attack analysis will be performed in subsequent documents at a more detailed level when further information on ledgers, balances and everything else is also available.

Discussing the mechanics of the ledger, considering the scale of the topic and the technical innovation to be covered is not a post for BTT  So I'm afraid you'll have to wait for that.

I knew that of course, which was another reason I am thinking the design is flawed. But let me read your reply below in case I don't yet have a complete picture...


You have to consider the holistic interaction of conflicts in trust and game theory. This is already getting so complicated that I don't think anyone can be sure they've addressed all possible attack scenarios. Any way, I realize such as statement is FUD without an explicit attack vector described. And you haven't released all the details yet. But I will just caution you that I think you opened Pandora's box. I see much simpler and provably modeled ways for a design which has a near boundless transaction rate. I am all for experimentation and having more competition though. That is way we hopefully get something better than Bitcoin. I'll try to make this my last reply unless you write something that I feel I must address. Thank you for your respectful reply.

I've been aware you were working on this back in 2013 when I (as AnonyMint) used to debate with the creator of Decrits (one of your former competitors to the general concept of a complex delegated trust consensus design). I've gained a lot of domain knowledge since then, as I assume you have to. Btw, I wrote a balances design with PoW in 2014 and coded some of it, but abandoned it.


Of course I put "first seen" in quotes because it is really "first propagated" with dependencies. I don't think your last sentence changes any of my concerns below.


Sorry but I think your conceptualization is incorrect. The Sybil attack can game the double spend by allowing only a minority of the trust to see the propagation of the first transaction, then it can feed the double spend to the majority of the trust. For example, the adversary has 25% of the trust and can block propagation to 25% of the other trust. There are so many possible attacks, I would need to think about this for a long time to enumerate them all. In my high IQ visualization, the system has no reference point and thus not Byzantine fault tolerant.



Because Bitcoin relies on proof-of-work so it doesn't matter which order the transactions propagate, because only one will make it into a block and then the network hashrate will mine on that block. The only way to cheat in Bitcoin is to have a majority of the hashrate (or 33% for selfish mining) to create an orphaned transaction.

See Bitcoin has a reference point called a block.

Note your point does apply to 0-confirmation transactions in Bitcoin, which is why they are unsound. And recall the recent discussion on VanillaCoin's zerotime being unsound as well. It is a tough nut to crack, but I dare say I did.


Again I asserted in my prior post this will drive the money supply to 0, else it won't prevent profit from spam transactions in your design.

Yes he could set up 2000 nodes all providing services of different types to the network, and he could run those 2000 nodes until he has some trust that can perhaps influence the outcome of some transactions.

This is of course assuming that there is enough transactional activity in the network to continuously provide endorsements to his 2000 nodes.  If there is not enough, then all 2000 of them will be sitting idle for 90% of the time or greater burning costs and effort to maintain them.  Sure you could VM maybe 10 or so nodes on a single box, but that is still 200 machines with operation costs and maintenance.

Building the trust in this way would also be a long process and would reach a cap that can not be overcome naturally.  Because of the decay there will come a point where he would be earning the same amount of trust per day that is decaying. 

If the network was small enough then he could potentially achieve some influence to direct maybe some of the transactions, but the hindrance of cost vs reward on such a small inactive network would not be worth the effort.  There is still the practical issues of triggering and influencing a double spend in time in the first place.

---

If there is enough transactional activity to keep his 2000 nodes busy for a large percentage of time, then there is also very likely to be 1000s of nodes in the network, which are not his, doing the same thing.  Thus the trust that he would acquire naturally over those 2000 nodes still would be far short of what would be required to have confidence of success in any attack, and would suffer the same capping effect due to decay as the low activity network.

Additionally, if you are in control of 2000 nodes that are constantly busy, you will be earning a very large amount of revenue from service fees and new supply, and it would most likely be more than any gains made by using this naturally acquired trust to enact a double spend.

You kind of do, because otherwise you can't analyse things like the long range attack. I'd appreciate a brief description of what the ledger looks like

Why does he *have* to produce transactions himself (and therefore pay the fee) in order to gain trust? Can't he just act like 2000 normal nodes for a while until he has the necessary trust and then perform his attack?

Yes of course, the trust consensus is to ensure that all nodes agree on the valid set of transactions that make up the ledger.

I'd like to just clarify that all transaction information is public, other than who the sender is and who the receiver is.  Any person can audit the ledger to ensure that balances hold enough to make the transactions, audit the fee and supply distributions, audit new supply etc etc.  All that is hidden is the participants.

You don't need to know this information to understand consensus, and all of the above will be covered in ledger documentation.

There is a record of all transactions though right ? And nodes do agree on that record right ?

First, there are no blocks!!

Because the commital of transaction is fluid and real time, and providing you have a majority of honest nodes where no Sybil attacker has achieved 50%+ of the trust, you can safely and easily approximate the current time to within about a minute.  Time management is also another document, but that fact should be apparent if you "read between the lines" a little when digesting the consensus.


Your understanding is slightly wrong, its not explicitly the "first seen" transaction, as the first seen may not validate for that node at the time.  Because transactions are fluid, nodes may be missing dependent transactions and so can not validate the first seen.  By the time the second has come along, those nodes may have the dependent transactions required and so counter-sign on it.

This is part of the reason why an attacker that causes a conflict without a successful Sybil attack has a best a 50/50 chance, as explained in the document, of the second transaction being accepted


Again your understanding breaks down here.  A successful Sybil attack can prevent and hinder the propagation of counter-signature information to some degree by not forwarding on counter-signatures, and it can also isolate some nodes from broadcasting counter-signatures at all.  But you don't need every node in the network to present a counter-signature to form a consensus on a transaction, only a majority.  Thus to completely prevent any counter-signatures and prevent any transaction committals at all, the attacker would have to isolate ALL nodes in the network from ALL other nodes other than his to be sure of disruption, and that is no easy task to do.

The most an attack of this type could do, would be to slow down the finalization of transactions.

In Bitcoin you can target a miner and isolate him much easier, provide him with bad transactions to mine, and not broadcast on any of his blocks.  Isolating ALL miners its a monumental undertaking.


Explained in a follow up post further up, it should really be left to a document of its own on economics, but the information I've provided should be adequate.


Isn't this the case with all developers?


No offense intended either, but I'm too vested into this to even consider jumping ship thanks

For the purpose of understanding trust consensus you do not need information about the ledger or how it is constructed.

There is no chain as specified in the document, there are no blocks either.  Transaction are validated and committed individually in real time.  The ledger is 100% different from Bitcoin and everything else.

If me and you both submit a transaction 10 seconds apart, then mine will be committed and final around 10 seconds after yours.

So let's see if I understand this.

Nodes build trust. With that trust they can - simply put - vote on transactions by countersigning them which gives the transactions consensus value. When nodes sync with each other they don't pcik the longest chain like in bitcoin but they pick the chain with the highest concesus value i.e. the chain that most trusted nodes signed.

Is that about right ?

Yeah exactly, everyone else can see it and make of it what they will.

So basically trust is "credited" on the ledger and there for everyone to see. Thanks for clearing that up.

Sure, maybe a simple example will help.

Lets assume there are only 3 nodes in the network, A is you, B is me, and C is someone else and is currently offline.

A & B are connected in the network, and have been sending challenges to each other periodically.  
B wants to send a transaction to somebody, and as it is only connected to A, it endorses A for any work done and for passing the challenges, and sends the transaction.
This endorsement is recorded in the transaction directly, remember that.

C now comes online, synchronizes and connects to A.  
C is curious if A is trusted, so scans the transactions for any endorsements that reference A's SNID.  
C will see the recent endorsement of B -> A and any others that have been made in the past, and can easily calculate A's trust level from the endorsement information in transactions.  
(Note: C will not be able to discover who endorsed A, that information is not recorded)

Transactions are stored in a public ledger just as in BTC and other cryptos, and endorsements are not encrypted or masked in any way.  Therefore everyone can see at any moment, who has been endorsed and calculate their trust level and compare it should they wish to any other trust level.

Does that help to understand it?

Evaluation of eMunie

CN = consensus node = holds local information regarding the state of the ledger, and likely peripheral repository content.
IN = issuing node = challenges CN to insure they hold the correct data
SN = service nodes = only they can earn trust, and only if they respond to services timely. Thus CN and IN must be SNs.
TXN = transaction creation node = seed the trust earning process for each txn for a chosen service. Unclear how the network reaches consensus on trust awarded.

To start, one nitpick is there is no reliable concept of time in a consensus network, so instead you must base decay on blocks elapsed. If you entrust consensus on time, it adds another complex attack vcctor.

If I understand the general conflict resolution concept (ignoring for the moment possible attack vectors created by the bandwidth optimization that need more study), transactions are propagated over the network and counter signatures (CS) weighted by trust of the SNIDs propogate telling each node which of each set of transactions (amongst each double spend set) are the "first seen" transaction.

The attack vectors are DoS (especially on network propagation), Sybil attacks (spreading trust around to infinite nodes in order to control the transaction propagation order legally in the protocol), and collusion of nodes (legally within the protocol).

You address the Sybil attack due to trying to impart trust to self by creating spam transactions, but you don't address the Sybil attack designed to control propagation order. Additionally your proposed solution to transaction spam is flawed because if the transaction fees are greater than what is earned by any node(s), then eventually the money supply must go to zero (and that is true even if you create new money supply in other ways since the game theory will be holistically connected).

Also what is the financial incentive for these nodes to participate? Game theory can't be analyzed without that information.

You will have a very difficult challenge to beat me in terms of designing a better consensus network. Seriously. Good luck.

P.S. you have decent coin name. Perhaps you may consider abandoning your (what appears to me to be a) faulty design and joining me.

No personal offense intended, and I will not harp on this. Again good luck.

Could explain how trust is formed on a network level and not on a node level ?
As far as I understood nodes send challegens and if those are answered correctly the node on the other end will gain a little trust. But that trust would only be for the challenging node as he sent the challenge right ? How is that experience brought to a network leve ? Does the simply broadcrast to the network that he received a valid result for a challegen from node x ?

This is true and Sybil attacks are expensive even at low network loads.

Let me give some example numbers:

The base fee is currently defined as the equivalent to $0.01.  We'll ignore the load fee for now.

Lets assume that the network is processing 1 tx/s (similar to Bitcoin) which is a total transaction load of 86400 tx per day.  A attacker using a Sybil ideally wants 40%+ as stated in the article so that he is able to influence the outcome of the TCW process enough to direct which transactions are selected.  Thus he has to produce ~35k transactions per day, the cost of which is 35k * 0.01 = $345 per day.  Not a great deal, but not insignificant either.

Any profits from double spends or Finney variants needs to be greater than $345 per day for it to be worth while, but also remember that there is maturity time and decay of trust.  The attacker can't counter-sign any transactions until the trust he has produced is mature, which is 1 snapshot period (currently set to a week).  So the total cost before he can make any profit is 7*£345 = $2415 + $345 per day there after.

If we then apply the load fee the costs become greater, at < 1 or tx/s the load fee is very high, 0.10c and greater.  The load fee doesn't diminish until > 25 tx/s.

Applying the load fee to the above results in the following 35k * ($0.01 + $0.10) = $3,850 per day, with an initial cost before maturity of $26,950

Plus, I would imagine that anyone transacting where values are exceeding a few thousand dollars or more, would at least be prudent and wait a minute or so before releasing whatever goods have been purchased as even with a successful Sybil, the window of opportunity is still very short, <30s or so from the time of the 3rd party receiving the initial transaction.

Micro transactions just aren't worth the effort, and for larger transactions its trivial to instruct the user to "wait for confirmation" like with BTC and others.  Except in this case, only 1 "confirmation" is required and you get it within a short period of time.

As the network grows and hopefully is a success, it becomes self-securing and the load fee isn't needed at all due to the massive costs of successfully attempting a Sybil.   Lets assume success is achieved and the network is processing Paypal type loads of 150 tx/s

150 * 86400 = 12.9M tx/day
Attacker requires 40%+ so 5.1M tx/day need to be produced.
5.1M * 0.01 = $51,840 per day with a cost of $362,880 to achieve maturity

Just as in the early days of BTC's adoption, 51% attacks, Finney attacks were much easier, but over time the security of the network has increased to a point where its nigh impossible nor worth it to pull these off.  The same can be said for eMunie, a larger network is a safer network.

It simply didn't scale enough.

Transaction throughput was high, but on networks with sustained high load, even with pruning, it would alienate a lot of commodity hardware.

eMunie has to be able to exceed Visa scale, but also allow everyone an opporutinity to take part in securing the network efficiently, and block trees couldn't provide that.

The new ledger does, you could run a couple Pis, make a income and participant fairly significantly to the operation and security of the network.

You didn't take into account indirect profits of double-spending attacks. Also, there always can be an irrational attacker.