monero.git - Monero: the secure, private, untraceable cryptocurrency

Age	Commit message (Collapse)	Author	Files	Lines
2022-03-04	Copyright: Update to 2022	mj-xmr	1	-1/+1

2020-12-10	protocol: drop origin IP if a block fails to verify in sync mode	moneromooo-monero	1	-8/+10
	It would otherwise be possible for a peer to send bad blocks, then disconnect and reconnect again, escaping bans
2020-05-06	Update copyright year to 2020	SomaticFanatic	1	-1/+1
	Update copyright year to 2020
2019-09-27	monerod can now sync from pruned blocks	moneromooo-monero	1	-1/+1
	If the peer (whether pruned or not itself) supports sending pruned blocks to syncing nodes, the pruned version will be sent along with the hash of the pruned data and the block weight. The original tx hashes can be reconstructed from the pruned txes and theur prunable data hash. Those hashes and the block weights are hashes and checked against the set of precompiled hashes, ensuring the data we received is the original data. It is currently not possible to use this system when not using the set of precompiled hashes, since block weights can not otherwise be checked for validity. This is off by default for now, and is enabled by --sync-pruned-blocks
2019-03-05	Update 2019 copyright	binaryFate	1	-1/+1

2019-01-22	Pruning	moneromooo-monero	1	-6/+11
	The blockchain prunes seven eighths of prunable tx data. This saves about two thirds of the blockchain size, while keeping the node useful as a sync source for an eighth of the blockchain. No other data is currently pruned. There are three ways to prune a blockchain: - run monerod with --prune-blockchain - run "prune_blockchain" in the monerod console - run the monero-blockchain-prune utility The first two will prune in place. Due to how LMDB works, this will not reduce the blockchain size on disk. Instead, it will mark parts of the file as free, so that future data will use that free space, causing the file to not grow until free space grows scarce. The third way will create a second database, a pruned copy of the original one. Since this is a new file, this one will be smaller than the original one. Once the database is pruned, it will stay pruned as it syncs. That is, there is no need to use --prune-blockchain again, etc.
2018-07-20	block_queue: faster check whether a block was requested	moneromooo-monero	1	-0/+6

2018-06-26	replace std::list with std::vector on some hot paths	moneromooo-monero	1	-10/+10
	also use reserve where appropriate
2018-01-26	Readd copyright starting date	xmr-eric	1	-1/+1

2018-01-26	Update 2018 copyright	xmr-eric	1	-1/+1

2017-08-21	cryptonote_protocol: misc fixes to the new sync algorithm	moneromooo-monero	1	-1/+2
	Fix sync wedge corner case: It could happen if a connection went into standby mode, while it was the one which had requested the next span, and that span was still waiting for the data, and that peer is not on the main chain. Other peers can then start asking for that data again and again, but never get it as only that forked peer does. And various other fixes
2017-08-16	cryptonote_protocol: kick idle synchronizing peers	moneromooo-monero	1	-0/+1
	In case they dropped off downloading for any reason, they'll get sent to download again.
2017-08-12	protocol: fix reorgs while syncing	moneromooo-monero	1	-3/+3

2017-08-07	cryptonote_protocol: retry stale spans early	moneromooo-monero	1	-0/+1
	Connections can be dropped by the net_node layer, unbeknownst to cryptonote_protocol, which would then not flush any spans scheduled to that connection, which would cause it to be only downloaded again once it becomes the next span (possibly after a small delay if it had been requested less than 5 seconds ago).
2017-08-07	cryptonote_protocol_handler: sync speedup	moneromooo-monero	1	-0/+96
	A block queue is now placed between block download and block processing. Blocks are now requested only from one peer (unless starved). Includes a new sync_info coommand.