| fip | title | status | type | author | created | updated |
|---|---|---|---|---|---|---|
32 |
Allow unlimited size of content parameter in New Funds Request |
Final |
Functionality |
Pawel Mastalerz <[email protected]> |
2021-09-02 |
2022-04-25 |
After this FIP is adopted:
- Unlimited size of content parameter in New Funds Request is allowed. Transaction would still be subject to transaction limit.
- new_funds_request fee is assessed based on size of request.
- Bundled transactions charged by new_funds_request are assessed based on size of request.
- LNBC token code is part of FIP-15 Chain and token code standard.
| Contract | Action | Endpoint | Description |
|---|---|---|---|
| fio.reqobt | newfundsreq | /new_funds_request | Modifies processing to allow unlimited size of content parameter and changes fee/bundles calculation to be based on request size. |
Recent assessment of how FIO Protocol can support Lightning Network has uncovered that:
- Since Lightning Network uses Invoices instead of addresses, FIO Request is the best mechanism to support Lightning in FIO Protocol.
- Current New Funds Request content parameter size limitations do not support a typical Lightning Invoice string.
This FIP's objective is to increase the size of content parameter in New Funds Request to accommodate Lightning Invoice or any other data that FIO Protocol users would want to include in FIO Request.
LNBC token is added to FIP-15 Chain and token code standard to enable integrators to distinguish Lightning transaction from the base layer transaction (BTC).
Modifies processing to allow unlimited size of content parameter and changes fee/bundles calculation to be based on request size.
No change
- content parameter max size validation is removed.
- The fee is determined based on the following logic:
- If paying with fee: new_funds_request fee is charged per each X bytes of request or content parameter size.
- If paying with bundled transactions: Y bundled transactions are charged per each X bytes of request or content parameter size.
- Account's RAM is bumped by Z per each X bytes of request or content parameter size.
X, Y, Z, and if sizing is based on request or content parameter will be determined during implementation and this FIP will be updated.
No change
Rather than increasing the size of the content parameter to a bigger fixed number, it was determined that the best strategy is to implement a dynamic pricing model where the fee, or bundled transaction cost, is increased dynamically as the size of the content parameter grows.
Similar model is already being used for msig_propose and auth_update, although those actions do not allow payment using bundled transactions.
X, Y, Z, and if sizing is based on request or content parameter will be determined during implementation and this FIP will be updated.
Also, during implementation, level of effort to support same logic in record_obt should be evaluated and discussed if this FIP should be amended to include that change as well.
Released in:
Since there is no change to the request or response parameters in newfundsreq action, there should be no impact on existing implementations.
However, if an integrator is currently expecting that the size of the content parameter will not exceed a certain size, their integration may have to be updated. An advisory to all existing integrators should be issued once this FIP is deployed.
Since Lightning Network FIO Requests will use a unique token code (LNBC), wallets which do not support Lightning will not require any changes as they likely already show an error when an unsupported token code is received in a FIO Request.
For consistency, a similar approach could be adopted for recordobt in the future.
https://fioprotocol.atlassian.net/wiki/spaces/FC/pages/374243331/Lightning+Network+Support+in+FIO