You are viewing a single comment's thread from:

RE: BSIP-020 Draft - "Introducing profit-sharing/dividends to Bitshares (UIA only)" - Input would be massively appreciated!

in #bitshares • 7 years ago

Some points:

  • Yield harvesting cannot occur here because nobody can simply short a UIA into existence.
  • The problems of EBAs and max coin supply can be covered simply by requiring the dividends to exist before they are paid out.
  • The problem of decimal places does not exist, due to the way amounts are handled internally. Payouts are always rounded (down) according to the number of decimals configured for the asset. Micro-payouts are rounded to zero.
  • KISS. Coin-age and market-making incentives require statistics that we (currently) don't have, so you should leave them out of the proposal.
7 years ago in #bitshares by
$2.78
  • Past Payouts $2.78, 0.00 TRX
  • - Author $2.35, 0.00 TRX
  • - Curators $0.43, 0.00 TRX
3 votes
Reply 7
Sort:  
  • Trending
    • [-]
     7 years ago 

    Do you imagine the determination of coin-age to be problematic either due to implementation and/or computationally expensive by node software?

    $1.20
    • Past Payouts $1.20, 0.00 TRX
    • - Author $0.90, 0.00 TRX
    • - Curators $0.30, 0.00 TRX
    1 vote
    Reply
    [-]
     7 years ago (edited)

    I spent a couple hours last night writing up a BSIP on coin-age, how we go about calculating it and how the dividend system works factor in, some brief thoughts:

    • Should dividends be paid on holding assets for part of a sharedrop period (10 days of 30 days) without holding the asset at the exact moment of sharedrop?
      • If not: We could query the holders of said asset at the moment of dividend issuance (existing functionality), then calculate the coin-age for each lump of assets (individual transactions) by performing the calculation 'current_time - inbound_transaction_time'.
        • This would require additional functionality to retrieve the list of 'inbound_transaction_time' or simply the transaction id (so as to then retrieve the inbound transaction time with existing functionality) for each transaction that makes up an user's immediate asset holdings.
      • If so: we would need to evaluate the historical holders of an asset, which may involve looking back overall transaction history (filtering for chosen asset) then evaluating the coin-age accumulated; this would be computationally expensive as this may involve a serious quantity of transactions to process in the future (potentially also open to abuse if I was to spam an asset between two accounts to increase time to compute coin-age).
    $1.08
    • Past Payouts $1.08, 0.00 TRX
    • - Author $0.81, 0.00 TRX
    • - Curators $0.27, 0.00 TRX
    1 vote
    Reply
    [-]
     7 years ago (edited)

    The problems of EBAs and max coin supply can be covered simply by requiring the dividends to exist before they are paid out.

    Good point, I could add this as a per-requisite to the distribution of a dividend.

    The problem of decimal places does not exist, due to the way amounts are handled internally. Payouts are always rounded (down) according to the number of decimals configured for the asset. Micro-payouts are rounded to zero.

    That's good to know, so think it's safe to entirely remove the sections regarding the decimal places?

    Coin-age and market-making incentives require statistics that we (currently) don't have, so you should leave them out of the proposal.

    I agree regarding market-making incentives (because it's largely a last minute addition & just a topic of discussion rather than a core proposal), however coin-age is featured in both BSIP-019 and this BSIP, without it how would we prevent users from buying immediately before the scheduled dividend then selling immediately after?

    Would you propose that I create an additional BSIP specifically for tracking the 'coin-age' of BTS assets then reference said BSIP from within these two BSIPs?

    Edit: Ok, writing up a draft coin-age BSIP since it's referenced by two BSIPs thus far.

    Double edit: Perhaps an alternative idea to coin-age could be taking a random date within the time period set for the snapshot, then performing the sharedrop at a later date so as to encourage holding the assets throughout the month, though you could potentially hold the assets for the majority of the month and not be eligible for a dividend because you missed the snapshot..

    $0.00
      Reply
      [-]
       7 years ago 

      If coin-age is essential to both, and avoids the gaming/timing problem, then it would seem to merit its adoption. Although it is possible that its technical implementation might either be tricky and/or computationally expensive. However, it merits its own elaboration.

      $1.22
      • Past Payouts $1.22, 0.00 TRX
      • - Author $0.91, 0.00 TRX
      • - Curators $0.30, 0.00 TRX
      1 vote
      Reply
      [-]
       7 years ago 

      without it how would we prevent users from buying immediately before the scheduled dividend then selling immediately after?

      I wouldn't even try to prevent that. Happens all the time in traditional stock markets. A well-functioning market will take the sharedrop into account during price discovery.

      $0.00
        Reply
        [-]
         7 years ago 

        It'd be great to offer the option though, since we want long term asset holders (at least for MPA) and we want to discourage 'yield-harvesting' that similarly troubled 'socialized-yield'.

        $0.00
          Reply