summaryrefslogtreecommitdiff
path: root/src/cryptonote_core/blockchain.cpp
Commit message (Collapse)AuthorAgeFilesLines
* update quick sync checkpoints and hashRiccardo Spagni2019-02-201-1/+1
|
* blockchain: remove buggy long term block weight cachemoneromooo-monero2019-02-191-67/+34
| | | | | | It seems to be buggy on reorgs, and prevents the use of a blockchain with two nodes. We'll speed this up again if/when the need arises.
* blockchain: fix block template creation racemoneromooo-monero2019-02-181-5/+5
| | | | | | | | | | | | | | | If two create_block_template are called at nearly the same time, and a block is added at nearly the same time, this could happen: - the blockchain top block is B0 - thread 1 enters create_block_template, takes blockchain lock - thread 1 creates a fresh block referencing prev block B0 - thread 1 releases blockchain lock - thread 0 adds a new block - thread 0 enters create_block_template - thread 0 updates block template - thread 1 takes txpool lock and continues creating block template - thread 1 overwrites block template with previous data
* blockchain: fix long term weight addition on pop/initmoneromooo-monero2019-02-181-2/+4
|
* blockchain: fix m_long_term_block_weight_height initializationmoneromooo-monero2019-02-151-6/+13
| | | | Also check return of that function, it can now return error
* blockchain: forbid older BP rct versions from v11moneromooo-monero2019-02-151-1/+18
|
* Fix v3/v4 db conversionmoneromooo-monero2019-02-151-0/+2
|
* Build fixes for some platformsmoneromooo-monero2019-02-141-4/+4
|
* blockchain: add v10 fork heightsmoneromooo-monero2019-02-141-0/+5
|
* cryptonote: Fix enum check in expand_transaction_2Tom Smeding2019-02-141-1/+1
| | | | | This was noticed because GCC warned about using an enum value in a boolean context.
* add a bulletproof version, new bulletproof type, and rct configmoneromooo-monero2019-02-121-2/+15
| | | | This makes it easier to modify the bulletproof format
* blockchain: fix wrong hf version when popping multiple blocksmoneromooo-monero2019-02-121-6/+4
| | | | | | Since we keep track of the hf version in the db, we pick it up from there instead of doing the full reorg call, which is quite expensive
* blockchain: fix block rate check for empty blockchainsmoneromooo-monero2019-02-121-1/+3
|
* core: fix unmixable special case allowing ring size below 11moneromooo-monero2019-02-121-1/+1
|
* blockchain: include number of discarded blocks in --reorg-notifymoneromooo-monero2019-02-121-1/+2
|
* blockchain: add --reorg-notifymoneromooo-monero2019-02-121-0/+5
| | | | | | | | | 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
* cryptonote_core: warn when the block rate deviates from expectationsmoneromooo-monero2019-02-121-0/+9
| | | | | The warning threshold is set to allow a false positive every ten days on average.
* notify: handle arbitrary tagsmoneromooo-monero2019-02-121-1/+1
|
* ArticMine's new block weight algorithmmoneromooo-monero2019-02-121-12/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* blockchain: move two new verification errors to the verify categorymoneromooo-monero2018-10-191-2/+2
| | | | Lest we get people get scared again
* Revert "Merge pull request #4472"Riccardo Spagni2018-10-081-14/+15
| | | | This reverts commit b26ab0b5803af4ffe23de11a45e43877301a4902.
* Merge pull request #4472Riccardo Spagni2018-10-061-15/+14
| | | | 02d3ef7b blocks: use auto-generated .c files instead of 'LD -r -b binary' (xiphon)
* Merge pull request #4467Riccardo Spagni2018-10-021-2/+2
| | | | fa942ef6 daemon: silence daemon update warnings on testnet (iDunk5400)
* add --block-notify to monerod and --tx-notify to monero-wallet-{cli,rpc}moneromooo-monero2018-09-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #4423v0.13.0.0-RC1Riccardo Spagni2018-09-251-1/+1
|\ | | | | | | | | | | | | 357441a2 add checkpoints for testnet and mainnet (Riccardo Spagni) d9f666d7 update checkpoints.dat (Riccardo Spagni) 6b1b4e83 update version to 13.0 (Riccardo Spagni) 6f153533 update readme with v13.0 (Riccardo Spagni)
| * update checkpoints.datRiccardo Spagni2018-09-231-1/+1
| |
* | blockchain: add stagenet v8 and v9, two weeks before mainnetmoneromooo-monero2018-09-241-0/+2
|/
* Merge pull request #4369Riccardo Spagni2018-09-211-7/+2
|\ | | | | | | | | b2bb9312 blockchain: simplify output distribution code (moneromooo-monero) befdcbf4 db_lmdb: do not use base for cumulative distribution (moneromooo-monero)
| * blockchain: simplify output distribution codemoneromooo-monero2018-09-121-7/+2
| |
* | Merge pull request #4325Riccardo Spagni2018-09-181-0/+6
|\ \ | | | | | | | | | 4e1e9a60 blockchain: add mainnet v8 height targetting 18 october (moneromooo-monero)
| * | blockchain: add mainnet v8 height targetting 18 octobermoneromooo-monero2018-09-021-0/+6
| | | | | | | | | | | | and v9 a day later
* | | remove obsolete daemon selection of fake outs and old tx constructionmoneromooo-monero2018-09-141-242/+0
| |/ |/|
* | blockchain: add a testnet v9 a day after v8moneromooo-monero2018-09-111-0/+1
| | | | | | | | So that bulletproofs become mandatory
* | v8: per byte fee, pad bulletproofs, fixed 11 ring sizemoneromooo-monero2018-09-111-122/+175
| |
* | Bulletproof aggregated verification and testsmoneromooo-monero2018-09-111-8/+7
| | | | | | | | Also constrains bulletproofs to simple rct, for simplicity
* | bulletproofs: add aggregated verificationmoneromooo-monero2018-09-111-1/+1
| | | | | | | | Ported from sarang's java code
* | bulletproofs: add multi output bulletproofs to rctmoneromooo-monero2018-09-111-0/+16
|/
* Merge pull request #4240luigi11112018-08-221-1/+1
|\ | | | | | | 83f5587 blockchain: use uint64_t for height, not size_t (moneromooo-monero)
| * blockchain: use uint64_t for height, not size_tmoneromooo-monero2018-08-091-1/+1
| |
* | Merge pull request #4204luigi11112018-08-221-4/+8
|\ \ | | | | | | | | | b278b83 core: sync database based on bytes added, not blocks added (moneromooo-monero)
| * | core: sync database based on bytes added, not blocks addedmoneromooo-monero2018-08-121-4/+8
| |/ | | | | | | | | Blocks have a very wide range, whereas actual size is the relevant quantity to consider when syncing
* | core: cache block template where possiblemoneromooo-monero2018-08-161-1/+43
| | | | | | | | | | | | | | This avoids constant rechecking of the same things each time a miner asks for the block template. The tx pool maintains a cookie to allow users to detect when the pool state changed, which means the block template needs rebuilding.
* | Merge pull request #4164luigi11112018-08-151-15/+19
|\ \ | |/ |/| | | 8e24533 blockchain: some batch tx scanning speedup (moneromooo-monero)
| * blockchain: some batch tx scanning speedupmoneromooo-monero2018-07-211-15/+19
| |
* | Merge pull request #4108luigi11112018-07-271-0/+1
|\ \ | |/ |/| | | 8c05237 blockchain: cache next block difficulty after adding a block (moneromooo-monero)
| * blockchain: cache next block difficulty after adding a blockmoneromooo-monero2018-07-071-0/+1
| | | | | | | | | | It's not 100% certain it'll be needed, but it avoids getinfo needing the blockchain lock and potentially blocking
* | Merge pull request #4081luigi11112018-07-191-1/+2
|\ \ | | | | | | | | | d95bc44 blockchain: fix getting invalid block data on failure (moneromooo-monero)
| * | blockchain: fix getting invalid block data on failuremoneromooo-monero2018-06-291-1/+2
| |/
* | Merge pull request #4076luigi11112018-07-191-0/+2
|\ \ | | | | | | | | | aa0ea0a blockchain: set the m_verifivation_failed flag in a couple more places (moneromooo-monero)
| * | blockchain: set the m_verifivation_failed flag in a couple more placesmoneromooo-monero2018-06-281-0/+2
| |/ | | | | | | | | | | when a block being added to the main chain is invalid. This ensures the peer is banned after a number of these.
generated by cgit v1.2.3 (git 2.51.0) at 2026-08-17 10:41:10 +0000