To be perfectly honest, I don’t know it at that intimate of a level.
I would ask @danda, @oetyng, or @mav
Would be cool to have the primer updated with the economy information update that is supposed to be released soon.
5 Likes
our DBCs include a recipient pubkey, so no one else can spend it. This means the recipient does not have to immediately reissue the DBC upon receipt. For traditional ownerless DBC, immediate reissue is necessary to prevent the sender from possibly reissuing first (double spending).
12 Likes
Is there a way to say that a pubkey is valid just for some time? Theres no time in the SN so i guess not? Im just thinking of this use case: i wanna buy a pair of shoes at my town so i set the pubkey of the vendor at home and then make the purchase in person (offline). But that means that i already “spent” it at home before the actual purchase. If the purchase fails for some reason im stuck with unspendable funds. Can i make them spendable again? I think that the whole offline spending (or receiving) isnt going to really work, at least one party needs to be online. But thats an improvement over the standard DBC where the receiver has to be online, not any of the two parties. But the same issue might apply here too if the tx fails im stuck with unspendable funds. So the standard way of handling DBC seems to be a more fool safe way, i can still just “double spend” it after a failed tx (reissue to myself, to not allow the vendor to steal my funds), which implies that both parties need to be online, i (to take back ownership, if im not trusting the vendor) and the vendor (to take ownership).
You can create a DBC without an owner and hand this over physically when you make a purchase. You or anyone with a copy of it can take ownership, but only one of you obviously - first to do so owns/spends it.
3 Likes
yeah, that’s what i meant by “standard DBC”.
I’m questioning the “pre assigning the receivers pubkey” SN-DBC feature, which seems to be an easy way to lose funds, in the case of setting the pubkey far in the past (from home for example), but also just before the purchase (the processing of the vendor might brake and im stuck with unspendable funds).
Sorry to bother, but for awhile now, I felt like the erasureprotocol could help to prevent a double spend, by staking and recourse.
Obviously this is built on Ethereum and I’m clueless to SAFE smartcontracts 
not presently. that starts to fall under the realm of “smart contracts” or “programmable money” which we’re not aiming to support initially.
If you want to get back the ownerless “bearer” property then the sender can simply provide the private key to the recipient rather than reissuing a new DBC to recipient’s pubkey. (or we could make pubkey optional in the dbc, tbd).
6 Likes
Think of it like going into a bank and getting them to write a bankers draft from your account. You’ll see the amount be debited from your account immediately, and you’ll have a paper draft/cheque made out to the vendor.
You head down to the store with the funds to collect you shoes. If they fit, no problem, you hand over the banker draft, which the salesperson scans, it is validated, and their account is credited with funds.
If the shoes don’t fit however, you head back to the bank, and you can deposit it back into your account, cancelling/invalidating the draft, and restoring the funds to your account.
DBCs in their most raw form, won’t do this out of the box, with a single owner. But, if you give it two owners it becomes like that banker’s draft: either the shoe shop can cash it if you want to proceed with the purchase, or you can deposit it back in your Safe if not.
And there’s the thing, most users won’t be interacting with DBCs in their rawest form (or really need to know what a DBCs is) because we’re building a layer of UX on top of all this. So you can expect various payment solutions powered by DBCs under the hood:
Instant payments: Enter an amount and payee (e.g. @safeshoes) and the payment is transferred across the network immediately. Could of course be a single click operation in an e-commerce scenario too. These can be sent anonymously or not, depending on your needs.
Bankers Draft style payments: As described above, this would be like making out a cheque to a specific payee, but the funds can also be paid back to be should I need it. This could be made out on paper, or sent via other channels on the clearnet, email or whatever. Again, anon or not, it’s up to you.
Cheques with out a payee: This is a method of paying someone a specific amount, when I don’t know their details, or even if they have a Safe on the Network at all. It’s like a cheque without a blank payee. The funds are withdrawn from my Safe, but I can keep track of if they have been deposited, and take them back if I need to. These could be anonymous too, or not, depends on your needs.
Digital Cash: This needs a little more work (@danda is on it!) but the desire here is for ownerless DBCs which would allow users to withdraw cash notes, which anyone could then deposit. If you were given one, you’d want a network connection to validate it, and then secure it through depositing it of course, but it would always be anonymous, for both parties in the transaction.
21 Likes
If elders are going to be exposed and given that there may (probably) be tax implications for earning tokens in the future in some jurisdictions, then perhaps a proof of work would be better here than a potential transaction fee – assuming either ends up being needed to secure against attacks.
The complications that might be involved in tracking taxable events as an elder might also be a large hurdle for potential nodes depending on where they live.
Then again farming in general might be a problem for those with exposed IP’s.
2 Likes
This sounds good.
Thanks for giving the various forms, sounds like going back to the olden times of last century, with the benefits, but in a digital form
9 Likes
Yeah, I think we can make something really nice and useable.
There will be other use cases too, some more nuanced or specific, and some exciting expanded applications of them down the line too, but’s that’s the basic shape it anyway.
9 Likes
This is really cool!
Just as a reminder, I know I’ve mentioned bevore (and I hope this is implemented 
) where a 2/3 multi-sig, 1/3 being an escrow, for e-commerce which can prevent site owners from doing “exit scams”. This should also be accompanied by third party arbitration for disputes. That would make e-commerce on Safe a full package and the most decentralized and resistant to scams.
10 Likes
Yeah there are some powerful applications for that (oh the possibilities!), but it’s defo on the slightly more complex side, rather than the out of the box solutions I mentioned.
But don’t worry, we’ve not forgotten!
7 Likes
I think this could be a solution that actually removes the need for the more complicated arbitration part actually. People just need skin in the game so that they don’t misbehave. Give this a read when you have time but replace bitmessage with SafeID messaging.
cc: @oetyng @danda @mav and rusu (if someone could pass it along)
2 Likes
For the first time ever, untrustworthy parties
will actually be compelled to perform in good faith.
A very bold statement from the intro to that whitepaper. I think I’ll read on…
1 Like
It’s older I’m pretty sure but the main points is if a 2/2 multi-sig where the two parties funds locked up and at stake (and ways this can be done) is present then people will typically behave which reduces extortion and avoids possibility of collusion present in a 2/3 multi-sig.
Also makes it a line in the sand where no third party arbitration has to be done. You either behave or don’t and lose money.
Where those locked funds go when there is misbehavior is a question though. Can it go to the networks benefit? Can those funds just be burned, or recycled, go to a charity or the foundation?
3 Likes
My initial thought would be the Foundation.
I can feel a poll coming on if this gets further attention.
1 Like
bisq uses 2/2 multisig these days I believe. Originally was 2/3, with 3rd being an arbitrator. You might be interested to look at their protocol and discussions.
3 Likes
Nice! Yeah I’ll try to hunt down some info. I think Twitter’s rumored DEX is supposedly a partnership or something with BISQ so they must have a good clue what’s up with best practices.
What are your thoughts on this as an option for DBC/e-commerce on the network? Think it’s a good solution?
I think that the world has never yet seen a decentralized, fungible, scalable, sound (non-inflationary) cryptocurrency. I think that is the “killer app”, and once the world has it, untold new possibilities will emerge kind of fractally. So personally I’m most excited about getting the base unit right, and less interested in anything that seems to entail “programmable money” (which often impacts negatively on the above properties). That said, we do support multisig “out of the box”, so things requiring 2-of-2 should be workable.
You may be interested in this paper which discusses Mutually Assured Destruction as used in online marketplaces, eg OpenBazarre (and I believe bisq as well). I definitely think/agree we as a community must build decentralized solutions in order for us to succeed.
9 Likes