Questions about AT2

Premer said that

Blockquote The Elders check the logic, that sufficient funds exist and that the Client’s signature is valid, and then each sends back a signed agreement. The Client collects these signed agreements and once a quorum has arrived (say 5 out of 7 Elders agree) sends them back to the Elders. The Elders now see a valid message “Please deduct from my account the sum of X” and carry out the command.

DBC, I think, consists of mint (or bank/elders), spendbook and blind signatures.

Clients can hide the contents of their DBC with their signature and get Mint’s signature. So Mint doesn’t know what the DBC is. I think that anonymity keeps the DBC’s sender, recipient and content unknown. If I’m wrong, let me know. If it is correct, the primer’s “sufficient funds” and “Please deduct from my account the sum of X” appear to be incorrect. Because elders cannot know the contents of the DBC. So it looks like it hasn’t been updated.

But sn_dbc/decode.txt at master · maidsafe/sn_dbc · GitHub and sn_dbc/reissue_ez.txt at master · maidsafe/sn_dbc · GitHub said that DBC consists of id, amount, output_number, owner, inputs and outputs. I don’t think the Elders can know amount of DBC. Is that right?

  • Q1: so, how can we prevent double-spending when reissuing and splitting the DBC?

But Digital Money and DBCs • said that

The way to secure a Mint against this was usually to have the user provide many different blinded DBC candidates for signing, then the mint randomly requires the user to prove the content of all but one of those candidates, and then signing the remaining DBC if all other candidates were valid.

According to this, it looks like Q1’s double-spending can be resolved.

  • Q2: I would like to know if safe network actually checks the honesty of the clients in this way, i.e. prevents double spending.

  • Q3: From my understanding, DBCs seem to use a way of passing DBC directly to others, rather than managing the ledger, i.e. global state. If so, senders should transfer the DBC only to the receivers, rather than broadcasting on the blockchain. Then, because of anonymity, should Mint transfer the DBC without knowing the sender and the receiver? How?

Thanks.

6 Likes

atm we don’t use blind sigs. We do obfuscate output keys though. We are considering bulletproofs to blind though. At the moment though we don’t so the mint sees the input dbc amount owner and out put amounts.

With bulletproof or confidential transaction type here we would do the same as now. So how this works is the client can mint a dbc as many times as they wish, inputs hash and outputs hash make up the spendbook entry. The output Dbcs are valid when a spendbook entry exists for the input dbc(s). On receipt of a dbc you check the parent was spent and the dbc you have is in the output dbcs of the spendbook entry. Only you know the actual owner of the output dbc (you) then you can spend it by signing the re-issue request.

9 Likes

Thanks, I need to study about this:

1 Like

If you have an hour this vid is the best I have found for quick explainer. The guys approach is really easy to follow 18. Confidential Transactions - YouTube

8 Likes