 Apr 2024

arxiv.org arxiv.org

according to my entire history


arxiv.org arxiv.org

Every pblock with a payment in rcoins by a correct trader p ̸ = ris eventually approved or disapproved by an rblock [provided p and r are friends or have acommon friend in SG(B)]a.
Strange that you need to have a friendpath in order to use
r
's coins. I'd expectr
to accept&approve a message from me, given I hold his coin (which he can see from my message). 
An rblock b that repays a redemption claim with comment (redeem, P ), P =[p1, p2, . . . , pk], k ≥ 1, has a payment in picoins, 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 rcoins,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.

An rblock b with an empty payment and comment (disapprove, h′) pointsto an rcoin 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 selfparent chain of the "DISAPPROVE" issuer.

Given a blocklace B and two agents p, r ∈ Π, the rcoins balance of p in B isthe sum of rcoins payments accepted by p in B minus the sum of rcoins payments issued by p in B.
Great, so rbalance of
p
is derived by the history of ops regardingr
. So no need forp
to calculate it and add to every op, would be redundant. Not sure the derivation is the proposed protocol though. 
Finality: A pblock consumes a nonpblock b′ with a payment to p only if r approves b′.
Would be nice to have finality optional. As to not incur roundtrip to a possibly offline
r
. Doublespends will be detected and punished. Given the value of doublespend spend is less than a cost  no incentive to do so. 
consisting of rcoins, which can be thought of as IOUs issued and signed by r
Why do coins need to be signed?

The black agent mints a black coin, increasing its balance from 3 to 4 coins
Why to capture
4
? Ops likeburn(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? 
C
That looks messy, accidentally so, it seems.

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

Selfpayments are redundant.

Links other than selfparent and otherparent(s) are redundant. You can derive anybody's balance out of their selfparent chain.
3.1 Otherparent_s_ make the order of received messages ambiguous.
REPAY
is redundant. WhenREDEEM
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 thatREDEEM
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.


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?

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 outofservice 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 tobedetected 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 roundtrip to currency owner at their choice, a tradeoff that's up to them.

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?

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 Alicecoin Bob holds against any coin heldby Alice.
The device of Alice may be offline, e.g., smartphone discharged. We can't assume constant connectivity.

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?


arxiv.org arxiv.org

Minting: Each agent p mints (i.e. creates initial NFTs with)its own pcoins, as many as it pleases
An agent may create as many agent's coins as he pleases.
