Should a user be able to send two coins at the same time

[ana0]

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)

[edzillion]

Some thoughts:

Transactions will often contain more than one coin type. this increases over time as a trust network gets more integrated. e.g. if all people are connected to all people then all coins are 100% fungible so you would have mix in every transaction.

but whats interesting about this is the strategy one takes to decide which coins.

1. Send my coins first, then send coins of greatest sum
2. Send mutual coins of the smallest sum first upward

1 benefits the reciever, 2 benefits the sender 2 will obv have much more diff coins than 1

[edzillion]

This raises the issue of transactions possibly having many coin types. Imagine this scenario:

Café Grundeinkommen sells 500 coffees in a week and now has 1000 circles from 500 people, if the Café were to pay their suppliers for coffee for the next week the 1000 circles it costs would be a transaction with 500 coin types.

[ana0]

Github will not let me emoji react to Ed's last comment with :scream: but let it be known, I want to

[edzillion]

meta :scream:

[dumpa]

Why not convert coins to my coins as soon add I get them? All coins i get now are mine. This solves the problem.

On Tue, 15 Jan 2019, 5:33 p.m. edzillion, notifications@github.com wrote:

meta 😱

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CirclesUBI/circles-contracts/issues/28#issuecomment-454577965, or mute the thread https://github.com/notifications/unsubscribe-auth/ABppjTFMGxuTxAaD8hobZiHfFRx3ClXPks5vDlc6gaJpZM4aB3yn .

[edzillion]

Why not convert coins to my coins as soon add I get them? All coins i get now are mine. This solves the problem

There is no converting of coins in the Circles system.

[dumpa]

Why not? We want eventually to converge to a single coin, don't we?

Is this not converting coins a technological constrain ?

I don't see why when I receive edcoins they can't become Juancoins, and when you receive juancoins they become edcoins. For me our makes sense. If I have the money, it is my money. And if you trust me you will want to trade with me and will receive my money.

On Wed, 16 Jan 2019, 8:03 a.m. edzillion, notifications@github.com wrote:

Why not convert coins to my coins as soon add I get them? All coins i get now are mine. This solves the problem

There is no converting of coins in the Circles system.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/CirclesUBI/circles-contracts/issues/28#issuecomment-454771346, or mute the thread https://github.com/notifications/unsubscribe-auth/ABppjaONipuge4z0B9bLqOwgSQh329Ksks5vDyMSgaJpZM4aB3yn .

[ana0]

@dumpa Converting coins (or losing the reference to the original account they were minted to) opens an easy attack vector: I make a sybil coin, send it all to my non-sybil account, and then voila, the sybil-heritage is gone and I can spend the sybil coins in my strong and real trust network.

I'm not sure what you mean by converge to a single coin?

[dumpa]

I understand.

Converge comes from an early Circles explanation (don't remember where), it said that as we create circles and we become more connected, our personal coins will converge into a single coin. As I understand, we are both in a circle then we can use that circle coin, and eventually preferred it from our personal coin. If we have enough circles we could end up with a common coin.

On Wed, 16 Jan 2019, 5:40 p.m. ana0, notifications@github.com wrote:

@dumpa https://github.com/dumpa Converting coins (or losing the reference to the original account they were minted to) opens an easy attack vector: I make a sybil coin, send it all to my non-sybil account, and then voila, the sybil-heritage is gone and I can spend the sybil coins in my strong and real trust network.

I'm not sure what you mean by converge to a single coin?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/CirclesUBI/circles-contracts/issues/28#issuecomment-454971932, or mute the thread https://github.com/notifications/unsubscribe-auth/ABppjTRaj4Y4fmx8mWTPbM4jp5QrT4ATks5vD6pigaJpZM4aB3yn .

[ana0]

Right - think that language is in the whitepaper. My interpretation was always that it meant something like, "behave like a unified monetary system," but there are also proposals for ways additional currencies could be launched on top of circles. It starts to get a little speculative at that point though

[dumpa]

I'm worried about the usability of too manu coins. It is not going to be simple if I carry one coin named after every friend I interact with. I don't think the best way to approach this Sybil attack is for the user to have lots of different coins and have to choose which combination to send.

If I'm trading with someone who is attacking the system then I'm responsible. I should be trading with people I trust and are good people.

There should be some bottom up control instead of top down. Let people pick there connections instead of labeling people.

I don't want to make our to complicated. I vote for simple.

On Wed, 16 Jan 2019, 7:22 p.m. ana0, notifications@github.com wrote:

Right - think that language is in the whitepaper. My interpretation was always that it meant something like, "behave like a unified monetary system," but there are also proposals for ways additional currencies could be launched on top of circles. It starts to get a little speculative at that point though

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/CirclesUBI/circles-contracts/issues/28#issuecomment-454994767, or mute the thread https://github.com/notifications/unsubscribe-auth/ABppjZv7mcC8dbVD9QYC-karLddUDNklks5vD8I4gaJpZM4aB3yn .

[edzillion]

If I'm trading with someone who is attacking the system then I'm responsible. I should be trading with people I trust and are good people.

This is one of the reasons why we chose the personal currency system. It protects against sybil attacks by making the fake coins easily identifiable, and the trust network enforces the rule that only the person who trusts that user will have those fake coins.

[ana0]

There should be some bottom up control instead of top down. Let people pick there connections instead of labeling people.

Yup, we're planning to let users have full control over these trust connections, and override all 'recommendations'. The recommendations are important though, for exactly the reasons you mention (cognitive overload of choosing which coin to send)

[ana0]

Some notes on dust:

To some extent, the problem of @edzillion describes above is a problem all blockchains have too, at a protocol level

Café Grundeinkommen sells 500 coffees in a week and now has 1000 circles from 500 people, if the Café were to pay their suppliers for coffee for the next week the 1000 circles it costs would be a transaction with 500 coin types.

This is similar to many small utxos on the bitcoin network, making transaction sizes large and increasing fees. Of strategies to reduce fees on the bitcoin network, probably consolidation is most relevant. Ethereum also deals with storage bloat, and actually explicitly incentivizes operations that clear storage which has had some fascinating second-order effects

Some options for dealing with dust:

1. A recommendation strategy that tries to reduce dust by consolidating currencies whenever possible.

ie. Alice is has 1 Bobcoin, 30 Carolcoin, and 20 Davidcoin, and she's trying to send 10 circles Ed. Ed has 10 Bobcoin, 0 Carolcoin, and 5 Davidcoin. Everyone trusts everyone, so the app recommends Alice send 1 Bobcoin and 9 Davidcoin. Now Alice has 30 Carolcoin, and 11 Davidcoin and Ed has 11 Bobcoin and 14 Davidcoin. Total 'pools' were reduced by 1.

It's not immediately clear to what extent this will mitigate the problem: there will definitely be transactions where there's no way to reduce dust. Increasing algorithmic complexity may give this strategy diminishing returns pretty quickly too

2. Prompt pool consolidation.

ie. Alice has 20 Alicecoin and 5 Bobcoin. Bob has 20 Bobcoin and 3 Alicecoin. The app 'notices' this and prompts them to swap. Alice sends Bob 3 Bobcoin amd Bob sends Alice 3 Alicecoin. Alice now has 23 Alicecoin and 2 Bobcoin, and Bob has 23 Bobcoin. Total 'pools' were reduced by 1.

Extremely questionable but possible: the app actually just does this for them in the background.

3. Explicitly incentivize reducing dust. It might be possible to do well, but also something to be very careful about. Incentives lead to perverse incentives.

[JuliointheStudio]

what if, as Dumpa says, there was an option for people who trust each other to convert other people´s coins to theirs? we don´t want to end up with a system where a lot of people have a bunch of coins they can´t really use. Normal LETS systems have exchangeable credits to all their members. I understand the attack problem but there it seems, from the options, that there will be a lot of complexity after some time. Why not allow people to interchange their coins after a certain threshold? xx

[ana0]

I think the problem is, what is the threshold? Any threshold opens up the possibility of this attack. A time-delay for the conversion doesn't mitigate it. A maximum amount to convert just means you need more sybil contracts. Even an overlapping trust graph doesn't mitigate it, because many sybils could all trust each other.

[dumpa]

I think I shouldn't have to think which coins to send, this has to be automatic. I want to pay coffee, if I have to think too much how to pay for coffee I would use something else. Maybe coins carry a history of where they come from, but when they touch me they are now my coins, and all are the same? will this work?

On Fri, Jan 18, 2019 at 1:14 PM ana0 notifications@github.com wrote:

I think the problem is, what is the threshold? Any threshold opens up the possibility of this attack. A time-delay for the conversion doesn't mitigate it. A maximum amount to convert just means you need more sybil contracts. Even an overlapping trust graph doesn't mitigate it, because many sybils could all trust each other.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/CirclesUBI/circles-contracts/issues/28#issuecomment-455638570, or mute the thread https://github.com/notifications/unsubscribe-auth/ABppjVnvVEeWZTFoeSmNDrLuioHrWfo4ks5vEg8ggaJpZM4aB3yn .

[ravachol70]

This sounds like a proper scalability issue. Two things struck me as I review the commentary.

1) Circles could be implemented using a Multi-Class token model where every class (partition) is its own user/identity. This should take the multi-transaction case into clearer light; it might also address scalability.

2) At the other end of the spectrum, if a singular mainnet ERC-20 presence is not an initial requirement, then Circles could sponsor another chain, turn each and every user into his/her own ERC-20 token on that chain, then establish the exchange by specialised management, e.g. curation/promotion of the chain's real-world economy.

[ravachol70]

For #1, see the multi-class Plasma cash example here:

https://blog.polymath.network/what-do-in-game-credits-plasma-cash-and-security-tokens-have-in-common-1b490843ab85

[ana0]

maximum flow addresses this, at least in terms of allowing for parallel sends