Sounds good. I hope those non paid antispam measurres work:) This DBC solution is so powerful.
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.
I think the idea that Safenetwokr users have to be SNT users is very discutable. In current sotfware world, most of the users spent time on mobile phones using some apps. So how many of them will install safenetwork browser initially? I think not many. But 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 in fact they are watching videos, listening to music stored on Safenetwork or even storing a content, but that content is paid by developer in SNT. I think this scenario is the most likely outcome in early years. That is how people behave. And onboarding will come from developers searching for cheap storage, tokens, privacy, etc… This can easily bring hundreds of millions of users, that are using activelly network and will not know about that.
In such environment, those users can use tokens without knowing the whole story. Safenetwork tokens can work on clearnet environment easily, using clearnet webwallets and safenetwork backend.
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.
12 posts were split to a new topic: Pimms and Spam
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
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.
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!
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).
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
gives the bitcoin uncompressed public key of
with compressed bitcoin address
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.
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.
But this solution requires network to have Bitcoin plugin managed in decentralized way, to check those burn transactions. Snapshot solution is way simpler to implement in this case. Plugins are distant future.
True. But this might be the first plugin (obviously simplified compared to generic plugin framework) available at launch
Looking forward to that SN composable future!
This means, we should try to make our tokens, smart conract and computational layer compatible with existing crypto standartds if possible.
Not necessarily mainly its just just contract, token and plugin standards which will all evolve on the SN in due course. The rest of crypto each project does its own thing and go their own ways.
The question is whether atomic composability will be possible on SN or not given its nature… we will see.