BSIP: <BSIP number>
Title: Wishlist for New Assert Predicates
Authors: Christopher J. Sanborn, ...
Status: Draft
Type: Protocol
Created: 2019-06-08
Discussion: <url>
New predicates for the assert_operation are proposed to enable conditional validity of transactions for various use cases, including safety of transactions that depend on recent prior transactions, and transactions signed in advance but intended to be broadcast at a later time.
This BSIP is motivated by a multitude of potential use cases in which conditional validity of a transaction may be valuable. One example is the implementation of payment channels described in Short-lived Unidirectional Payment Channels, which depends on refund transactions being secured by a time lock. A time lock could be trivially implemented as an assert on a particular head block time. Thus an assert predicate head_block_time_ge_time_predicate could open up new possible applications on top of the BitShares protocol.
There are other interesting use cases and the predicates that would support them. So this BSIP will serve as a batch list of desired predicates to add in an upcoming scheduled protocol upgrade.
The assert_operation as currently implemented offers only three predicates, which are primarily geared at ensuring that a newly created account or asset has in fact been created as believed before doing something with that account or asset that could produce unintended consequences were the account or asset not created as believed. (This protects against, e.g., a race condition in which a block reorganization could potentially change the user ID given to a newly-registered user name.) The three existing predicates are defined in assert.hpp as:
| Predicate | Description |
|---|---|
account_name_eq_lit_predicate |
Tests the name of a given account ID equals a particular string literal |
asset_symbol_eq_lit_predicate |
Tests the symbol of a given asset ID equals a particular string literal |
block_id_predicate |
Tests that a block with a given ID appears within the last 2^16 blocks |
Propose to add the following predicates:
| Predicate | Description |
|---|---|
head_block_time_ge_time_predicate |
Head block time meets or exceeds time. Ensures a transaction is only valid at or after a specified time. |
head_block_time_lt_time_predicate |
Head block time is less than time. Ensures a transaction is only valid if included before a specified time. |
head_block_height_ge_height_predicate |
Head block height meets or exceeds height. Ensures a transaction is only valid at or after a specified block height. |
head_block_height_lt_height_predicate |
Head block height is less than height. Ensures a transaction is only valid if included before a specified block height. |
TODO: Should the predicates include ALL the comparisons: eq, lt, le, gt, ge? OR is ge, lt sufficient for real-world use cases? Note also that block_time_lt_time might be functionally equivalent to a transaction expiration and redundant.
The existing predicates check for the successful creation of a new account or asset by testing the correlation of an object ID and a name string. But this still leaves open a vulnerability from an attacking party trying to register the same account name or asset symbol. Thus to confirm expected object creation, it would be better to test the account authorities or asset issuer, than to check the name or symbol.
Propose to add the following predicates:
| Predicate | Description |
|---|---|
account_owner_is_authority_predicate |
Tests owner authority |
account_active_is_authority_predicate |
Tests active authority |
asset_issuer_is_account_predicate |
Tests asset issuer |