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

Age	Commit message (Collapse)	Author	Files	Lines
2015-11-24	hardfork: fix more major/minor issues	moneromooo-monero	1	-44/+57
	Also add some more tests, and rename some instances of "version" and "add" for clarity. NOTE: the starting height values are sometimes wrong. I suspect this is due to the hard fork reorg code being buggy, since they're good when syncing after the fact. However, they're not actually used by the consensus code, so I'm ignoring this for now, but this needs debugging.
2015-11-10	hardfork: add a get_ideal_version(uint64_t) function	moneromooo-monero	1	-0/+22
	It returns the ideal version for a given height, which is based on the minimum height for a fork, disregarding votes
2015-11-08	hardfork: allow per-fork voting thresholds	moneromooo-monero	1	-0/+28
	And setup the first fork to not vote
2015-10-27	Remove some old/obsolete/unused code	moneromooo-monero	1	-1/+0
	git history's here if needed to get any of this back
2015-10-26	Build fixes for the old blockchain_storage version	moneromooo-monero	1	-0/+5

2015-10-21	hardfork: switch voting to block minor version	moneromooo-monero	1	-4/+1
	Using major version would cause older daemons to reject those blocks as they fail to deserialize blocks with a major version which is not 1. There is no such restriction on the minor version, so switching allows older daemons to coexist with newer ones till the actual fork date, when most will hopefully have updated already. Also, for the same reason, we consider a vote for 0 to be a vote for 1, since older daemons set minor version to 0.
2015-10-21	unit_tests: remove leftover debug traces in hardfork test	moneromooo-monero	1	-2/+0

2015-09-27	hardfork: rescan speedup	moneromooo-monero	1	-8/+8
	Add a block height before which version 1 is assumed Use DB transactions
2015-09-27	hardfork: change window semantics to not count the newly added block	moneromooo-monero	1	-10/+13
	This allows knowing the hard fork a block must obey in order to be added to the blockchain. The previous semantics would use that new block's version vote to determine this hard fork, which made it impossible to use the rules to validate transactions entering the tx pool (and made it impossible to validate a block before adding it to the blockchain).
2015-09-20	hardfork: most state now saved to the DB	moneromooo-monero	1	-142/+200
	There will be a delay on first load of an existing blockchain as it gets reparsed for this state data.
2015-09-12	New hardfork class	moneromooo-monero	1	-0/+394
	This keeps track of voting via block version, in order to decide when to enable a particular fork's code.