Topic: Mastercoin Limited Account - new feature suggestion (Read 2371 times)
following
For the main balance view, I would say respect the principle that the main balance is exactly what you can currently spend. So if you have 100 MSC plus a limited account with 50 per week of which you've already spend 27, show the balance as 123 MSC.
The thing is that if you include these in your main balance, then that balance can change out of "no fault" or action of your own, which is highly counter-intuitive.
Hmm. Well, if you authorized another account to make limited withdrawals from your account, then I think you should realize that the balance can change due to no fault of your own. But if you own a limited account, then I suppose you do have a point, that should be handled separately.
Perhaps something like:
1622 MSC (+17.23 BTC from limited accounts)
Alternatively, perhaps you might not even want to mix up your main balance and limited accounts at all, just creating a separate tab for them and including a "withdraw from limited account" button beside each one to transfer money from the limited account to an address fully controlled by yourself.
Yeah, these suggestions can all work.
Alright, we've covered some nice grounds here. I would like to get more eyes on this by developers / Willett. Not urgent though, there are other features in the pipeline with higher priority.
For the main balance view, I would say respect the principle that the main balance is exactly what you can currently spend. So if you have 100 MSC plus a limited account with 50 per week of which you've already spend 27, show the balance as 123 MSC.
The thing is that if you include these in your main balance, then that balance can change out of "no fault" or action of your own, which is highly counter-intuitive.
Hmm. Well, if you authorized another account to make limited withdrawals from your account, then I think you should realize that the balance can change due to no fault of your own. But if you own a limited account, then I suppose you do have a point, that should be handled separately.
Perhaps something like:
1622 MSC (+17.23 BTC from limited accounts)
Alternatively, perhaps you might not even want to mix up your main balance and limited accounts at all, just creating a separate tab for them and including a "withdraw from limited account" button beside each one to transfer money from the limited account to an address fully controlled by yourself.
For the main balance view, I would say respect the principle that the main balance is exactly what you can currently spend. So if you have 100 MSC plus a limited account with 50 per week of which you've already spend 27, show the balance as 123 MSC.
The thing is that if you include these in your main balance, then that balance can change out of "no fault" or action of your own, which is highly counter-intuitive.
I would suggest to simplify things by only allowing withdrawal in the currency that was specified in the operation, and not get into automatic conversions.
Sounds reasonable.
What if the feature was implemented the way you originally suggested? How would multiple currencies work there? Would you need to set a separate limit for each currency, defaulting to 0 otherwise?
Yes indeed, this was my original plan.
I'll soon get the Mastercoin spec uploaded to github in the form of markdown, we can start editing the spec and adding various features in a more formal way.
Vitalik, what do you think about my original reservations from your version - specifically, how would we visualize this sort of shared balance in the wallet software and explain it to users?
For the main balance view, I would say respect the principle that the main balance is exactly what you can currently spend. So if you have 100 MSC plus a limited account with 50 per week of which you've already spend 27, show the balance as 123 MSC.
In the view that shows your addresses, there would be three types of addresses:
1. normal addresses that are yours - depict these normally
2. addresses that are yours but for which someone else has a limited account - depict some kind of icon, and optionally the precise conditions in brackets. If the limited account has less money in it than the limits allow, display it in red.
3. addresses that are limited accounts - highlight the entire row yellow, and show (1) the precise conditions (eg. 50 MSC per 7 days), and (2) the maximum amount that you can currently spend
For example:
1P9AVPviAZeixJbwVbpX2RmYRFXh3RfDHW 7.125 MSC
1JYCo3X2So2Gm3XDztiPX91sLt4pof8Mzb 2.022 MSC
1M4VFHiR4VWt1b73EPEf1eGPdnXGTyBdQt * (-1 MSC per 30 days) 6.12 MSC
16trAPnrPsZf1kW3oDoAxCAnUHA6onw8VA (10 MSC per 7 days) 10 MSC avail.
1M4VFHiR4VWt1b73EPEf1eGPdnXGTyBdQt * (-15 MSC per 30 days) 12.9 MSC
1M4VFHiR4VWt1b73EPEf1eGPdnXGTyBdQt * (-0.2 MSC per 6 hours) 3.38 MSC
You can also have a special tab for just limited accounts.
I would suggest to simplify things by only allowing withdrawal in the currency that was specified in the operation, and not get into automatic conversions.
Sounds reasonable.
What if the feature was implemented the way you originally suggested? How would multiple currencies work there? Would you need to set a separate limit for each currency, defaulting to 0 otherwise?
Yes indeed, this was my original plan.
I'll soon get the Mastercoin spec uploaded to github in the form of markdown, we can start editing the spec and adding various features in a more formal way.
Vitalik, what do you think about my original reservations from your version - specifically, how would we visualize this sort of shared balance in the wallet software and explain it to users?
I would suggest to simplify things by only allowing withdrawal in the currency that was specified in the operation, and not get into automatic conversions.
Sounds reasonable.
What if the feature was implemented the way you originally suggested? How would multiple currencies work there? Would you need to set a separate limit for each currency, defaulting to 0 otherwise?
I would suggest to simplify things by only allowing withdrawal in the currency that was specified in the operation, and not get into automatic conversions.
Elaborating on my proposal:
SETUP_LIMITED_ACCOUNT(address X, address Y, LIMIT, INTERVAL, CURRENCY)
Once the command is made, private key y (corresponding to address Y) would have the right to withdraw money from address X, but the transaction would be invalid if, including the transaction, more than LIMIT units of CURRENCY get withdrawn within a span of INTERVAL, where the "time" of a transaction is defined as the timestamp of the block it is included in. The CURRENCY parameter could either be (1) BTC, (2) MSC, (3) a Mastercoin-based custom currency or (4) a price index published by some organization leading back to either (1), (2) or (3).
The reason why I say "address X" and "address Y" is that you might want to create a limited account for a multisig, in which case there is no single private key. The authorization would come in because one input to the SETUP_LIMITED_ACCOUNT transaction (probably input 0) would need to come from address X, and by Bitcoin's rules the transaction would then need a valid signature for address X.
Example:
-> SETUP_LIMITED_ACCOUNT(X,Y,10,1000000,'Bitstamp:USD')
-> sign(send(X,Z,5,'Bitstamp:USD'),y), block timestamp 1370000000, txid 132
OK
-> sign(send(X,Z,3,'Bitstamp:USD'),y), block timestamp 1370500001, txid 2c4
OK
-> sign(send(X,Z,3,'Bitstamp:USD'),y), block timestamp 1371000002, txid 9ff
OK
-> sign(send(X,Z,5,'Bitstamp:USD'),y), block timestamp 1371500000, txid 81a
NOT OK (as 2c4+9ff+81a have total value 11 Bitstamp:USD but appear within the span [1370500001,1371500001), violating the constraint)
-> sign(send(X,Z,5,'Bitstamp:USD'),y), block timestamp 1371500312, txid cd1
OK
The command can also be used to adjust the limit (by calling SETUP_LIMITED_ACCOUNT on an address that is already a limited account), or revoke it (by calling SETUP_LIMITED_ACCOUNT(x,y,0,1,0)).
Use cases:
1. Your own Bitcoin account. Store the main password in cold storage, but first create an account with the right to withdraw 1000 Bitstamp:USD per week and put the privkey to that in a more accessible wallet.
2. Corporate wallet with limited employee rights. Company creates a multisig address and stores its funds there, but also gives Fred a limited account with 500 currency units per week, George 250 per week, Sam 250 per week, and every other employee 50 per week.
3. Recurring payments. I currently pay 40 USD per month for a Namecheap server. To simplify this, I might instead just give Namecheap a key to 40 USD per 30 days out of my account, and Namecheap could take the money automatically.
One challenge though: if the payments are made in a different currency from the currency in which the limit is measured, how is that to be calculated? In case 4 (indices), that's easy; just use the last index measurement at the time each transaction was made, so eg:
-> Bitstamp says: 1 BTC = 170 USD
-> send(X,Z,1,BTC)
Running total: 170 USD
-> Bitstamp says: 1 BTC = 206 USD
-> send(X,Z,2 BTC)
Running total: 582 USD
-> send(X,Z,1 BTC)
Running total: 788 USD
and so on. In cases (1 ... 3), however, it's harder; the markets are not precise, as there is always an ask-bid spread. One option is to always take the last order, but my worry is that in small markets it will be vulnerable to attacks (eg. attacker grabs all the orders down to to 0.2 CHF/BTC and then can withdraw as much BTC as desired from a CHF-denominated limited account). There are potential ways to mitigate this, but they all have their own potential vulnerabilities. One option would be to just let this vulnerability slide, and people would use indices for more security, but that has the downside of centralization. Another argument is that this really doesn't matter, as in the Bitcoin economy in practice sites like BitPay use exchange rates for their price data and they don't have problems from being scammed in the above way because the market is too deep and so an attack is too expensive. The more restrictive approach would be to allow withdrawals denominated in one currency only, and require the private key holder to make multiple limited accounts if they want to give themselves or someone else a limited right to withdraw in multiple currencies.
SETUP_LIMITED_ACCOUNT(address X, address Y, LIMIT, INTERVAL, CURRENCY)
Once the command is made, private key y (corresponding to address Y) would have the right to withdraw money from address X, but the transaction would be invalid if, including the transaction, more than LIMIT units of CURRENCY get withdrawn within a span of INTERVAL, where the "time" of a transaction is defined as the timestamp of the block it is included in. The CURRENCY parameter could either be (1) BTC, (2) MSC, (3) a Mastercoin-based custom currency or (4) a price index published by some organization leading back to either (1), (2) or (3).
The reason why I say "address X" and "address Y" is that you might want to create a limited account for a multisig, in which case there is no single private key. The authorization would come in because one input to the SETUP_LIMITED_ACCOUNT transaction (probably input 0) would need to come from address X, and by Bitcoin's rules the transaction would then need a valid signature for address X.
Example:
-> SETUP_LIMITED_ACCOUNT(X,Y,10,1000000,'Bitstamp:USD')
-> sign(send(X,Z,5,'Bitstamp:USD'),y), block timestamp 1370000000, txid 132
OK
-> sign(send(X,Z,3,'Bitstamp:USD'),y), block timestamp 1370500001, txid 2c4
OK
-> sign(send(X,Z,3,'Bitstamp:USD'),y), block timestamp 1371000002, txid 9ff
OK
-> sign(send(X,Z,5,'Bitstamp:USD'),y), block timestamp 1371500000, txid 81a
NOT OK (as 2c4+9ff+81a have total value 11 Bitstamp:USD but appear within the span [1370500001,1371500001), violating the constraint)
-> sign(send(X,Z,5,'Bitstamp:USD'),y), block timestamp 1371500312, txid cd1
OK
The command can also be used to adjust the limit (by calling SETUP_LIMITED_ACCOUNT on an address that is already a limited account), or revoke it (by calling SETUP_LIMITED_ACCOUNT(x,y,0,1,0)).
Use cases:
1. Your own Bitcoin account. Store the main password in cold storage, but first create an account with the right to withdraw 1000 Bitstamp:USD per week and put the privkey to that in a more accessible wallet.
2. Corporate wallet with limited employee rights. Company creates a multisig address and stores its funds there, but also gives Fred a limited account with 500 currency units per week, George 250 per week, Sam 250 per week, and every other employee 50 per week.
3. Recurring payments. I currently pay 40 USD per month for a Namecheap server. To simplify this, I might instead just give Namecheap a key to 40 USD per 30 days out of my account, and Namecheap could take the money automatically.
One challenge though: if the payments are made in a different currency from the currency in which the limit is measured, how is that to be calculated? In case 4 (indices), that's easy; just use the last index measurement at the time each transaction was made, so eg:
-> Bitstamp says: 1 BTC = 170 USD
-> send(X,Z,1,BTC)
Running total: 170 USD
-> Bitstamp says: 1 BTC = 206 USD
-> send(X,Z,2 BTC)
Running total: 582 USD
-> send(X,Z,1 BTC)
Running total: 788 USD
and so on. In cases (1 ... 3), however, it's harder; the markets are not precise, as there is always an ask-bid spread. One option is to always take the last order, but my worry is that in small markets it will be vulnerable to attacks (eg. attacker grabs all the orders down to to 0.2 CHF/BTC and then can withdraw as much BTC as desired from a CHF-denominated limited account). There are potential ways to mitigate this, but they all have their own potential vulnerabilities. One option would be to just let this vulnerability slide, and people would use indices for more security, but that has the downside of centralization. Another argument is that this really doesn't matter, as in the Bitcoin economy in practice sites like BitPay use exchange rates for their price data and they don't have problems from being scammed in the above way because the market is too deep and so an attack is too expensive. The more restrictive approach would be to allow withdrawals denominated in one currency only, and require the private key holder to make multiple limited accounts if they want to give themselves or someone else a limited right to withdraw in multiple currencies.
Hello everyone,
I'm starting this thread to discuss the specificaiton of a new Mastercoin feature suggested by Vitalik.
Here is the way I originally specified this feature:
Here is Vitalik's suggestion on how to implement this feature:
I do like his proposal, it's an interesting twist.
It's slightly different conceptually than what I had in mind - in this proposal, X is really the owner of the funds, and he's letting Y use his (X's) funds. It would be an interesting challange visualizing this in a wallet software.
In my proposal, the owner of the funds is X, and Y can set withdrawal limits on X, but can't withdraw any of X's funds.
I still need to give this some thought, I think there are pros and cons to each approach.
I'm starting this thread to discuss the specificaiton of a new Mastercoin feature suggested by Vitalik.
Here is the way I originally specified this feature:
I had an interesting conversation this week with Vitalik from the Bitcoin Magazine, and he suggested this cool feature:
Spending Limit
This feature would limit the rate at which a particular address can send mastercoins.
Here is how I would specify the feature: We would add two new operations SETUP_LIMITED_ACCOUNT and SET_LIMIT.
SETUP_LIMITED_ACCOUNT(priv_key_x, pub_key_y)
This operation would designate address Y as the "limiting address" of address X.
This means the owner of address Y can control the spending limits of address X.
SET_LIMIT(priv_key_y, pub_key_x, currency_ID, limit, time_period)
After a SET_LIMIT operation is transmitted (by the owner of address Y), only if there was a prior matching SETUP_LIMITED_ACCOUNT with Y's public key, then from now on outgoing transactions from address X in the specified currency are limited - for any window of blocks with length time_period, if any send operation would cause the sum of all send operations from address X within this window to cross limit, this send operation would be invalid.
The reason to use two different addresses is that we want to prevent an attacker that gained the private key of X to cheat the system by changing the send limit. You would use a more secure address Y to specify a send limit on address X (just like the Saving Account feature uses a Guardian Address (Y)).
The above is just my initial specification, we can beautify and formalize this a bit more.
I think it's a useful easy to implement feature and would love to see it in an upcoming version of the whitepaper.
Spending Limit
This feature would limit the rate at which a particular address can send mastercoins.
Here is how I would specify the feature: We would add two new operations SETUP_LIMITED_ACCOUNT and SET_LIMIT.
SETUP_LIMITED_ACCOUNT(priv_key_x, pub_key_y)
This operation would designate address Y as the "limiting address" of address X.
This means the owner of address Y can control the spending limits of address X.
SET_LIMIT(priv_key_y, pub_key_x, currency_ID, limit, time_period)
After a SET_LIMIT operation is transmitted (by the owner of address Y), only if there was a prior matching SETUP_LIMITED_ACCOUNT with Y's public key, then from now on outgoing transactions from address X in the specified currency are limited - for any window of blocks with length time_period, if any send operation would cause the sum of all send operations from address X within this window to cross limit, this send operation would be invalid.
The reason to use two different addresses is that we want to prevent an attacker that gained the private key of X to cheat the system by changing the send limit. You would use a more secure address Y to specify a send limit on address X (just like the Saving Account feature uses a Guardian Address (Y)).
The above is just my initial specification, we can beautify and formalize this a bit more.
I think it's a useful easy to implement feature and would love to see it in an upcoming version of the whitepaper.
Here is Vitalik's suggestion on how to implement this feature:
Quote
setup_limited_account(privkey x, pubkey y, limit, time period, currency) -> lets address y withdraw from address x at a maximum rate of limit per time period as measured in some currency
The advantage of this is that (i) it would be simpler (one command instead of two) and (ii) more importantly, you would be able to set up multiple limited accounts with different limits for the same main account. This would also then kill two birds with one stone by simultaneously serving as a Coinbase-style recurring payment feature (eg. I give Private Internet Access a key to withdraw $5 USD per month from me).
The advantage of this is that (i) it would be simpler (one command instead of two) and (ii) more importantly, you would be able to set up multiple limited accounts with different limits for the same main account. This would also then kill two birds with one stone by simultaneously serving as a Coinbase-style recurring payment feature (eg. I give Private Internet Access a key to withdraw $5 USD per month from me).
I do like his proposal, it's an interesting twist.
It's slightly different conceptually than what I had in mind - in this proposal, X is really the owner of the funds, and he's letting Y use his (X's) funds. It would be an interesting challange visualizing this in a wallet software.
In my proposal, the owner of the funds is X, and Y can set withdrawal limits on X, but can't withdraw any of X's funds.
I still need to give this some thought, I think there are pros and cons to each approach.
Jump to: