3 Matching Annotations
  1. Apr 2024
    1. 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.

    2. 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.
    3. 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.