Author Topic: User Issued Asset Upgrades  (Read 18430 times)

0 Members and 1 Guest are viewing this topic.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I'm finishing up tests for all features in OP right now, so either christmas release or Devshares, whichever comes first
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
1) You can now specify a required transaction fee (payable in user issued asset) once per transaction that withdraws that asset type.
2) You can now have multi-sig issuers/control over an asset
3) You can now have child asset symbols like child accounts to facilitate trust in a common issuer of related assets.
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
5) Issuers can now optionally white list public keys that may own/trade the issued asset.

With these powers Gateways can comply with all regulations just like with Ripple.  Companies can issue shares while remaining in full compliance with the law.

@bytemaster

all features available in clientversion 0.4.26? Wich commands on the commandlines are to do for example 3) ? Didn't find a command to do it.

25/26 did not provide any hard forking changes, it was merely a security fix.   
`

ah thank you. so this features are coming. can you speculate when we have this features usable?

Offline bytemaster

1) You can now specify a required transaction fee (payable in user issued asset) once per transaction that withdraws that asset type.
2) You can now have multi-sig issuers/control over an asset
3) You can now have child asset symbols like child accounts to facilitate trust in a common issuer of related assets.
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
5) Issuers can now optionally white list public keys that may own/trade the issued asset.

With these powers Gateways can comply with all regulations just like with Ripple.  Companies can issue shares while remaining in full compliance with the law.

@bytemaster

all features available in clientversion 0.4.26? Wich commands on the commandlines are to do for example 3) ? Didn't find a command to do it.

25/26 did not provide any hard forking changes, it was merely a security fix.   
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
1) You can now specify a required transaction fee (payable in user issued asset) once per transaction that withdraws that asset type.
2) You can now have multi-sig issuers/control over an asset
3) You can now have child asset symbols like child accounts to facilitate trust in a common issuer of related assets.
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
5) Issuers can now optionally white list public keys that may own/trade the issued asset.

With these powers Gateways can comply with all regulations just like with Ripple.  Companies can issue shares while remaining in full compliance with the law.

@bytemaster

all features available in clientversion 0.4.26? Wich commands on the commandlines are to do for example 3) ? Didn't find a command to do it.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
No it wouldn't.  You could do something similar to one of my yield proposals.  For each distribution event, put the BTS / BitAssets being distributed into a "pool" specific to that distribution.  The pool just contains a balance for each BitAsset type being distributed, plus a record of the time at which the distribution occurred and the quantity of UIA in existence at that time.

Then every time a balance moves, you check if there have been any distributions since the last time it moved.  If so, then the transaction's allowed (or perhaps even required) to withdraw funds from the pool equal to the UIA balance which is moving, divided by the total UIA in existence at the time of the distribution event (which was recorded as part of the pool record).

+5% That way every dividend collection transfer operation is O(N) where N is the number of distribution events that have occurred since the UIA stake was last moved. But we can design the system to do better than that.

If we want the number of operations to not depend on the number of distribution events, we could simply accumulate the ratios between the total distribution event yield and the amount of outstanding UIA at the time of the distribution event as each distribution event occurs. Then the difference between these accumulated values at the time the stake was last moved and the current time can be used to determine how many BitAssets the transfer is allowed to remove from the dividend pool.

There may be some numerical errors that grow with the number of distribution events, but I am not too concerned about that. If we round down when calculating the dividend for a transfer, I think there will be some dust left over in the dividend pool after everyone claims their dividends. Even if not, the amount of dividends the last person to claim the dividend would lose would likely be very small. In order to prevent a large accumulation of unclaimable BitAsset dividends in the pool due to rounding errors, it might make sense to have different generations of pools. For example there can be a separate pool for every year. Once all of the stake that existed in the prior year has moved (this is tracked by the variable t in my proposal below), any remaining dust in the pool for the previous year becomes reclaimable by the UIA issuer. Also, in order to prevent the transfer operations from becoming too complicated because of multiple generation of pools existing due to unclaimed stake in an old pool, we can simply require that the UIA holder move their balance once a year if they want to collect dividends (otherwise they still get to move their UIA stake, they just do not get to collect any dividends older than a year).

I have described this proposal more precisely below.

y_{u,a,i} = quantity of BitAsset a distributed to UIA u stakeholders as part of distribution event i of UIA u
b_{u,i}    = block number at the time of the distribution event i of UIA u
I_{u,b}   = most recent distribution event index for UIA u as of block number b ( b_{u,I_{u,n}} <= n < b_{u,I_{u,n}+1} for all n < b_{u,I_{u,latest_block}} )
l_{u}      = latest distribution event index for UIA u (l_{u} is a mutable variable)
s_{u,i}    = quantity of outstanding UIA u stake during block number b_{u,i}
t_{u,i}    = quantity of unmoved UIA u stake existing in a block after b_{u,i} but before b_{u,i+1} if defined (each t_{u,i} is a mutable variable)
r_{u,i}    = accumulator to help calculate dividends for UIA u right after distribution event i of UIA u

The accumulator is defined as follows:
r_{u,0}    = 0,
r_{u,i+1} = a_{u,i} + y_{u,b,i+1} / s_{u,i+1},  for all i > 0 for which a distribution event exists.

For every UIA u, the database tracks a mutable variable l_{u}, a list of (i, r_{u,i}, b_{u,i}, t_{u,i}) for all distribution events (or as an optimization, only the relevant subset of them), and I_{u,b} for all blocks in which at least one UIA u transfer occurred (or again as an optimization, only the relevant subset). The values r_{u,i}, b_{u,i}, and I_{u,b} are immutable, but t_{u,i} is a mutable variable in the database. So, if a distribution (the ith distribution for UIA u) of BitAsset a of quantity y is given as a dividend at block b to all UIA u stake in existence at that time (total quantity of UIA u stake is s), the client sets the following values in the database:
r_{u,i} = r_{u,i-1} + y/s,
l_{u}   := b,
t_{u,i} := 0.
Also, the BitAsset a of quantity y is moved into a dividend fund for the UIA u.

When a transfer occurs of UIA u stake of quantity q which was last moved at block b, the client calculates the divided d as follows:
d = (r_{u,l_{u}} - r_{u,I_{u,b}}) * q.
It then withdraws BitAsset a of quantity d from the dividend fund (or as much as possible if there is not enough do to rounding errors for example). Finally, it updates/sets the following values in the database:
t_{u,I_{u,b}} := t_{u,I_{u,b}} - q,
t_{u,l_{u}}    := t_{u,l_{u}} + q,
I_{u,b} = l_{u} (this is only necessary to set once for the block b if there are multiple UIA u transfers in the block).

Also, whenever UIA u stake is either issued into existence or destroyed, the values of t_{u,*} may need to be updated. If UIA u stake of quantity q is issued in the newest block, then the following values must be update/set in the database:
t_{u,l_{u}} := t_{u,l_{u}} + q,
I_{u,b} = l_{u} (this is only necessary to set once for the block b if there are multiple UIA u stake issuance in the block or not necessary to set at all if there are any UIA u transfers in the block).
On the other hand, if UIA u stake of quantity q which was last moved in block b is destroyed in the current block, then the following value must be updated in the database:
t_{u,I_{u,b}} := t_{u,I_{u,b}} - q.

The full list of (i, r_{u,i}, b_{u,i}, t_{u,i}) recording the entire history of distributions does not need to be stored in the database (it can always be recovered from the blockchain anyway). It can be pruned by removing items from the head of the list if they are no longer necessary. An item at the head of the list corresponding to distribution event i is no longer necessary if its t_{u,i} == 0. Anytime there is an update to the t_{u,i} at the head of the pruned list, there is a potential for further pruning of the list. If this update happens (due to a transfer of UIA u stake), the client checks to see if t_{u,i} == 0. If so, it sets a pruning flag to true for the UIA u stake in the database that pruning is possible. When it gets the time (there are no time constraints), it can go through the list and check how many of the items in the beginning of the list satisfy the t == 0 condition, and remove them one by one. Only when the client gets to an item at the head of the new list where t != 0 does it set the pruning flag to false (at least until it is triggered to true again because of a UIA u stake transfer causing the t at the head of the list to become 0). The block number b_l for the item at the head of this list where t !=0 determines the blocks for which the I_{u,b} values can be also safely removed from the database (again no there are no time constraints to do this). The client can iterate in ascending order of block number b from the earliest pruned block for UIA u, and remove the I_{u,b} value if b < b_l. A more clever implementation would include the block number of the block storing the next I value, I_{u,b_{u,I_{u,b}+1}}, together with the value I_{u,b} to create a linked list of stored I values for each UIA u (also it would need to keep track of the mutable head index, H_{u}, and mutable tail index, T_{u}, of the linked list for each UIA u). This would allow the pruning process for the I values to be much faster.
« Last Edit: December 05, 2014, 08:19:50 pm by arhag »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
 +5% I was trying to convince BM how we could effectively "snapshot" a point in time for polling, I think you made the intuition concrete better than I was able to.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline theoretical

The previous post could be expressed more concisely as follows:  For each balance b_i, we want to keep track of dividends_due(b_i), how much b_i is allowed to receive from the dividend pool.  However, if we do that, for N balances, issuing a dividend will result in O(N) database updates which is way too resource intensive to be practical.

So I propose tracking dividends_paid(b_i) instead, which is cheap since it only updates when the balance owner decides to withdraw the dividend.  With a few macro stats which are also cheap to update, we can then compute dividends_due(b_i) from dividends_paid(b_i).
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical


Another idea for how dividends could be implemented:

- Allow each UIA to have a "write-only" dividend pool which can only grow, never shrink.

Anyone who has a position in the UIA would be able to "take a loan" against the pool up to their share of the pool, collateralized by their UIA holdings.  Unlike loans to short sellers, these loans wouldn't need forced covering since the user can't default (since the write-only pool cannot shrink, the backing of the UIA shares will always be enough to cover their loan), so users would be allowed to maintain a loan forever.  The only inconvenience of having a loan is being unable to transfer the underlying UIA shares until the loan is repaid since they're encumbered.  The user would even be able to increase their loan if future dividends occur.

Handling retraction of these assets would be interesting.  I'm thinking basically if an asset both receives dividends and is retractable, retraction should be implemented like a forced cover using the pool.  I.e. when a UIA which a user has taken a loan against is retracted, the UIA shares are destroyed, and the backing from the pool is liberated and used to repay the loan, with any leftover going to the UIA issuer who is retracting the asset.

The only issue I foresee is when printing new UIA shares, the issuer would have to provide BTS / BitAssets equal to all the historical dividends that would have been earned, had that new float been issued from the beginning.  Actually this could be avoided by allowing encumbered floats to be transferrable as well, and simply letting the issuer create new fully encumbered floats for free.  Since they can't take out any more loan, they don't have to have actual BTS / BitAssets backing them in the pool.

So I think the best way is to only allow fully encumbered float to be transferrable by anyone -- i.e. users would be forced to withdraw any pending dividends before they could transfer them.  This makes all shares of a given UIA fungible against each other instead of having a distinction between encumbered or unencumbered shares.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Can Issuer pay dividends yet?

+5% Mass payment module.

This would be very expensive to implement a primitive for.   You can send out 1000 transactions or use a "send many" to group them into manageable sizes.   Having an operation do that would be too expensive.

No it wouldn't.  You could do something similar to one of my yield proposals.  For each distribution event, put the BTS / BitAssets being distributed into a "pool" specific to that distribution.  The pool just contains a balance for each BitAsset type being distributed, plus a record of the time at which the distribution occurred and the quantity of UIA in existence at that time.

Then every time a balance moves, you check if there have been any distributions since the last time it moved.  If so, then the transaction's allowed (or perhaps even required) to withdraw funds from the pool equal to the UIA balance which is moving, divided by the total UIA in existence at the time of the distribution event (which was recorded as part of the pool record).
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline darbon

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
    • HolyTransaction
wallet_approve_delegate holytransaction
https://holytransaction.com/

Offline joele

  • Sr. Member
  • ****
  • Posts: 467
    • View Profile
Can Issuer pay dividends yet?

+5% Mass payment module.

This would be very expensive to implement a primitive for.   You can send out 1000 transactions or use a "send many" to group them into manageable sizes.   Having an operation do that would be too expensive.

Instead of paying one by one, a module to import CSV file (name, amt, memo) and the system will loop and transfer the amount with fee for every transaction.
Command like mass_transfer <asset_symbol> <from_account_name> <{name, amount, memo}>  [vote_method]
« Last Edit: December 03, 2014, 04:31:46 am by joele »

Offline biophil

  • Hero Member
  • *****
  • Posts: 880
  • Professor of Computer Science
    • View Profile
    • My Academic Website
  • BitShares: biophil
Can Issuer pay dividends yet?

+5% Mass payment module.

This would be very expensive to implement a primitive for.   You can send out 1000 transactions or use a "send many" to group them into manageable sizes.   Having an operation do that would be too expensive.

I believe at least 80% of user issued assets would require regular dividend payments, when I was playing with crypto stocks on BTCT, I believe 99% of assets were paying regular dividends. Therefore this is a needed feature, no matter how technically expensive, you need to figure it out.

This could be automated client-side quite easily, I suspect. Any reason that wouldn't be sufficient?

Sent from my SCH-S720C using Tapatalk 2

Support our research efforts to improve BitAsset price-pegging! Vote for worker 1.14.204 "201907-uccs-research-project."

Offline kokojie

  • Sr. Member
  • ****
  • Posts: 286
    • View Profile
Can Issuer pay dividends yet?

+5% Mass payment module.

This would be very expensive to implement a primitive for.   You can send out 1000 transactions or use a "send many" to group them into manageable sizes.   Having an operation do that would be too expensive.

I believe at least 80% of user issued assets would require regular dividend payments, when I was playing with crypto stocks on BTCT, I believe 99% of assets were paying regular dividends. Therefore this is a needed feature, no matter how technically expensive, you need to figure it out.

Offline matt608

  • Hero Member
  • *****
  • Posts: 878
    • View Profile
The wiki page is completely empty:
http://wiki.bitshares.org/index.php/BitShares/UserAssets

EVERYONE is invited to change that .. please go ahead! Write something .. I can't do all of it on my own

Part 2 of my article series will include a guide to creating a user issued asset complete with screenshots which could be recycled into wiki content.  I'll need to issue an asset myself to educate myself and take screenshots. 
« Last Edit: December 02, 2014, 10:07:56 pm by matt608 »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
The wiki page is completely empty:
http://wiki.bitshares.org/index.php/BitShares/UserAssets

EVERYONE is invited to change that .. please go ahead! Write something .. I can't do all of it on my own