Update 28 September, 2023

Development Updates
21

This doesn’t feel right. Like burning paper money because someone attemped a bad thing, when the money is a useful tool which ‘belongs’ to the network.

If we can’t punish the behaviour, to me it seems better just to block it.

EDIT:

An additional concern is punishing innocent behaviour. I’m sure there are many scenarios but how about:

  • Accidental double spends. Such as a user who uses the CLI without realising double spend will lose funds, and for some reason does a transaction twice. There are many ways that might happen such as not being sure it went through perhaps due to connectivity problems, or accidentally choosing the wrong command from history etc.

  • Wallet bugs. It’s fair enough to say we want quality wallets but unfair for users to be the guinea pigs, and be punished for choosing a wallet with an unknown bug in it. I don’t think detection of bugs or malicious wallets should be designed to be based on punishing users. That can’t be eliminated but I think should be minimised rather than baked into the protocol.

Punishing innocent behaviour by design seems particularly questionable when you consider that the value of funds lost could be very significant for the individual concerned.

7 Likes
22

We can certainly help users, even at the CLI level. A check that should happen when sending money is

  • Is the parent SPENT only in one transaction
  • Is this SNT a child of that parent and not yet spent.

So if you have already spent money you should not try and spend it again as it’s not there.

These can be easily prevented if the wallet checks if the cash is actually there and not spent. Worse bugs would be sent all your money to bad dude. I feel we should not tolerate such badly coded wallets, ever.

Here though, that bad thing is

  • Send 1 SNT to persona a THEN
  • Send the same SNT to person B

That is intentional and the API and any code should make that clear to the user, that they are acting irresponsibly.

The paper money analogy would be

  • Photocopy an SNT
  • Send 1 SNT to person a THEN
  • Send the same SNT to person B

I suppose it all comes down to solid API’s and software doing the correct checks before sending SNT. As we are OSS folk could circumvent the API to try a doublespend and they will do that, but it’s definitely intentional and not human error IMO.

10 Likes
23

The implementation seems interesting but the name “CashNotes” is rather silly/goofy.

3 Likes
24

In the past when banks issued receipts for gold, those were traded and called ‘bank notes’. Along that line these are ‘Safe Notes’.

I’m still unclear though - how does this new term CashNote relate to SNT - does it replace it everywhere? Or is this just terminology for the network?

2 Likes
25

SaiNT

Like!
10char

1 Like
26

We all agree that is the aim and that in reality if a thing can go wrong it will go wrong. So we design defensively.

My point though is that we should design not to punish innocent users when things do go wrong. For the sake of what? Punishing the ignorant bad guy who tries to spend twice.

I still think it’s enough to block the attempt (assuming we can), because it removes a very nasty risk for innocent users and the bad guy just wastes their time. I don’t see much value in punishing them and destroying tokens in the process.

4 Likes
27

Not just goofy but inconsistent with the reasoning for renaming Safecoin to Safe Network Token.

Would it therefore be ok to rename the token Safe Cash?

1 Like
28

I think CashNote in still a placeholder and the final name will be revealed on launch.

1 Like
29

I’m not sure that’s the case because it was introduced to replace DBC throughout the codebase.

2 Likes
30

No, CashNote is not a replacement for SNT, it replaces the role that DBC played, or rather what it became:

It’s a structure that provides a spendable unique key along with related metadata, that contains an amount of Safe Network Tokens.

It can damage your privacy if this information is leaked, but it’s not spendable/stealable (by itself), as it doesn’t have your private key within it.

It’s like a verifiable document that is generated when a financial transaction on the Network has been written, but it’s not yet complete.

So it’s much more a procedural artefact, in the same way an invoice, or a receipt would be, rather than directly related to value like SNT is, or like a Bearer Certificate is (hence the reason we have moved away from DBC terminology).

12 Likes
31

Without total order that’s pretty hard to do. You get into the realms of the usual consensus approach quickly.

(good chat, so keep going)

In total order network folk are allowed to try and doublespend as much as they want and the network blocks it.

So

  • Safe for innocent mistakes
  • Safe for attempted black hat hackers to keep trying and not suffer any loss in doing so

That’s basically the trade off. Order everything and block doublespend (attempts) where the attempt is not just an attempt any more it’s a full doublespend (world has been ordered to say so) .
Or

Separate attempts from doublespend (force the parent to be checked when the child is trying to spend) and look for folk trying this.

/-> Begin distraction
It’s very much like bitcoin cannot refund and folk said, of irreversible transactions are hell, folk will lose everything, but I don’t see that happening too much. We need to take into account many things. Basically for a buyer (B) and seller (S) then the process goes kinda

IRL →
→ S can I buy X from you B

Then it’s either pay up front or on delivery
S → delivers goods
B → Pays

Now if S does not receive the cash it’s easy to say, hey B you need to prove you paid me and I need to be able to access the funds
or
If B does not receive the goods, it’s mostly the same, you need to prove I have the goods etc.

So anyway in real life the transaction between 2 parties really depends on goods/service ↔ payment and most of that is “out of band” of any crypto currency (you can use smart contracts etc. but it ends up the same thing, payment and delivery need to be provable and it’s out of band or via an oracle (out of band))

/ OK distraction over :slight_smile:

So it’s down to innocent users and mistakes, but this is also in the realms of loosing your password/key in a decentralised network (there are options via BLS that will work well). So there is a price for freedom, I suppose.

OK that was more distraction :slight_smile: Sorry

Back to SAFE

The approach here is do not require total order so we have a much faster parallelisable network. To do that we split a couple of things and that makes us different form the rest:

Transaction → Parent transaction PLUS Child transaction (a pair)
Finality in blockhains we all understand, but here → When the Child is spent

So we split up the transaction to require the Parent and require the parent is unique. The biggest and worst hack is a doublespend (try and spend the same thing more than once). That is prevented by basically stopping the world (waiting on block height or supermajority of nodes to agree on a ledger) or for Safe we say

  • Write the parent tot the network and we check it’s parent is OK

Now the doublespend attacker will try and write 1 Parent with output X to some nodes and the same Parent with output Y to others. He hopes that he can cash out X and Y before anyone notices.

So this is where our multiple sources of the Parent come in. ANY node seeing X and Y as outputs of PARENT can broadcast that to the world. IF X or Y are not owned by the attacker (he is trying to pay you and also me or something) then either of us in our transaction ask the network for PARENT (but there are 2 PARENTS) and if we see the wrong one, we also broadcast (and as above contact B and tell them they have not yet paid).

So the basis is global visibility of doublespend attempts and quickly, but also stopping the spend of ANY outputs of a doublespend PARENT.

This is why X or Y can spend but only whilst the other does not exist anywhere an honest node sees it. As soon as the doublspend attempt happens, any honest node can stop it. Otherwise, we need to order everything and tick blocks one at a time.

10 Likes
32

I’m a bit distracted to grok that explanation properly, but thanks for later.

I’m a little confused about the following.

If we can’t block double spends for the reasons you have explained, how can we reliably decide to burn the tokens in a double spend attempt, or is that not the intention?

Whichever we do needs to be reliable doesn’t it? I’ll come back later to look at you explanation of what happens, so again thanks for that.

7 Likes
33

No worries and thanks

The key point is that if a Parent is seen as a doublespend attempt (more than 1 transaction from same Parent) then the child cannot be spent. It’s subtle, but it means to doublespend you need the network to agree both Children from both spends are valid, but the check is the Parent is unique. I.e. if the parent is not unique the Child is invalid.

7 Likes
34

So the way that double spends are (reliably) prevented causes the output to be unspendable. Gotit!

…and once again, I don’t like the consequences. :man_shrugging:

7 Likes
35

Can’t intentional which is proofable be punished, by offering to pay to the foundation or network or the SNT remaining in limbo forever?

The problem with destroy, is somebody else in the community could be needing that money. It’s extremely wasteful for the energy in the SAFE universe to disappear. Money should flow and not be destroyed or locked like tvl, that’s if that money is at all useful to be used for goods and services.

4 Likes
36

It’s all about complexity, really. Any If → Then → Else is super hard to do in a decentralised way. It generally involves agreement with many, if that makes sense?

6 Likes
37

I totally agree, but like all resources and cryptocurrencies some will be lost. Here it’s just super hard to allow hackers to try and hack and good people to make mistakes and lump them all together to make things feel good.

If we take bitcoin for instance. If you try and doublespend you will find it really, really hard as your wallet simply won’t let you even try. You could try and send fake transaction to the network and they will be refused, so you won’t have lost your money (maybe your fee though) but to even get to that point you need a badly coded wallet. With such a wallet, you doing a doublespend is not the worst thing I think could happen

7 Likes
38

That was my initial thought too and still is. I suppose its a balance to not making it sound like securities and also being understood by the general non-tech public.

To me using “cashnotes” is a move away from SNT (whatever its called in the end) being a token used in network to sounding like a replacement for cash. Yes i realise its not replacing SNT, but it does change how SNT is seen as well.

Token in network has a good status and some protections
cash replacement will attract a lot of attention from those who print nation’s cash

I am not the only one it seems who sees this

6 Likes
39

For the most part, with even simple clients developer on top of the network, most people won’t need to encounter a CashNote. They will send and receive tokens, into a wallet—or Safe, if you will—and redemption, summing of balances, etc will all be handled for them.

But as a concept in the system, and in code, it’s useful to have a metaphor that helps with what this thing is, how it is to be used.

There is no perfect, short, noun decripter for what this thing is, otherwise we wouldn’t need to creat a metaphor.

But CashNote is pretty good. Good enough. As it tells people this thing:

  • Represents something of value
  • Is spendable in some way (by you, when you use your private key with it)
  • Can have a varying amount of tokens, but is not a token itself
  • Contains some information and metadata about a financial instrument, and in fact is perhaps a form of financial instrument itself.
  • Is not just like a receipt, or an invoice in that regard, it’s more important and had more value than that. It’s more like cheque, or that regard. But…
  • Can’t be cancelled, unlike a cheque (it’s more like a bankers draft in that regard… but folk don’t often encounter them)
  • I can have a bunch of them locally in my Safe, or wallet, and all with varying amounts, and I sum them to get a balance
  • Can be verified as legit by the network — and they contain the information to do that. Like a serial number on a bank note.
  • Contain all the information needed for the owner to spend it’s value
  • Could, in theory, hold more than just SNT, containing other financial information/instruments too
21 Likes
40

From what @JimCollinson has explained, a cashnote is to SNT what an email is to it’s message content.

So it’s not replacing SNT in any way and I don’t really think most will even think about cashnotes - it seems like it’s more of a backend term and simply replace DBC which had a similar purpose…

6 Likes