summaryrefslogtreecommitdiff
path: root/src/cryptonote_core
Commit message (Collapse)AuthorAgeFilesLines
* blockchain: fix off by one brought by the regtest mode fixmoneromooo-monero2019-03-041-2/+4
|
* Merge pull request #5205Riccardo Spagni2019-03-031-7/+15
|\ | | | | | | 49896e5c blockchain: fix long term block weight for regtest mode (moneromooo-monero)
| * blockchain: fix long term block weight for regtest modemoneromooo-monero2019-02-271-7/+15
| |
* | core: fix adding new pre-hoh block when a tx is already in the poolmoneromooo-monero2019-02-241-5/+4
|/
* update quick sync checkpoints and hashRiccardo Spagni2019-02-201-1/+1
|
* blockchain: remove buggy long term block weight cachemoneromooo-monero2019-02-192-76/+36
| | | | | | 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-143-6/+6
|
* blockchain: add v10 fork heightsmoneromooo-monero2019-02-141-0/+5
|
* New scheme key destination contrfolcslashm2019-02-142-41/+10
| | | | Implies protocol version management.
* 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-124-12/+26
| | | | This makes it easier to modify the bulletproof format
* core: include a dummy encrypted payment id when no payment is usedmoneromooo-monero2019-02-121-6/+40
| | | | For better transaction uniformity, even though this wastes space.
* core, wallet: remember original text version of destination addressmoneromooo-monero2019-02-121-3/+15
|
* 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-122-3/+5
|
* core: add a few more block rate window sizesmoneromooo-monero2019-02-121-1/+1
| | | | | | | The 10 minute one will never trigger for 0 blocks, as it's still fairly likely to happen even without the actual hash rate changing much, so we add a 20 minute window, where it will (for 0 blocks) and a one hour window.
* core: add --block-rate-notifymoneromooo-monero2019-02-122-0/+33
| | | | | This runs a command whenever the block rate deviates too much from the expectation
* blockchain: add --reorg-notifymoneromooo-monero2019-02-123-1/+32
| | | | | | | | | 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-124-7/+64
| | | | | 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-124-14/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #4667Riccardo Spagni2018-10-201-2/+2
|\ | | | | | | 14515ef2 blockchain: move two new verification errors to the verify category (moneromooo-monero)
| * blockchain: move two new verification errors to the verify categorymoneromooo-monero2018-10-191-2/+2
| | | | | | | | Lest we get people get scared again
* | Merge pull request #4638Riccardo Spagni2018-10-201-1/+6
|\ \ | | | | | | | | | a23c80df core: don't verify range proofs multiple times (moneromooo-monero)
| * | core: don't verify range proofs multiple timesmoneromooo-monero2018-10-171-1/+6
| |/
* / tx_pool: revert #4592 and move bin2hex conversion to on_get_transaction_poolstoffu2018-10-181-1/+1
|/
* tx_pool: store hex string instead of raw binary to tx_blob of ↵stoffu2018-10-151-1/+1
| | | | | | get_transaction_pool RPC Inspired by https://github.com/masari-project/masari/issues/93
* Revert "Merge pull request #4472"Riccardo Spagni2018-10-085-34/+27
| | | | This reverts commit b26ab0b5803af4ffe23de11a45e43877301a4902.
* Merge pull request #4472Riccardo Spagni2018-10-065-27/+34
| | | | 02d3ef7b blocks: use auto-generated .c files instead of 'LD -r -b binary' (xiphon)
* Merge pull request #4476Riccardo Spagni2018-10-021-1/+1
| | | | fa9e54b6 build: fix gcc false positive 'stringop-overflow' warning (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-293-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| |
* | Merge pull request #4435Riccardo Spagni2018-09-251-0/+1
|\ \ | | | | | | | | | c39ad0cd tx_pool: fix tx removal at startup keeping references (moneromooo-monero)
| * | tx_pool: fix tx removal at startup keeping referencesmoneromooo-monero2018-09-251-0/+1
| |/
* / blockchain: add stagenet v8 and v9, two weeks before mainnetmoneromooo-monero2018-09-241-0/+2
|/
* Merge pull request #4378Riccardo Spagni2018-09-212-1/+18
|\ | | | | | | ac934663 rpc: add a "is an update available" flag in get_info (moneromooo-monero)
| * rpc: add a "is an update available" flag in get_infomoneromooo-monero2018-09-142-1/+18
| | | | | | | | Make it easier for a user to be told when to update
* | 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
generated by cgit v1.2.3 (git 2.51.0) at 2026-08-18 20:08:18 +0000