<
 
 
 
 
×
>
hide You are viewing an archived web page, collected at the request of Ethereum Foundation using Archive-It. This page was captured on 19:37:55 Jun 21, 2021 , and is part of the Community collection. The information on this web page may be out of date. See All versions of this archived page. Loading media information

Basic Income (CIRCLES) - reputation/market based approach to solve the identity problem/Sybil attacs

koeppelmannkoeppelmann Member Posts: 51
edited November 2014 in Projects
Since about two years I am thinking about a blockchain currency where coins are constantly distributed to all people participating. Obviously the challenge to solve is the identity problem.

This proposal might be a solution to this problem. I thought about doing it as a new coin/blockchain but I guess it is instead a perfect potential usecase for the ethereum platform:

This is the latest version of the proposal:
http://piratepad.net/kjTwIzn5u3 (feel free to comment directly or here)

Proposal for a cryptocurrency implementing the "unconditional Basic Income

This is a proposal for a new cryptocurrency. In the system outlied in the following, new money is constantly distributed to every account participating in the system. The coins in every individual account are uniquely identifiyable and only gain in value if the account connects to other accounts and joins groups. This incentivizes every user to limit themself to one account.
A 2% demurrage fee ensures that the total supply of money is limited.




1. coins will be distributed as follows: 1000 coins per week per account. (number does not matter and distribution can be constantly)
2. coins in new accounts are worthless - they gain in value as soon as the account is trusted by other accounts or the account becomes a members of a group
3. if two accounts trust each other they express their willingness to exchange their money 1:1
4. as long as there is a liquid connection between to people they can pay each other
5. it is in the interest of a person to focus all their connections to other persons and memberships of groups (like citzenship) into one account to make the coins worth as much as possible
6. all coins constantly have a demurrage fee of 2% per year to limit the total supply of coins
7. arbitrary groups can be made: (>10 bitcoin holder, bitcointalkaccount with >x posts, citizen of germany, ...)
8. creators of a group are responsible for rule compliance
9. all members can convert their private money into group money



This coin could grow very quickly because people can join and get coins at no costs. As soon as they do so, it is in their best interest to get others to accept their coins to make them worth something.


Detailed discussion.

6:
The demurrage fee of d = 2%.
The fee determines the ratio between the final total coin supply per person and the income per month. The number is subject to discussion. It should be choosen to maximize the value of the income.
Note that a high demurrage fee destroys the capibility of the currency for the storage of value. Consequently, the potential dollar market cap is a function of the demurrage fee, f(d). d should be choosen to maximize d*f(d)
The same effect that the demurage fee has can also be achieved by constantly increasing the basic income (by d per year). Mathematically these two approaches are identical but the second one might be better psychologically as it is more similar to our current financial system.

7-9:
Groups
Groups are necessary to bring more stability into the system. Holding coins of a specific person always carries a certain risk. In some sense the value of theses coins is always backed by the person. If the person dies or more broadly speaking the trust in this person sinks, these coins may become worth less. However, as long as a person is member of a group the money can irreversibly be converted into group money. It is in the responsibility of the groups themselves to keep them tight on the one hand to not dilute the value, but on the other hand have a positive network effect. This makes it interesting for merchants to accept such group money.

A possible modification of group money conversion:


3+4:
Transitive Transactions
If A and B trust each other, and B and C trust each other, then A and C can pay each other as long as B is liquid. If A is a customer and C is a merchant, A could send money to C. The network will automatically send coins from A to B and from B to C.


1:
It is not necessary to do something like "coin creation". You only need an account with an timestamp and you can directly calculate how much money is on this account at a given point of time.

FAQ:
Can I create 100 fake accounts that all trust each other and abuse the system?
You can create them but this will not create value. As long as nobody else trusts these accounts they can only exchange money with each other, rendering all the money worthless.


What is the money of an account worth?
In theory it should be max(value(group1), value(group2), value(group3), ... , value(connection1), value(connection2), ...). Note that only connections to liquid people count. As long as the memberships in the groups and the connections are stable (or expected to be stable) there should be no incentive to convert money into group money.
This concludes in the assumption that it is not necessary to convert your money into group money or to exchange it to money with one of your trustees. Just having the ability to do so makes your money at least as worthy. This could stabilize the system and allow user A to connect to user B despite the fact that user B's coins are worth less. This connection could raise the value of user B's coins without changing the value of A's coins. However, this stops if B tries to abuse this connection but in this case A can cancel it.
From time to time users could lose their connections because they cause panic. This is the unliklier the better the user is connected. This strengthens the incentive to concentrate all your social connections/ reputation into one accout.


(Edit: Numbers added for easier referencing)

Comments

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    It is an interesting idea.. not quite clear how it is supposed to work.. So it is a coin with inputs tracing back to a group or person, and each person for himself decides how much the coin from another person is worth? That sounds potentially way too many things to track.

    I considered a variant (just now) where each person uses your coins to buy stuff, and later sell services/goods for said coins. Coins are valued due to the latter, if two people meet, they(their computers) try calculate a switcharoo that suits them. Anyway, in a selfish context, it is not much of an UBI, it is only worth anything insofar you have services to offer, although now it also counts if you might have services to offer in the future. (demurrage decreasing that effect) Altruism might modify it, but it seems that doing so might concentrate all the weight onto you, essentially you end up with coin that doesnt give you products. You could in principle accept coins that are not yours for your services and not bother with your own UBI coin, but then the UBI serves an opposite role as intended.(giving the rich money) Possibly that can be made forcedly impossible, really though, i think for it to be UBI, you kindah need to level the value of the different coins a bit.

    Your approach looks much different than that though.. Not clear, are the coins the same coins or are they really different? If they're the same, well, attackers will have connected nodes, and try attach them to a real network, stopping that could prevent the system from spreading. If they're different, blocking transfer doesnt matter, because people will have to figure out the value to them anyway.
  • koeppelmannkoeppelmann Member Posts: 51
    Thanks for your comment!
    Jasper said:

    It is an interesting idea.. not quite clear how it is supposed to work.. So it is a coin with inputs tracing back to a group or person, and each person for himself decides how much the coin from another person is worth? That sounds potentially way too many things to track.

    So everyone has his own distinguishable coin ("really different"). Now people can "connect" - that would mean for both signing a message that they exchange there coins 1:1 (of course other exchanges rates can develop on market places but to support the original idea of a UBI (unconditional basic income) this would not be supported by the protocol. As soon as 2 persons have signed such a message the system would use such paths as needed (similar to ripple). The second way people can connect is with groups. Groups can add people (there accounts) to a group. This would give everyone who holds money of group members the option to convert this money into the group money.

    The reason why you connect to other people could be altruism (maybe your family members) Or you see potential in the person in a few years. To really establish a reliable UBI you need to be part of some bigger group that in the end pays you (accepts you money) just because you are part of this group. In theory there could be the group "Mankind on earth" but it will be difficult to find good rules for managing it. However, groups like citizen of a country with electronic passport might succeed.

    Not that the membership of a group can always just increase the worth of your personal coin since you always have the option to convert your coins (irrevertible) into group money but you can not be forced to. This is why the value of you coin is always >= max(value(group1), value(group2), ..., value(groupN))
  • ArcurusArcurus Member Posts: 3
    sounds great! Funny, just though the last year about something similar. Maybe sharing storing place could be a great thing to start with building up the initial trust relationships. Something like the ripple protocol could be used for consens making. As unique note list, each node can use its trust relationships to other nodes.
  • koeppelmannkoeppelmann Member Posts: 51
    I agree - a ripple like own consensus mechanism would be possible - but if it is build on ethereuem this would not be necessary.

    What do you mean by "sharing storing place"?
  • koeppelmannkoeppelmann Member Posts: 51
    One possible interpretation of the system that may make it more clear why it could work:

    Money is debt
    There is a interpretation of money as exchangeable debt. This is one way to understand this system: you basically you give all your friends the ability to take a loan from you. This loan is documented by the fact that you own "money"/debt of the other person. So if everyone keeps its basic income basically everyone is at 0. As soon as someone spends something he takes a loan. However - instead of paying interest on it he even gets interest on it - or better explained - the loan disappears over the years by the inflation/demurrage fee. This may sound like a system where everyone would like to take as much loans as possible. Note that this would mean that you would be spending your basic income. So it would come at the price of not being liquid.
    In the financial world as we know it today banks give loans to people in a complicated and costly process. In this system loans are granted p2p or by the belonging to a certain group. This is much more cost efficient and maybe even a stronger verification.
  • ArcurusArcurus Member Posts: 3
    with "sharing storing space" I mean: node A stores stuff from node B. Node B (or a contract) is continuously testing that A stores correctly. As time goes Node B trust more and more node A if tests succeed. Trust can be measured as KilloByte*Days. The more node B trusts A the more node B is willing to store stuff from node A and friends of node A. In best both would store the equal amount of data over the same time. So both would trust each other the same. If Node A stores more then Node B, there is an discrepancy. So Node A would reduce Node Bs and firends of Bs stuff, or would want to have an payment. Of course Node Bs trust could be exchanged in an ripple style way to pay A.
  • ArcurusArcurus Member Posts: 3
    On top of the storage currency you cold lay an basic income currency. With for example 5% of the storage currency is demuraged and given out as basic income to registered participants. to become an registered participant, one must deposit one month worth of basic income.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Still dont get it, once you have a chain of 1:1 trades to a large group, your coins are worth 100% the value. So at that point you can basically Sybil attack, attaching to that starting point, and get tonnes of coins? Would seem to me that a single point of failure can take it down..

    I still like the more general idea, because there are lots of things to try. Basically there must be strong limits on how much mostly-disconnected parts can transfer coin to each other. For instance, you could use connections that arent entirely efficient, or 'tire', becoming less inefficient as more coin passes, or have some form of upper limit.. Idea being that for a Sybil attack to be effective, you need to convince many of the participants to create bad connections.

    (also: being a bit annoying, sorry; there: "over there"(location), their: "belongs to them", they're: they are. All different meanings!)
  • koeppelmannkoeppelmann Member Posts: 51
    Jasper said:

    Still dont get it, once you have a chain of 1:1 trades to a large group, your coins are worth 100% the value. So at that point you can basically Sybil attack, attaching to that starting point, and get tonnes of coins? Would seem to me that a single point of failure can take it down..

    So lets say Alice is an attacker and she creates 100 accounts and connect them all to each other and with her and - since she is a real person, she is connected to the merchant Bob.
    Now any of the 100 fake accounts can pay Bob since they are connected over Alice. So lets say a fake account - lets call him "Sybil" - will buy something from Bob for 10coins. What would happen is that Sybil sends SybilCoins to Alice and Alice send automatically 10 AliceCoins to Bob. So this mechanism does of course only work as long as Alice has coins. That is what im calling in the proposal a "liquid connection". So as soon as all AliceCoins are spend all the fake accounts could not any longer spend money at Bobs shop. So Alice now owns a lot of worthless SybilCoins - and that is no advantage at all.
    Jasper said:


    (also: being a bit annoying, sorry; there: "over there"(location), their: "belongs to them", they're: they are. All different meanings!)

    Oh no, don't worry: thank you for mentioning! By the way this is the reason why I linked to pirate pad so its easy to edit. My written english is really not good and usually google translate improves it, but this are the kind of error that are not filtered by it. Anyway I try to write more careful.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    If there are two clusters A, B, and one node connects them, and A only buys from B(not other way around) only coins from the connecting node are worth anything in B. So A gets 'one UBI', in B, if there are N connecting nodes, N UBIs. Actually if there is a trade discrepancy, it can at max be the number of UBIs implied.

    I think that means that having a coin for each person, and assuming effective swapping, it is equivalent to UBI and one UBI trade discrepancy 'accross a node'.

    Seeing it that way, it also seems like we might have equalled two constants in the system that can be separate. After all, you could set the UBI and trade discrepancy to be different.(though then it is no longer equivalent to many-coins) Also, it is "across" a node, an alternative would be per-edge, or a combination.

    Making connections to productive clusters is incentivized, because for each connection you get flow to get coins there, so you can pay for stuff. But adding badly connected unproductive clusters, can be bad to your own cluster,(and node) as coin will use up capacity of paths to the greater system. This is of course a mechanism to ensure people don't accept people that create fake clusters of people. However, how do you make sure people know those clusters are fake? Simply limit the level of damage in coins to the number of UBIs the fake personas connect with? A waiting time?

    What if merchants try to pull off adding a new node for each payment?

    It's important to try understand how the thing will operate... I should try a mathier version of this..
  • koeppelmannkoeppelmann Member Posts: 51
    great!! Now we are getting to the core! This is exactly what should be done next - check if the incentive structure for everyone in the system is sound and if the system will likely lead to the intended UBI.

    Maybe a simulation would be useful. Nodes (people) can be defined by a production factor (n-dimensional vector - where n are the different types of products), a consumption factor (same n dimensional space), and maybe an m-dimensional vector indicating to what social group they belong.

    Now the simulation would assume:
    • that some groups exist with different rules (maybe accepting people within a certain distance from a point in the social vector space or just having an certain productivity factor in one productivity dimension (like all the producers of a certain good).
    • People randomly connect to each other based on the social distance (and maybe also the consumption/productivity ratio)
    • People will connect if the connection helps both to fulfill a consumption need with this connection.
    • people spend money (if they can) if a consumption dimension lines up with a productivity dimension
    Of course lots of rules can be added...

    I'm not sure what the result of this simulation would be, I guess we'll just have to see. Do all people get connected somehow or get some isolated? How would a fake group perform (all with a very specific social dimension but with a 0 vector of productivity) And much more...
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Going a little slow. It is just the model that is in my head, but i think that if you have a system where each connection can transfer at max one UBI, then if two portions have connections and the trade imbalance exceeds that, then either you have "first come first serve", or people will anticipate it, and create an in-effect exchange rate.
  • koeppelmannkoeppelmann Member Posts: 51
    This is a very similar approach: http://ucoin.io/
    I really like the arguments here: http://ucoin.io/theoretical/ that can be 100% used for the "CIRCLES" approach discussed here.

    However, besides from using an own blockchain they plan to issue only one currency for all participants. The Sybil attack problem should be solved by WoT approach also based on personal connections between people.

    I think to have only one currency is too dangerous because a sybil attack can harm the hole network and not only those who directly trust the attacker (who are indeed somehow responsible for the attack)

    Nevertheless, the WoT approach http://ucoin.io/theoretical/#blockchain-wot is super useful for the rules of "groups" in the here discussed "CIRCLES" proposal.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Not clear what the groups do exactly. So if a node is disconnected, the coins it spreads around become useless. Do groups somehow mitigates coins "useless-ized" this way?

    For instance, if you show some of your coins can no longer be used, you get a fraction of other coins others in the group have, compensating for it.(potentially partially) The amount the others 'chip in' could be some arbitrary function, for instance just the same factor of the total number of useful coins each account has.
  • twiceddtwicedd Member Posts: 2

    they plan to issue only one currency for all participants.

    Hmm no! We plan to have any number of currencies. Where did you see that so we can correct?

    I think to have only one currency is too dangerous because a sybil attack can harm the hole network

    Of course, a large currency also needs to have a large Web of Trust, hence permissive rules like a large WoT diameter. However, a too long distance between members won't permit trust between members. So there is probably a maximum size for a WoT. We typically think a distance of 3 (so 4 members invovled) is probably the longer acceptable distance.
  • koeppelmannkoeppelmann Member Posts: 51
    Hi @cgeek‌! Thanks for joining the discussion!

    And sorry for making false statements on your cool project. I just read over the FAQ and some forum posts (about 2 month ago?) and never came across the concept of different coins/WOTs so I assumed there would be only one.

    How to they connect to each other? Every one on an own blockchain - so completely separated? Or one blockchain with several WOTs? Can a person be part of several WOTs? Will it receive a UBI from every group?

    I would strongly vote for one blockchain and a person could be part of different WOTs based on its personal connections - however - the person would have to choose only one WOTs group at a time to get the UBI.

  • twiceddtwicedd Member Posts: 2
    Each blockchain will be a WoT and a currency. An individual can be part of several WoT, hence several currencies, and can have several UBIs.

    You might think this is "unfair", but it's definitely not: as a human, you already belong to several communities. Obviously, I belong to "France" community, but also uCoin one. Why couldn't I touch both UBIs?

    France UBI & uCoin UBI are different, that's why their is no problem. I do not touch 2 France UBI, neither 2 uCoin UBI. You do not have the same "buying power" with France UBI and uCoin UBI. These are just different :smile:

    Imagine: I could also get the "Diablo 2 community" UBI. Why would you care about that? :wink:
  • SmithgiftSmithgift Member Posts: 64
    edited January 2015
    I'm thinking on how to implement this, which would probably be way easier than making a simulator. After all, if it takes off, we know it works, no?

    After thinking through the options, I think the best way is to have one mega-contract, which I will call the Master, and a number of Personal contracts.

    (My brain isn't in programming mode right now, so no pseudocode for the moment.)

    The Master contract would have several functions. One, "create_coin" would create a Personal contract, assigning all the Personal coins to the sending account. Another, "set_exchange" would allow two users to agree to allow exchange between their currencies (defaulting or always set to 1:1.) "make_exchange" would force an exchange between two coins. Finally, there should be a programmatic way to find who has what exchange rate with whom, but that's about it for the Master.

    The Personal Contracts would be created directly by the Master, and the Master will refuse to register any exchange rates between contracts that it did not create. They would be just like the standard coins you find in tutorials, with the exception that the Master contract can make transfers in it at will (so the exchanges can happen.)

    For Charlie to buy a cake from Alice through Bob, the front end would do something like this:

    1. Send a "make_exchange" to the Master swapping 30 Charliecoins for 30 Bobcoins.

    2. Send a "make_exchange" to the Master swapping 30 Bobcoins for 30 Alicecoins.

    3. Send a transfer message to Alice's Personal contract (in which Charlie now owns 30 Alicecoins) sending 30 Alicecoins to Alice.

    Alice (who now has 30 more Bobcoins) should now actually send the cake to Charlie.

    The first programmatic wrinkle I can see here is that the demurrage/UBI cycles needs to be synchronized, because I'm sure there is some bad thing you could do if it is not. The simple solution is to allow no transactions in a Personal contract if the cycle has not happened yet. Meanwhile, anyone can send a "cycle" transaction to the Personal contract which does the cycle if it needs done. I have a feeling most people will be entirely willing to pay for a transaction which gives them income and demurs someone else's coins. (The Master cannot do this, because it would take an enormous amount of gas to cycle every contract, and would hit the gas-per-block maximum inevitably [by attackers creating useless coins, if nothing else.])

    Wrinkle two is that the transaction may take some time. Each transfer in this system takes a block to actually happen, and so it takes 36 seconds in the above example for Charlie to get that Cake ordered. If something happens along the way, such as someone else making another transaction-chain going across the same coins (and therefore there not actually being coins to transfer when Charlie's come along), the results are non-obvious and probably harmful. A sufficiently bad set of chains might possibly create a deadlock situation(?). Worse, if Alice's bakery becomes extremely popular, there might not be enough Alice-coins to go 'round.

    (One Master contract that stores both exchange rates and the actual coins might be a better system, come to think of it. Then again, a contract holding so much data might run into its own problems, and dangers such as one storage figuring out how to overwrite the other.

    NINJA EDIT: On further thought, there is nothing stopping the make_exchange Master function from taking a whole chain of exchanges, though it would be more expensive in gas. At least the transfers would be atomic, though.)
  • koeppelmannkoeppelmann Member Posts: 51
    edited January 2015
    Hey @Smithgift‌! Thanks for your ideas!

    Indeed - such a "master-contract" would be the way too go. You left out the groups (guess I need to explain them better soon) but they can easily be added.


    The first "wrinkle" you mentioned (demurrage fees cycle) can be solved much easier. Actually I should update the first post - I think it is mathematically the same, psychological maybe better and easier to implement to constantly increase the rate of your basic income instead of having a demurrage fee.


    First lets assume a constant income rate. You would not update all the time the balance - you would shout save a timestamp for the account creation and than you would just save the amount spend or received by transactions ans always make sure that you do not spend more than what was created until know.

    very simplified:
    
    register:
        storage[tx.sender][0] = timestamp
        storage[tx.sender][1] = 0
    
    get_amount(account):
        duration = currentblocktime - storage[account][0]
        created = duration * 100
        return created + storage[sender][1]
    
    send(receiver, amount):
        if get_amount(tx.sender) >= amount:
           storage[tx.sender][1] -=amount
           storage[receiver][1][tx.sender] += amount
           // note that every account has lots of amount for all the currencies it owns
        else:
            stop
    
    So the same can be done when the created factor (in my example 100) is not linear but instead a function of the time since the beginning of the system with an annual increase of x% (2%?).


  • SmithgiftSmithgift Member Posts: 64
    @koeppelmann‌ That [constant increase] does make more sense, though it will increase every transaction's gas cost by a little. That might not be even noticable, though.

    NINJA EDIT: What happens to people who join later? I may wish to convert 1:1 to a guy who I absolutely trust, but if he joins the system years after I do (and therefore has far far fewer coins in circulation), the mathematics of converting Guycoins to Smithcoins is nontrivial, especially since we will be growing at different rates as time progresses.

    I didn't include groups as I wasn't sure how exactly they worked, or differed from a single account with exchange agreements to all group members. It's probably as simple as modifying the Personal contracts to comprehend the destruction of Personal coins and adding a new "Group" contract.

    I'm still concerned about the popularity problem. If Alice has more kinds of Personal coins, for example, that she accepts for her cakes, she would get more basic income from having multiple coins contracts. If those extra contracts had some flag to not have any UBI, then they are not as valuable/fungible as the original Alice-with-UBI coins, which brings its own set of headaches.

    It's possible that that Alice could accept Bobcoins as well as Alicecoins, but then we have a run on Bobcoins when Alice's bakery takes off. Or she could accept any coin, calculating its value through the exchange rates and fees it would take her to convert it to Alicecoins--but there's the inherent danger that the value might fluctuate. Instead of having one volatile currency to worry about, we now have literally seven billion of them.

    (I suppose computers could automatically deal with the volatility by converting the coins in a user's wallet based on certain metrics. I also think this would be just asking for some horrible cascading failure with too many automated processes acting completely rationally and self-interested.)

  • SmithgiftSmithgift Member Posts: 64
    Further thoughts:

    Truth be told, there is not perfect fungiblity between two coins except in ideal scenarios. Charlie may wish to have Alicecoins just in general, if he regularly buys cakes. But Alice may wish to have Largegroupcoins or Importantpersoncoins or Famouspopstarcoins. Meanwhile, Dave might just want to have whatever coin seems the most stable at the time. If the perceived advantage from switching is greater than percieved-average-risk-of-loss + transaction fees, the rational decision is to make the trade. And while you or I will hopefully have better things to do than sit at the keyboard all day executing trades for penny profits, a computer can do that all day long for its owners.

    This essentially means we have something like (7.1 billion * mean_inter_Personal_coin_connections) /2 Forex markets going at once, not including Groups, Sybil accounts, accounts of the dead*, other strange things, etc.

    There is the additional problem that these transactions can both be automatic and involuntary. Someone you've never heard of might make a twenty-account-long transaction chain that routes through your account, and suddenly your portfolio has some Neighborcoins and some neighbor 's portfolio has some Youcoins. If you consider Neighborcoins and Youcoins to be worth exactly the same, that's not a problem, but again, except in perfect scenarios they are not truly fungible. At the very least it will cost you a little more gas to use the other coins.

    A possible (but more complex) solution is to allow exchanges rates to be contracts themselves, so you can specify your own monetary policy as the market changes. Then again, this will lead to an even bigger disaster if things go south.

    * Do dead people still get UBI? If they do, people who get access to an UBI account (after say, a funeral) will get more UBI themselves. Do they not? I'd be a bit wary of accepting Riskyneighborcoins, because if Riskyneighbor dies I now have less valuable coins.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @Smithgift actually people create edges in the graph by accepting one-to-one. There might not even be a way to exchange coin without accepting to on-to-one conversion. Until there is enough chance the coin runs out, the coins are at one-to-one.

    Sending coins further away causes a "switcheroo" where people one-to-one switch until both parties are satisfied. Note that the switches are all local. It is a bit like electic dipoles responding to an external field, the electrons moves a tiny distance, but it causes effective charges.

    If the trade-inbalance is greater than how far people can "polarize" the ownership of coin no more coin can move. Value difference might then occur because this state might be anticipated. Basically people would buy in the direction that gets stuck, before it gets stuck, to sell those coins in terms of some other coin. It would likely be better if there was a neat mechanism that prevents a race to try figure out the best strategy to do this.

    Death is a problem. Perhaps you could add a 'poke' feature that keeps "coin creation". That doesn't stop people from trying to hide the death of old parents.(if they have the privkey) I expect this might need to be backed up with a at least a second system.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Smithgift said:

    I'm thinking on how to implement this, which would probably be way easier than making a simulator. After all, if it takes off, we know it works, no?

    I say we act less rashly, and try think and analyse things through. Better chance of success, more lessons learned if it fails.
  • SmithgiftSmithgift Member Posts: 64
    edited January 2015
    @Jasper: The "lack-of-possible-polarization" problem is what concerns me.

    Suppose Alice has a hundred Alicecoins. Suppose a hundred people want to buy a cake from her every day, each at the price of one Alicecoin. They get the Alicecoin by swapping to a Bobcoin (because Bob has a 1:1 trading relationship with Alice) and then swapping their Bobcoin for an Alicecoin, with which they pay Alice.

    Suppose for the sake of the scenario the "block time" is a day.

    The moment she spends one coin, one person can't buy a cake that day. So let's say the price of Alicecoins grows over the next few days, and some people who do not even like cake begin buying Alicecoins to speculate, and until they spend their Alicecoin (or it demurrs away), its gone from circulation. Now Alice may only have a portion of her original Alicecoins with which people can swap with to pay her back. At this point she will have accept other coins from beyond her direct neighbors. or lose business. If she does (and this happens all over the world) people will inevitably end up with a weird mish-mash of coins from all over the network, of various values.

    OK, but the block time isn't a day, and people will probably not completely overload a real-life Alice with more orders than her Alicecoins can service every 12 seconds, right?

    Well, suppose she still has a hundred Alicecoins, which in today's money would be $100 USD. Suppose someone comes and wants to buy more than $100 worth of cake. "OK," she says, "Buy it in chunks."

    Suppose Alice has exactly five neighbors, Bob1 to Bob5.

    So the big cake-buyer buys one $100 cake, using Bob1coins which he swaps with Alicecoins. Alice ends up with 100 Alicecoins, 100 Bob1coins. Bob1 has 100 coins of some other kind, originally belonging to the big cake-buyer.

    So the big cake-buyer buys another $100 cake, using Bob2coins which he swaps with Alicecoins. Alice ends up with 100 Alicecoins, 100 Bob1coins, 100 Bob2coins. Bob2 has 100 coins of some other kind, originally belonging to the big cake-buyer.

    Fast forward to Bob5. Alice now has 600 coins, one hundred of her own and a hundred from each of her neighbors. The big cake-buyer wants to get more cake, but there is no possible route to get to her. Everyone who owns a coin within a neighborhood of 1 from Alice is out of their own coins. To receive Alicecoins again, Alice has to spend some neighbor's coin. If she doesn't have anything to buy, she can't sell anything at all--except for distant coins!

    EDIT: And if in the process of buying so many Alicecoins, the big buyer ran some other nodes of the network out of their personal coins, there is now even more issues with the network.

    Add in attackers, highly traveled routes running out of coins, and simple mistakes and we have a dangerous mixture.

    Re: implementing as opposed to simulation. I don't know. The simulation would have the advantage of being safe, but testing it on, say, the test net might give a more accurate result of the idea's performance in real life.

    I do agree we shouldn't be, say, petitioning any government to accept something that has not even been fully designed yet.
  • SmithgiftSmithgift Member Posts: 64
    (I was writing this post when the above came up.)

    After a LONG amount of thought, I think I've found a mix of @koeppelmann's debt-with-reverse-interest and the ideas from here that might work.

    Consider this:

    There is one master currency, which I'll call "Ubis." It comes only in bonds between two accounts, i.e. Bob agrees he owes 10 Ubis to Alice.

    Meanwhile, groups issue tokens, which I'll call "cards." They represent membership in a Group, (however that Group defines it) and also that the Group will back your debts to a point (also however that Group defines it.)

    Accounts can also determine how they value the cards of the Group, in Ubi-per-day. For example, Alice values the "Three-letter-name" group with 1 Ubi-per-day. This means that Alice will treat a member of the Three-letter-name group as if they had one Ubi of income every day. It doesn't matter if Charlie or Dave think the "Three-letter-name" group is bogus; Alice will still Personally treat Bob as having (days with Three-letter-name group card * 1) Ubi.

    Now to some examples of spending.

    Suppose Bob of the Three-letter-name group wants to buy a cake from Alice. Bob has just joined the system, and the cake costs 10 Ubis.

    If it has been ten days since Bob joined, his total Ubis will be 10, and therefore he can simply buy the cake. He sends a message to the Master Transaction, which confirms that Alice thinks that Bob has 10 Ubis, and then makes a record that Bob owes Alice 10 Ubis.

    Suppose now that Alice needs to buy 6 Ubi of baking supplies from Aaron. There are two scenarios:

    1) Alice has cards from groups that Aaron recognizes (The name-beginning-with-a-group, and the three-vowel-name group). The Master Contract confirms she isn't in debt from spending that Ubi elsewhere, and therefore she can simply buy the supplies outright.

    Let's say she can't do that (she spend her other card's Ubi-per-day on hats). So option two...

    2) Alice can pay with her bonds. The Master Contract confirms that Alice did accept a bond of 10 Ubi from Bob. The Master Contract then recurses onto Bob, seeing if he can pay Alice by Aaron's standards. Aaron thinks the three-letter-name-group also is worth one Ubi-per-day, and therefore the Master Contract allows Alice to owe Aaron at most 10 Ubi that she got from Bob.

    Alice thinks this is OK, and the Master Contract records that Alice owes 6 Ubi to Aaron.

    Now Aaron, the next day, wishes to pay homage (and Ubi) to Lord ____, who despises Sybil attacks.

    By Lord ____'s standard, the Hangman Champion card that Aaron has is pretty awesome, and worth 2 Ubi-per-day. Aaron (who hasn't paid a homage in a week) can therefore pay Lord ____ 14 Ubi, but Aaron would rather pay his liege an even 20 Ubi. He offers the bond he got from Alice, but wait! Alice paid that Ubi from the Ubi she got from Bob. And Lord ____ despises letters, so he doesn't think Bob's Ubi (from the Three-letter-name group) is worth anything. Thankfully, Lord ____ is fond of hats, and unspent Ubi from Alice's Hats-not-hate card (which Lord ____ values at 6 Ubi a day) is worth enough to cover it. Note that Aaron could not care less about hats, and gives no value to the Hats-not-hate group, but the Master Contract approves. Now Lord ____ has 20 more Ubi to spend on the War Against the CamelCaseKingdom.

    tl;dr version:

    When spending N Ubi, the Master Contract must see, by the standards of your payee, that:

    1) You have cards that by the payee's standard have given you at least N more Ubi than your outstanding debts.

    2) You have bonds that show that someone (or several someones) owe you at least N Ubi. In which case the Master contract will recurse into your debtor's account and see if they can pay you that bond by by the original payee's standard.

    3) A mix of the above.

    The basic idea anti-Sybil idea is that even if you did create a million accounts with a million cards that you believe entitled them to a million Ubi every day, which they graciously sent you every morning, no one who doesn't recognize the Sybil-group-cards as valid will accept any of it.

    Meanwhile, you can provide charity to anyone by recognizing their card having a little more Ubi-per-day.

    The issue I can immediately see is that the "bonds" (is that even the best word for the concept?) are never repaid (as they always had the "money" in the first place) and therefore never are removed. Without caution this could hit bitcoin levels of blockchain bloat. I haven't thought of anything to prevent this yet, and I've actually ran out of thought energy writing this.

    I'm putting this up mostly for brainstorming, as is.
  • SmithgiftSmithgift Member Posts: 64
    IGNORE THE ABOVE COMPLICATED METHOD! A SIMPLER ONE AWAITS:

    Cards have limits (like, say, a credit card) and each account determines what that limit is when the card-holder is paying them. (Accounts may value cards differently, obviously.)

    The debt and value of bonds demurr over time. i.e. a bond of 100 at a reverse-interest rate of %2 is worth 98 next cycle, then 96.04 after that, and so on. Adjust with math if the demurrage is continuous rather than than in cycles. When the bond becomes worthless (a debt of 0), it is taken off the records.

    The payment verification works like this:

    1) Does the paying account have enough total limit from cards that the payee accepts? If so, stop and accept.

    2) Does the paying account have bonds that would pay the rest? If so, recurse into each bond's debtor to see if the payee would agree that the debtor has the Ubi (through card limits or bonds [in which case the recursion goes deeper]). If he does, return back up and mark the bond as valid. Otherwise, the bond is not considered valid by the payee and the payer must find a different method of payment (such as another bond). If there are enough valid bonds and card limits for the payment, stop and accept.

    3) If none can be found, stop and reject.

    Actually, an optimization is for the payer to figure out the chain of bonds/cards that the payee accepts, and send the message containing it; the Master Contract only verifies that that specific chain is correct.

    The weirdness of this system is that it would seem to heavily promote spending, as the more you owe, the more relative limit you get back through demurrage (and bonds owed to you slowly lose their value as well.) This was why I rejected this idea initially, but this is literally the point of demurrage in the first place.

    If you can buy cards (i.e. membership in a valued group) you can still save in this system, it's just more risky. Or you can just buy something physical like gold and hope it stays valuable or appreciates. This doesn't seem to be worse than our current financial system as-is.

    Meanwhile, storage use is drastically reduced (old bonds can be deleted) and it's more sturdy, IMHO. It doesn't matter if some distant guy Sybil-attacks some other guy, as long as you don't accept cards from the Sybil-group. It doesn't even matter if some distant transaction was invalid either, because the concept of "invalid" is a little relative in this system. A perfectly valid transaction from John to George may be invalid from Alice's perspective, while Bob's transaction to her may be equally invalid-looking from George's perspective.

    (We also don't have to worry about having a network and the problems with that. If someone accepts your card, it doesn't matter if they'd be one neighbor away in the original system or six.)
  • resilience_meresilience_me Member Posts: 7
    edited March 2015
    You might be interested in my system. I designed it 2012, and started developing 2014, and Bitnation have acquired it and it's received some media attention.



    It uses a concept called dividend pathways. Each transaction you make creates or adds to one of these pathways. Each pathway facilitates a flow of dividends up to the amount that was transacted to create the pathway. If you send me $100, up to $100 in dividends will flow through that pathway.





    The dividends are divided on everyone that's connected through these pathways. I call this a swarm, and I've called the algorithm itself swarm-redistribution or p2p-dividend protocols.

    The flow of dividends is then optimized through an optimization layer,



    You can see this optimization on the GIF below in real time,




    It uses an inventive structure, a sort of reward system, or you could think of it as a governance system that emerges from the feedback loops between producers and consumers,





    This meta-pattern, the incentive layer, is similar to what the co-operative business movement has used for decades,
    "The dividend scheme makes it more advantageous to be a loyal Coop member. As more people realize the economic benefits, the idea is that more people will become members, more people will shop at Coop and that casual customers will transform into regulars and consolidate their purchases to Coop. This will make Coop more profitable, making it possible to further improve the stores and offers to members. "

    -@CoopSverige, In Brief, 2010


    This incentive mechanism was described brilliantly in the Coinssource.com article,
    “This means that consumers who want to receive basicincome will benefit greatly from seeking out corporations that are connected to basicincome.co. Therefore, corporations are incited to join the network in their effort to gain and keep costumers. Not only will this mean that consumers can create a resilient financial safety net through making active consumerist choices. The corporations will also be encouraged to take greater financial responsibility for their entire supply line.”

    The system interfaces every currency online, bitcoin, ripple, NXT, and old banks too if they install an API so the app can read their ledgers. The system is like a third-party web-app, and all the user has to do is to sign their outgoing dividends, micro-payments, which could be automated if they let an app manage their password.





    Brief whitepaper, http://www.resilience.world/#!whitepaper/c21xm
    Videos, http://www.resilience.world/#!videos/c1xs3
    In Coinssource.com, http://coinssource.com/bitnation-decentralized-borderless-government-universal-basic-income/

    On Twitter, https://twitter.com/resilience_me



    re-posted from Self-Redistributing Wealth
  • koeppelmannkoeppelmann Member Posts: 51
    Sorry for the long absence. I tried to rewrite the initial post based on the discussion here and maybe described the concept a little bit more clear - also added some improvements. Therefore I started a new thread: https://forum.ethereum.org/discussion/2228/circles-universal-basic-income?new=1
Sign In or Register to comment.