Organizations can accept ubi tokens, but do not receive a ubi.

• Can transitive transactions pass through an organization?
• Can they be validated?
• Can organizations trust users?
• Can users trust organizations?
• How are they 'owned' in a blockchain sense?

Add some

test

deploy token, update hub inflation rate, test token payouts

testing clickup integration

Making a note so I don't forget to think it through. A person spawns a circles token contract, it's owned by their user address, can they later change the user address and keep the same token? Will require updating the trust graph.

From Julio, 20 sept 2018:
The Paradox of Wealth, or the Lauderdale Paradox https://monthlyreview.org/2009/11/01/the-paradox-of-wealth-capitalism-and-ecological-destruction/
Im thinking of this in relation to circles and demurrage. What would happen when people start putting things of use value into circles (like care work), granting them a number and sending it over to the person who performed the work. The problem with most political economy we have from those times is that their ideas of what money is were very rigid, seeing them as commodities and not as social relations. Now, with credit theories of money, what would happen if care becomes render visible and important through its valuing,,, demurrage is a system by which the value of money loses is lost if its not used. The main argument for it is to avoid hoarding (savings as we know it in daily life)
demurrage is a way of giving life to money and changing the nature which it holds today i.e. as an interest bearing debt.
if i get money from a bank, with a fixed or variable interest, the amount of money whch i must pay back through my labor is higher than the amount which i was given. With demurrage + a basic income, you have a constant amount of money which dies out slowly, like any other living thing. its kinda like an ecology of money.
so say i have 100 circles every month and we set the demurrage rate at some level like, say, one month. Let's say my rent is 50 circles and I pay for it every month with my basic income.. the other 50 i can use for spending money /exchanging things with others and at the end of the month, whatever is left dissapears or rots away, and a new basic income is issued.
this is a practical way of putting limits to consumption within the system.. in real life it will of course co exist with fiat currencies, which work on a hoarding/circulation dialectic and continously grow as new money is issued.
now....for money to be able to buy the basic things we need in life, we must first create an ecosystem which allows that to happen. This is one of the goals of Circles. A basic income will only happen as the money gains value. The value of money comes from its social life i.e. from all the interactions in which money is submerged, all the different transactions which bring its value into being. One way to do this is by asking the users what do they need to have a basic livelihood and look for actors accordingly.
food, housing, energy, sanitation, there are many different things that are needed for people to be able to live a basic life. What are those things in Berlin? we must identify them as the project runs. Part of research is to document this but most importantly, to translate this information to the community and see how we get new people onboard.
@edzillion says its too much to add demurrage to the system in the first run but i think its just a system design question. @jake.gillberg check this out: https://en.wikipedia.org/wiki/Demurrage_(currency)
it shouldnt be too hard to embedd it in the system, or is it?
@martin.lundfall i need your brains on this one.
http://userpage.fu-berlin.de/roehrigw/fisher/ Irving Fisher wrote a book during the Depression, called Stamp Scrip, where we outlines the experiments at demurrage credit systems that were going on at the time in the US. These were all, for the most part, forgotten by most. But worth to look into: http://userpage.fu-berlin.de/roehrigw/fisher/

Considering:

• Allowing users to set a "cap" of issuance rates they are willing to accept. Allow users to update their own issuance rates. When a user (Alice) updates their issuance rates, all of those who trust Alice and who's "cap" is lower than the updated rate will break their trust relationship with Alice.

Use @gnosis.pm/safe-contracts

https://github.com/trailofbits/publications/blob/master/reviews/dapphub.pdf

Come up with a some possible use patterns and estimate gas costs for them

#16 (comment)

In a way that is not a transitive transaction. For example, Alice wants to trade with Bob, and she has 30 Alicecoins and 20 Bobcoins. She wants to send a total of 40 coins - can she send both in one transaction?

Can she specify how much of each coin she wants to spend? What is the system default preference in a case like this, and can she override it or set her own preference?

And if we enable sending several coins like this, what's the ceiling? Like how many diff coins in one tx is the max?

Finally, can a transaction of more than one token be made transitively? (Pls say no to this last one)

Also for checkSendLimit when tokenAddress hasn't signed up, and when dest hasn't signed up

As per @xwvvvvwx, Kovan is being deprecated. POANetwork is still a contender (https://poa.network/). This is a thread for discussion/suggestions

How the circles-sketch contracts worked:

From Martin L.
@martin.koeppelmann Yes, limiting the trust connection does make sense. The current, quick and dirty implementation has the trust connection not as a binary thing, but when person A trust person B they are doing so up to a certain amount. In other words, when A trusts B, she sets a maximum amount of B tokens she are willing to automatically (through the transitive transfer) exchange 1:1 with any other circles token she owns.
This is a lot simpler from an implementation perspective than varying everybody's trust relation whenever a new person joins your trust network, and also allows for more flexibility and personal tweaks. That said, I think setting the trust limit proportional to the amount of connections you have serves as a good default – that is still a reasonable choice to implement on the application layer

Köppelman's Trust Quota

martin.koeppelmann 11:16 PM
https://chat.joincircles.net/channel/general?msg=PSPXEy2iqLTtAQjiB
hey guys. @harriet, @karenina and me had today an interesting discussion about the 1:1 relationships and wether or not they should be "unbounded" (you can exchange unlimited tokens 1:1)
One suggestion that evolved in this conversation was that it should be limited according to the trust graph.
The basic idea is: If I am connected to N people than the capacity of a connection is only unlimited if the other person is also connected to ALL N people.
If the person is only connected to M out of N the connection is limited to M/N
That mean if e.g that person is connected to half of the people the connection is limited to 1/2
If the limit is 1/2 it means that I will never exchange tokens in a way that I end up holding more than 1/2 of all my circles of that person.
So if I hold t Circles in total I stop exchanging tokens 1:1 with a person if I already hold at least M/N * t tokens of that person.
I think this approach can solve a bunch of problems @martin.lundfall @Zandy @wouter @edzillion - what do you think?

edzillion 5:03 PM
that's a really elegant solution @martin.koeppelmann - I was thinking that it would be limited by distance instead, so that if you directly trust someone you will allow 100% and then maybe divide by .6 each time so that a person 2 hops away can exchange 60%, the next hop 36% etc.
In fact I bet your system would share the same decreasing-over-hops feature, since those further away from you on the graph are likely to have less connections in common
Does it encourage or hinder making new connections though?

karenina 5:14 PM
we thought it'd rather encourage new connections as it lowers the risk of being stuck with coins you cannot use. other question: does it discriminate against people who do not have a large network in the Circles world (for example if they come from marginalized communities?)

aleeza 10:31 PM
@karenina @harriet @martin.koeppelmann It is a really nice elegant baseline but technically I'd say yeah, it still discriminates against those with a weaker network... I think it is an improvement on the default, as it will give people a "lower bound" for how much of their friends' coins to accept. We can set M/N as the minimum and still allow "generous" people to accept a higher percentage of weak coins against their own. That doesn't solve the actual problem though. Since that lower bound doesn't actually reflect use value: You may not be spending with everyone in your network evenly (unless living on a commune), which means just because somebody shares your network 90%, the "valuable" transaction potential is actually with that 10% connection outside the major network (assuming a "marginalized" community). If you're the bridge to that 10%, one enterprising buddy could quickly use up all of your personal coins that are accepted at that valuable outside connection. The only way to actually solve this problem is to get that marginalized community properly integrated... >>> Which is where this could be super interesting! Because it will encourage diverse connections, aka new connections with people who do not share the rest of your network, and thus are way more limited in the percentage of your coins they can transact with. That is a really great incentive system for creating a stable, distributed, interconnected trust network... 🙂

moth 8:27 AM
@aleeza I'm still thinking about this new algorithm and its effects and I will post my thoughts below, but first I'd like to share my thoughts on scaling in this public chat like I have been so far in our closed meetings.
Personally I don't think personal currencies can ever scale well enough to actually be allowed to have this problem.
When it reaches the point where discrimination against those with weaker network matters, the network should be big and stable enough to shed it's baby skin and grow up, switching its personal currency system to some kind of group currency and instead start acting as its own cell in a larger organism; This would be analogous to zooming out from proton/neutron scale and start looking at atoms and suddenly you care about molecules and different rules apply. Scaling means you need to start managing things like inflation which requires governance so as far as I know what we have to do to achieve this is build a group currency with custom governance. We can supply a recommended set of governance methods and I'm currently reading about this, but ultimately it will be up to the community itself.
But the key here is that just like the protons in the atoms, personal currency particles exist within the group currency atoms and is what keeps them stable.
Here I will puke out some slightly organized thoughts on this new way of limiting exchange, @martin.koeppelmann @edzillion @aleeza @karenina . I'm most interested in how the results will differ from our previous mechanisms. Asking whether trust connections should be unbounded should already be clear, no they can't - it would mean it's too big a risk to ever trust a new node and hub nodes would be depleted instantly of their own currency.
In what Andy proposed as limited trust in Athens last summer, you defined a certain amount of personal currency to be exchangable per time period per trust connection, (e.g. let's say we mint 1 CircleCurrency/s and for new-guy-Bob you allow the 1:1 exchange 1/100 minted currency or one per 100s and for old-friend-Alice you allow 50/100 or 1/2 since she's well established already and has many trust connections in common with you).
In this new model, I'm gonna call it Köppelman's Trust Quota for now, saying that the capacity is unlimited if you are both connected to the same set, N, is redundant since you will never need to do transitive transactions if you all have the same direct trust connections - you can simply transact with your target directly. In KTQ you would allow 1/2 of your currency to be Alice's but only 1/100 to be Bob's. Bob is one of your trusted connections and you can receive payments in BobCoin, so this can lead to a curious situation: you have 200 of your own coins, Alice buys your old bicycle for 400 BobCoin and already you hold 2/3 of your currency as BobCoin meaning Bob can not exchange with you for a substantial amount of time (depending on when you spend his currency or how much other currency you accumulate).
They both limit the risk of trusting new nodes, good, so they should both allow (encourage) you to trust new nodes. Athens limited trust (ALS?? 🤡 ) is not defined automatically in the same way, but is set up "manually" or more likely through some other automated process (in the app). ALS does not take into account in any way how much or what type of currency you are holding right now.
How is the quota calculated? Does it happen off-chain and continously consulted?
Will these different methods lead to different behaviours? Is there ever a reason for someone to want to manually set the exchange limit of a certain connection and disregard the automated limit set by something like KTQ?

This seems like an obvious attack we should defend against.

User launches a token on a hub. User then builds a trust graph attached their their real identity. Then user launches an attack-hub with a much higher issuance-rate. They migrate their token to the new hub and stay their long enough to collect issuance. Then they migrate back to the legitimate hub, with their real trust graph, but they are now a whale.

Mitigations: Disallow migrating back? Reset balance in some way when token is migrated? Surface hub-migrations in the UI?

this shit lit brah, 4/6 spicy nuggets

Pros and cons?

Con of the current approach is we need to whitelist relayers/have special methods on all contracts for the relayer.

Adding a proxy would allow the main hub and token to not know about the relayer, and add a nice path for upgradability with further user features, like social recovery.

They're only used for testing

enable CirclesPerson to send arbitrary transactions, like the uPort proxy contract. Maybe even make this a uPort proxy contract?

depends on #64

A diagram would be nice

Get a working testcase

testing 2

https://solidity.readthedocs.io/en/v0.4.24/layout-of-source-files.html#comments

Architecture comparison

Here is a break down of differences between the contracts in this repo and the old "contract sketches" and my thoughts generally on what the architecture for the Circles contracts should look like.
The minimal functionality these architectures are trying to achieve is a system of personal currencies and a way to exchange these currencies (transitive transfer) based on a network of trust.
##Circles token contract
Both approaches center around an extended ERC20 contract with a couple of added features. In this repo, this contract is called TimeIssuedToken and in the old sketches it is known as CirclesToken. Since these contracts are very similar, I will sometimes refer to the "archetype" of this contract as a PersonalToken

Similarities

• The token specifies an address, a designated person that we should understand of the owner / source of the token. This makes it a personal token.
• There is a minting function which continuously increases the balance of the person based on the time elapsed since the function was last called. The rate of tokens minted over time is decided by another variable issuanceRate a.k.a. factor. The minting function is automatically triggered whenever a transfer occurs.

Differences

• The TimeIssuedToken has a quirky way of referencing the balance of the person as totalSupply - elsewhere instead of through the balances mapping.
• The math in TimeIssuedToken is not overflow safe (see #10)
• The person of the TimeIssuedToken seems to be intended to be a Person proxy contract, rather than an end user.
• The CirclesToken has an owner address specified, which is exempt from requiring approval from token holders to move tokens on their behalf (implemented as an added clause in transferFrom). The owner of all CirclesToken contracts is intended to be the CirclesHub contract.

Transitive transfer functionality

Besides the personal currency contracts, a key feature of Circles is the ability to do transitive transfers in the web of trust.

Differences

Here approaches start to differ a lot.
The old sketches rely on a single CirclesHub.sol to keep track of trust relations and execute transitive transfer using its special authority in the CirclesTokens. Here a trust relation is specified by a limit, a value and a time lastTouched. We should understand this relation as specifying a daily limit of their own tokens that the truster is willing to substitute for the trustees tokens. Circle users join the network, specify their trust relations and make transitiveTransfers all using this one contract. Trust relations are from a person to a currency, or from a person to a validator (which we can regard as a person). The transitive transfer supports transfers facilitated by validators.

This repo takes a different approach. For each user, there is a Person.sol contract, which has an owner (the user). The owner can select tokens that it is willing to accept as input and output in an exchange. If Bob trusts Alice (here meaning that Bob has specified Alice's token as an valid "exchange input", and his own tokens as a valid "exchange output"), Alice can perform a swap by first approving Bobs Person contract for transferFroms of AliceTokens by calling ExchangeApprove and then call the ExchangeTransfer function of Bobs Person contract. The two actions must be performed in the same transaction, as anyone can call the ExchangeTransfer function after Alice has approved Bobs Personcontract to transact on her behalf.
By this method, Alice can make one transitive exchange, i.e. transfer A -> B -> C.
If a longer transitive transaction is needed, then they can be performed as a series of ExchangeTransfers, executed by the sender.

My take

I prefer the first architecture, the "old sketch" model, for a number of reasons:

• I prefer having the person of the PersonalToken be an arbitrary address, and not necessarily a proxy contract. The proxy solution is more complex, both from a smart contract perspective and for the user to deal with.
• I prefer having one central point where trust relations are kept. To gather data about the trust graph in the version where everyone states their trust relations in their ownPerson contract, the trust graph is scattered among all these contracts.
• It is my opinion that the ExchangeTransfer procedure is a lot more complicated than the swapping of tokens that happens in CirclesHubs transferThrough function. The latter also provides an arbitrary amount of hops while the former only allows for one transitive hop. In order to facilitate a longer transitive transfer with the ExchangeTransfer method, one would essentially need to write a function that performs the logic of transferThrough anyway.
• Having a central Hub that is "in charge" of the PersonalToken contracts gives a clear entry point to implement monetary policy. If we want to be able to change the issuance rate or the starting balance, or implement demurrage, we will need a managing entity that has special privileges in the PersonalTokens. I think making CirclesHub be this contract is an easy change.
• My critique of our old sketches right now is that they are somewhat opaque as much of the functionality is hidden in its library contracts, and in a kind of "quick and dirty" state.
• The ExchangeTransfer mechanism has an upside in that it allows people to automatically swap tokens other than their own. I.e. if Bob holds 10 EveCoins, then Alice can make a transitive transfer to Carol passing through Bob, but now exchanging AliceCoin for EveCoin which she sends to Carol. It's a slightly more general functionality than the old sketches.

Ways forward:

Of course, I am slightly biased and I would be happy to hear @Jake-Gillberg's comments on the two different approaches. But if I were to go ahead with this, I would modify the old contracts sketches and update them with the following things:

• The ds libraries are out of date, and a lot of complexity is hidden by relying on their functionality. I think there is still motivation to use them in some scenarios, like logging, but I think for the sake of understandability and security, we should not sweep complexity under the carpet. The transferThrough function looks a little bit gnarly right now and can be simplified a lot.
• The CirclesToken should ask the CirclesHub what the issuance rate is so that we can update it centrally.
• The CirclesHub should be given a (replaceable) owner/admin, that can modify certain system parameters, like the issuance rate, starting balance, and whether there is demurrage in place.
• A lot more tests. And in particular of cases that you DONT want to work!
• Since the CirclesHub essentially acts as an operator, it can adhere to some of the conventions in erc777 (although I don't like the calling hooks very much, so I would skip those).
  Optionally, we can also make it so that these contracts can be interacted with signed messages, instead of ethereum transactions. I think this is out of scope for the MVP though.

More literal less confusing

As per @xwvvvvwx's suggestion, don't think we need timed weights, can probably simplify to just the total of user's tokens other user is willing to hold

How would we best approach this?

What we want is to have a payout happening for everyone worldwide on a Friday, either all at the same time worldwide, or at a certain time in each timezone/region.

I talked briefly with @MrChico on this and he suggested that it might be possible to have the contracts creating money continuously but have the client only call for the new balance on Friday?

@shkfnly and @ana0 you had some thoughts on this on the call can you note them here?

In scope:

• Continuous issuance (similar to previous sketch)
• Basic org wallets (multiple admins all with total control (whitelist))
• Monetary policy

and can take into account from balance in all cases

special circles-only transfer event

https://stackoverflow.com/questions/33701505/a-dotfile-that-will-set-the-default-node-version-on-a-project-using-nvm

Do this before client integration

And also proxy factory