monzero-core.git/src/cryptonote_core/cryptonote_basic.h, branch v0.9.0 Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.9.0 2015-12-31T06:39:56Z updated copyright year 2015-12-31T06:39:56Z Riccardo Spagni ric@spagni.net 2015-12-31T06:39:56Z urn:sha1:de0392685063d93dbdad3a6b1a2712eaf94dd51a Revert "Merge pull request #506" 2015-11-30T09:07:22Z Riccardo Spagni ric@spagni.net 2015-11-30T09:07:22Z urn:sha1:2ea8d7345fa6bebf99c0630fbaab4eae6d5805b2 This reverts commit c6bf73131aaf804cb17f24c856f826be2761a566, reversing changes made to 8a52cf4055d247dd4b162985c931e99683992e3c. core: serialize block major/minor versions as bytes, not varints 2015-11-27T20:54:01Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2015-11-27T20:54:01Z urn:sha1:e45a8c9768d942868fbe7f62ea5f521947e9f671 This allows them to be saved as a fixed (one byte) chunk whatever the value. Using a varint will use two bytes as the high bit gets set. This is backward compatible with current usage (0-2 values). hardfork: switch voting to block minor version 2015-10-21T18:21:14Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2015-10-21T18:18:00Z urn:sha1:63766275301f1c562205e22d5f14b220f321ad58 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. blockchain: use the new hardfork class 2015-09-12T10:15:53Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2015-09-12T10:14:00Z urn:sha1:f85498422d9aec79411c739835ab4a5ed27b1688 encrypted payment ids are now 64 bit, instead of 256 bit 2015-08-09T09:13:51Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2015-08-09T09:09:39Z urn:sha1:a2d7a5fb49dedd6c7e024701eefc4c0beade1edd Pros: - smaller on the blockchain - shorter integrated addresses Cons: - less sparseness - less ability to embed actual information The boolean argument to encrypt payment ids is now gone from the RPC calls, since the decision is made based on the length of the payment id passed. Add compile-time support for both db implementations: in-memory and LMDB 2015-02-02T19:53:09Z warptangent warptangent@inbox.com 2015-01-26T05:36:09Z urn:sha1:84fe5fbd65100a731608471ef0a4c462ea8f5626 Usage: default is lmdb for blockchain branch: $ make release same as: $ DATABASE=lmdb make release for original in-memory implementation: $ DATABASE=memory make release year updated in license 2015-01-02T16:52:46Z Riccardo Spagni ric@spagni.net 2015-01-02T16:52:46Z urn:sha1:f4b69d553a249ace3694e3b4fd307ddffa156d7d Revert "low risk, potentially varint overflow bug patched thanks to BBR" 2014-09-25T06:24:42Z Riccardo Spagni ric@spagni.net 2014-09-25T06:24:42Z urn:sha1:59a8366bb18653f14142321a9d85377ceaef8fad This reverts commit 4e2b2b942daa4206ec44c66e59863670dfe3fde4. low risk, potentially varint overflow bug patched thanks to BBR 2014-09-25T02:17:33Z Riccardo Spagni ric@spagni.net 2014-09-24T20:28:25Z urn:sha1:4e2b2b942daa4206ec44c66e59863670dfe3fde4