This will trigger if a reorg is seen. This may be used to do things
like stop automated withdrawals on large reorgs.
%s is replaced by the height at the split point
%h is replaced by the height of the new chain
%n is replaced by the number of new blocks after the reorg
This curbs runaway growth while still allowing substantial
spikes in block weight
Original specification from ArticMine:
here is the scaling proposal
Define: LongTermBlockWeight
Before fork:
LongTermBlockWeight = BlockWeight
At or after fork:
LongTermBlockWeight = min(BlockWeight, 1.4*LongTermEffectiveMedianBlockWeight)
Note: To avoid possible consensus issues over rounding the LongTermBlockWeight for a given block should be calculated to the nearest byte, and stored as a integer in the block itself. The stored LongTermBlockWeight is then used for future calculations of the LongTermEffectiveMedianBlockWeight and not recalculated each time.
Define: LongTermEffectiveMedianBlockWeight
LongTermEffectiveMedianBlockWeight = max(300000, MedianOverPrevious100000Blocks(LongTermBlockWeight))
Change Definition of EffectiveMedianBlockWeight
From (current definition)
EffectiveMedianBlockWeight = max(300000, MedianOverPrevious100Blocks(BlockWeight))
To (proposed definition)
EffectiveMedianBlockWeight = min(max(300000, MedianOverPrevious100Blocks(BlockWeight)), 50*LongTermEffectiveMedianBlockWeight)
Notes:
1) There are no other changes to the existing penalty formula, median calculation, fees etc.
2) There is the requirement to store the LongTermBlockWeight of a block unencrypted in the block itself. This is to avoid possible consensus issues over rounding and also to prevent the calculations from becoming unwieldy as we move away from the fork.
3) When the EffectiveMedianBlockWeight cap is reached it is still possible to mine blocks up to 2x the EffectiveMedianBlockWeight by paying the corresponding penalty.
0 is placeholder for whole chain, so we should compare chain
height changes rather than chain-height-or-zero. Even this isn't
totally foolproof if a blocks are popped and the same number
added again, but it is much better as it prevents the data from
slowly going out of sync.
9acf42d3 Multisig M/N functionality core tests added (naughtyfox)
9f3963e8 Arbitrary M/N multisig schemes: * support in wallet2 * support in monero-wallet-cli * support in monero-wallet-rpc * support in wallet api * support in monero-gen-trusted-multisig * unit tests for multisig wallets creation (naughtyfox)
2fbf38ee Fix 32bit depends builds (TheCharlatan)
17142ec9 malloc scratchpad for all supported android archs (m2049r)
6a781408 Make depends use self built clang for darwin (TheCharlatan)
69da14e1 fixes make debug compilation on OSX (Dusan Klinec)
fe125647 Fixup RENAME_DB() macro (Howard Chu)
b2972927 osx compilation fix: missing boost libs added (Dusan Klinec)
174f31bf simplewallet: don't complain about payment id on pool mined blocks (moneromooo-monero)
89288863 README: mention ASAN usage alongside valgrind (moneromooo-monero)
83debef9 wallet_rpc_server: remove verbose field in incoming_transfers query (moneromooo-monero)
a69271fa Fixed a typo (Piotr Kąkol)
92d1da28 unit_tests: fix build with GCC 5.4.0 on ubuntu (moneromooo-monero)
a21da905 Wallet: use unique_ptr for WalletImpl members (oneiric)
7a056f44 WalletAPI: multisigSignData bug fixed (naughtyfox)
43a06350 ringdb: use cursors to be a bit faster (moneromooo-monero)
7964d4f8 wallet2: handle corner case in picking fake outputs (moneromooo-monero)
6f5360b3 bump version to 0.13.0.1 (Riccardo Spagni)
cf470bf3 switch from master to rc (Riccardo Spagni)
bcf3f6af fuzz_tests: catch unhandled exceptions (moneromooo-monero)
3ebd05d4 miner: restore stream flags after changing them (moneromooo-monero)
a093092e levin_protocol_handler_async: do not propagate exception through dtor (moneromooo-monero)
1eebb82b net_helper: do not propagate exceptions through dtor (moneromooo-monero)
fb6a3630 miner: do not propagate exceptions through dtor (moneromooo-monero)
2e2139ff epee: do not propagate exception through dtor (moneromooo-monero)
0749a8bd db_lmdb: do not propagate exceptions in dtor (moneromooo-monero)
1b0afeeb wallet_rpc_server: exit cleanly on unhandled exceptions (moneromooo-monero)
418a9936 unit_tests: catch unhandled exceptions (moneromooo-monero)
ea7f9543 threadpool: do not propagate exceptions through the dtor (moneromooo-monero)
6e855422 gen_multisig: nice exit on unhandled exception (moneromooo-monero)
53df2deb db_lmdb: catch error in mdb_stat calls during migration (moneromooo-monero)
e67016dd blockchain_blackball: catch failure to commit db transaction (moneromooo-monero)
661439f4 mlog: don't remove old logs if we failed to rename the current file (moneromooo-monero)
5fdcda50 easylogging++: test for NULL before dereference (moneromooo-monero)
7ece1550 performance_test: fix bad last argument calling add_arg (moneromooo-monero)
a085da32 unit_tests: add check for page size > 0 before dividing (moneromooo-monero)
d8b1ec8b unit_tests: use std::shared_ptr to shut coverity up about leaks (moneromooo-monero)
02563bf4 simplewallet: top level exception catcher to print nicer messages (moneromooo-monero)
c57a65b2 blockchain_blackball: fix shift range for 32 bit archs (moneromooo-monero)
Those take a command line of the form "A [B]", with A being the
name (and optional path, if not in the caller's CWD, but fully
qualified path is recommended, avoids possible security issues)
to a program, and optional arguments. Any occurence of the two
character string "%s" will be replaced by the hash of the block
or transaction which triggered the notification.
Tokenization is barebones. If you want things like pipes, calls
to paths with spaces, etc, then use a script (though exec time
will suffer).
block-notify is called when a new block is added onto the chain.
tx-notify is called when a new transaction happens with the
wallet as source and/or destination.
It is the notification program's responsibility to determine what
to do in those cases.
Note that this is asynchronous, so it is very possible that:
- the notification programs will be run out of order
- several events happen before the notification for the first one
A Windows port would be nice if someone wants to make one.
The key image (which was only supplied if verbose was true) is
readily available, not a secret key, and it was only modelled
after the CLI command because it's a bit spammy for the CLI.
