15 Matching Annotations
1. Apr 2024
2. arxiv.org arxiv.org
1. according to my entire history

#### URL

3. arxiv.org arxiv.org
1. Every p-block with a payment in r-coins by a correct trader p ̸ = ris eventually approved or disapproved by an r-block [provided p and r are friends or have acommon friend in SG(B)]a.

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).

2. An r-block b that repays a redemption claim with comment (redeem, P ), P =[p1, p2, . . . , pk], k ≥ 1, has a payment in pi-coins, i ∈ [k], provided the balance of r does notinclude any pj -coins for any 1 ≤ j < i at the time of creating b, and has a payment in r-coins,r /∈ P , provided the balance of r does not include any P -coins at the time of creating b

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.

3. An r-block b with an empty payment and comment (disapprove, h′) pointsto an r-coin payment block b′, where h′ points to the reason for disapproval: To b′, if it isunbalanced, or to a block b′′ equivocating with b′

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.

4. Given a blocklace B and two agents p, r ∈ Π, the r-coins balance of p in B isthe sum of r-coins payments accepted by p in B minus the sum of r-coins payments issued by p in B.

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.

5. Finality: A p-block consumes a non-p-block b′ with a payment to p only if r approves b′.

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.

6. consisting of r-coins, which can be thought of as IOUs issued and signed by r

Why do coins need to be signed?

7. The black agent mints a black coin, increasing its balance from 3 to 4 coins

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?

8. C

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.
9. and the red agent acceptsthe payment, increasing its balance to 6 black coins.

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

10. The black agent approves the payment

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.

11. decreasing its balance to 2 black coins

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?

12. Agree to redeem any domestic coin issued in return for any foreign coin held. Forexample, Alice must agree to a request by Bob to redeem an Alice-coin Bob holds against any coin heldby Alice.

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

13. eachpricing their goods and services in terms of their own personal coins. Next, assume that every two villagersexchange 100 personal coins with each other

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?

#### URL

4. arxiv.org arxiv.org
1. Minting: Each agent p mints (i.e. creates initial NFTs with)its own p-coins, as many as it pleases

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