The power of DBCs on Safe Network

[dask]

Indeed! The major point I was fumbling to make is that, as I understand it, there is one more ingredient missing to enable that scenario. I mentioned hash/timelocks, but it doesn’t have to be that. A field covered by the DBC signature that says “only execute if another set of transactions (attached) with this hash are also valid” would do the same thing (but put maybe more work on the elders??). The architecture of SAFE gives multiple methods to resolve this, and so I do have confidence that it will be. Only point was saying that a two way transaction has an additional requirement over a transfer.

[bones]

Couldn’t the dbc’s be minted in a secure way, so the senders / sellers had no way to even attempt a double spend?

[Traktion]

I’m not sure you can ever stop an ‘attempt’, but presumably it isn’t possible to succeed. I’m not the best person to answer that though, but from what I’ve read from the team, they are robust.

[bones]

I’m no programmer, but I’d imagine a secure environment that no one could snoop on, maybe not possible, but would accomplish what we need.

[digipl]

From this PDF about DBC:

Ownership

eCache DBCs encode information about who can spend the DBC, that is: Who the owner is. This is simply a hash of a public signing key that is used to verify any transaction in which that DBC is used. Any transaction command from the user to the mint has to be signed by the private key that corresponds to the public key encoded in the DBC, otherwise the mint will not process the transaction.

[bones]

So for a btc dbc, would that be the btc pvt key, or the Safe acc pvt key?
Because if its just the btc pvt key, and someone could snoop and see it, it wouldn’t be secure.

[happybeing]

This is answered in the OP.

[bones]

Ty, drinking so ill re read tomorrow. Didn’t recall op mentioning secure environments, but ill have a look once I’m sober.

[Nigel]

I don’t think Maidsafe would ever unnecessarily charge for a transaction so I would suspect it comes down to spam attacks and the amount of load it could put on the network. DBC’s are light and fast and I believe the AT2 feature they adapted to DBC’s was signature aggregation by the client to avoid extra work for elders.

So that’s a great question. Is that enough for free transactions as long as it’s using the Safe Network DBC implementation? Do anti spam measures need to be in place in either case?
Any kind of data type based alt coin would be technically inferior though if was desired to mimic bitcoin with traceable public transactions then still possible but with fees certainly.

[happybeing]

Any fees would be tiny, and not comparable to Blockchain so not fair to compare with the issues around Omni etc. Plus anyone creating a DBC is going to be asking the network to store data so it may be necessary to use fees to tie them into the SNT ecosystem. If not you’re allowing value to be extracted without participation.

So to me it isn’t clear that fees are either a significant impediment, or can be waived without creating risk.

[dirvine]

@Antifragile

How are DBCs transfers paid? I expect that SNT should be moved without any fees, as was said many times.

xfers free of charge.

@Antifragile

But what about the tokens?

If you mean the actual dbc themselves then there are user choices.

1. Store on Safe, so you pay for that
2. Don’t store them on Safe, but keep them offline or in hw wallet etc. So no charge.

At least so far anyway. It seems to make sense, but payments would be hopefully imperceptible if storing on Safe. Not really a transaction charge in terms of something to stop spam. @Nigel is right, we hope the work clients need to do is enough to stop spam, otherwise, we will hashcash them.

[happybeing]

@Antifragile

Imagine a business, that creates a web page on Safe network. Owner can create a token and wants to distribute it and wants users to use it. If users need to have SNT, than this token has very limited onboarding power.

This isn’t such a hurdle since those users are by definition SN users, many whom will already have SNT, and as time goes on this becomes less of an issue. Early on, I agree it has a slight downside for the service owners, but this incentivise them to get users to obtain SNT which is good for the network and for them in the long run. Also, it helps pay for the network which will make other services cheaper, so swings and roundabouts.

So I don’t deny your point, I just think it’s not all bad, or particularly bad if fees were charged.

Anyway, it seems not charging for transfers is the intention which is amazing. We’ll have to deal with lots of “but this leaves SN wide open to spam” so we need to hit this hard when we have DBCs integrated into the testnets.

Over to you @Southside!

EDIT: I was excited right away by Digital Bearer Certificates, but never imagined they would bring so much value through efficiency, additional features and use cases. Safe Network was already head and shoulders above the pack, then along come DBCs and multiply it by ten to a thousand times.

[happybeing]

This doesn’t mean users of Safe Network have to be SNT owners but we surely want to make that easy and worthwhile.

Most users will install SN App which as part of onboarding keeps the barrier to obtaining SNT small too, so any user joining to use another tokenised service is incentivised to take advantage of this.

Needing SNT in order to use another token isn’t much of a barrier IMO - they will have to get and manage the other token too anyway. A service provider creating their own token will be one who can make the requirement for SNT as easy for their users as possible - and the more services helping to smooth the way for SNT and SNT based services the better for the network and every stakeholder.

I repeat, I’m not arguing that we should charge for non SNT transactions, but don’t think it is all bad, or particularly bad if we do.

I take your point about native apps, it remains to be seen whether this is something we should prioritise though IMO, because it negates many of the benefits of Safe Network (privacy, targeting, surveillance) which are only assured in Safe Browser. So I expect SB to be the early focus for developers and early adopters, especially as SN App is going to be spearheading the onboarding process.

[neo]

@dirvine

@Nigel is right, we hope the work clients need to do is enough to stop spam, otherwise, we will hashcash them.

And of course limit clients to one transaction at a time. So the second or few seconds in real time it takes for the transaction to go through will limit each client’s ability to spam. And if we achieve 50K transactions per second per section then it will be a difficult task to get enough clients in the bot attack since they do not choose the section for the attack to occur in

[JimCollinson]

@Antifragile

I think the idea that Safenetwokr users have to be SNT users is very discutable.

You’re putting your finger on it… they don’t need to. Reading data from the Network still makes you a user of the Safe Network: no SNT required.

@Antifragile

ut a developer of mobile app can include Safenetwork API, or embed a safenetwork browser into webview and pusblish it as an app. This way users don’t know they are using the safenetwork.

But then, of course, should someone want to store data, and not have to entrust that to a developer, not anyone else, then SNTs are there for that.

Likewise, should a dev want to make an app and not have the responsibility of handling any user—and all that comes along with that—then again, SNTs are there for that.

The fact is that DBCs will make access to SNTs even easier, especially for those on mobile and first time users. So all good news!

[mav]

@dirvine

We can easily 1 way convert / swap coins like this.

• Create Safe keypair (BLS so we can then make it multisig if we wish)
• Try convert to btc address (or whatever) i.e. base58 and check starts with a 1 (or repeat above)
• Send your BTC to that btc address (which nobody can create a priv key for)

A bit of technical exploration to show how this process might work…

• Create a bls key (try using eip2333 tool)

• Copy the bls public key - this will be where SNT funds are received

• Modify the bls public key so it can be turned into a bitcoin address

  • Bitcoin pubkeys can be compressed (32 bytes) or uncompressed (64 bytes). Since bls pubkeys are 48 bytes we must use uncompressed bitcoin pubkeys to fully encode the bls pubkey into the bitcoin pubkey.

  • Convert the bls public key to a bitcoin uncompressed public key by prepending “04” and adding an extra 16 bytes to the end (the extra 16 bytes come from repeating the first 16 bytes of the bls pubkey, maybe could be some other padding like zeros).
    This in javascript is:
    blsPubkey = "<your bls hex pubkey>";
bitcoinPubkey = "04" + blsPubkey + blsPubkey.substring(0,32);
console.log("Bitcoin uncompressed pubkey:\n" + bitcoinPubkey);

  • Convert this uncompressed bitcoin public key into a compressed bitcoin address (try using key compression tool). This saves on fees when doing the burn transaction.

  • As an example the bls public key
    84187c88ab2fc5a82a0c9bdd6b7214b74459dc5e268865030784c9c247b0dd6fbf835457fae5a7064c220ea4ed9d87f1
    gives the bitcoin uncompressed public key of
    0484187c88ab2fc5a82a0c9bdd6b7214b74459dc5e268865030784c9c247b0dd6fbf835457fae5a7064c220ea4ed9d87f184187c88ab2fc5a82a0c9bdd6b7214b7
    with compressed bitcoin address
    1BPGYfqx3c7EwFCxEruGJ9AMgXzxeHyHHm

  • Appreciate there’s no way to know the secret key for this bitcoin address (need a cryptographer to please confirm) but we do know the bls secret key.

• Send your omni maid to that address

• Present your bls public key to the mint

  • The mint converts it to a bitcoin address using the same process as above

  • The mint checks the bitcoin blockchain for the presence of omni maid at the bitcoin address

  • If there’s omni maid there, the mint issues the same number of SNT to the bls public key

• Only the bls secret key is available, the bitcoin secret key is impossible to discover, so only SNT can be spent, never the omni maid.

[Traktion]

Excellent work, @mav - love your posts and input!

So, MAID to SNT transfers look possible with no exchanges or middlemen, with no time lock, etc?

This is the sort of solution I like to see. It will be great to be able to wrap other cryptocurrencies in a similar way too, then take advantages (and trade offs, ofc) of what the safe network brings.

Really cool. Really, really, cool.

[oetyng]

@Antifragile

But this solution requires network to have Bitcoin plugin managed in decentralized way

True. But this might be the first plugin (obviously simplified compared to generic plugin framework) available at launch

[krnelson]

@oetyng

this might be the first plugin (obviously simplified compared to generic plugin framework)

Looking forward to that SN composable future!

Composability is Innovation - a16z crypto