Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

checkpoints should explicitly declare transactions/blocks that are part of the history but would no longer verify #136

Closed
daira opened this issue Mar 5, 2015 · 2 comments
Labels
A-consensus Area: Consensus rules C-future-proofing Category: Changes that minimise the effects of shocks and stresses of future events. M-requires-zip This change would need to be specified in a ZIP. network upgrade management not in 1.0 notary related special to Daira use case

Comments

@daira
Copy link
Contributor

daira commented Mar 5, 2015

Suppose that we want to fix a bug or irregularity in the consensus protocol, but there are transactions or blocks in the consensus block chain history that took advantage of that bug/irregularity. We ideally want it to be possible to verify the entire history using the current protocol, but that is a potential obstacle to making consensus protocol changes, particularly changes that tighten the acceptance rules.

If we include hashes of known transactions and blocks that wouldn't verify under the new rules as part of a checkpoint, that tells any new verifier that their nonverifiability is intentional and not a mistake, thus giving us more flexibility to change the consensus algorithm. The specific reasons why they no longer verify should be documented.

@daira daira added potential feature dev policy A-consensus Area: Consensus rules use case C-future-proofing Category: Changes that minimise the effects of shocks and stresses of future events. notary related labels Mar 5, 2015
@zookoatleastauthoritycom

This is fascinating. Feels like potentially a great idea. What do we do now about it: document the process?

ebfull pushed a commit that referenced this issue Nov 4, 2015
bccaf86 Merge pull request #150
2a53a47 Merge pull request #151
5f5a31f Merge pull request #149
3907277 Merge pull request #142
a3e0611 Enable tests in x86 travis builds
45da235 x86 builder
8bb0e93 Merge pull request #155
971fe81 build: fix openssl detection for cross builds
f22d73e Explicitly access %0..%2 as 64-bit so we use the right registers for x32 ABI
e66d4d6 Avoid the stack in assembly and use explicit registers
cf7b2b4 Fix ECDSA message hashes to 32 bytes
056ad31 Really compile with -O3 by default
74ad63a Merge pull request #146
9000458 Merge pull request #145
1f46b00 build: fix __builtin_expect detection for clang
aaba2e0 Merge pull request #136
8a0775c Merge pull request #144
ee1eaa7 Merge pull request #141
c88e2b8 Compile with -O3 by default
6558a26 Make the benchmarks print out stats
000bdf6 Rename bench_verify to bench_recovery
7c6fed2 Add a few more additional tests.
992e03b travis: add clang to the test matrix
b43b79a Merge pull request #143
e06a924 Include time.h header for time().
8d11164 Add some additional tests.
3545627 Merge pull request #118
6a9901e Merge pull request #137
376b28b Merge pull request #128
1728806 Merge pull request #138
a5759c5 Check return value of malloc
39bd94d Variable time normalize
ad86bdf Merge pull request #140
54b768c Another redundant secp256k1_fe_normalize
69dcaab Merge pull request #139
1c29f2e Remove redundant secp256k1_fe_normalize from secp256k1_gej_add_ge_var.
2b9388b Remove unused secp256k1_fe_inv_all
f461b76 Allocate precomputation arrays on the heap
b2c9681 Make {mul,sqr}_inner use the same argument order as {mul,sqr}
6793505 Convert YASM code into inline assembly
f048615 Rewrite field assembly to match the C version
3ce74b1 Tweak precomputed table size for G

git-subtree-dir: src/secp256k1
git-subtree-split: bccaf86caa9c44166e5a66600b742c516e03c3f0
@daira daira added the M-requires-zip This change would need to be specified in a ZIP. label Sep 29, 2016
@nuttycom
Copy link
Contributor

The zcashd hardforking upgrade approach means that this is no longer relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-consensus Area: Consensus rules C-future-proofing Category: Changes that minimise the effects of shocks and stresses of future events. M-requires-zip This change would need to be specified in a ZIP. network upgrade management not in 1.0 notary related special to Daira use case
Projects
None yet
Development

No branches or pull requests

4 participants