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

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

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?

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.

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.

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.

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

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? 

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.

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.

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

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.

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.

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

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

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

+1

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://bitcointalksearch.org/topic/fundamental-flaw-in-consensus-algorithms-1159691

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.

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?

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.