sami7777/cac3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bitcoin to NYC3 and update gitian compile code

Browse Source
This commit is contained in:
Akshay
2019-06-09 12:22:49 +03:00
parent d8192b664c
commit 516a7bafec
921 changed files with 1868 additions and 1858 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/developer-notes.md
+3 -3
View File
@@ -807,7 +807,7 @@ you must be aware of.
In most configurations we use the default LevelDB value for `max_open_files`,
which is 1000 at the time of this writing. If LevelDB actually uses this many
file descriptors it will cause problems with Bitcoin's `select()` loop, because
file descriptors it will cause problems with NYC3's `select()` loop, because
it may cause new sockets to be created where the fd value is >= 1024. For this
reason, on 64-bit Unix systems we rely on an internal LevelDB optimization that
uses `mmap()` + `close()` to open table files without actually retaining
@@ -833,14 +833,14 @@ details.
### Consensus Compatibility
It is possible for LevelDB changes to inadvertently change consensus
compatibility between nodes. This happened in Bitcoin 0.8 (when LevelDB was
compatibility between nodes. This happened in NYC3 0.8 (when LevelDB was
first introduced). When upgrading LevelDB you should review the upstream changes
to check for issues affecting consensus compatibility.
For example, if LevelDB had a bug that accidentally prevented a key from being
returned in an edge case, and that bug was fixed upstream, the bug "fix" would
be an incompatible consensus change. In this situation the correct behavior
would be to revert the upstream fix before applying the updates to Bitcoin's
would be to revert the upstream fix before applying the updates to NYC3's
copy of LevelDB. In general you should be wary of any upstream changes affecting
what data is returned from LevelDB queries.