search

CirclesUBI / whitepaper

Circles Protocol Whitepaper
https://joincircles.net
Creative Commons Attribution Share Alike 4.0 International
348 stars 23 forks source link

The Paper diverges from our implementation on the payout schedule #2

Closed edzillion closed 4 years ago

edzillion commented 6 years ago

Alice joins the system, creating AliceCoin PersonalCoins are all minted at a rate of 1 per minute Five minutes later Alice has 5 AliceCoin and Bob joins the system, creating BobCoin Five minutes later Alice has 10 AliceCoin and Bob has 5 BobCoin

I will strongly argue for not having a 1-per-minute issuance. Our current implementation has an issuance schedule of a weekly payout, paid on Friday morning.

Should we change this to reflect our implementation? Do we need to debate this out?

edit: might as well roll these comments in to one issue

Money is useful when it allows complete strangers to efficiently conduct business.

Circles can not, for the foreseeable future, allow 'complete strangers' to transact. People separated by one user in common, are by definition not 'complete' strangers. Perhaps edit to remove 'complete'.

This diagram appears to be wrong, users cannot trust validators. Validators trust users, so the arrow should be pointing from 'Tigers Fans' to Eve.

apmilen commented 6 years ago

there is no concept of "friday morning" inside a smart contract, only specific numbers of seconds between each issuance. if we did 604,800 seconds, which is the first-pass approximation of a week, this value would slowly diverge from friday due to the existence of leap seconds, leap years, clock skew, etc. the continuous issuance model is the only way to achieve a level of certainty and predictability with regards to the schedule. i agree it will take some getting used to, but in general i don't think the user will have to make such a huge conceptual leap to switch from the weekly wage-style payout to a token-stream model.

Money is useful when it allows complete strangers to efficiently conduct business

you're right this is probably too opinionated for this paper, i'll find a way to reword it.

users cannot trust validators

currently in the contract implementation users can indeed trust validators. I plan on simplifying this even more to make validators exactly the same as users and to make it so that their functionality is a part of the transaction format rather than a special type of stored data. from a usability perspective, its good to have users trusting validators because otherwise it would be impossible for a business to say "i will accept circles from anyone that is validated by this account"

toonsevrin commented 6 years ago

Smaller issuance intervals sound better to me as well. Not because of the divergence of real time but because issuing coins weekly would create waves of inflation which is an unnecessary complexity.