search

bitshares / bitshares-core

BitShares Blockchain node and command-line wallet
https://bitshares.github.io/
Other
1.17k stars 647 forks source link

Ability to airdrop/sharedrop/pay dividends of one asset to all holders of another. #1172

Open clockworkgr opened 6 years ago

clockworkgr commented 6 years ago

As a user/asset issuer I want to have a transfer_asset_to_asset_holders API call so that I can perform airdrops/sharedrops or dividend payouts.

Additional Context (optional)

Case 1: I own asset COOLASSET and decide to airdrop 50% of the total 1000000 COOLASSET supply to holders of BTS. I issue the relevant amount to myself and use transfer_asset_to_asset_holders(500000, 'COOLASSET','BTS')

Case 2: As a gateway operator, I collect market fees on all assets I provide gateway services for. Once a month, I want to share 50% of all market fee profits to holders of my GATEWAYCOIN. So for each gateway asset, I withdraw market fees, calculate 50% profit share (e.g. say 500 GATEWAY.UIA1) and use transfer_asset_to_asset_holders(500,'GATEWAY.UIA1','GATEWAYCOIN')

I believe PBSA has already implemented most of the code needed for this in peerplays.

Referencecs

CORE TEAM TASK LIST

clockworkgr commented 6 years ago

As a side note, the same code could be called upon to allow airdrops on asset creation time.

So from a UX point of view, the user would set all his UIA parameters just like now and on the supply settings, once a max supply is entered, he can choose a "percentage_to_airdrop" (e.g. 100%), an "airdrop_target_asset" (e.g. BTS) and a future block no for the snapshot (e.g. block 30000000).

Thus creating the asset and planning the airdrop at the same time.

cogutvalera commented 6 years ago

good idea ! nice !

abitmore commented 6 years ago

Interesting. I think there is a BSIP already.

Do it at maintenance interval? Deduct (transfer/issue) fees relative to number of holders?

clockworkgr commented 6 years ago

Yep...a superset of the functionality is mentioned here: https://github.com/bitshares/bsips/blob/master/bsip-0020.md

So change this issue to let's get BSIP-20 done instead :)

Maintenance interval sounds good.. Doesn't seem like an operation that will ever be required to be performed instantly.

Fees based on no of holders sounds good. Although we should probably make a special allowance for/treat core token BTS differently.

clockworkgr commented 6 years ago

@ryanRfox you were part of the original conversation so I'm tagging you here... As you can see there already was a BSIP...I was unaware

abitmore commented 6 years ago

Please be aware that balance look-up impacts performance, as mentioned in https://github.com/bitshares/bitshares-core/issues/1083#issuecomment-399992509, utilizing more than 7% of total replay time. Balance-modify may impact performance (much) further, as we need to insert 100k objects to object database in a few seconds.

clockworkgr commented 6 years ago

Hence why I checked performance when submitting the issue :)

I really don't know what the impact would be. I hope it's something that can be handled. It can be a high-fee operation if needed, as long as it's possible.

abitmore commented 6 years ago

According to the profiling data, every modification takes around 0.000002 second, so 100K modifications can be done in 0.2 second. However, it's all time average, When we have more and more data, it could be slower and slower. In addition, the profiling data is for replay, which means undo database is disabled. On a live chain, there is big overhead (2x data copy) when doing those modifications.

Update: forgot to mention the data (0.2 second) is with asset_api functionality enabled. With PR #1099 (for issue #1083), block producers (witnesses) can disable asset_api support for better performance (1.7x - 3x speed).

clockworkgr commented 6 years ago

https://github.com/BunkerChainLabsInc/peerplays-profitshare

ryanRfox commented 6 years ago

Currently BSIP 20 (UIA) and BSIP 19 (MPA) are Deferred. @xeroc may I request you to remind us of the conclusion at that time?

clockworkgr commented 6 years ago

I'm guessing deferred as in to be discussed again later...does now fit the definition of later? :D

clockworkgr commented 5 years ago

Bumping this. @xeroc / @ryanRfox ?

Had this request in UI too: https://github.com/bitshares/bitshares-ui/issues/2458

pmconrad commented 5 years ago

Related: https://github.com/bitshares/bsips/pull/132