> The security-correctness proof of bitcoin doesn't depend on "honest nodes reliably receiving all honest nodes' blocks". Actually bitcoin is simple in that it doesn't try to distinguish between honest vs malicious, the security argument just says with overwhelming probabliity that any colluding subset of nodes with >50% computation wins.

But only if those "colluding subset of nodes" can eventually be able to communicate with each other (and the users they are trying to collude against). Maybe you're reading too much into what I'm saying, but it's basically a variant of "If a tree falls and no one is around to hear it, does it make a sound?" That is, if the nodes can't communicate with each other, then obviously, it doesn't matter what they publish if the other nodes can't hear it.

----

> But transports are unreliable and systems buggy, and so this could happen anyways in a real run of the protocol.

It's true that it could happen, and the paper doesn't seem to account for this. But the general idea is that for an attacker to pull off a double spend, they'd have to reliably be able to create a fork for a long string of nodes. If the network has a single hiccup, it may give the attacker the ability to create a short fork, but it would quickly be resolved once the network became reliable again.

> Honest parties of the protocol have to be able to contact the leader by the normal operation of the protocol, so the attacker could just hook into this mechanism.

Yes, but they don't need to know that the slot leader is the slot leader to do so. He could be hidden within thousands of running nodes. How would the attacker know which one to DOS?

> More generally, these are not holes that one wants to leave untreated by the protocol, it can open up escalation / chained attacks.

Yes, I agree with you there. If an attacker found the ip address which corresponds to a large stake, by some means, then he could perform a DOS attack.

----

> When I say `sort | head -n1` I don't mean "also prefer longer branches", I mean only `sort | head -n1`, unconditionally on all fork-points. Assuming honest nodes can all reliably broadcast (which the paper does, even explicitly on page 16), this is enough to achieve the "unforkability" property. (The attack you mentioned wouldn't work because the longer branch would still be ignored.)

If I'm understanding you correctly, than this would make it even worse! Suppose at block n+100, an attacker made a fork at block n. If the attacker's branch of length n was determined to be "better" by the sort algorithm than the branch of length n+100, then the system would reorg in favor of the attacker, and 100 blocks would be lost.

> I agree the former is overkill, but the security assumptions of "forkable strings" don't handle the latter case, it assumes it's already handled.

I don't understand why your "sort | head -n1" algorithm would work, so I can't follow this to your conclusion.

Are you assuming that no node could go offline at any time?

---

You have a point about buggy networks, and there is an attack vector of an adversary performing a DOS against an honest node, as we talked about beforehand.

However, I doubt these considerations would have much of an impact. First, in order to double spend, you'd need to reliably be able to maintain a fork.

Second, you haven't mentioned is covert vs overt attacks. If an attacker was to sign two different blocks, the network would quickly be able to determine this as foul play. Since the attacker's stake is associated with the blocks, it would be trivial to punish an attacker severely, by destroying his funds. So, if we eliminate cases where the attacker signs more than one block, then his chances diminish substantially.

So, I do see the proof doesn't consider some circumstances, but I think they are rare enough that it wouldn't be an issue in the real world.