> Justice. Also, there's no incentive for the honest party to not punish - presumably their software would automatically punish, and why go through any effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a $10 bribe might get someone somewhere to install hacked up software to be able to fulfill such a bribe, but even then i think it would be a rare person that would stoop to that. Were it to become a true negotiation, the cheater has more to lose, and therefore the bribee has a lot of leverage.
Justice isn't a strong enough incentive, it's too context-dependent, and in particular it's not something you could rely on if there is any financial incentive pushing the other way. Especially the ordering of events: if you have a counterparty who is malicious and they *take action* to steal, then they can present you with two alternatives one of which is more favourable than the other, if there is a bribe. It isn't *just* about logic I think, though the logic definitely matters.
These arguments about whether we could use 'mutually assured destruction' approaches (burn in particular) to make contract enforcement work have been ongoing amongst Bitcoin enthusiasts for a decade, I've always felt strongly that they do not ultimately work and haven't seen anything to change my mind (I seem to remember convincing Manfred Karrer not to use it in Bitsquare in 2014/15, but there've been many other examples of people proposing it and it never really getting traction).
> One thing I thought of regarding path coin, if there's ever a situation where there are multiple choices in path, whatever punishment there is probably needs to be able to handle the multiple of the number of paths.
Right, I briefly alluded to setting up with multiple paths - general idea is instead of only a->b->c->d->e it's possible to setup the n-ary tree, so a can go to all of b,c,d,e etc., but the problem is the factorial blowup that you get even if you restrict to no-revisiting (or exponential otherwise). For the toy example of 5 participants though, it is entirely possible to build the matrix as illustrated in the gist, but it's an N^2 matrix duplicated for every change in the path, here's the simplest possible extension of the base case:
path 1: A B* C* D* E*
path 2: A B C* D* E*
path 3: A B C* D* E*
path 4: A B C D* E*
path 5: A B C D E
path 6: A C* B* D* E*
path 7: A C B* D* E*
path 8: A C B D* E*
path 9: A C B D E*
path 10: A C B D E
The * would indicate pre-signs (and this whole list is branches in the taproot output of the pathcoin); this setup *only* allows one alternate path (second C instead of second B) for the coin.
If A chooses to pay B (not C), then: instead of only giving B an adaptor on path1 and signatures on paths 2,3,4,5, A would also have to give B adaptors on paths 6-10 as well. So it's easy to see that if you kept adding branches for every possible spending path A->E with no revisits you have like n^2(n-1)! (maybe not exactly; something very similar).
(Notice: though there are multiple paths via which A can cheat, they all reveal the same adaptor secret (and they're all the same coin) leading to the same forfeit of fidelity bond, see gist for the nice way you can always have it so that a single fidelity bond goes to the honest owner).
All of this is predicated on the idea that the participants do *not* coordinate at all after the initial setup; only a data transfer from payer to payee. A pretty massive restriction, of course.