BSIP66: Sharedrop Operation #132
Conversation
|
|
||
| # Abstract | ||
| We should add the ability to distribute arbitrary amount of some token (SHAREDROP token) to holders of a specific other token (STAKE token) according to the share(stake) of such tokens. | ||
| The importance of a similar solution was raised in BSIPs-19, 20, however never implemented. (link below). |
There was a problem hiding this comment.
This is pretty much the same thing as paying dividends.
The dividends feature has been implemented already for the PeerPlays blockchain.
See here: bitshares/bitshares-core#695
There was a problem hiding this comment.
As I mentioned, the idea is very similar to bsip-20 (and 19).
We have spent quite a lot of time looking into the PeerPlay code. And at this point of time (2 years after the code has been written) we have concluded that it is easier, safer and more maintainable in the future to write our own code.
Please see my extensive reply here:
#123 (comment)
Thanks,
Denis
There was a problem hiding this comment.
We have just posted related BSIP - Market Fee Backed Asset (MFBA) - #134
and here:
https://bitsharestalk.org/index.php?topic=27601.0
The idea is quite similar, but it's more automated with MFBA.
And it's more flexible with Sharedrop.
We can have one or the other or both.
Code base, when it comes to splitting share with stakeholders to their vesting balances would be quite similar.
There was a problem hiding this comment.
What is the difference to BSIP 19/20 in essence?
| # Rationale | ||
|
|
||
| - Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. | ||
| - Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within BitShares. |
There was a problem hiding this comment.
BitShares has a "sendmany" too. It is just a transaction with "many" transfer operations. Same thing that bitcoin forks do.
There was a problem hiding this comment.
We have looked at the way "sendmany" is implemented and it does not exactly cover our needs. It is like many different transfers.. Block can only have limited amount of transfers. So if there are too many, then we will have several transactions and it will not be atomic.
There was a problem hiding this comment.
The same will happen with an actual send_many operation. The thing that will make the transaction too big will be the account_id to amount list, and not the header of the serialization.
There was a problem hiding this comment.
A serialized transfer_operation in BitShares is much smaller than a bitcoin address. A BitShares transaction with many transfers will be significantly smaller than a bitcoin transaction with as many recipients.
For a large number of recipients you'll hit the bitcoin block size limit much faster than the BitShares block size limit. Not to mention the fees.
| - Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. | ||
| - Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within BitShares. | ||
|
|
||
| To make it more difficult to abuse the system dropping multiple useless tokens, there will be a vesting stake for the sharedrop operation. For example, vest 5000 bitUSD (in BTS) for 2 month to be able to do sharedrop operation. |
There was a problem hiding this comment.
This looks like an arbitrary barrier. Why not raise the fee for that operation?
There was a problem hiding this comment.
That's just an idea. It's up for discussion. Our take was that if we make it let's say 50 bitUSD, then it's still open for shitcoins to send airdrops.
There was a problem hiding this comment.
Actually, we thought some more about it.. And we can definitely scrap the idea of vesting stake.
AND/OR
We might change the transaction fee for the sharedrop not to depend on the number of users. This way we would not need to calculate the fee. And it will be much simpler and easier to implement.
LET'S HAVE A DISCUSSION HERE GUYS!
Or we can have it in the forum
https://bitsharestalk.org/index.php?topic=27588.0
There was a problem hiding this comment.
It shouldn't be the same price to sharedrop on 2 as it is 2 million, the more users the more resources it'll consume so the higher the fee required, no?
|
|
||
| Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. | ||
|
|
||
| ## dry_run_sharedrop operation |
There was a problem hiding this comment.
No need for an extra operation for this. If it doesn't hit the blockchain, it could as well be the real operation and use the get_required_fees api call
There was a problem hiding this comment.
Please see above. If we change the fee to the FIXED fee then we do not need it at all.
if we still have the fee depend on the number of users, then we still need to calculate it.
In this case, we can definitely extend the get_required_fees for this operation and implement our calculations there.
Thank you for the idea.
Again, it depends on the discussion about the fees and vesting stake.
There was a problem hiding this comment.
What is the idea which vesting balance object to use?
If the user does not have a vesting balance object, it will need to be created inducing more fees. IMO it can't be a fixed fee in such a case. Also, I'd recommend that any newly created vesting balances should purge themselves after being unused to avoid cluttering up the current state.
merge latest changes to openledger bsips repository Dec 2018
|
I worked with @OpenLedgerApp to establish a drafting budget for this BSIP of 10 hours. It will be paid in weeks 50-51. Revisions will continue within this budget. |
|
|
||
| https://github.com/bitshares/bsips/blob/master/bsip-0020.md | ||
|
|
||
| ## Copyright |
There was a problem hiding this comment.
Please add a easy-to-understand Summary for the Shareholders
What are the additional leverages created for BTS holders, what are the benefits? Also, where are the risks?
There was a problem hiding this comment.
Addressing why BSIP 20 was deferred is relevant too, I believe it's because the BSIP terminology was about dividends/profit-sharing of fees instead of sharedropping as a form of issuance? If the reason for deference was related to regulations then perhaps BTS and committee owned assets could be excluded?
|
A sharedrop on BTS could easily lead to more than 1 million write operations in the database. This cannot be done during normal block processing. Please modify the spec so that sharedrops are executed during maintenance. |
|
We will add sharedrops operations in our BSIP Market Fee Based Asset -#134 We will modify the BSIP MFBA so that sharedrops are executed during maintenance. |
I would recommend to keep them separate as they are different design. Consider that each BSIP requires voter approval. Additionally, it makes sense to have a generic sharedrop operation that can be used for MFBA and also for UIA and SmartCoins. |
|
We agree with @pmconrad |
|
@ryanRfox please assign BSIP number. |
Dear BitShares Community,
We would like to introduce the sharedrop operation BSIP.
The purpose is to share potential profit/money/other assets with the holders of the specific asset according with their stake.
As per BitShares Core Team request we have spent some time drafting this BSIP.
And here's the resulting BSIP:
https://github.com/openledger/bsips/blob/bsip-sharedropoperation/bsip-00XX%20Sharedrop%20Operation.md
The pull request is here:
#132
Forum thread is here:
https://bitsharestalk.org/index.php?topic=27588.0
Please share your opinion.
If you think it might help BitShares, please voice your opinion and vote for it, when the worker is created.
Sincerely,
Denis Sokolov
OpenLedger