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.
Couldn’t the dbc’s be minted in a secure way, so the senders / sellers had no way to even attempt a double spend?
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.
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.
From this PDF about DBC:
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.
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.
This is answered in the OP.
Ty, drinking so ill re read tomorrow. Didn’t recall op mentioning secure environments, but ill have a look once I’m sober.
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.
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.
xfers free of charge.
If you mean the actual dbc themselves then there are user choices.
- Store on Safe, so you pay for that
- 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.
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.
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.
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!