Quote from: smaragda on August 24, 2015, 05:29:41 AM

Quote from: Fuserleer on August 24, 2015, 04:01:53 AM

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?

Oh boy... it's happening again... two spaces after periods & cannot with a space... BCNext is that you? Shocked

Edit:

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!

Quote from: Come-from-Beyond on August 24, 2015, 08:50:01 AM

Quote from: monsterer on August 24, 2015, 08:30:53 AM

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.

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.

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.

Quote from: r0ach on August 24, 2015, 04:10:44 PM

Quote from: patmast3r on August 24, 2015, 09:33:37 AM

Maybe we should all just wait for the ledger discription.

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.

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