Bitcoin Forum

Hello everyone,

Before hand I would like to express that any and all information you think you already know about how eMunie functions should be forgotten immediately!  Almost all of that old information is defunct and out of date and no longer relevant in anyway.  Thank you :)

It is with great pleasure that I publish the first article regarding eMunie technology focusing on our consensus algorithms based around trust.

The first of many upcoming articles covering all areas of the eMunie project, I wanted to start with consensus as it is probably the most important of all.

This first document focuses on the topic in a high level and is meant for a wide audience. There is lots of detail to dig into in future articles, even though it gets quite in depth, but I want to also provide documentation for those not so technically minded which is written in every day language and is easy to understand.

To enable a full and complete understanding of the project, what it offers and how it functions will require many articles and documentation totaling 100s of pages. I'll do my best to make sure that important topics that rely on content within other documents are explained as best I can so that the topics being covered in the material being read can be understood clearly.

I'm happy to answer any questions where I can, but please understand that there may be some items that will be difficult to explain without these yet unfinished additional documents.

The article can be viewed at http://blog.emunie.com

Best Regards to all

- Dan/Fuserleer

PS: I've set self-moderation on this topic as a precaution and will only be removing posts that are blatant attacks and severe trolling.

Well, whether this turns out to be the best or worst distributed ledger, once you factor in the consensus mechanism + economics system (if it's still the same one as before), it will probably win the award for most complicated one.  I was surprised that I couldn't find any Satoshi post regarding inputs/outputs vs balance sheet, only a Gavin post saying basically it won't work, and a Theymos post saying headers first and merkle root solves the same problem.  It does solve space constraints, creating SPV clients, but does nothing to address the issue of lower number of consensus nodes in general from exponentially increasing overhead in the input/output blockchain model.

I tried to speed read through this post and didn't really see what motivation existed for creating a large number of unique, non-sybil nodes.  I'm not sure if incentives were adequately addressed or not.  Overhead is the main variable.  If the overhead is low, then you have a larger number of sybil nodes, and possibly a small number of real nodes since who wants to be one out of a billion transaction processors making one cent a month?  If the overhead is high, then you have a lower amount of every type of node, until the moment someone decides to attack it, since it's almost impossible to guard against people who willingly operate at a loss.  You have a no win situation in that regard in terms of trying to design overhead into the system.  Quite a paradox...

This is related to the Satoshi "no free lunch" principle and general game theory, where in order to trust output from an entity, somebody somewhere has to be making a revenue stream, where them substituting false information is going to end that revenue stream.

Thanks for taking the time to read.

Firstly, I should of made it clear in the OP to dis-regard anything you may have read about eMunie in the past, as all of it is out of date and likely incorrect by now.  Ive modified to the OP to state that.

Regarding balances, the decision to use them was based on an lot of research into which of the two method could achieve the core goals that we wanted.  Lots of time and effort was put into applying different scenarios, use and edge cases which were evaluated against the strengths and weaknesses of both approaches.  In the end, balances won out due to the long term efficiency and flexibility they can provide as will be clear soon.

They are more complicated to implement than input/output, but the declarations that it does not work are simply wrong, it can work, and it does work.  Its just a hard task to achieve in an efficient and reliable manner.

I really didn't want to get into economics within the article, as the eMunie ecosystem is very fluid, dynamic and diverse.  It will likely require quite a few detailed documents to cover all aspects of it, and I didn't want to "brain dump" too much unrelated information, distract from the main topic of the article and risk sending readers into a confusion induced coma.

The details following really should be left for the associated economic documentation to explain them fully, but your question about incentive is an important one so I'll briefly cover some of it.  

Revenue for the work performed by the nodes in the network can quickly become quite significant when you apply all factors of the economics.  Not only that, the distribution of this revenue is very broad, due to work being recorded at a much granular level all over the network, instead of it being a huge "race condition" such as with Bitcoin. Nodes that perform even the smallest amount of work get rewarded for doing so, and the execution of that work is much more efficient than simply testing billions of hashes per second in what might as well be a lottery.

In terms of income there are multiple streams:  

Firstly, fees that are generated by transactional and peripheral content actions are allocated to the relevant service providers, and this income is periodically distributed between them as per the amount of work they have done.  We've performed a number of calculations with regard to income and even in the most frugal of cases, the cost required to operate the services providers is much less than the fees recouped, even if that node only performs a couple of tasks per day.

Bitcoin is perhaps the lowest income provider of any currency in relation to the amount of work done.  Megawatts of electricity is currently burned just to enable miners to make a few cents of profit over that cost, not to mention hardware replacement costs, maintenance, disposal of old hardware, pollution from both the creation and disposal of said hardware and the additional pollution of generating all that electricity.  Most of that is a hidden cost, but at some point it has to be paid for in some manner.

With eMunie the efficiency of performing work is many magnitudes more efficient than Bitcoin.  For example a Pi could be used to provide some of the lighter network services, consuming just a handful of watts per day yet seeing an income of a few dollars or more per month from minimal workload.  When there is no work for it to do, it can sit idle and power consumption is literally 1-2 watts.

Secondly, eMunie's new currency supply is dynamic and the total amount of currency can increase or decrease depending on the demand.  Assuming that eMunie is successful and sees even moderate success compared to Bitcoin, then the network will nearly always be in growth, and an increase in supply will consistently be required.  Of course, at some point in time there comes a plateau but I'm digging too much into economics already, so I'm going to skip that.  

New supply is distributed in 2 ways, the first being in the same manner as fees.  Nodes that have done work are also eligible for a slice of the new supply proportionate to the amount of work they have done since the last distribution.  The second mechanism is via interest on assets that are held in balances within the network, with holders of balance receiving a slice of new supply proportional to the amount of EMU they hold v's total supply, and how long that EMU has been sitting in that balance.

For service nodes that are active, not only do they receive a portion of fees for that service and a portion of new supply for doing work, if they were to hold those earned EMU and not move them, they would also receive a 2nd portion of new supply as interest.

The question isn't should I run a service node, the question should be why on earth aren't I?

What has made you abandon the idea of block-trees?

For the sybil attack to be unprofitable, the amount of funds spent to acquire the needed trust to pull it off must be <= the amount you can potentially double spend with such an attack. Is this the case?

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

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.

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.

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 ?

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.

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?

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

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

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 ?

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.

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? :P


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

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

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.

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?

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 :)

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.

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.

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.

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?

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.

If an attacker is running a large number of nodes with the view of eventually becoming dishonest, if he is able to build enough trust (which is unlikely) naturally to do that, then his earnings from being honest will most likely be more than any earnings he could generate from being dis-honest.

There is no way to know if an honest node is going to become dishonest, and so if a node is doing legitimate honest work, then it should be paid.  If the operator is earning as much, or more, from being honest, what is his incentive to turn heel and be dishonest?

200 IPs pointing at one box, yet doing legitimate work is going to have 1000s of incoming connections.  That will saturate either the connection, the machine, or both.  That machine will not be able to process the challenges or work requests in time, so other nodes will not endorse it.

Hi Dan,

Great to see you back around.

I was busy and had a hard time to read 15 pages in 5 minutes, but what I took away from it was Hyperledger's method for keeping track of only running balances is being adopted or something kind of similar.  (but the problem with the Hyperledger like projects is that they end up being too centralized, although its plus is that is seems to scale much better)  So to decentralize it a node reputations system kind of like NEM's Eigentrust++ is being used to make sure that nodes stay honest and are checking each other and giving each other ratings and reputation.  

That being said, here are a couple of my questions.  Maybe I missed it, but how are people that are running nodes being incentivised?  I can easily see that there is a negative incentive for giving bad information to the network as they loose their reputation, but what do they get from helping out with the network?  Fees?

I'm also really happy to your focus of trust.  One of the big things that I took away from the system of a blockchain is that, yes, it solves the problem of the double spend, but what it really does having solved that problem is expand your circle of trust.  In the old days a person could only trust people they knew well, people in their neighborhood or family; people that you knew where they lived so if they ripped you off, you could get then. (that is funny, but that is how it was).

But a blockchain expands my circle of trust to billions of people in hundreds of countries.  If they send me money I don't have to worry if it is fake, because I know where the money lives and how it lives.  It lives on the net and is ruled by code.  I don't have to trust the person, I can trust the cash.  

Your system sounds like a great way of expanding trust in balances and trust in the nodes that support the network, but in giving up the history of an account, I can't help but wonder if you are giving up some valuable information that could help with trust.  Seeing a history of an account allows a person to know if it is the real deal.  If I am sending money to a major business, I would expect that account to have lots of transactions in and out, and if it doesn't, I can be suspicious.  

Will there be a way to give reputations to accounts now that you can't see their history?

I caution you jabo, that my impression (having interacted with you in the past) is you are reasonably smart guy but don't have the necessary domain technical expertise to make some of the conclusions I've seen you posting lately:

https://bitcointalk.org/index.php?topic=1159691.0

I know everyone wants to think they've found the holy grail. Unfortunately most all of it is fundamentally flawed, but only the most expert can see why. And we don't have enough time to write white papers revealing the flaws in every whiz-bang new tech for crypto.

+1

Hey thanks, I've been under a rock for a while for sure :)  Nice to get some air, even BitcoinTalk air at that  ;D

I'd encourage you to re-read it at a bit of a slower pace when/if you have the time in case you missed anything of significance.

I cover fees briefly in a post here further up the thread that should be adequate for your question.

I really want to touch on the amazing capabilities that using balances over inputs/outputs provides, and that will reinforce not only the choice of balances, but why this consensus route was chosen and the ledger design we have adopted too.   I know though, if I start to talk about all that juicy stuff, it will immediately distract from this trust consensus, so I'm going to force myself to refrain from it for now :)

Your question about transactions is exactly the reason that I don't really want to touch too much on other areas that will be covered in other documents, as things get missed out and its impossible to proof-read properly to ensure you are not missing something.

My statement further up this thread in a post about transactions and the participants being hidden is the default configuration of the ledger so that it provides a level of additional anonymity.  This is actually configurable, so that in the case of your question, companies could choose to expose that they are the sender or receiver of a transaction, but keep the other party hidden.

This optional feature is also important for companies that want to comply with tax and regulatory laws as they can expose in public these transactions and earnings to everyone and the tax man.  Individuals can also do this too of course.

Parties who chose this configuration can easily prove that they are in control of the balance(s) associated with that transaction, so then you can have a full representation of the transactions they have performed and achieve a similar level of trust in the manner that you speak of.

I don't mean to be rude, but this and some other things you have said portray you in an extremely arrogant manner.  Talking down to people never gets you anywhere.  

Bitcoin is fundamentally flawed also, if I have 51% of the hashing power, thats it, I can do what the hell I want with it :)

You mean this?

"For example, the adversary has 25% of the trust and can block propagation to 25% of the other trust."

If so, again disregarding the cost/effort involved to secure that level of trust and the propagation, there is no real attack there as it puts you, at best, in the same camp as the guy that triggers a conflict without any Sybil at all.

100% of trust of which you have 25%, so real available trust is 75%

If you can block 25% (do you mean 25% of 100% or 25% of 75%??) of other trust, then that leaves 50% of honest remaining, of which your 25% is not enough to overcome to a majority, at best you have a 50/50 chance., which is the same as the attacker with no Sybil as discussed in the article.

If you are blocking 25% of the remaining 75%, then the odds for you are worse, 75% * 0.75 = 56% of honest trust remaining, again of which your 25% is not enough to overcome a majority at best your chances are < 50/50

It was a suggestion to someone I know and hopefully a wake up call to readers to be careful. But he is of course free to make statements such as this where he is implying some very complex math and algorithm with some blackbox non-peer reviewed simulation model is some how at some higher level of soundness (it is the sort of proclamation only n00bs can make because they don't seem to understand that even academics make big mistakes, that is why peer review is so important). And I provided a link for him in my prior post for one reason all consensus algorithms up to now may be fundamentally flawed. Specifically I expect serious issues to be found in NEM, once someone expert has the time to dig into breaking it. The more complex a model, the more likely it will have flaws. Bitcoin's proof-of-work is simple and withstood the test of time so far and up to a $10 billion market cap to attack (and yes I do think it is fundamentally flawed also  but at least the flaws are enumerable which I can't say for complex designs):

These are huge if's, though. If the other POS like blockchains are anything to go by (NXT, bitshares, etc), the earnings from being an honest node will barely pay for the hosting of the machine, making the attack all the more profitable to pull off in relative terms.

Ripple actually moved away from their initial trust lines design because it was possible to game the system (recall the tradefortress scam?). Your design attempts to mitigate this to some degree by making acquiring trust quickly expensive, but the long-con attack will still be profitable IMO.

If adversary has 25% and can block propagation to 25% of the other trust, he can allow the first spend to propagate to remaining 50% of the trust, then he can propagate the double spend to the other 50% (i.e. his 25% and the other 25% he originally blocked). He only needs an infinitesimally small more % to be sure his double spend wins. TADA! It's magic.

Somehow I knew you weren't going to keep your promise  :(

They are huge ifs from your perspective because you do not have the relevant information that explains how it is achieved.

If possible I'd like to leave this as an "open topic" until I finished the required documentation and present it so that you have a better understanding and can be more informed regarding any questions you still have.

I agree that it is difficult to achieve and on the surface my seem wide open, but in reality the desired function can be achieved with a smart economics system.

Which puts you in exactly the position I said you would be in, 50/50 which is also stated in the document.  So its not magic at all really is it?

That is a lot of work and effort for a 50/50, you'd be better off spending all that money on buying scratch cards, and the effort used by scratching them off.

The adversary with say 26% of the trust and block 25% (sure you can read where I wrote "infinitesimally...") can impart 51% trust to the double spend thus he wins. Not 50/50.

---

Because he did not follow my request to edit his prior post. Instead he made a new post. So I did too. See how that works?  ::)

Where do you get all those 25%s and 50%s from? Byzantine generals problem talks about 33%.

We can pick numbers out of a hat all day long to reinforce your theoretical argument, but it remains that in practice its difficult, costly and requires a lot of effort for what is probably minimal gain.

At the very worst case, we have a solution that is as secure as Bitcoin, but with many other benefits as will be revealed soon.

I'm not sure about that - a double spend in bitcoin requires you outpace the entire network after you have acquired the technological inventory to produce the hashing power. That is very expensive to do.

As far as I can see, once you have your set of trusted sybil nodes in your scheme, a double spend costs nothing.

You realise you both contradict yourself and cause a paradox in two sentences?

Outpacing the BTC network via hashing power to achieve 51% is akin to acquiring enough trust via a Sybil to out vote the majority with 51% and outpacing them to act on it.

Both have expense associated with each, so a double spend can not cost a lot in one, and nothing in another.

I've already provided undeniable proof with the base and load fee example that acquiring 40% or more of the trust in the network for a high success rate can cost $1000's per day even in small networks.  So the statement that it costs nothing is false.

No it isn't. Acquiring enough trust with a set of sybil nodes is equivalent to buying a bunch of mining equipment.

Producing a block still costs in bitcoin (25 BTC, to be exact), and outpacing the network costs significantly, whereas I don't see the ongoing cost in your scheme?

Then I don't mean to be rude, but you need to re-read the document and my replies to other questions in this thread regarding fees and trust decay.

Just having a bunch of nodes doing work will not be sufficient to acquire enough trust to be able to reliably effect the outcome of transactions in conflict at will, and I explained why in my response to one of your questions.

If I am wrong, please provide examples that prove it instead of just stating "you're wrong"

Also if producing a block in BTC cost 25BTC, then no one would do it because the reward is only 25BTC for doing so :|

Example, long con:

* Pretend to N nodes by acquiring N ip addresses
* Build trust by behaving normally
* Once the required sybil majority of bad, trusted nodes is reached, perform a massive double spend by using your trusted majority

Cost of this is basically zero, right?

There is no way around this problem unless the actual voting process costs something.

All your sybil attacks are abstract and don't take into account factors of the real world. The attacks may succeed in a spherical vacuum, but what about attacking eMunie if it's used by, say, Starbucks? You walk into a cafe and scan a special QR-code (displayed on an interactive screen) with your smartphone. This code is the root of Merkle tree of the ledger essential part. If your version of eMunie ledger is "hacked" then you will see the difference right away. Whom will you trust, the Starbucks system or unknown random guy with 2 million fake nodes?

Finally, someone that sees sense.

This is the problem, everyone thinks only in theory land and doesn't consider the real world.

Even if you have spent crazy amounts of money, time and effort to have an inflated trust value, you have 10-15 seconds to pull it off...that includes the receiver seeing the payment, handing you the keys to the shiny BMW (because anything less doesn't provide profit), you screeching off, and presenting a double spend transaction while being Mr Getaway driver.

I've had these same arguments face to face with people endless time and it always goes the same

"Well I can create 1 million nodes and take over the network"
"sure, if you had 1 million nodes could you take over Bitcoin too?"
"YES!"
"so why hasn't anybody?"
"erm...."

There has to be a point where you say "Thats enough for 99.999% of all situations" and be happy with what you have

A point of distinction is that the adversary only needs to acquire as much trust T as is necessary to be able spread his nodes around sufficiently to block (delay) propagation to (51% - T) of the total trust in the network.

I don't know how small T can be until it is properly modeled. Maybe it is only 5%. The other 46% then comes for free. Maybe it is 26% then the 24% comes for free. We won't know until the system is holistically modeled.

I don't have time to go back and forth here.

Your design might be somewhat secure or it might not. It is far too complex for someone to know that in this thread. Will require much peer review and modeling.

I can't visualize at all even the slightest way that could be achieved in a P2P network when these events are broadcast events and not routed traffic events.  Routed traffic that has an origin and destination, yes, if you had a small amount of nodes in the network, then you could block traffic quite well to a large number of routes that hopped over one of your nodes.

But in a broadcast environment, where each peer is connected to 8-16 other peers, how can any of what you suggest even cause any disruption at all without completely isolating a large number of nodes, and having a large number of nodes yourself.  How do you prevent N broadcasting to M whom it is connected to about a transaction/counter-signature, and then prevent M broadcasting that same transaction/counter-signature to L and so and and so forth and do it all over the network?

I really am curious and would like some detail if possible on how you would do it.

Of course that is the point of spreading your trust around to as many nodes as possible and target isolating nodes with a Sybil attack. You can also isolate nodes by identifying the patterns that make some nodes more important to isolate than others, so a lot of nodes are isolated by isolating a fewer nodes. No P2P network is perfectly distributed.

Again I don't know what the ratios will end up being between T and 51% - T. A proper modeling has to be built.

And I doubt that is the only attack. I haven't expended more than 5 minutes yet thinking about how I would attack it. And I don't even know all the fine design points and I would need to probably know that in order to try to identity more vulnerabilities.

Also it is not clear if your economic model isn't gameable. I haven't delved in that.

For example, nodes might even pay other nodes to accept them as their peers. Remember Vitalik's point that consensus is an undersupplied public good (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/).


In summary, I don't want to comment more other than to say it is a complex model and I would want extensive peer review.

Edit: I want to emphasize that my comments in this thread are not to be taken as a statement of certainty (or even probability) that eMunie has a flawed security. I am presenting my initial opinion (based on very quick read of the first blog article) that it is difficult to reason about with certainty and I'd prefer a more thorough analytical review especially a formal model would be fabulous.

That doesn't really answer my question in any manner at all.

I want to know how you isolate a node A, that is honest and free to connect to any node that it wants, from either connecting to that node, or sending it information.

Lets say that A is an important node, lets also say that it has a slightly above average trust weight.  It has many connections incoming to it, and many outgoing from it that it makes of its own.  Assume that is also has a list of preferred outgoing connections to nodes it knows are of similar importance to it.  If you can isolate it then it improves your chances of success slightly.

How do you isolate it so that it can not receive or relay information to anyone without being physically near it?

If you fill up its inbound connections so that regular clients cannot connect to it, it can still make outbound connections to any other SN nodes like itself.  If/when that fails (because you are filling them up too) it makes connections to regular non-SN nodes instead.  All the other important nodes in the network are doing the same thing, and by doing so, they have a route to each other (albeit it a bit slower).  The regular clients become the service providers for the SNs, by providing a route for data between them.

The network topology is such that for every 100-200 connected users of the network, on average you need at least 1 SN available.  With 10000 users that is ~50-100 SNs, with 100000 that is ~500-1000 SNs, 1M you are 5k-10k SNs.  With a large number of SNs comes a good distribution of trust, so there wont be just a handful of SNs you need to isolate.  You'll need to isolate a lot of them (1000s as the network grows), and as all of these SNs will have inbound connection pools of 100-200 in size, you'll need to fill up 10,000s of connection slots in total.

You make a holistic assumption about the economics which I can't even make. Again see my point about undersupplied good and the ability to bribe nodes. I mean every one is participating in consensus "mining" (or what ever you want to call it) to earn the most they can for themselves. Until we know well the holistic economics game theory of your complex design, it is not really possible to even reason about what 'honest' means. It isn't dishonest to maximize my profit.

I thought you were going to let me leave the thread with my gracious comment that my comments were speculative only.

But since you insist, I guess I have to become more forceful than I wanted to.

I didn't see your edit until I had replied actually.

But fair enough, I was genuinely interested in how you propose to do it, but seeing as my interest is angering you I guess I'll leave it at that.

I assume A is not going to connect to infinite nodes.

Thus I assume there are certain finite number of nodes it connected to such that if they were all adversarial then node A would never know it was occasionally receiving a delayed transaction propagation. Even if there were a few connections to A that were not the attacker, those connections connect to other connections and the attacker may be able to map out the network and determine where to place its effort so that as a mesh it becomes blocked off. If you can't visualize this, then I don't know what to say. I can visualize that in my mind. I don't feel like diagramming it. I don't know how successful it would be. Attacker might just maximize number of nodes by diluting trust and how random luck plays out in terms of the amount of trust cordoned off.

Now as for the probabilities and what would be the ratio between T and 51% - T, I don't know. Would have to develop a formal model and analyze.

Btw the more trust A has, the most incentive to focus all adversarial nodes, on isolating that node.

Note there was a research article I saw recently on how surprisingly hierarchical the Bitcoin P2P network is and how propagation is controlled by fewer super nodes.

As most people know, the cost has mostly shifted from hardware to electricity, but when I've calculated mining costs during the last year, there are times when it seemed like a huge percent, maybe even the majority, were mining at a loss.  It makes perfect sense from many angles.  For instance, if you own 1000 Bitcoins, but only now pull in a small amount through mining at a small loss, you're increasing the value of the stash you already hold by increasing network hash rate.  You're increasing both network security and scarcity for others at the same time.  I think Satoshi's papers would classify this as an irrational miner, but it seems perfectly rational to me.  This is assuming they did not believe the speculative price of Bitcoin would go up, since that would be a different reason to mine, but the results from their direct actions would have an effect.

This also occurs on a daily basis for any coin not secured by heavy parallelization computing, since bot nets can mine for free, thus making legit miners unprofitable.  Some people still do it anyway...until the coin dies.  Seems like one of Satoshi's biggest blunders, not accounting for botnets, ASIC, Chinese government subsidized power, currency manipulation to increase exports which results in all mining hardware being made in one country, etc.  That's a lot of anti-decentralization going on.  PoW was kind of presented as a bulletproof solution, when it was more like the best bad solution.

The real reason PoW mining exists is because there is no other valid form of distribution that can hope to reach a wide audience.

As you say how can you know if they are mining at a loss if their electricity is heavily subsidized.

Also how do we know they aren't being funded by the $4 trillion Black Budget that is confirmed to exist by Donald Rumsfeld and thus growing hashrate over time to take over Bitcoin.

I don't think you can conclude with certainty the motivation is altruistic.

Btw, I have solutions to all those issues with PoW that you mention.

Right, thats pretty much exactly what I just said, you identify all the SN nodes with a higher than average weight, and attempt to connect to them all.  If you have a lot of Sybil nodes, then you may even get some inbound connections from these nodes as they try to connect out.

Thats a few times today you've responded with the same thing said in a different way, maybe you should give me some more credit than you do :)

But, I still find it difficult to swallow that this can, and would be coordinated, with 1000s or more machines and all the effort required to maintain it, to take advantage of a 15 second window to influence a transaction conflict.  When all that is needed for all of this effort to be thwarted, is to wait 60 seconds or more for the transaction to be fully final and have a majority.

This isn't like BTC where I have a 10+ minute window, or can run home and turn on a few PH of mining power and UNDO the transaction.  Once its final and has a majority of the trust, its in forever!

Thats interesting, I have havent been keeping up to speed on mining costs and things like that for a long time now.

Thanks for the insight though, it does seem backwards to me though, but I guess mixing capitalism with anarchism results in crazy behaviour! :)

You dont need anything like $4T, you could re-mine the entire blockchain from the genesis again in secret in about 2 years and $200M.  As a bonus you'd end up back at today with about 65% of current mining power.  Then just present that chain as it'll have more work than the current one, and BAM.  All BTC transactions gone on all nodes that are active at that time, you can easily outpace everyone else too so they cant present a stronger chain.

BTC is dead in that scenario, and they would have to change the protocol to hard-fork away from the current version and start from scratch unless someone, somewhere had an up to date copy of the old chain that could be imported somehow.

You couldnt use POW anymore though in the same form, because someone somewhere is sitting on 65%+ of all the hashpower and just ruined yours and everyones day with it.

Well remember you have bandwidth to worry about ;)

You see the devil is in the holistic details. I said in my first post that the bandwidth optimization would work to open more opportunities to attack.

So decrease bandwidth, that must equate with reduced # of P2P connections per node, no matter how you formulate it.

Thus increasing the probability of being able to isolate it.

I know the devil is in the detail, Ive optimized bandwidth and usage a lot, its very efficient.

Network fragmentation and Bitcoin is dead because you can spend your coins in every fragment. Not just a double spend rather an N spend. Where N is number of fragments.


I'm very sleepy so will sign off.

If Fuserleer is BCNext, he has a serious Dissociative identity disorder.

https://bitcointalk.org/index.php?topic=303898.msg3390794#msg3390794

I think this is a fine balance for a system.  A consumer should have the right to protect their privacy and even be completely anon if they want.  A business doesn't need to know anything about that consumer except that they sent the money.  Can a deposit be seen on the blockchain?  If so, good.  That is all they need to know.

This doesn't apply for business though.

A consumer and governments to some extent need to know about the dealings of a business so that the consumers can protect themselves, and at the same time the government can protect those consumers that are too young, too old, or too foolish to protect themselves.  Businesses having an option to show their histories openly and transparently is a nice step in this direction.

Bitcoin and other blockchains have been stricken by a series of scammers as it is such a great platform for them.  They get them money and can easily disappear.  It would be nice for those businesses not interested in scamming to have a proper outlet to do so in a system that helps to support their claims of legitimacy setting a bar for how legit players look and how they act. 

I really don't follow you. I'm not talking about producing a fake ledger, I'm talking about abusing the system into accepting a double spend into the genuine ledger.

I'm sorry, this is just rubbish. In the best case you can mine, lets say 95% of it, but you can never mine the last 5% because the difficulty will end up being contemporary and then you are back to outpacing the entire network again, which you just won't do by yourself, unless you have the majority of mining power, which is the classic 51% attack.

There are no blocks as Fuserleer said, so I assumed there was no blockchain reorgs. A ledger can't accept a double-spending transaction without doing a reorg.

This is true. However, the only way to have no forks is to know in advance (and forever) who the nodes building the ledger are - in that case, if, say a network split occurs, the nodes who split off will lose connection to the ledger production nodes and simply stop with a 'no consensus' result.

But if your list is arbitrary and constantly changing, then forks are inevitable.

Maybe we should all just wait for the ledger discription.

There are no blocks but there has to be someway for reorgnaizations right? The primer itself says that all nodes are not always in the exact same state (for legitimate reasons). So there has to be a way for them to agree on states (which afaik is the transaction consensus value) and to change their own state in case it turns out someone else has a "better" state.

Yea, nobody can figure out how this thing is supposed to work from the information provided so far.  Maybe he's making the coin on the fly as the thread progresses.  As a side issue, even though he's running a different system, I really think Dan is going to be forced to cap nodes at a certain number just like Bitshares and Darkcoin before this is out the door.  For monetary incentives and security-wise.

Why? - like BTC, work is rewarded. The more transactions, the more profitable it is to run a client. If its not profittable, people will shut theirs down and the revenue for the remaining nodes are increased accordingly. Its will be self regulating by the incentives already put on the table  :)

You do not need some centralized shit to regulate incentives. People will figure out themselves if it makes sense to donate ressources or not.

more importantly, is the damn thing still written in java dan?

and you mean this closet of pi's ive been hoarding all these years cant attack emunie? fuck.

*sorry, this was border line toooo serious.*

Me?? BCNext? lol  In that case I could be Satoshi too as I write block chain with a space and frequently mix American and British spelling of words!  I am everyone and no one, the many faced man!


Correct, once final a transaction can not be undone.  Transactions sit in a pending state until they are final, and that state duration is dependent on a number of variables.  Transaction that are in this state for too long are rejected.


As Ive said the purpose of the document is to give a high level overview of a Byzantine tolerant consensus, for which if you read it as it is intended, explains exactly that.  There is only confusion because of the application of block chain thought processes, and that we are delving into topics regarding ledgers, economics and other things.  

If you read the document as an entity in its own right, then it reads just like a Byzantine tolerant solution for which you do not need to know any other details of the system.  It could be applied in any system, and the prevention of Sybil attacks is possible via the simple substitution of fees for simple Proof of Work (not necessarily of the hashing type, there are many forms of POW used for many things before Satoshi) before each node is allowed to present a change to build its trust as a form of cost, with the trust "reward" being something relevant to the system being protected.

Also, no Byzantine solutions are infallible and have a fault tolerance limit of (n-1)/3, most fall short of this maximum or have to apply further restrictions to move closer to it.  Bitcoin itself does not even meet all the requirements needed for a Byzantine tolerant stamp of approval, but achieves "good enough" security though the utilization of its POW mechanism.

Heh, I can assure you I'm not winging this project by the seat of my pants :)  But I do like to take the time and effort to ensure that everything is covered, which I believe it is in regard to the trust consensus.  I'm also not so egoistic to think I'm right 100% of the time, and I actively spend lots of time reviewing everything after comments from others or possible concerns which they have.  

The past couple of days I have reviewed some of the concerns posted here and investigated them once more to be sure they are not serious and nor have I missed something.  The consensus presented holds up, and doesn't allow an attacker any more of an advantage than any other accepted solution for consensus.  All of the attacks presented have a cost attached which are greater than any reward in almost all cases, and in the others, they are easily thwarted by simply waiting.  Only irrational adversaries would would employ these attacks, and none of them take advantage of an attack surface area that is not also present in other consensus solutions.

That said, after reviewing concerns posted here, and investigating them in detail, I do have a few small improvements that I may make to the algorithm to further make these attacks more difficult to achieve.  I'll update the document (and others if published by then) with any changes made moving forward if and when I make them.   So, thanks to all for kicking my ass, it'll probably lead to improvements :)

So, how does this deal with a network split? I have yet to see any consensus proposal which is truly forkless without the ledger producing nodes being set in concrete, like they are in ripple.

I put it to you that forks are inevitable unless the nodes producing the ledger are a fixed set.

Which is why I said he will probably have to cap nodes at a specific number like Bitshares and Darkcoin did.

The ledger is append only, honest nodes either all agree to commit a change, or do not, so between honest nodes there are no network splits.  

With dishonest nodes, you can not enforce that they are committing the correct data or not, or if their ledger is in the correct state. Dishonest nodes may be doing all kinds of manipulation with the ledger they hold, yet still be actively participating in the protocol.

We simply do not care if dishonest nodes have a different state of ledger or not, because assuming that bad actors do not exceed (n/3)-1, we can be sure that we can guard against it.  

All the honest nodes are in a state of correctness, and will not commit any actions presented by dishonest nodes that attempt to subvert that correctness, because they will all arrive at the same result when presented with that data.  Should some data from a dishonest node be accepted, then all honest nodes will retain the state of correctness, because they will all have committed the change from the bad actor.

The dishonest node can present changes to historical data all it likes, all of the honest nodes will refuse to make the change because it violates the append only rule, even if greater than (n/3)-1 are telling it do so and honest nodes are in the minority.

Not true, while Byzantine solutions typically employ some form of elected "leader", or have a predetermined static set of trusted nodes, it is possible to achieve agreement with an ever changing set of n nodes. 

There doesn't need to be any enforced cap, as any number of "voters" can be used in the set, and the set modified at any time.  Your workable limit is simply the point where the communication channels between this set becomes saturated and overloaded.

The network split I was referring to was a not a malicious one, but a topological one. If one group of nodes becomes disconnected from the rest, they will form their own completely valid consensus within their own group, creating a fork. When they re-join the network, the fork will need resolving somehow?

This kind of forking will happen all the time due to network latency, the topological split is the extreme case.

Network topology splits are handled in exactly the same way as malicious actors.  

Byzantine agreement protocols can not determine if a node is faulty, or dishonest.  Non-response may be for a number of reasons, a node may be faulty and cant not respond, it may be offline, or it may be choosing not to respond as its dishonest.

BA protocols regard all of these cases as a failure, and providing that less than (n/3)-1 failure occur at the same time, an agreement can still be met.

A fork/network partition/split-brain whatever you want to call it doesn't violate or hinder the operation of the majority providing the failure % is within bounds.  In the case of a true BA protocol, the split partition may be able to continue operating for a short period of time after the fact, but will not be able to operate indefinitely.

For example:  

Assume there is a network of 15 nodes and active traffic.  

4 of these nodes suddenly loose communication from the other 11, but can communicate between themselves. These 4 nodes will likely get "stuck" immediately.  They are not able to achieve a majority regarding any pending committals as they are not able to receive the votes from the other 11 voters.

Even in the case where there are no committals pending, or active traffic, the split of 4 will be aware that something is amiss upon one of them presenting a new transaction, as the set of nodes those 4 expects to acknowledge the next transaction, 11 will not respond.

While the original network regards the sudden non-response of these nodes as failures, it is below the maximum of (n/3)-1, and can continue operating.  The network split containing 4 nodes regards the sudden non-response of 11 nodes as a critical issue as there has been > than (n/3)-1 failures which is easily detectable.  That split network can then act accordingly, pausing operation and perhaps even informing users of the sudden critical issue until reconnection to the main network partition.

In this scenario there is no "data fork/split" because the failed group can not proceed unless they all decide to, which in most BA protocols, is not the case.  This means that this group can rejoin the main network partition at any point, be given the information they need to achieve data correctness with the majority, and continue operation as before.  No rollbacks, no re-organizing.

This IMO is a critical issue that proves block chains & POW are not truly Byzantine tolerant, because there isn't a majority agreement that can prevent changes to history.  Bitcoin's use of POW results in an asynchronous network, as there is no mechanism to vote and thus prevent historical changes, and it has been proven that asyncronous networks can not tolerate even 1 Byzantine failure.  

In Bitcoin's case the single Byzantine failure is when someone produces a Proof of Work that exceeds the one currently in place.  In essence by presenting it, they are disagreeing with the rest of the network about what the state should be, and thus it can be classed as a Byzantine failure.

And what happens when some edge case means that the 4 are not aware of their previous connections to the other 11?

This kind of reactionary design is very fragile because it relies on state transitions. If you start from scratch with two groups, one of 5, one of 11 which operate independently (for whatever reason), forming separate valid consensuses but are supposed to be on the same network, what happens when they rejoin?


In POW the votes are the blocks. The chain with the most votes becomes the canonical chain. The reason for this choice is that it is very robust, simple and doesn't rely on any state transition, reactionary design and is resistant to sybil attack.

It has been argued that POW is ,in fact, *the only* solution to the byzantine generals problem:

https://gist.github.com/oleganza/8cc921e48f396515c6d6

Indeed it appears his system needs to be modeled as a complex state machine.

You can't just make a claim out-of-context that an "honest" majority of the trust reputation will decide the winner of a double-spend. You have to model the state machine holistically before you can make any claim.

Proof-of-work eliminates that requirement because each new iteration of a block solution is independent (trials, often simplistically modeled as a Poisson distribution) from the prior one (except to some small extent in selfish mining which is also easily modeled with a few equations). See the selfish-mining paper for the state machine and then imagine how complex the model for his design will be.

This is independence is what I mean when I say the entropy of PoW is open (unbounded), while it is closed for PoS.[1]

[1]	https://bitcointalk.org/index.php?topic=1159691.msg12242278#msg12242278 https://bitcointalk.org/index.php?topic=1159691.msg12227357#msg12227357

Imagine this highly technical discussion comparing PoW and PoS can't happen in the Bitcoin Technical & Discussion forum, because the overlord Gregory Maxwell moves it to the Altcoin Discussion thread.

You can't prove that without iteration through all possible alternatives. Even unknown yet.

If you started with two groups, how could they rejoin?


Generally by people with a lot to lose if it isn't.

You can prove that the average of all random numbers between 0 and 1 is exactly 0.5 without averaging every possible number. That is the definition of a 'proof'

Nodes crash and need to be restarted. Temporary loss of network routing could keep them separated from the main group of nodes until time X, when they rejoin.

I meant big asymmetry in efforts required to prove existence or absence of something.

This forum is private property. Its owner and moderators have the right to do anything they wish. Is Gregory Maxwell bad because he moved your topic? I wouldn't judge without hearing his reasons.

The 4 are always aware of the other 11, because if they werent how could they know what where the majority should be?

You are very mistaken about how Byzantine agreement consensus works and the requirements needed for a robust one.  Bitcoins blocks are not votes, if they were classed and acting as such, then a record would be kept by the network of all votes (orphans).  The network doesn't, so they aren't votes, it is a dictation instead.

The argument that POW is the only solution to the Byzantine problem is ridiculous as it doesn't even meet all the criteria.

Edit:  All distributed applications operate as a state machine, Bitcoin's ledger is a state machine also, as is Ripples ledger and everyone elses.   If it wasn't a state-machine, then new nodes couldn't download the ledger, replay all the states and end up at the same place as everyone else.

I'm beginning to feel like no matter what argument I present here, even arguments that have been proven by minds smarter than what are behind Bitcoin, they are going to be dismissed just for the sake of arguing.

A very simplified state machine of the longest chain. The block solutions are nearly independent events which can be approximated by the Poisson distribution.

One exception is the selfish mining attack where in the longest chain rule is subjected to selfish hiding of the dominate hash power. Yet even this state machine is reasonably simple, just a few simple equations.

Whereas the state of your system is numerous agents and states. It is not yet clear to me this model can be modeled with some simplifying assumptions. Perhaps you can work with your academic researchers to see if they can.

Yet my design maintains the simple state machine of proof-of-work, while removing virtually all the bandwidth scaling restrictions. You say you can't do 100,000 transactions per second microtransactions. I can easily.

All these grandiose claims of what you have, that seemingly defy proven limits of information theory, yet not an ounce of information to back it up.

If you have it, show it, if you don't want to show it, send me any binding legal document of your choice that protects you, I'll review it, and if you have what you claim, I'll back you up in any arena for the rest of my life.  You could even hash whatever document presents your algorithms and timestamp that in the block chain.

Until then, I would suggest a little restraint, because as you have said to me, until it is peer reviewed you don't have anything.  If it is proven to be the case that you don't have what you claim, even for legit reasons or oversights, then you are going to have a severe case of egg on face if you don't apply a little humility.

Also you are mis-quoting me, I said its not possible to do 100,000/s of micro transactions on a block chain, that statement may not apply to other architectures.

Translation:

Derp derp derp, this Fuserleer guy might be smart, but not as smart as me... derp derp derp, emunie sounds interesting, but my vaporware will solve all the problems with cryptos that those before me weren't smart enough to figure out... derp derp derp, don't pay attention to this Fuserleer guy and the almost ready to launch emunie, pay attention to me and my theoretical cryptocurrency which, while I can't reveal any details, will definitely be much better and faster than emunie in every regard... derp, derp, derp...

How does this function if you're releasing something as open source where people will be running their own custom clients?  Is it safe to say this relies on hard coded client level restrictions rather than protocol based restrictions?  Instead of relying on resources (51%) to attack the base protocol, you have a resourceless attack of people just modifying the client?  Am I missing something here?

If I do this in Bitcoin, I have to expend gigantic resources in order to make my decision or my decision doesn't exist, which by all metrics, I would consider a "vote".  Also, as you said, eMunie nodes are very cheap to run, you can create a huge number of Sybil nodes at the start of the network, then diverge your nodes from the real (but smaller) network and render it non-functional?

Please excuse me if this is ignorant but if there are no blocks how does one know when a tx is "confirmed" ?

How do I know there is not another tx around the corner that has an even highter consensus value that some of the trusted nodes just haven't seen yet ?

Is there a specific time that a tx needs to be on the ledger for so it can be considered confirmed ?
Is there a certain threshhold of consensus value that a tx needs before it is actually added to the ledger at which point every future tx will be disregarded ?

And if they started isolated from the main group, for whatever reason?

There are so many ways this can happen, the protocol must be able to recover from this position, otherwise you'll end up like Stellar... frantically searching for a new consensus algorithm while they run one validating node, because they cannot handle forks.


Blocks are votes (sybil proof votes at that) in a very real sense. New blocks added to a chain are a vote for that chain, plain and simple. Chains with the most votes win.


In fact, POW is a very robust solution to this problem, able to handle up to 50% byzantine failures, which is the highest I know of. In this thread you state that eMunie is capable of resolving up to (n/3)-1 failures, which is 33%.


Quite the contrary - the only reason I'm able to present these counter arguments is that I've been down this theoretical ripple a-like road, in a search for my own fast, energy efficient consensus mechanism. I hope to offer you some food for thought before you go to all that effort of implementation.

You can fix a lot of these problems; here I what I suggest:

* Throw away the trust model completely
* Make votes for transactions cost something (either POW, or burn)
* Handle forks

(n/3)-1 is neither a client nor protocol restriction, it is an information theory restriction.  

In all true Byzantine agreement solutions there has to exist a either a set of trusted parties that can come to a majority, or a leader ( a set of 1) has to be elected to decide for everyone else based on their inputs ( it should be apparent in both cases that (n/3)-1 applies to both as does f3+1).  In the case of non-leader solutions, that set can be a defined list that never changes, a set that is built from neighboring nodes, or a set that is deterministic from some globally agreed upon inputs.

Changes to the client, or protocol would do nothing other than cause those modified to fail, either immediately or some time in the future, as they would not be operating in line with everyone else.

Regarding the Sybil nodes you are forgetting about trust decay, and the need to replenish it to continue holding whatever position you currently do.  Nodes with high trust at day-0 will not have high trust at day-90 unless they maintain it, due to decay and possible network growth.  As I've said many times in the this thread, to do that has a cost, both in effort and financial terms.  But lets get into detail about what is required in a natural environment to build/hold trust in and the potential "costs".

For a Sybil attack to be able to gain enough trust for an adversary to be in a position of influence, no matter how many nodes you have, the collective network penetration of these nodes should be 1 to be the most efficient.

Network penetration of value 1 is defined as: all attackers nodes are connected to all non-SN transaction producing nodes (TXPN) at all times and that the attacker has an equal presence at all TXPNs as that TXPN has honest SN connections.  For example if all TXPNs have 3 honest SN connections, you need to have 3 connections there also, all coming from different nodes you own.

A penetration of 1 would ensure that all of your nodes have a 50% chance of receiving an endorsement, less than 1 means that some of your nodes are not connected to TXPNs, so the probability of that TXPN endorsing an honest SN instead of yours if/when it creates a transaction is higher, thus making it harder for you to build trust.

Generally the maximum penetration you could achieve would be around 0.8 in a natural environment, maybe 0.85 with a lot of effort.

Achieving a penetration anywhere near 1 in a natural environment will be very hard:

• logistics of ensuring the required amount of all your SNs are connected all TXPNs
• you wont know how many honest SNs any TXPN has, as nodes can change the default # accepted connections
• TXPNs coming online, going offline, rotating connections and all manner of other activities you can't preempt

If your network penetration is < 1, then you need more connections/nodes to ensure you are receiving a as many of the endorsements as possible to gain trust.  More nodes = more effort/cost.

Because you need connections to all present TXPNs in the network, the quantity of TXPNs defines how many nodes you will need depending on what each node can support.  In our tests, an SN with an i7 Intel processor can support 100-150 connections concurrently, perform work requests presented by connected TXPNs as its advertising a service, process ALL POW challenges from connected TXPNs correctly, and keep sync with the network.  A node of that performance with 100-150 connections is pretty much flat out and burning 100-150w of electricity, sounds quite costly, just like mining!

In a natural Sybil attack its worse than that, as attackers need multiple connections to all TXPNs to acquire a good portion of any trust being endorsed from these TXPNs, and these additional connections need to support the associated work that comes with them, as TXPNs do not, of course, know that you are the same entity.  By default 8 connections are accepted per TXPN, both inbound and outbound, so you need to hold at least 4 of those connections on all TXPNs at all times to get close to a penetration of 1.  Your nodes are doing at least 4x more work in the network other SNs, and so cost 4x as much to operate.  Any earnings from doing the work requested to ensure a chance of endorsement will be less than it costs you to operate them.

Finally he will have to foot the cost of operating those nodes in that manner for almost 90 days until he reaches peak trust, as before 90 days, he may not have enough influence to direct any conflicts in the network towards his preferred outcome.

Manipulated Sybil attacks, are much easier!  An attacker can guarantee a network penetration of very close to 1, because the attacker is also in control of the TXPNs making the transactions and can easily ensure that his TXPNs are always connected to one of his SNs.  Manipulated Sybil attacks are costly in fees though, but can build trust much more rapidly.

If they start not connected to the main group they can not make transactions for a 2 simple reasons, there are no transactions for them to process because no one has any assets to send, and if anyone does have any assets to send, the initial set of allowed counter-signers isn't present because they are on the main group.


A block is 1 persons vote, the miner who made it.  There can not be a majority in a set of 1, and I can come and change that "vote" at any time providing I produce a block(s) with a greater amount of work done.


Are you sure?  Who is presenting all these Byzantine failures that total 50%?  It is proven by people many times smarter than you, I and everyone else here that the limit of true Byzantine tolerance in any trustless information system is 33%.  Are you saying they are wrong?  That Satoshi has achieved the equivalent of faster than light travel in information theory?

Bitcoin gives the illusion that it is more tolerant than 33%, but it isn't, because its impossible as it is an asynchronous, anonymous system.



With all due respect, I'm not going to throw away 2 years of work on the say so of someone I've never even spoken to before 3 days ago.  This isn't theoretical work, as we've been actively testing this model for failures for 9 months or more now.

Just to clarify, Byzantine solutions can achieve 50% tolerance (2f+1) in certain environments, but those are generally trusted environments with many restrictions in place.

Distributed P2P network are not a trusted environment, so they can not achieve 50% tolerance.

How can the smaller group know about the main group until it rejoins it?

I maintain that unless you have a fixed set of ledger producing nodes, or a deterministic selection policy (which has its own set of problems), you must be able to deal with forks, because they will be inevitable.


1 block represents 25 BTC of hashing power, not one person. In addition, subsequent blocks placed on top of that block are *additional votes* for that chain.


Byzantine failures are basically misinformation, through whatever means. The truth in POW is the longest chain of work, and since a majority is >50%, POW can withstand 50% byzantine failures. That is the true genius of satoshi.


That is your prerogative, of course. I know it is very hard to look at your own work objectively, but it is also essential to do so, no matter the cost.

Slightly unrelated issue, and I'm not exactly a pro-IPO guy in the first place either, but how exactly is the eMunie IPO going to avoid the Satoshi stash issue I outlined here where anyone who can smash the order books down to 0 is a "trusted 3rd party" by default?

https://bitcointalk.org/index.php?topic=1162416.0

IPO/ICO would have to be limited to something like 1% per person max, and even that's not verifiable.  Since you're not anonymous, people's acceptance might be a bit higher, but if you had something like 10-20%+ equity, you can short your own coin, smash the order books to nothing, and ride off into the sunset.

I'm honestly surprised we haven't seen this happen in alt coins already.  Maybe it has but just wasn't documented heh.

...until hidden ASICs don't awake (or next-gen ones hit the market) and make last 2016 blocks orphaned.

This is exactly why its not Byzantine tolerant, as those hidden ASICs are the dishonest generals, and you only need 1 of them to undo each historic block.  True Byzantine tolerant systems shouldn't have to undo history to provide the tolerance, otherwise there is no tolerance at all.

I'm not going to endlessly debate Byzantine agreement relating to Bitcoin.  If you can't see why Bitcoin isn't by now, and don't believe that the model presented is secure due to your understanding, then fair enough, but I feel that we are going round and round in circles over the same argument.

The forthcoming economics documents address this issue and how to guard against it.

A single article covering everything would have been ridiculous in length, hence being split into relevant documents over time.

Transactions are not committed to the ledger until there is a majority vote on them by the currently selected and agreed group of voters.  Votes are final, so by effect consensus is too.

The ledger is append-only, so once a majority consensus between the set of voters has been reached, any conflicting transactions are simply ignored.

If a transaction is not agreed upon within 4 vote rounds (30 seconds each) from its declared timestamp it is discarded.  If it is presented after 4 vote rounds have passed since its declared timestamp, it is automatically discarded and to send those assets a new transaction would have to be recreated with a current timestamp and resulting hash.

No problem ;)

Thanks for explaining. I must not read anymore primers before my first coffee. I hadn't even realized that there are agreed upon voters. I though trusted nodes just sign and then at some point all nodes in the network will have gotten it signed by one of their trusted nodes.

Hehe no problem, perhaps I shouldn't write anymore high level primers either.  It seems to have caused more confusion than it was worth! :)

There has to be a set of selected nodes that everyone agrees on, otherwise you run into some problems if a majority of those nodes are offline at the time of a transaction, a majority vote can never be reached.

Perhaps I should amend the article to make that, and some other points more clear.

Fuserleer, honestly I would hire some academics to make a formal paper, or do it yourself if you think you are qualified.

The more you waste time trying to piecemeal the design to layman, the more confusion and the less certain you will be that you've caught every flaw.

Before coding, I was very focused on making sure the white papers were precise, so that coding can proceed from that which is well specified.

I really can't make a final determination on your design until it is fully specified with a mathematical model. That intended to be a strong statement of my fairness.

After the formal white paper, you can work on how to explain what is in that white paper to layman. Don't put the cart before the horse.

Yeah, I (mistakenly) thought that a higher level overview would assist those that are not as technical to have a general understanding and provide an initial look for more technical people until the paper is completed soon.  

Perhaps that is a good idea in a different arena, but here the audience is mainly technical to some degree, so all its done is raise questions, even if the general understanding is appreciated.

I have some academics in my immediate council, they aren't professors or anything of similar caliber, but they know how to write a paper so that is ongoing at the moment with guidance from myself.

I know a cryptocoin that was launched without a whitepaper but still became pretty popular...

This is the key to understanding how this can work in practice... How do you arrive at a consensus for who your consensus nodes are?

The hardest to answer Fuserleer topic so far IMO, let's see what the answer is:

This is quite easy to explain, and it is essentially a random set.

Remember endorsements, they are the key.  These are acquired through TXNs that produce transactions, and there is no way to predict which SN will get the next transaction as it is based on human behavior, and also depends on which nodes are connected to a TXN at the time of creation.

Endorsements are public, so anyone can see which nodes have been endorsed and when.   You simply use a set of the most recent endorsements to determine who the current consensus nodes are for a transaction at the time it was created (and if the time is forged, it doesn't matter).

This works, is reliable and robust for a number of reasons:

1  Only endorsed nodes that were included in final transactions, voted for by a previous set of eligible nodes are selected, so you have a reliable set that everyone can agree.  Consensus on the transactions results in consensus of a future agreed set.

2  Providing that the selection set is recent, then you have a very high chance that those nodes are still online and that they will be around to take part in the consensus process.  Thus you have a reliable majority available.  Only in rare edge cases would a majority of those nodes have all suddenly gone offline.

3  You are still able to calculate what the majority trust value should be, as you'll be able to easily calculate what the portion of total network trust is that those nodes control.

4  The same probabilities and information theory limits apply no matter set size, whether it be all the nodes in the network, or a handful.

The trust consensus is similar to other attempts in a few ways, but this is (as far as I know) the only one so far that has a agreeable, globally verifiable set of ever changing consensus nodes.  Most consensus algorithms have a fixed static set that is easy to attack (as you know who the nodes are going to be at all times), or it is a leader-follower set up which is not suitable for P2P systems.

The exception is FBA (Stellar), but I'm not sure if I 100% align with the philosophy of it, as having nodes pick their own consensus nodes raises a few flags for me.

What is the question here? :|  Or are you commenting on monsterer's question?

A service node would run a dedicated wallet for services, and any wallets the user might use on it for day to day activities are completely decoupled and separate.  There is no way to tie a SNID to a regular wallet on the same machine, as the addresses of regular actions are never public.

Only the address of the service wallet is revealed, and even then it is masked as a 12 byte ID

Ahem. You need to prove mathematically and holistically that is a random process and not subject to game theory. That is essentially the fundamental problem with PoS, its entropy is bounded unlike PoW where the entropy is external.

*sigh* please, for once, just read it for what it is and accept the general concept of what I am explaining.

In normal operating conditions it is random.  I am fully aware that this will not always be the case, but every time I try to explain something clearly, someone jumps in and complicates it.  If I was to explain something taking into account all the attack vectors, 99% of people wouldn't understand it.

Which do you want?

Sorry not meaning to be a pain. I think as you said, this is evidence that you can't discuss this piecemeal. There needs to be a white paper.

Hi TPTB/AnonyMint,

I bet some of us are actually happy with Fuserleer sharing/discussing "chapters" as he writes them rather than him holding them back until he finished writing the whole book.  Time may be limited once the book is finished - so any head start we can get to wrap our heads around the apparently radical solution to crypto that is "eMunie", the sooner we can support the nascent ecosystem when/if it launches.

One option for you and those wanting answers ASAP is to hold off reading the early deliveries until after the last delivery (when the details arrive in full).   That way both groups are happy: the read/discuss-it-in-stages types, and the read/discuss-it-in-one-fell-swoop types.

cheers,
- Wingspan.

p.s.  I've been a beta tester for 2 years almost, and while it is taking a long time, I think we're in for a wonderful treat - a gift from Fuserleer - a crypto that has a shot at replacing fiat for billions.

Two questions:

1) Is is possible that the eligible set of nodes changes so rapidly, that nodes with high latency don't have time to pick up on what the agreed set should be?

2) Doesn't this lead to an ever decreasing set of eligible nodes, since nodes will go offline and only nodes that are eligible are from the previous round?


You are aware of the fact that stellar's consensus was so completely broken that they had to resort to running only one validating node? The reason being that they were unable to deal with forks, which the consensus didn't expect to be possible.

1) No, there is a set interval of 60 seconds (which is also the transaction failure duration) where eligible nodes are valid.  So say that the time now is 00:01:00, a set of nodes are valid, at 00:02:00 a different set of nodes are valid based on the endorsements made in the interval 00:00:00 -> 00:01:00.  This should allow even the most latent of nodes to keep pace.

2) Hmm I'm not sure how you have come to that conclusion.  If nodes go offline, then come online again later, they will receive endorsements again, which will increase the eligible set of nodes again.

Yes I'm aware of that, the FBA algorithm is the replacement for that broken one.

1) I suppose it depend on what bounds the latency is under. I agree that 60 latency is hilariously long for nominal operations, but its always the edge cases which cause the problems

2) If nodes go off-line never to return, doesn't that reduce the set eligible set to 0 on the limit?

Regarding FBA - I thought that was the broken design, not the new one?

1) It would have to be a really bad day for the internet globally if all of the eligible nodes at any time are seeing latencies approaching 60 seconds.

2) Eventually yeah, but then that will likely also mean the network is dead and there aren't any client nodes coming online to make transactions either.  Same as if all the miners went offline never to return.

1) Of course, steady state you don't expect to see latencies like that, but connection interruptions and crashes do happen. How does a crashed node, which has been disconnected for, say 1 day know how to resync and who the correct nodes are to listen to?

2) What I mean is that if you have set of N nodes, who propose future nodes M from the subset of N, nodes going offline will lead to 0 eligible nodes if M must always be a subset of N.

How does http://blog.cr.yp.to/20140205-entropy.html relate to the assertion that bounded entropy is bad? Bitcoin's reused R value attacks arise since it requires new entropy for each transaction, while with the curve25519 this does not seem to be the case.

James

Well, any eMunie client, new or offline for several days, can fully sync even when only non-service nodes such as a client only.  Some of the client only also have the full ledgers. I proved this by syncing a new client with just the client only faucet as the only active node.