Strange that you need to have a friend-path in order to use r's coins. I'd expect r to accept&approve a message from me, given I hold his coin (which he can see from my message).

Why have signed coins?

Makes it possible to track which coins been equivocated.

But what's the use for it?

What's the difference between "you can't use these specific coins as they were equivocatedly used already" and "you can't use these opaque coins, as they are in equivocation"?

Later, at least, may succed given equivocation issuer have enough balance for both. Although then there's no point in creating equivocation in the first place. So nevermind, won't happen, except by silly equivocators.

Again, this can be derived out of DAG. Seems redundant.

It would somewhat spare computation, as one can check equivocation by following a pointer, but then he would need to ensure that both equivocated blocks are observed by a self-parent chain of the "DISAPPROVE" issuer.

Great, so r-balance of p is derived by the history of ops regarding r. So no need for p to calculate it and add to every op, would be redundant. Not sure the derivation is the proposed protocol though.

Would be nice to have finality optional. As to not incur round-trip to a possibly offline r. Double-spends will be detected and punished. Given the value of double-spend spend is less than a cost - no incentive to do so.

Why do coins need to be signed?

Why to capture 4? Ops like burn(10), mint(1) do the same, yet being more semantic, as they convey what happens, rather than the result.

E.g., when green has 3 green_coins, and we see send(1, green_coin, (to) black), send(3, green_coins, (to) green) did green just miscalculated his balance (should be 2), or did he sent and minted one at the same time?

That looks messy, accidentally so, it seems.

1. Green agent only needs to REDEEM(green_coin) op to convey what he wants.

2. Self-payments are redundant.

3. Links other than self-parent and other-parent(s) are redundant. You can derive anybody's balance out of their self-parent chain.

3.1 Other-parent_s_ make the order of received messages ambiguous.

1. REPAY is redundant. When REDEEM is received, and given one can indeed redeem (recepient has his coin at the moment of receival) - the REDEEM should be automatic. I.e., plainly observing that REDEEM been accepted by recepient is enough to derive out of it one of 1) it's a suffessfull redeem 2) it's a failed redeem.

Why does he need to explicitly accept? Can't it be done by default? Can he reject?

Why does he need to approve? It is a mean of equivocation detection. But it requires all coins going through its creator. Incurring latency and possible indefinete out-of-service as creator goes offline.

Why is it not optional? Like we can exchange coins with recepient directly, and he may come to redeem it later, if he wishes, detecting eqiuvocation at that point.

Some services, that offer say a cup of coffee, would be willing to take the risk of loosing $5 of value on to-be-detected equivocations. Since equivocators will be punished severily that does not worth 5$ of value. So they can be rest assured that nobody's gonna do that.

Now this example holds if coffee provider prices in currency other than its own, say bank's.

And banks are generally online. But still. Why force it? Let them do a round-trip to currency owner at their choice, a tradeoff that's up to them.

Why does red agent need to issue pay to itself?

What red agents holds after he transferred 1 black coin can be derived from history his ops.

We can't trust what he issues, he may issue to self 1000 black coins. So we'd need to go check history whether he computed it right.

But then again, if we need to do that, why issue an explicit payment to self?

The device of Alice may be offline, e.g., smartphone discharged. We can't assume constant connectivity.

Pricing in your own coins means personal coins may not match in value behind them. One may offer a cup of coffee for 1 coin, another for 5. Simply exchanging 100 coins with each other would mean one'll get 1/5 of value from this exchange. So 1:5 exchange would be needed. But how to know that in advance?

An agent may create as many agent's coins as he pleases.