Implement simple rate limited free transaction feature

[vikramrajkumar]

From @abitmore on February 29, 2016 23:14

This ticket is for the implementation of a simplified version of "rate limited free transaction" feature which is introduced in bytemaster's blog post "How to build a Decentralized Application without Fees".

The simplified feature is:

• we still keep the fees, but stake holders can accumulate coin-days, which can be used to pay fees, so if someone has held a certain number of stake for a certain time she can for example make one certain transaction for free.
• No real-time dynamic fee adjusting.

Features:

• Committee can define the rate of coin-days to be converted to fees, for example, for normal users 1K BTS * 1day = 1BTS of fee, for AM 1KBTS * 1day = 2 BTS of fee, for LTM 1KBTS*1day=5BTS of fee
• Committee can define a cap of coin-days used for fees for each operation. for example, users can use coin-days to pay at most 10 BTS of transfer fee, or 1 BTS of market order creating fee, or etc
• Committee can define a cap for every account type(LTM/AM/normal user), so a user would be unable to spam 100 or more free transactions at same time. for example, LTMs will have a cap of 100BTS, AM 50BTS, normal user 30BTS.
• fees paid with coin-days won't go to referral program (or cash back for LTM)

With the parameters defined in above examples, if an LTM has 1M BTS, she can accumulate 5000 BTS of fees per day, or about 3.5BTS per minute. In case when transfer fee is 30BTS and the committee set the cap of transfer to 30BTS , she can transfer once for free every 10 minutes.

Possible future extensions:

• allow collateral to accumulate coin-days
• holding smart coins can accumulate coin-days
• allow fees to be paid from another account's coin-days
• per-asset settings/limitations
• dynamically adjust fees in response to system/network load

Copied from original issue: cryptonomex/graphene#603

[vikramrajkumar]

From @theoreticalbts on March 1, 2016 16:2

OK, some initial review:

• These commits need to be cherry-picked onto Graphene. All development takes place in Graphene and is merged into BitShares. The only commits that go on BitShares chain are BitShares specific things (e.g. BitShares has a particular built-in genesis, particular built-in seed nodes, and configuration constants such as the key prefix are different from Graphene). Occasionally we will make an exception for emergency fixes.
• One of Graphene's design principles is that the fee paid may be calculated based on the operation alone. This greatly simplifies wallet implementation and our wallets heavily rely on it. Adding the operation as a parameter to pay_fee breaks this design principle.
• Allowing null CER (here) is a different change, and should be its own issue with its own ticket number. As this changes chain semantics, it should be assigned its own hardfork number, which will be set to the upgrade deadline for the release for which it is included. This code uses HARDFORK_583_TIME.

[vikramrajkumar]

From @abitmore on March 1, 2016 17:34

@theoreticalbts thanks for the info.

Would you please review #583 (BSIP10 percentage based transfer fee) first? This implementation is currently based on #583, and #583 can be merged to develop branch directly, no need to cherry-pick.

I think we already discussed the principle you mentioned in another ticket, which is related to #583. I wrote some arguments in #583, can you comment in that ticket?

To make it simpler, I put null-CER feature into #583's scope (and another new operation), which is mentioned in OP of #583. It doesn't matter if you like to create another ticket.

[vikramrajkumar]

From @abitmore on March 1, 2016 23:5

We need a BSIP document for this feature.

[vikramrajkumar]

From @abitmore on March 3, 2016 1:2

@theoreticalbts @bytemaster I guess it's better to postpone this feature after #554 implemented? Since this feature requires several extensions to the global system parameters.

Or it's super high priority so it's better deploy it as is but asap? If yes, I'll do my best asap to re-branch it to be independent to #583 (percentage based transfer fee feature).

Also need to consider using the new extension<> template to extend extensions field, in this case need to merge the fix in #599.

[vikramrajkumar]

From @abitmore on March 3, 2016 12:57

Looks like this can be easily cherry-pick to develop branch. It's quite independent from #583 now. I'll create a new branch for it.

[vikramrajkumar]

From @abitmore on March 3, 2016 13:55

OK, the office command name is "rebase". Completed, and squashed to one commit: https://github.com/abitmore/bitshares-2/commit/f9ad1dfd105ade94b64a350f03dc1fa0b3e62b6f. Please review. @theoreticalbts @bytemaster

[vikramrajkumar]

From @xeroc on March 3, 2016 15:9

OK, the office command name is "rebase". Completed, and squashed to one commit: abitmore@f9ad1df. Please review. @theoreticalbts @bytemaster

This is AWESOME! Thank you sooo much ..

[vikramrajkumar]

From @abitmore on March 8, 2016 0:52

Unit testing code added. Push request submitted.