[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Money with capabilities

From: Sebastian
Subject: Re: [Taler] Money with capabilities
Date: Thu, 19 Aug 2021 15:46:07 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi Ozgur,

Very interesting topic indeed. I will divide my questions in two parts:

1.- social consideration
2.- implementation related


I think it will be useful to define two kinds of capabilities: people
capabilities and money capabilities. Every group of people have
different definitions of people capabilities and if money adds or
reduces capabilities to those users there are problems. We want these
capabilities to match, always.

Also, I will define two mechanism to modify the current money
capabilities today:
 * reduce money capability: there are some users that should not be
using money in some ways (kids, people in recovery, just-for-food money)
 * adding money capability: there are some products/services that needs
permissions (guns, medicine, alcohol)

I think we can debate if one mechanism can be reduced to the other, like
in the absence of proving any capability the money has the less
restricted subset. But the main difference is:

 * the first is related to the user/destination of the money and the
mechanism is there in order to protect them in some way. We don't want
the user to reveal any information besides that they cannot buy it and
the user should not be able to pass this restriction.
 * and the second is related to the product itself, there could be
information in the ContractTerms that some extra validation is needed
and the restriction is not tied to the user of the money.

In this way, I think that giving GNU Taler the flexibility to reduce the
difference between people and money capabilities is only good. It should
create a better system to exchange value.

What do you think? Do you agree with these definitions?


First: could the implementation be flexible enough?

In your current proposal, Does this list need to be defined
exhaustively? What happens if it changes over time?

If we want to minimize the gap between people and money capabilities the
flexibility will depend on the size of the list or the possibility to
adapt over time. From your description I assume that this capabilities
are predefined.

I can easily imagine that the list of possible capabilities will grow
into a big big list.

Second: is the unlocked wallet for LPP a good feature?

I'm not sure if the ability to exchange LPP with UPP money has a
positive impact. For example:

 * You want Alice unable to exchange the currency for X product at "Xp"
 * There is a GNU Taler coin LPP that allow Alice to but stuff other than X
 * Bob can have generic GNU Taler coin for the same currency and it's
willing to exchange with fee R
 * Then this just mean that Alice will be able to buy X at Xp + R
 * This will also means that Bob can buy it at Xp - R

IMHO this will mean that in order to avoid unintended effect of the
capabilities the coins should have 1 defined use. Or maybe the
capability of this LPP to be traded for other LPP/UPP may also be a
capability? :)

Third: should the capability information be in the coin?

If we agree that we are trying to reduce the gap between what one person
can do vs what money allows you to do, adding this information into the
coin seems a bit redundant. It will be repeated into every coin and
having different capabilities in different coins will be also difficult
to communicate and manage.

Fourth: will this require a especial exchange? and the subsidiary to be
online in the coin minting process?

As I follow you, these specials coins will need some actions from the
Subsidiarity to mint this coins before the user has access to it.

I hope I have understood your suggestion and my questions are in the
correct direction. Looking forward to keep investigating this feature
and also learning from others. 

On 18/8/21 11:07, Özgür Kesim wrote:
> Hello Talerians,
> This is a post about the question: "What social impact would money
> have if it comes with certain constraints?".  It is a longer post and
> I thank you right away for taking your time to read it.
> My aim is to initiate a discussion and investigation of the landscape
> of scenarios and arguments for and against adding capabilities to
> digital money.
> Let me start with my premise.
> #  1  Universal Purchasing Power (UPP) of money and its implications
> Cash money is fungible:  Any two coins with the same denomination can
> be used to pay the same kind of stuff. It gives money _universal
> purchasing powers_ (UPP).  This clearly is a property that serves many
> people, if not the majority, well.  However, there are also
> consequences to UPP that negatively effect various groups of people,
> as I want to describe in the next sections.
> ## 1.1        Privacy disclosure
> For certain goods, the purchasing power of money is _not sufficient_
> to buy it:  For alcohol or other legal drugs, you have to prove to be
> of sufficient age.  Similar age restrictions apply when purchasing
> certain games, media and services.  Other purchases might require
> specific permits:  Renting a car, buying medical equipment, chemical
> components or weapons, etc.
> The general approach in these scenarios is to take the UPP of money as
> a given and to ask you for a proof of the fulfillment of the
> requirements, usually by _disclosing your identity_ or parts of it.
> (And I am not even considering the dangers of running IT-systems to
> store personal information here.)
> So here we have cases where UPP leads to the disclosure of private
> information.
> ## 1.2        Limitation of economic freedom
> The universality of the purchasing power of money can also have a
> _limiting_ effect for some people:  For example, minors usually need
> the assistance and/or supervision of the guardians/parents for online
> purchases, as parents might not trust them otherwise to purchase only
> permitted goods.
> So here we have a case where UPP leads to limitation of economic
> freedom.
> ## 1.3        Reduced wellfare
> Here is a delicate one: In public debate over wellfare provided by the
> state (or - on a personal level - on an encounter with a person in
> severe need), we notice reluctance in parts of the population to
> provide direct financial support to the needy.  This is often
> rationalized by prejudgement that the beneficiary would be using the
> money for goods that is considered harmful for him or herself.
> So here we have a case - if we take these concerns at faith value -
> where UPP hinders support and wellfare.
> ## 1.4        Assisting personal harm and financial ruin
> As we learn from social sciences, individuals may have difficulty to
> make sensible financial decisions.  For example elderly people or
> people with cognitive disabilities might need assistance when dealing
> with their allowances.  People with severe addiction to substances,
> gambling, shopping etc. might eventualy suffer from financial ruin and
> severe detriment to their health as consequence of their compulsary
> purchasing decisions.
> So here we have cases where UPP assists in leading to personal harm
> and financial ruin.
> #  2  Money with capabilities
> But what if there would be a type of money that has different
> _capabilities_?  That is: money without _universal_ purchasing powers
> but with a set of selected capabilities? (Of course, that type of
> money would exist _alongside_ with the usual UPP-money)
> ## 2.1        Prior art: foodstamps, coupons etc.
> In fact, we do already have similar restricted mechanisms for
> purchase, such as foodstamps and coupons with limited purchasing power
> (either limited to specific goods or specific vendors).  For the sake
> of argument let's consider those as money with Limited Purchasing
> Power (LPP).
> In a sense, I'm going present a generalized mechanism for money with
> LPP in the context of GNU Taler.  But with a twinge of euphemism I'm
> going to call it (limited) _capabilities_ instead of restrictions.
> ## 2.2        Purchasing capabilities
> Assume that we have a set of well defined capabilites, like
> | capability  | semantics                                                  |
> | ----        | ----                                                       |
> | age 8+      | Can be used to buy goods only allowed for age group 8+     |
> | age 18+     | Can be used to buy goods only allowed for age group 18+    |
> | alcohol -5% | Can be used to buy goods with ethanol content less than 5% |
> | nighttime   | Can be used when puying between 8pm and 6am                |
> | etc..       | ...                                                        |
> Also assume that these capabilities are publicly documented, so that
> there is no doubt what they mean.  We can even assume that they where
> defined and publicized by a legal authority.
> Now let's imagine that some of the minted money in circulation was
> inseperably bonded during minting with a selection of these
> capabilities.
> For example, a minting authority cold give out money with capabilities
> "age 14+" and "alcohol -5%", allowing that money to be used when
> buying stuff for age group 14 and older and beverages with alcohol
> content of less than 5%.
> Of course, the payment systems and inventories of merchants need to be
> able to recognize and handle those capabilities accordingly.  We can
> assume that standard UPP-money would implicitely have all capabilities
> set.
> ## 2.3        Subsidiarity and authority
> In the previous section I wrote "minting authority" as the authority
> that bonds selected capabilities to the money.  But in the context of
> GNU Taler we can even split and delegate some of the power of choice
> of capabilites, for example:
> Parents should be the authority that chooses the appropriate age group
> for the pocket money they are giving their children.  Similarly, legal
> guardians should be able to make such decisions for their wards.
> So we shall assume that the principle of subsidiarity[^1] applies 
> when the capabilities are selected by guardians for the money and the
> receiver of that money.
> [^1]: [Subsidiarity](https://en.wikipedia.org/wiki/Subsidiarity)
> #  3  Impact of money with capabilities
> Here I want to lay out some of the positive and negative impacts of
> money with capabilities that I can think of.   These thoughts are not
> complete and probably biased so the whole section is open for
> discussion.
> ## 3.1        Positive impacts
> I claim that with the introduction of capabilities for money, we offer
> relief in all the problems mentioned in sections 1.1 through 1.4.
> Money with age restrictions would make ID based age verification
> unnecessary. Similary for access to alcohol.  This would protect the
> privacy of the buyer and resolve the issues in section 1.1.
> (At least for those cases where showing an ID is not mandatory for
> other legal reasons - like medical equipment.)
> With money only having certain capabilities, guardians might be
> willing to let their wards make free(r) choices without supervision.
> This would increase economic freedom for the wards (see section 1.2).
> The argument can be extended to the case in section 1.3:  People might
> be less reluctant to help people in need, if they have some control
> over the purchasing power of the money - for example: if one can not
> buy alcohol with it.
> And finally, money with limited capabilities might be usefull when
> counceling or treating people with addictions.  A sensible selection
> of capabilities for their allowances might help to avoid selfharm (see
> section 1.4.)
> ##  3.2       Negative impacts
> I will now describe the negative impacts that came to my mind.
> ### 3.2.1     Misuse in oppressive goverments
> One could make the argument that the introduction of money with
> limited capabilites could be misused by oppressive goverments:  They
> could give out money with only certain capabilities set and make its
> use mandatory to every person and merchant.
> However, I don't think that oppressive goverments would need a
> monetary system to enforce such control.  They can (and do) simply put
> pressure on the merchants or declare some transactions as illegal.
> While I do see how capability based money could be used as a means to
> inact oppression, I don't see how UPP money reduces oppression in such
> a society - mainly because there is no money with UPP in those
> societies in first place due to the limited access to markets.
> ### 3.2.2     Lock-in to limited capabilities
> One could make the argument that people who are given only money with
> limited capabilities might be permenantly locked-out from legal access
> to money with UPP.  For example: Authorities might allow refugees only
> limited access to the market by giving them money with reduced
> capabilities.  
> However, in the context of GNU Taler there are at least two options
> available for the owner of money with limited capabilities:
> 1. Peer-to-peer transactions could be used to exchange coins with
>    limited capabilities for coins with UPP for a fee.  This would
>    allow for transparent and controllable transactions.
> 2. Based on trust, another person with access to UPP-money could
>    simply share their (UPP) coins in exchange for the coins with
>    limited capabilities.
> So I think that a monetary system based on GNU Taler can offer
> enough opportunities for exchange of UPP-money from LPP-money.
> # 4   Preliminary Conclusion
> I started with the premise that universal purchasing power of money
> has negative effects one some people in certain circumstances.  I
> argue that the introduction of money with limited, selectable
> capabilities, can be a relief or improvement in such situations.  For
> the presented negative impacts of such money, I either show that
> solutions exists or that the negative impact would exist different
> form even without money with limited capabilities.
> I don't claim to have covered all circumenstances, use-cases, positive
> and negative impacts (I'm neither a sociologist nor economist).  But
> based on my arguments I conclude that the introduction of money with
> selectable, limiting capabilities (alongside with UPP money) would
> provide a net benefit for societies.
> By ending this section I open the discussion.
> #  Appendix
> ## A  Sketch of the technical realisation in GNU Taler
> Imagine we select a particular set of capabilities an put them into an
> ordered list, like:
> 1. [ ] age 0+
> 2. [ ] age 8+
> 3. [ ] age 14+
> 4. [ ] age 18+
> 5. [ ] alcohol low
> 6. [ ] alcohol high
> 7. [ ] nighttime
> An exchange server in GNU Taler could offer to mint coins of specific
> denominations and a given list of capabilities, such as the one above.
> A custodian or subsidiary whith the ability to withdraw money from the
> exchange could select particular capabilities for a coin. For example,
> a parent might choose for its adolescent child:
> 1. [x] age 0+
> 2. [x] age 8+
> 3. [x] age 14+
> 4. [ ] age 18+
> 5. [x] alcohol low
> 6. [ ] alcohol high
> 7. [ ] nighttime
> Those selected capabilities would than be bound to the coin that is
> minted.
> Technically we can realize this the following way:
> 1. The custodian generates one cryptographic key pair per capability
>    (in our example: 7 key pairs).
> 2. The hash of all public keys goes into the minting process and binds
>    the capabilities to the coin.
> 3. The custodian gives all public keys to the ward but _only_ the
>    private keys for the permitted capabilities.
>    (In our example: Only the private keys to the 1., 2., 3. and 5.
>    capabilities are given to the minor).
> 4. On a purchase, the merchant can require some of those capabilities
>    to be set for particular goods - or that UPP money is used for the
>    payment.
>    (In our example:  When buying beer from a store, the system might
>     require the "alcohol low" capability to be set.)
> 5. If the ward is in possesion of the corresponding private key for
>    the required capability, it can sign the contract with those keys
>    and the merchant can verify them according to the public keys.
> There are a lot of details, complications and optimizations missing in
> this description, but this is basically the gist of it.
> Cheers,
> Özgür

Attachment: 0xBE4FF68352439FC1.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]