New BSIP: Free TRANSFERs with POS

[froooze]

BSIP: 
Title: Free TRANSFERs with POS
Author: [bench] <https://github.com/froooze>
Status: Draft
Type: Protocol
Created: 2019-09-15
Discussion: https://github.com/bitshares/bsips/issues/212

Abstract

Newer blockchains (EOS, IOTA, NANO ... ) want to improve adoption and offer new use cases with Free Transfers (FT). There are different concepts to prevent spam attacks, but PoS (Proof of Stake) looks like the most convenient one.

Specifications

• Locking up a certain amount BTS in a smart contract, to allow a certain amount of free transfers during a certain time period.
• One staking account can provide free transfers for other accounts with the Whitelist function.

FT_parameter

• ft_rate (How many BTS are needed per FT and ft_period)
• ft_period (How long is one period)

FT_object

• user_id
• ft_locked (amount of BTS, which are locked for FT)
• ft_whitelist

FT_function

Transfer function needs to check if there is a FT available:

ft_sum = counting all FTs from last ft_period till now

if sum_ft < ft_locked/ft_rate
ft_bool = true
else
ft_bool = false

Copyright

This document is placed in the public domain.

See also

#191
cryptonomex/graphene#612
bitshares/bitshares-core#186

[froooze]

Free transfer feature requested:
https://bitsharestalk.org/index.php?topic=22263.msg335931#msg335931

[pmconrad]

Do margin positions also count as locked BTS?

The BTS collateral in margin positions is not locked up - a variable part of it is backing the debt and can be taken out at any time due to margin calls and/or forced settlement and/or simply paying back the debt.

A margin position quote for free transfers ?

I see no justification for this.

Locking up x BTS allows x/BTS_per_FT during period_for_FT.

You need to specify what "Locking up" means.

Also, using explicit parameters has the downside that these parameters will need to be discussed and defined explicitly. I would prefer an automatic approach, similar to the rate-limited bandwidth model used by STEEM.

POS wit coin-days

There are other models. IMO simple coin-days is not good because it allows accumulating over long time followed by heavy spamming in a short time.

[froooze]

@pmconrad
I agree on your answers and coin-days was the wrong wording for my concept.

I look for a concept which needs ft_period to reload balance from 0% to 100%