Also candidates: PepperMint, SpearMint and WinterMint, but, please, no DoubleMint.
9 Likes
thats a hellofamarketing right there! upload stuff and you might get lucky getting the reward of the 70% left!
7 Likes
I can just think of you. You will be a good person. this is what I like. Thx @danda
I also admire @dirvine . You’re a very nice person, too. Thx @dirvine
You are the great stone face for me.
6 Likes
Well its for farming, rewarding the nodes.
Call it “Reward DBC”
I was thinking "Branch DBC" since root and genesis are pretty much the same meaning the beginning of Everything. But branch is not meaningful.
6 Likes
I asked last week but no answer. It is a good idea for the client to do the work BUT
What is to stop the client changing the recipients or even making it the only recipient?
3 Likes
Emissions / rewards are created from upload payments. Only some upload payments, not all of them.
The amount of each reward is determined by the upload fee (so ultimately the rate of reward is determined by storecost, which is determined by the amount of resources available to the network).
The recipients of the reward is the same as the recipients of the upload fee. Maybe also the client that did the upload will get some of the reward too.
But the emission rate is still a work in progress:
11 Likes
I guess if it doesn’t conform to the rules the Elders won’t authorise and sign it.
4 Likes
The recipients are derived from the original payment, which forms part of the GenesisProof. If they’re changed in any way it’ll not be valid.
10 Likes
Thanks for the update Maid team!
I too favor the distribution going to the client, not the farmer. For the reason @danda gave, but also I think it keeps the value paid to farmers in-line with the cost of storing data, which seems like an important market signal for people to use to decide whether or not it’s cost effective to que up for farming.
Ambiguity in markets isn’t good and the more clarity for the data marketplace of SN the better IMO.
Keep up the great work. The next major testnet could be interesting!
4 Likes
I like some aspects of this, particularly the incentive to upload if in fact that turns out to result in a broader distribution. So will it?
It’s hard to say I think because rewarding uploaders effectively gives a discount to bigger uploaders. While for small uploaders the incentive will be small, so may not really encourage more individuals to upload in practice. Might be useful to have some figures for the likely rewards for uploading different amounts over say each year from year 1 to year 20. Perhaps framed in terms of upload cost, or discount on upload cost in order to factor out the big unknown of SNT value. Then we could look at whether that will encourage more people to upload, or just end up rewarding people who upload a lot for other reasons. I imagine a small discount isn’t going to have much effect, but that bigger less likely ‘lottery’ payout would interest a new group to get involved.
On the other hand, rewarding nodes potentially restricts distribution because I think there will be more individuals uploading than farming, but getting more people to farm in order to participate in a lottery might also be beneficial.
So 
7 Likes
There is an option to do both, pay the storing nodes (plus elders) and also discount to the uploader. It would mean we treat clients as part of the payment group and they get a slice of the reward.
14 Likes
Was just going to ask if this would be possible. I like this idea if it’s easy to implement and not a security issue.
3 Likes
To elaborate on my previous post …
Analyzing the ultimate outcome of market behavior is impossible … we can only see a few steps in advance. But I think it’s clear that farmers are more likely than uploaders to sell on the open market, and that pushes down the price, which then ends up driving up the token-cost for uploading … but if they get the reward, the cost is subsidized, so they can still farm for below cost.
Hence I think this may affect the desire of potential farmers to participate as they may not have a clear view of the amount of reward they’d receive (the subsidy), but will clearly see the cost as being higher than it really is.
On the other hand if reward goes in part or in whole to uploaders, they may be more likely to hodl than sell – a farmer might sell to buy more storage and expand their farming business, but an uploader may or may not have a business; so that’s the basis for my assumption here.
So if uploaders do actually hodl more, then there is less selling pressure and the token market value remains relatively higher.
It’s confusing to think about. We have to remember that the network adjusts upload cost based on farmer supply … so there should always be farmers unless something get’s pushed way out of whack - some big shock to the token price for instance. But all in all it’s not farmer supply that’s the concern, it’s more about turnover and preventing oligopolization of the farming market - as that could actually become a threat if gov. agencies push hard and are able to grow a large enough foothold in the network – which is unlikely in any case … but also just to allow small farmers on the network too.
3 Likes
I’d much rather this than all the new DBC going to the client. Imagine the gaming that would happen.
Just upload one chunk in an upload for almost nothing then after 10 or 100 thousand uploads there is the reward of a few SNT while the uploads cost less than a SNT. Thus gaming would be so easy. Yes the cost of upload may be made so high this would not work, but then would anyone upload at such high costs LOL
EDIT: this will always be the problem if one client/node is the recipient of the whole created reward SNT/DBC. If only small amounts of SNT is given per reward then there has to be a massive number of reward DBCs to issue all 70%. Thus the reward amount has to be significant (prob > 10 SNT) to reduce the transactions (which is the goal of doing it this way anyhow) and gaming is easy if one or two receive the lot. Giving it to the adults/elders was always good due to the spread and no one node was receiving a large amount. Large amounts to one/two means gaming is easy.
@dirvine I much prefer this idea of yours (or not rewarding client, whichever) since it does incentivise people to upload, but not to such an extent its worth gaming.
1 Like
The proposal is the RootDBC is always less than the winning upload cost. The reason being we are insisting it is not gameable by brute force attacks, like uploading like mad.
So there will be millions of RootDBCs on the network, and that may be a good thing. Still auditable, but perhaps it even adds some more levels of security.
5 Likes
Thx 4 the update Maidsafe devs
The SAFEconomy will truelly bring change for humanity, may SNT reach all computers out there. SAFEs distribution model is more fair and sensible compare to…
SAFEconomy is the ‘Goldilock’ zone where you can even make the “poor rich”, take that 
market
Keep hacking super ants and have a great weekend SAFE community 
6 Likes
So there will be a fixed value for every RDBC, each identified by an address in an address space that limits their number, such that the total of unissued SNT is limited to the 70% which remain after launch to be issued automatically.
To ‘win’ an RDBC, some hash that is part of the upload transaction must match the address of an RDBC that has not yet been issued and must hold no more SNT than the fee being paid to upload.
A possibly issue with this is the trade off between having a large enough number of small values available to be won, such that as many uploads as possible qualify. For example:
- if only quite large uploads qualify (because a larger upload may be necessary to ensure the upload cost is more than the RDBC reward) then distribution favours larger uploaders
- if the cost of upload falls too low relative to the value of SNT in the rewards, it becomes increasingly difficult for SNT to be issued even if the upload hash matches an available RDBC. This could even leave large proportion of the 70% unissued, effectively forever.
To mitigate those requires choosing a small enough value of SNT for the reward which could be hard to predict, while choosing too small a value might make the rewards so small as to be superfluous, or to cost more to issue than they are worth. The latter would also be hard to predict because it will be dependent on the fiat value of SNT.
Seems tricky to reward clients based on a threshold amount of SNT because the value of SNT is hard to predict. 
Rewarding nodes gives much more leeway - you can keep the rewards larger because nodes are rewarded based on node age which is necessarily hard to game or the whole system will fail. There’s no more risk of unequal distribution than regular farming rewards and much less need to keep rewards small.
You could create a distribution of RDBCs with different values (eg based on some property of the RDBC address) but while this could help it doesn’t eliminate the problem of having to predict a suitable distribution. It would just be a bit less susceptible to the same problems.
Maybe there are other ways to avoid those issues. 
6 Likes
I just want to point out that rootDBCs are to a degree at odds with fungibility and privacy.
-
A rootDBC can (I think) be differentiated from non root DBCs by virtue of having no history, no input decoys. This by definition makes them non-fungible with regular DBC. (different, unique, special)
-
iiuc, a rootDBC must have a publicly known amount, for auditing purposes, to ensure supply is never increased inappropriately. This reduces privacy as well as fungibility.
Monero uses basically this system (new minted coins each block with public amount), so I’m not saying it is unworkable for a “privacy coin”. However compared to a currency without this feature, I think it is inarguable that this reduces privacy/fungibility.
9 Likes
But does it reduce it to an unacceptable level?
Cue discussion about “unacceptable”…
Monero seems to make it work… but I am no expert on Monero - tell me if Im wrong
1 Like
It will have after minting as it will be == payment amount (that payment amount may be hidden though, we have not dug that deep).
I am not sure input decoys would provide anything more here. The RootDbc only exists after minting criteria are met. What they may provide is a client key if payments are made to clients, but it will provide the farmers keys for sure. I am not sure this reduces fungabilty though, it’s just a payment of some amount (bulletproofed) to some nodes.
Can you expand on why?
4 Likes