BitShares-Core  6.1.0
BitShares blockchain implementation and command-line interface software
Modules | Classes | Functions


 A set of valid comands for mutating the globally shared state.


class  graphene::protocol::transaction
 groups operations that should be applied atomically More...
class  graphene::protocol::signed_transaction
 adds a signature to a transaction More...
class  graphene::protocol::precomputable_transaction
struct  graphene::protocol::processed_transaction
 captures the result of evaluating the operations contained in the transaction More...


void graphene::protocol::verify_authority (const vector< operation > &ops, const flat_set< public_key_type > &sigs, const std::function< const authority *(account_id_type)> &get_active, const std::function< const authority *(account_id_type)> &get_owner, const custom_authority_lookup &get_custom, bool allow_non_immediate_owner, bool ignore_custom_operation_required_auths, uint32_t max_recursion=GRAPHENE_MAX_SIG_CHECK_DEPTH, bool allow_committee=false, const flat_set< account_id_type > &active_approvals=flat_set< account_id_type >(), const flat_set< account_id_type > &owner_approvals=flat_set< account_id_type >())

Detailed Description

All transactions are sets of operations that must be applied atomically. Transactions must refer to a recent block that defines the context of the operation so that they assert a known binding to the object id's referenced in the transaction.

Rather than specify a full block number, we only specify the lower 16 bits of the block number which means you can reference any block within the last 65,536 blocks which is 3.5 days with a 5 second block interval or 18 hours with a 1 second interval.

All transactions must expire so that the network does not have to maintain a permanent record of all transactions ever published. A transaction may not have an expiration date too far in the future because this would require keeping too much transaction history in memory.

The block prefix is the first 4 bytes of the block hash of the reference block number, which is the second 4 bytes of the block_id_type (the first 4 bytes of the block ID are the block number)

Note: A transaction which selects a reference block cannot be migrated between forks outside the period of ref_block_num.time to (ref_block_num.time + rel_exp * interval). This fact can be used to protect market orders which should specify a relatively short re-org window of perhaps less than 1 minute. Normal payments should probably have a longer re-org window to ensure their transaction can still go through in the event of a momentary disruption in service.

It is not recommended to set the transaction::ref_block_num, transaction::ref_block_prefix, and transaction::expiration fields manually. Call the appropriate overload of transaction::set_expiration instead.

Function Documentation

◆ verify_authority()

void graphene::protocol::verify_authority ( const vector< operation > &  ops,
const flat_set< public_key_type > &  sigs,
const std::function< const authority *(account_id_type)> &  get_active,
const std::function< const authority *(account_id_type)> &  get_owner,
const custom_authority_lookup get_custom,
bool  allow_non_immediate_owner,
bool  ignore_custom_operation_required_auths,
uint32_t  max_recursion = GRAPHENE_MAX_SIG_CHECK_DEPTH,
bool  allow_committee = false,
const flat_set< account_id_type > &  active_approvals = flat_set<account_id_type>(),
const flat_set< account_id_type > &  owner_approvals = flat_set<account_id_type>() 

Checks whether given public keys and approvals are sufficient to authorize given operations. Throws an exception when failed.

opsa vector of operations
sigsa set of public keys
get_activecallback function to retrieve active authorities of a given account
get_ownercallback function to retrieve owner authorities of a given account
get_customcallback function to retrieve viable custom authorities for a given account and operation
allow_non_immediate_ownerwhether to allow owner authority of non-immediately required accounts to authorize operations
ignore_custom_operation_required_authsSee issue #210; whether to ignore the required_auths field of custom_operation or not
max_recursionmaximum level of recursion when verifying, since an account can have another account in active authorities and/or owner authorities
allow_committeewhether to allow the special "committee account" to authorize the operations
active_approvalsaccounts that approved the operations with their active authories
owner_approvalsaccounts that approved the operations with their owner authories

Definition at line 269 of file transaction.cpp.