Quote from: aaaxn on June 14, 2013, 07:24:18 PM

But what about these issues with missing TB?
What happens when SH from 1 to K signs TB, but SH K+1 releases his claiming previous K TBs did not arrive on time? And what if this (K+1)th TB contains transactions conflicting with ones in previous K blocks?
Blockchain does not have any data that would allow nodes to tell 'real' course of action and it would always resolve to some kind of voting between SHs?

Unfortunately, the situation here is not as well-defined. I've kind of gone back and forth on this, but honest CNPs will likely drop the section 2 TB data, wait until 10 honest TBs have come, then release the section 1 data so that the forking TB has no effect. If EvilCorp controls some significant amount of SHs in the same area of time, and controls a large percentage of the "trusted" CNPs--CNPs for whom non-connected nodes use as their view, EvilCorp could definitely cause problems. However, EC can't really use this attack to double spend, because anyone accepting a transaction is watching. If they see a block come that ignores the tx, they must wait longer. The longer EC waits before attempting this, the more people care about and have seen what is going on in between.

EC doesn't have to really convince anyone but the person(s) for whom it wants to dupe for this attack to actually accomplish something. After 10 TBs, EC must include the section 1s of the TB(s) it is attempting to reverse, or the counters for untrustworthiness are going to start going apeshit. If EC is trying to dupe someone out of a thousand, they might just wait around for a few minutes. If after a few minutes the tx has been confirmed and re-confirmed by 20 or so SHs, EC must deny 20 SHs per TB, resulting in an "untrustworthiness" counter that jumps by 20 each TB. If EC starts the reversal right away, the person being duped has no confirmation and sees a network split happening, potentially also seeing the bad/double spend in a later TB. This person will refuse the transaction at this point because it is obvious that a double spend is being attempted.

The larger the transaction, the longer you have to wait. And once EC does this once, everyone knows. A double spent transaction is provable, it's just not provable as to which side is honest.

Any CNPs that accepted the original TB in time but then are carrying the bad chain are provably dishonest for those connected to them, and perhaps provably dishonest to those who send the CNP's signatures around on these messages to other people that were watching at the same time. What this means is that anyone who sees it will remove all client-side reputation for that CNP. In fact, there might be a way to extend this further... hmm I think I have the beginnings of a really good idea about this, but I have to think more on it. But essentially, to get people to trust CNPs, they must provide a good view of the network for a long period of time. The client-side portion of these detection algorithms need to be robust. Since CNPs are much less anonymous than IP addresses, any time they perform this attack, they must create new CNPs and regain new trust all over. There might be a provable way to destroy their CNP deposits too, but I have to think on it.

However, the eventual resolution of all this is still murky. If there are no double spent transactions, it is rather easy, I think, but if there are, a potential algorithm must be considered to resolve it, or allow the network to fork on a double spend. EC could control 99% of the SHs, but almost none of the CNPs, and the fork will resolve on its own.

Also, this could lead to a very simple idea of "super CNPs" set up by trusted agencies for people who do not wish to be connected all the time. They could go to them for the answer when they are unsure. The super CNPs can be kept in check by anyone who is monitoring the network. These super CNPs don't even need to be anything other than something set in the client, voluntarily, by each user so that there is no centralizing attack possibility (the super CNPs wouldn't even know..). It is another layer of massive collusion that would be required to even attempt to fool anyone. I believe this is how ripple sort of works, but ripple gateways don't get paid and they hold IOUs like a bank. That would not be the case in decrits.