Eventually multisign will need to be enabled onto the network, at
which point compiling it in or out will no longer be an option.
In preparation, the compile guards are removed and multisign is
being enabled with a Feature.
You can locally enable a Feature using your config file. To
enable multisign with your config file add a section like this:
[features]
MultiSign
The exact spelling and capitalization of both "features" and
"MultiSign" is important. If you don't get those right multisign
will not be enabled.
There is a minor issue. The "sign_for" and "submit_multisigned"
RPC commands are only enabled if multisign is enabled. However
those commands are still shown in the help message even if
multisign is disabled. This is because the code that produces
the help message doesn't read the config file (where the Features
are kept). This problem will become irrelevant once multisign is
enabled onto the network.
An account can be made signable with only its regular key by
disabling the master key. Now an account can also be made
exclusively multisigned by both disabling the master key and
having no regular key.
In order to prevent an account from becoming unsignable the
network uses these rules:
o An account can always add or replace a regular key or a
SignerList as long as the fee and reserve can be met by the
account.
o The master key on an account can be disabled if either a
regular key or a SignerList (or both) is present on the account.
Either the regular key or the SignerList can be used to
re-enable the master key later if that is desired.
o The regular key on an account may only be removed if either the
master key is enabled or the account has a SignerList (or both).
o The SignerList on an account may only be removed if either the
master key is enabled or a regular key is present (or both).
As a consequence of this change, the tecMASTER_DISABLED error
code is renamed to tecNO_ALTERNATIVE_KEY. The error code number
(130 decimal) is unchanged.
With this changeset two-level multisigning is removed from the
codebase and replaced with single-level multisigning.
Additionally, SignerLists in the ledger are prepared for the
possibility of multiple SignerLists per account. This was done
by adding a defaulted 32-bit SignerListID to each SignerList.
The SignerListIndex calculation incorporates the SignerListID.
There are three known missing elements:
1. Multisigned transactions should require higher fees than
regular (single-signed) transaction. That's not yet
implemented.
2. It should be possible to disable the master key on an account
if that account is multisign enabled (has a signer list).
That's not yet implemented.
3. Documentation about multisigning needs to be improved.
Multisigning is still compiled out of the code base. To enable
multisigning for a stand-alone rippled, change the
RIPPLE_ENABLE_MULTI_SIGN macro (in BeastConfig.h) to "1" and
rebuild.
This commit also addresses:
o RIPD-912: Remove multisign APIs from STObject, and
o RIPD-944: Replace common_transactor with jtx at call sites.
This non-production config section allows features to be enabled
by listing their text descriptions, one line each, in the config
section titled "features".
NOTE: Feature names with leading or trailing whitespace, or
containing an equals sign ('=') are not supported.
This implements the tracking of when an amendment achieved a majority
in the ledger, ensuring that there's always network-wide agreement
on which amendments have achieved a majority and how long they've
held it.
* New fields
* Change transactor changes
* AmendmentTable API and implementation changes
* Update amendment enabled status on validated ledgers
* Reinstate support for ledger sequence in fee transactions
The View hierarchy of classes is reorganized to include new
classes with member functions moved and renamed, to solve
defects in the original design:
OpenView accumulates raw state and tx changes and
can be applied to the base. ApplyView accumulates changes
for a single transaction, including metadata, and can be
applied to an OpenView. The Sandbox allows changes with
the option to apply or throw them out. The PaymentSandbox
provides a sandbox with account credit deferral.
Call sites are changed to use the class appropriate for
the task.
