A World of Trust – eMunie Consensus Primer

[Fuserleer]

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.

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

Yes 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.

[1715261533]

1715261533

[1715261533]

1715261533

[1715261533]

1715261533

[1715261533]

1715261533

[1715261533]

1715261533

[TPTB_need_war]

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 vector.

First, there are no blocks!!

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

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.

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.

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 propagate telling each node which of each set of transactions (amongst each double spend set) are the "first seen" transaction.

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

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.

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

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.

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.

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.

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.

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

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.

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.

[Fuserleer]

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.

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

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.

[monsterer]

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.

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?

[Fuserleer]

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

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.

[Fuserleer]

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.

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?

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.

[jabo38]

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?

[TPTB_need_war]

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.

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.

[bitsire]

Then I will delete this post and not reply further at this time.

+1

[Fuserleer]

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?

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

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.

[Fuserleer]

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.

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.

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

[Fuserleer]

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.

Please edit your last reply to me and requote my post with the sentence I added:

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

And if necessary adjust your response. Then I will delete this post and not reply further at this time.

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

[TPTB_need_war]

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

PoI is one of the most complicated consensus mechanisms in crypto created by real published academics.  Stellar also has real academics working on their consensus mechanism, but it works in a completely different way so it is hard to compare.  



For an in depth explanation you can read the technical report in chapter 7.  http://nem.io/NEM_techRef.pdf

[monsterer]

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?

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.

[TPTB_need_war]

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

[bitsire]

Then I will delete this post and not reply further at this time.

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 

[Fuserleer]

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?

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.

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.

[Fuserleer]

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

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.

[TPTB_need_war]

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

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.

Then I will delete this post and not reply further at this time.

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 

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? 

[Come-from-Beyond]

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