This can be made impossible by spending the money on this wallet and not including this transaction. On block N the attacker broadcasts a transaction which spends all money from his wallet, but doesn't include it in his CB, using 1 CB "grace" period. On block N+1 he announces and includes 10 transactions involving money on the same wallet. The honest guys can't include them since they already confirmed the money spent, and the bad guy wins by 9 transactions. If you didn't observe this happening and you just see the blocks, you can never tell whose version is honest.

Imagine the CB is signed continuously, with every TB. There is no way to withhold a TB and announce it later: this would create a discontinuity easily observable, and the attacker will have to deny his own signatures. There is no way to drop TBs: everyone knows it has just arrived and the evil guy has it, so if he ignored it it's a fraud.

Then you'll have to explain how the attack works, under the new set of assumptions, namely: the broadcast delivery is guaranteed in bounded time and everyone is constantly online. Or wait for the system to be implemented and try to implement the attack. At this point I don't see such an attack.

Things are as not as simple, because if we count the branch with more transaction as the honest one, then the attacker can introduce his own transaction which wasn't broadcasted, and win. So in practice you don't know whether it's a transaction which has been dropped or added by an attacker. The time limits resolve this.

The proposed resolution of this is by timing. If you introduce some precise time windows when a message must be broadcasted, then the nodes who are always online can decide whether the protocol was followed. The protocol can be modified such that if an SH decides to not include a TB in his CB, he must declare that immediately at the time of that TB. In this way CB is built continuously and not just decided last minute, so there can be no surprises at the time of CB. Therefore anyone who observes the process can decide if TBs are being withheld or being dropped dishonestly. Etlase2 had a more elaborate solution above.

True. But the ability of the honest always-online node to see through 51% attack with just passive observation is already a good start.
Still the assumption of guaranteed broadcast message delivery must be taken.

I guess this kind of activity is a crime in most countries, so if someone lost real money with that they could put the guy in jail, theoretically.
From the moral point of view, I think it's not a huge problem. The people with significant value in their bitcoin wallets should be already smart enough to not get caught, and the minor losses of the losers are the payment for the basic security lesson.

Could you elaborate a bit more? A bitcoin-like setup is not scalable, because it forces each node to have a complete view of the entire system. If the transaction rate will increase above certain level, the bitcoin network will begin to drop transactions massively. See https://en.bitcoin.it/wiki/Scalability . For example, the network at the moment could not possible handle every transaction on mtgox, since the maximum rate is 7 transaction per second, while mtgox does about 30.

Each could declare the maximum single transfer amount that they wish to risk. A millionaire says he would risk 100$, while I'd say no more than 1c. Then we start transferring the money 1c at a time
And yeah, this works only with the arbitrarily divisible things, like money. No way you could buy an item with that approach.
What this system could give is some more insurance so that the people will feel somewhat safer and willing to risk more money than with the completely untrusted "you send first" exchange. Still the safety and efficiency is nowhere close to a centralized exchange.

The problem could be mitigated in the same way the untrusted exchange is made safer now: by splitting the transfer into chunks of size which is negligible to both parties. This would create a heavy load on the system and very high transaction fees though.

That's an assumption. When you're the second party, you don't want to bet your money on propositions like that (I wouldn't), and actually on the rational behavior of the other party as well (but that's a pitfall of the whole approach even if it was perfect othewise).

Now consider B = scammer.

He gets nothing. The first user will not send anything, of course. If you propose a different scheme than what is described at that website, please explain it more.

The utility issue that you pointed out is another valid point, albeit weaker.

The idea is flawed, because it's possible to make the other party lose more.
At this point you destroy the money, and whoever took the deal loses twice as much. This way a wealthy scammer can suck the money from the poor, increasing the gap between them further. So it will not work, a rational agent should never accept the deal.

I wonder if he can deliver even that. With his nickname I have serious doubts about his ability to produce Windows binaries

They aren't. They can only decide the truth for themselves.

I think this is a step forward already.

If we assume reliable propagation of the broadcasts within a certain time limit, then the nodes who are online continuously can indeed distinguish the honest chain in that attack. At the time of CB, they will know who was really on time, i.e. whose TBs appeared within allowed delay. If somebody withholds their TBs and at CB time claims that the others were late, the always-online nodes can compare that with their historical records. If somebody doesn't include the TBs of others, the always-online nodes can check if those TBs were broadcasted in time, in which case the party who omits them is the wrong one.

Some problems still remain with this attack:
1) The assumption of reliable time-bounded propagation. This can be disturbed in various ways by the attacker.
2) Race conditions with the timeouts. The malicious peers can release the critical information when its time is running out, in this way dividing the opinions of the observing nodes. Some of them will believe the message is late, others that it was on time. This confusion potentially will open possibilities for other attacks.
3) The nodes which didn't observe the attack, and only see the resulting fork, will still not know whom to trust. Both parties will claim that the other didn't release their TBs on time or didn't accept legitimate TBs which were released on time.

Let me recap what I understood so far about the attack resolution.

We (the honest people) know that there is a fork. Suppose we also know that it was created intentionally (although this point can also be attacked). We also know the two sets of peers who disagree. Each party claims that the other didn't sign in time, or didn't sign the right thing. We keep both, as opinions. They must be synchronized to some extent, otherwise we will observe one of them doing something strange, detect the fraud and dismiss their branch (algorithm pending). However they will not be fully synchronized, since in their respective branches they didn't loose the money while their adversary did. So the branches will gradually diverge. But everyone will be cautious to accept the questionable money from the disagreeing peers, because their branch can be eliminated at any time, so the divergence will not be a big problem apparently. It will load the systems though, because they all need to check everything twice for both branches.

The problem, as AnonyMint has already stated, is that there seems to be no way to end the situation. The malicious peers may keep creating branches until they become unmanageable.
I understand the "trusted party" proposal, however it's not a solution because the trust is not formalized within the system. If we are to accept trust-based resolution, then the whole security of the system relies on this trust mechanism, therefore we need to look more into that. BTW there is a proposal for trust-based coin on this board already, it's called eMunie.

Yes I also had this idea today. It's even worse than a single attack. The evil cartel doesn't need to make a visible "disaster" by dropping a lot of people at the same time. It will just chop them off in small batches, each one too small to be "heard" by the masses.

To me it's ok if he doesn't want to discuss the algorithms. There may be many legitimate reasons to do not disclose everything yet (he may try to patent it and so on).
Having no algorithm is another matter, however.

So the users will have to make this decision themselves? By this you admit that you don't have an algorithm to resolve the fork, and rely on human judgement to defend against the attack. In other words, you admit that your system is insecure.

It could be nice if you put the main mechanic in the OP.

What if the user doesn't have any honest friends? I don't have any honest friends in bitcoin. I have no idea how to even approach the problem of finding them.
What if the honest friends are on different branches? What if they are offline? What if they, like me, have no idea what to do and they just look back at me in hope I will somehow point them to the right branch?
No, that doesn't answer any security question. It's like saying that you have to check bitcoin branches manually to spot someone reversing transaction.

It is until the algorithm to choose the best chain is written down and analyzed. So far we have a "largest consensus" rule, which I've shown to be insecure.

Consider the dropping SHs 51% attack above. Why is it going to be rejected? No oracle merchants are allowed in the algorithm, sorry

Well, in bitcoin forks are clear as day: when a node receives two block broadcasts with different blocks pointing to the same parent. The algorithm chooses the chain which will eventually get longer. Merely detecting the fork and then offering the user to choose is not a good solution, since the users will not have enough information to make the right decision.

But do you want to discuss your proposal? In particular, the security proofs.

In response to what I've said, you mentioned
This is not a good answer to the proposed attack. You say that effectively this creates a fork and everyone is free to accept either branch. This is similar to saying that in bitcoin there is no 51% attack, users are free to choose a shorter chain if they prefer. It's simply not true. It's not the users, but the software in their wallets who will decide which chain to accept, and since it's the same program for every wallet they will all choose the same thing, given that they perceive the same situation. So one of the branches will die immediately, and per your rules it will be the honest branch.

Now for the propagation. I think the rewards for propagation, no matter how large, will not improve the defense against the attacks. The incentives are specified within the system, assuming that it still works; however if there is a possibility to break the system and gain complete control of it, the successful attacker will claim all the rewards and more. Even if the incentives will be designed in such a way that it would be impossible to claim them after a successful attack, the future gains from the complete domination of the system would still likely outweigh any lost rewards.
In short, the incentives cannot be used as a security measure. They may serve a role to keep the system efficient, but when it comes to security, they will not guard anything.

I'm afraid this could be right. However, there is no hard proof so far. Perhaps there is an algorithm that decides which viewpoint is the most "honest", according to some reasonable definition of "honest", even if only a minority share it. Unfortunately, we didn't find it yet.

Ok, I'll have to study it really. I think, from the security standpoint, proof of ownership of a real-world thing is better than proof of something withing the system, as latter may be compromised.

Aha, I see. Now it makes sense. Indeed, if everyone propagates everything, then a honest node cannot be kicked out because its CB will always include all the TBs which have been broadcasted. So it's only possible to kick nodes out by hiding signed TBs. Interesting!

Ok. Now I propose the following 51% attack. Malicious peers, who are the majority, withhold their signed TBs just until next CB. At the time of CB, they will be considered late and their TBs will not be included in the honest nodes' CB, which will therefore have 49% consensus. Right after the time of this decision, the attacking cartel releases their CB, which records all the honest nodes as dropouts, and therefore has 51% consensus. The other nodes, faced with the choice of two competing CBs both following the rules, will have to accept the malicious one. From now on, the cartel will have 100% power and will do what it wants.

Yes, I was considering the case when the cartel suddenly presents their version of history, which would then seem to be more legitimate than the accepted one, according to the rules. It may be possible to make a rule that a node would never revert its history too much to the past (kind of auto-checkpoint), but the new nodes, who don't have any history observed, could be easily fooled.

Let's consider proof-of-share first.
In that way it's pretty clear that the majority of signers can dictate the course of things, including extremely malicious ways: reverting transactions, dropping out other peers etc. If someone controls 51% of total number of peers who can sign, at this moment he can disregard the others, because his CB, whatever he puts in it, will have more signatures.
It follows that if at any point there is a majority in hands of a malicious user, he can kill the system at any point in the future. He can rewrite the history after this point, using arbitrarily many imaginary peers for the times after that, so that his chain of CBs will always have most TBs and signatures, and it will always have to be accepted by other peers as more legitimate.
Considering that the 51% shares situation may be likely at some early point, when there are not so many SHs just because not so much money has been generated yet, this seems very insecure overall.

I didn't study your proof-of-harddisk proposal yet, I'll do it a bit later. The name suggests that it's similar in spirit to PoW, just instead of a lot of computations you need a lot of storage. If my understanding is correct, then this will work out in a similar way to bitcoin, and thus offer the same security features.
I'll try to reduce the system to the bare minimum: some PoW (e.g. a proof-of-harddisk) is presented and then the peer can sign blocks. The key differences from bitcoin are: a) the blocks are standardized (definite time period), b) several peers can sign the same block and claim the reward. Again, the heaviest chain (with the most signatures) wins. Now the chain cannot be easily regenerated from start. It's still vulnerable to a 51% attack, however, in a similar way to bitcoin. Essentially this is like a mining pool built in the system, but one which forces every peer to check the transactions and try its best to come up with exactly the same block as the others (unless it controls 51%, in which case he does what he wants, like in bitcoin). I like it.

Sure it sounds more boring than the mysteriously complicated things described earlier, but I think this is what is really at the foundations of this system, as far as security is concerned.

I think you should be prepared to see it drop in price as soon as your backing is withdrawn. It will be so even for psychological reasons. The math confirms: from the point of view of an eMunie holder, while the backing is there, it can't drop below it, so it can only rise, and is therefore profitable to hold. Once the backing is gone, the game changes dramatically: the new bottom is 0. The profitability of holding is much less obvious. The new equilibrium will inevitably be lower.