Spentbook

Features
41

There is no need to make this into more than it is. I’m just casually trying to come up with some sort of descriptive analysis of de facto existing English phenomena. “School teachers” go on about normative grammar, i.e. about what’s “correct” or “incorrect”. That is something completely different. Also, morphology and syntax are very different from semantics or meaning, which I haven’t really touched at all.

Please don’t be. Seriously. I’ve studied, worked on and thought about this kind of “soft science” stuff for decades. I just wish I knew more math and could write more serious code. I can’t, so I sometimes feel like a bit of a schlemiel here, but that’s life. I shut up and listen when the big boys talk, the same way I do when a professional fisherman talks about fish.

2 Likes
42

Thanks for the clarification, but this now has me confused. Is there a graphic somewhere that shows the difference between a client issued dbc, the client writing to the spendtbook, and where the mint gives seals of approval? A simple block diagram is worth a thousand words here.

1 Like
43

Not a diagram but here goes

  1. Client prepares his input and output DBC’s - the transaction
  2. These are written to spentbook
  3. Now the client sends the transaction to mint
  4. Mint confirms these inputs are to be paid to these outputs
  5. Mint signs the outputs

So the mint can sign the outputs as many times as it wishes as they have the parent of the input and can only have come from there.

When spending an output then it’s the same, check parent is spent, check this is written to spentbook and sign the new outputs. So signing the outputs can be repeated, if signing fails then just go again. The spentbook locks the transactions and prevents a double-spend, but the client enforces this on himself. The mint just confirms this and signs the outputs.

9 Likes
44

I thought there was an option to revoke or reissue by including oneself as a recipient?

I see what you mean though about a unit transaction…

I get it. spent. semantics. From a practical point of view I don’t see why anyone would create an offline dbc they did not have the ability to revoke and reissue should the intended counterparty change. The same might be true for some online transactions too. It doesn’t feel like a “spent” until the dbc has been physically transferred and reissued by the recipient to not include the original owner.

45

Maybe it could be called something like ‘commitment log’ or just ‘Tx log’ to avoid the spend/spent confusion

2 Likes
46

There really is no confusion, as far as I’m concerned. And I hope my philosophizing didn’t contribute to creating any.

47

So the spent comes from the parent being spent (into the new DBCs) - correct?

48

Yes, the parent of the input DBC is Spent and this SpentBook entry is written. This makes the output DBCs locked. So the output DBCs must be signed and transferred and can not be changed.

You can think of it as the sender has locked their funds to the receiver. If he does not transfer them he loses them, i.e. the input DBC is spent at this point, it cannot be used for anything else and the output DBCs are committed to the recipient.

5 Likes
49

So the idea of the sender undoing the spend is not possible. The reason I ask is that it is not uncommon for people to arrange their payment and all set to send their $$$ but something crops up. The courier does not deliver to rural even though the place is in a suburb they supposedly deliver to. Or any other reason.

If it is not reversible or recoverable then people/shop software will need to be written that the spend is the last thing done ALWAYS.

But I gather if the receiver has not been set then the person simply does another spend with those child DBCs either back to themselves or use them for something else.

But if receiver is set in the DBC then I guess its lost?

2 Likes
50

Yes, these are not recoverable in the same way as handing over cash. So any recovery would have to be done in the same manner, i.e. refund for goods not delivered etc. But the sender can’t reverse the transaction, it’s like s/he handed over the cash.

4 Likes
51

Is there a revoke mechanism planned for the future?

52

I was actually meaning before sending the DBCs. I was not clear enough. I realise once its sent that is it.

  • so the person spends the parent into 2 dbcs - 1 back to themself and 1 meant for handing over
  • the sale does not go through so nothing was sent to the other person.

Is the 2nd dbc lost or able to be redirected back to themselves to be spent elsewhere.
OR do all DBCs have a receiver coded in (always)

53

I hope not really. Reversible transactions to me at least are a red herring. If you pay by cash or credit card, it’s not the same $bill you get back and in this case I feel the same, refunds should not be part of payments. I think it’s debatable, but I see payments as something that must terminate and refunds as a separate process, usually involving legal etc.

Smart contracts again I feel are separate and just a trigger for payments, but also refunds should be able to happen. I think the crypto world is a bit confused in these areas and if we can divorce payments as a pure transfer of money for X and have refund as a separate process then we are in a much cleaner situation.

At the point of writing the SpentBook though the sale has gone through. Otherwise don’t write the spentbook.

I see it like this

  1. Agree to pay X for Y
  2. Sender writes spentbok and transfers DBC
  3. Recipient concurrently (or pre/post payment, whichever is the agreement) sends Y

If either party is not happy then Y is returned and the vendor should refund by doing another mint reissue for a DBC back to customer.

The finality is a weird one to grok, but paying for something and try to reverse is like posting something and trying to stop that and reverse it too? I am not sure why we feel reversing a payment is good?

The world seems to perform such transactions without a requirement for reversibility of the actual $bills in cash, but does work well with refunds.

Perhaps I am missing something, but I feel to pay means to pay, to refund means to refund, but they are separate transactions.

11 Likes
54

I see how the finality of the spentbook offers great simplification and eliminates the double spend issue. I think the issue with the refunds is more a matter of perspective on how I was viewing the spentbook entry in practice.

I do see your description as one of using cash. There is a pre-approved agreement, the cash is given irreversibly, and what ever goods or services are also reciprocated irreversibly. A lot of trust is required in this transaction, or trust in an external authority that will help you get your funds back if the seller is a liar. Sometimes an escrow can help build trust. But yes, all separate atomic transactions.

My confusion arose based on forum readings. I was viewing the spentbook from the perspective of writing a bank check/cheque. When you write a check to a named individual, you have until the named individual “cashes” the check to reverse the process and secure your funds if the seller pulled any shenanigans. Sometimes you might write a check to someone only to later learn that they sold the product to someone else, so the check is destroyed and you haven’t lost any real value.

1 Like
55

I don’t think so, at least not for the base layer of SN Token.

David where was it you said a Network Agreed Logic could be built from? I half remember maybe the number and type field you were advocating for in DBCs?

If we can build some NAL from those then smart contracting could allow for some more sophisticated stuff transactionally.

Also @jlpell i think we’ve talked about two party escrow, where the mutually assured destruction of locking money in a 2/2 multi-sig transaction can mean in most cases each party will act in each other’s best interest.

So having SN Token spent in this 2/2 multi-sig way could mean partially solving what problem you see people having within commerce, I think.

4 Likes
56

Thanks for the clarification.

Yes, agreed for base atomic operations. I was getting ahead of myself a bit with the higher level day to day “payment” musings.

2 Likes
57

Yes, I was looking for a type field that could be used for basic smart contracts and a reason field, i.e “I am sending X coins to Y for service or goods Z” and using that as proof of payment etc. We have gone a bit sideways though in recent weeks to get complete unlinkability and privacy, so these things need to be reconsidered.

The 2 main points right now we need to solve is

  1. Proof of payment
  2. Farming

2. is kinda solved by 1. but with full privacy we need a way to prove to others something was paid for and this is true for farming also.

One simple idea for farming is: (cc @danda ) and it’s perhaps not great.

  1. On upload the user pays each mint node (elder) X to store Y chunks.
  2. Each elder takes the payments and signs the data
  3. Client aggregates sigs and can now store the data

Problem:

Adults are not paid

Possible solution:

We assume that the supermajority of Elders Are honest and this is important. So when an Adult is to be relocated ot rewarded (thx @neo ) each elder pays that adult a portion of the Elders earnings this session.

That means elders will pay different amounts, but all relative to the elders time in the section.

It’s sketchy right now, but this allows for private transactions and honest elders to pay Adults and do so without syncing with each other (which is a very nice property to have as sync is a nightmare).

Also in this vein, we can remove sync of store cost from the Elders (which is another nightmare). It would be like this

  1. Each elder calculates what it sees as the number of Adults and how full they are.
  2. This gives this Elder a store-cost.

Now we change the storage mechanism above change from

1. On upload the user pays each mint node (elder) X to store Y chunks. 
2. Each elder takes the payments and signs the data
3. Client aggregates sigs and can now store the data

to

  1. Client sends each elder a storecost request for storing Y chunks
  2. Elder signs reply with a cost
  3. Now client executes the above block paying each elder the storecost they ask for (iff the client agrees the elder is not trying to inflate costs)

For pt. 3 As the storecost is signed and if a client suspects fraud, they can send that Elders StoreCost to every other elder. That allows us to find rouge elders trying to inflate storecost.

In any case, this is the kind of thing we are playing with right now. I know I have said we had all the tech worked out, but this is a bit extra as we advanced DBCs to be fully fungible and private, or at least we think we have. There is still a fork of commitments and another of blind sigs, the latter being favourite, but not 100% decided as we need to work out how to do all the above.

5 Likes
58

For proof of payment (cc @danda) we could do something similar?

Process would be (buyer is A and merchant is B)

  1. A->B Here is a SpentBook entry that if it was written would give you the cash
  2. B signs a "payment proof identifying this SpentBook entry) and sends back to A
  3. A writes SpentBook

Now at this point it’s interesting. The SpentBook output DBCs are visible in SpentBook but not necessarily transferred to B So we have 2 main options

  1. A can send to B
  2. B can retrieve the spentbook output DBCs and ask the mint to sign them (again etc.) and therefore has them (note anyone can ask for the outputs to be signed, it makes no difference)

I think this works @danda and David Rusu?

3 Likes
59

The latter is being tested now, no? As a built in memo?

I think the direction danda is really advocating for is great. The unlinkability, fungibility, denominations really sets SN Token apart. I would still love to see the number and type field though because that opens the whole implementations benefits to a world of possibilities for building on top of the sn_dbc system.

You still think it’s possible but obviously and understandably not the current focus?

1 Like
60

Not yet in focus, but should be this week hopefully.

I do and think it is very likely too.

1 Like