BitShares Forum
Main => General Discussion => Topic started by: bytemaster on December 01, 2014, 10:45:44 pm
-
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.
-
sounds reasonable and promising +5%
-
Great! +5%
-
+5% Great. I think these features are needed for mainstream adoption.
-
Awesome.
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.
Yes, cryptostocks here we come.
1) You can now specify a required transaction fee (payable in user issued asset) once per transaction that withdraws that asset type.
Where does that transaction fee go? Does it go to delegates as part of DAC revenue? If so, doesn't that mean it needs to be converted to BTS in a BTS/UIA exchange? Does it go to the issuer of the UIA or is it just burned? If so, is an additional 0.1 BTS fee required for including the transaction in the blockchain?
2) You can now have multi-sig issuers/control over an asset
Great.
Can the next UIA upgrade please be a mechanism for UIA holders to optionally vote on the blockchain with their UIA stake for a new issuer (assuming the UIA was created with that option enabled)? Then if a majority of the UIA stake comes to a consensus on a particular issuer (either single address or particular multisig) the blockchain changes the issuer. Also, this would be coupled with a 48 hour delay on transactions by the issuer that issue new UIA into existence (to give the legitimate stakeholders enough time to change the issuer). The current UIA issuer could cancel these transactions at any time before the 48 hour time limit. These are the first and most important steps of the upgrades to UIA that I want to see as described in this post (https://bitsharestalk.org/index.php?topic=11349.msg149430#msg149430), which should eventually make side DPOS chains, shared BitAssets, experimental DACs, crowdfunding, actual mergers between DACs, and many other things possible.
-
Will be exciting to see when the first BTC gateway becomes operational (metaexhange?)
edit:
Does the UIA fee replace the normal tx fee in BTS? If it could be done in a way that didn't enable DOS spam, this would be really great at making on ramps easier.
-
I confess I probably have not fully grasped all the implications of the above. But even with that I think those are hugely important news.
and those will be there for 0.4.25, already?
-
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.
+5% +5% +5%
-
I just want to point out:
1) Ripple is essentially being valued by the market at over 1 billion dollars right now. Yes, its only 300 something million if you use the ~30 billion supply listed on coinmarketcap, but actually there are almost 100 billion ripple, its just that 70% of them are "unreleased" and being held by ripple labs.
2) With these changes, we can be Ripple. In addition to doing everything Bitshares does.
3) Bitshares is currently being valued at under $50 million.
Now you do the math.
-
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.
Is the traceability of tokens required for legal compliance in some way?
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
Would that be so that the user knows in advance whether the issuer has this capability or can any issuer gain that capability after having issued the assets?
-
Will be exciting to see when the first BTC gateway becomes operational (metaexhange?)
edit:
Does the UIA fee replace the normal tx fee in BTS? If it could be done in a way that didn't enable DOS spam, this would be really great at making on ramps easier.
Transaction fee goes to issuer and DOES NOT replace the required BTS transaction fee.
-
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.
Is the traceability of tokens required for legal compliance in some way?
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
Would that be so that the user knows in advance whether the issuer has this capability or can any issuer gain that capability after having issued the assets?
Assets can become less restrictive but not more restrictive.
Traceability is required for compliance with SEC for issuing shares in companies and KYC for depositors. Laws vary by state/country/etc but with what we have implemented the issuer/users has freedom to comply as little or as much as they want.
-
+5% +5% +5%
thanks for your work!
-
Great work! +5%
-
+5% Great work. Things are advancing rapidly it seems!
-
Can you still create user issued asset that is completely decentralized?
Meaning issuer doesn't have any control over it (except initial distribution)?
-
Can you still create user issued asset that is completely decentralized?
Meaning issuer doesn't have any control over it (except initial distribution)?
Of course.
-
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.
Is the traceability of tokens required for legal compliance in some way?
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
Would that be so that the user knows in advance whether the issuer has this capability or can any issuer gain that capability after having issued the assets?
Assets can become less restrictive but not more restrictive.
Traceability is required for compliance with SEC for issuing shares in companies and KYC for depositors. Laws vary by state/country/etc but with what we have implemented the issuer/users has freedom to comply as little or as much as they want.
So Titan can be turned of also at a (not thin) client level?
-
Looks good..
-
Can Issuer pay dividends yet?
-
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.
feature 4&5 support only public account or both public&titan account?
btw, line 124 in transaction_builder.cpp, I didn't see memo support for public account transaction for the recipient
-
a big step for BTA ,great!
+5%
-
Well done!
Funny how some of the most groundbreaking news can be so understated.
-
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
Can you give us a comfort level that this won't apply to bitUSD, bitGOLD, or bitSILVER?
-
+5% Great
-
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
Can you give us a comfort level that this won't apply to bitUSD, bitGOLD, or bitSILVER?
There are no 'Issuers' per se, for those (i.e. they are not user issued assets)...so I hope this helps.
-
4) Issuers can now optionally retain complete control over all balances in their asset. (Freeze accounts, etc) Needed for legal compliance.
Can you give us a comfort level that this won't apply to bitUSD, bitGOLD, or bitSILVER?
This would be a new hard forking change that I don't think any of the devs want to implement, and if they did implement it I suspect the branch without it would be the one that was actually populated.
-
I have thought some about 4) and 5),
I haven't view the source and I still don't how do you implement it,
but I think white list maybe not so easy, because the list can be very large
I think it's more reasonable to implement this with sub account.
some agent company can offer a service for identity authentication service, like:
register account, rescue private key, freeze account, offer some information to government....
all these sub account have the same root account, both customer and the agent company owner the private key.
the asset creater only need to set which root account can be trust.
they don't need to save the customer's information, they don't need to make deal with government directly,
they don't need to handle the customer's identity service.
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.
-
Assets can become less restrictive but not more restrictive.
Traceability is required for compliance with SEC for issuing shares in companies and KYC for depositors. Laws vary by state/country/etc but with what we have implemented the issuer/users has freedom to comply as little or as much as they want.
This is HUGE!!
+5% +5%
-
Can Issuer pay dividends yet?
+5% Mass payment module.
-
+5% +5%
-
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.
-
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.
i am curious. if i create a 500.000 BTS asset how much will a child asset cost?
- how will the naming function? like BTS - child would be BTS.child or BTS-child ?
-
Is there a place with all the information about user issued assets? I'll need the info for part 2 of an article series I'm writing. How much does it cost to issue an asset? Did alts idea of a 'maintain fee' go ahead? The wiki page is completely empty:
http://wiki.bitshares.org/index.php/BitShares/UserAssets
-
Is there a place with all the information about user issued assets? I'll need the info for part 2 of an article series I'm writing. How much does it cost to issue an asset? Did alts idea of a 'maintain fee' go ahead? The wiki page is completely empty:
http://wiki.bitshares.org/index.php/BitShares/UserAssets
I think price is something like 500 for 6-8 character asset names and 500k for 3-5 characters
-
Is there a place with all the information about user issued assets? I'll need the info for part 2 of an article series I'm writing. How much does it cost to issue an asset? Did alts idea of a 'maintain fee' go ahead? The wiki page is completely empty:
http://wiki.bitshares.org/index.php/BitShares/UserAssets
I think price is something like 500 for 6-8 character asset names and 500k for 3-5 characters
For a minute there I thought you meant 500k USD lol.
Details of the exact fees would be good.
-
For a minute there I thought you meant 500k USD lol.
Details of the exact fees would be good.
...soon to cost a whole lot more than 500k USD... :D
-
For a minute there I thought you meant 500k USD lol.
Details of the exact fees would be good.
...soon to cost a whole lot more than 500k USD... :D
From your lips to God's ears!
-
Do we have an official word on if #4 applies to MARKET assets (bitUSD, etc.)?
-
Do we have an official word on if #4 applies to MARKET assets (bitUSD, etc.)?
It doesn't. /official
-
Do we have an official word on if #4 applies to MARKET assets (bitUSD, etc.)?
It doesn't. /official
Link?
-
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
-
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.
-
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.
-
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
-
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]
-
+5% +5%
-
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).
-
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.
-
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).
-
+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.
-
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.
-
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.
-
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.
-
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?
-
I'm finishing up tests for all features in OP right now, so either christmas release or Devshares, whichever comes first
-
I'm finishing up tests for all features in OP right now, so either christmas release or Devshares, whichever comes first
When will the hardfork be?
I am currently in australia and might not have an internet connection at all ...
I'd prefer not to see a blockchain upgrade during christmas .. though not my decision to make ...
-
Bytemaster Dan we are going to need a User Issued Asset (UIA) Forum.
A tag line:
Speculate, Save, Invest, Grow, Accumulate.
-
Bytemaster Dan we are going to need a User Issued Asset (UIA) Forum.
A tag line:
Speculate, Save, Invest, Grow, Accumulate.
That's a really good idea! Once UIA with dividents are somehow available, such a forum section will be created.
-
Bytemaster Dan we are going to need a User Issued Asset (UIA) Forum.
A tag line:
Speculate, Save, Invest, Grow, Accumulate.
That's a really good idea! Once UIA with dividents are somehow available, such a forum section will be created.
It already exists? https://bitsharestalk.org/index.php?board=79.0
-
When will the hardfork be?
I am currently in australia and might not have an internet connection at all ...
I'd prefer not to see a blockchain upgrade during christmas .. though not my decision to make ...
We do have the internet in Australia :)
-
When will the hardfork be?
I am currently in australia and might not have an internet connection at all ...
I'd prefer not to see a blockchain upgrade during christmas .. though not my decision to make ...
We do have the internet in Australia :)
yhea .. you do .. sitting in the conference atm .. but from thursday on I will be traveling around with a van from Brisbane to Sydney .. not sure if all the campgrounds will have wifi .. surely not for free (unfortunatelly :( )
-
coming true in 0.7?
https://github.com/BitShares/bitshares/issues/1084
-
coming true in 0.7?
https://github.com/BitShares/bitshares/issues/1084
+5%
-
New calls:
* wallet_uia_collect_fees
* wallet_uia_update_description
* wallet_uia_update_supply
* wallet_uia_update_fees
* wallet_uia_update_active_flags -- flags: {dynamic_max_supply, dynamic_fees, halted_markets, halted_withdrawals, retractable_balances, restricted_deposits}
* wallet_uia_update_authority_permissions
* wallet_uia_update_whitelist
This will be amazing!
+5%!!!
-
New calls:
* wallet_uia_collect_fees
* wallet_uia_update_description
* wallet_uia_update_supply
* wallet_uia_update_fees
* wallet_uia_update_active_flags -- flags: {dynamic_max_supply, dynamic_fees, halted_markets, halted_withdrawals, retractable_balances, restricted_deposits}
* wallet_uia_update_authority_permissions
* wallet_uia_update_whitelist
This will be amazing!
+5%!!!
I love it. Great work guys!
-
Ahhh! So can you now disable trading for a given asset after it has been issued? This is a key feature for our partners who want to control their UIAs.
-
Ahhh! So can you now disable trading for a given asset after it has been issued? This is a key feature for our partners who want to control their UIAs.
flags: {dynamic_max_supply, dynamic_fees, halted_markets, halted_withdrawals, retractable_balances, restricted_deposits}
Seems that way ..
-
Upcoming release (0.7.0 or ?) or in current 0.6.2?
-
Upcoming release (0.7.0 or ?) or in current 0.6.2?
0.7
-
When ready these updates will first go into DevShares, and then we will want as much help as possible testing!