Length requirement is enforced by RFC 1035 grammar. Use a compiler
error to tell anyone changing config.hpp that any value for this
constant smaller than 3 is unsupported by the implementation.
When subscribing to markets the callback will now receive something that
looks like this:
[ "REMOVED ID1", "REMOVED ID2", ...,
{ "id": "UPDATED ID3", data... },
{ "id": "UPDATED ID4", data... },
...
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ],
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ],
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ],
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ]
]
When ever an order is removed from the order book, its ID will be
included as a string. When an order is modified the new order data is included as
an object. And the operations describing how orders were matched and
what fees are paid will be included as an operation, aka array.
Also added means to unsubscribe from full account data (issue #166)
When subscribing to an account via the get_full_account API it will
start streaming any object relevant to the account that is added,
removed, or modified.
- when updating account there is no need to sign with the active key if
the owner has signed.
- when updating an account the active key is enough to update the
active key.
The blockchain now has a minimal participation requirement that can only
be overridden with checkpoints. Any time participation falls below a
minimal level no new blocks may be added.
Currently it requires 66% participation and tolerates short periods of
time below 66% participation with a maximum of 500 consecutive blocks
missed. For every two blocks produced 1 can be missed with a slack of
999 bias.
This is done to comply with the policy that transactions should be self
describing and not depend upon implied state. This makes things easier
for everyone to understand exactly when a transaction will be invalid
without having to refer to chain state.
1. Implement a TaPoS assert operation predicate that offers full block ID
validation for transactions that want the added security. This is only
required for transactions that are of high value and transfer control of
funds to a newly created identifier and where the witnesses cannot be
trusted.
2. Remove the full block ID from the transaction digest generation.
- added an option (on by default) to prevent a witness from signing two
blocks in a row because this most likely indicates they have been cut
off from the network.
- added an option where a witness will not produce a block if the
witness participation rate is below a configurable threshold (default
to 33%)
- remove circular dependency with fee_schedule
- unitiy build db_* as database.cpp
- move protocol definitions in separate directory
- combined some objects/evaluators
- combined limit/call evaluator/objects into market_evaluator.*
- move balance_claim_evalautor implementation from header
- remove authority check from balance_claim evaluator, added to
other_auths defined by the operation
- this is a major refactor of the code and may have broken some behavior
in the wallet or witness nodes.
- this commit changes the serialization of operations
- the chain_tests pass
witnesses, registering witness url.
Derive memo, witness, etc. keys from the active key.
Make witness_create_operation accept relative key identifiers.
Prevent wif_to_key from throwing on invalid base58 input.
Make witness_node accept witness keys in WIF format.
- refactor how signatures are stored on the transaction, removing key_id
and extra_signatures maps and replacing with a vector
- verify that each key only signs one time
- update tests to handle stricter policies on signatures
The INITIAL_SUPPLY macro is generally not useful, and there's no good
way to fulfill the promise it creates. By removing it, I can skip the
scaling on the genesis values. Now, if there is an allocation at
genesis, the supply is determined by that allocation. Otherwise, the
supply is GRAPHENE_MAX_SHARE_SUPPLY and it all belongs to
GRAPHENE_COMMITTEE_ACCOUNT.
Also, remove one of the redundant and confusing MAX_SUPPLY macros and
unify the usage to always be GRAPHENE_MAX_SHARE_SUPPLY.
This logic was previously located in limit_order_create_evaluator, but
other code may need it in the future, so it should be made available at
the database level.
Core exchange rate is now redundantly stored in price feed for
bitassets, and updated when the median feed changes. This allows feed
producers to update the core exchange rate. Redundant storage is
necessary, because the core exchange rate is needed for user-issued
assets as well as market issued assets.
Use static variant to allow the types of vesting balances to be easily
extended and the creation operation allows for many different types of
initialization parameters.
Added a check that requires a minimum claim date which allows creating
of vesting balance objects with a cliff.
Reasons:
1. The protocol should not depend upon implementation details such as
how the database objects are structured or reflected
2. The protocol should deal in abstract concepts
3. Should use fc::datastream rather than istringstream for performance
and memory allocation reasons
4. Fees should be charged proportional to the size of the operation
5. Validate on the assert operation should also perform sanity checks
on types
6. Protocol definition objects should never depend upon the database
because they may be used in situations where the database and
evaluators are not present.
7. Reflected field names should never have '_' in them because they
become part of the *PUBLIC* json definition.
