| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| // fact guarantee detection of up to 4 errors within a window of 89 characters. | ||
| // x^12 + {31}x^10 + {10}x^9 + {18}x^8 + {31}x^7 + {14}x^6 | ||
| // + {18}x^5 + {23}x^3 + {22}x^2 + {4}x + {6} . g(x) is chosen in such a way | ||
| // that the resulting code is a BCH code, guaranteeing detection of up to ??? errors within a |
There was a problem hiding this comment.
@apoelstra Can you lookup the values needed for the 4 ??? values on lines 48 through 50?
Sorry, something went wrong.
There was a problem hiding this comment.
cc @sipa @instagibbs do either of you remember the paramaters of this code?
Sorry, something went wrong.
There was a problem hiding this comment.
Sipa would be the one to know what and why
Sorry, something went wrong.
There was a problem hiding this comment.
Given the size I think it was just algebraically constructed, not optimized for by exhaustive analysing its actual behavior. Let me run some tests to see if I can reconstruct it.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Pull requests without a rationale and clear improvement may be closed
immediately.
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly.
functional tests (see test/). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they significantly improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the developer notes, stylistic code
changes are usually rejected.
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.