-
Notifications
You must be signed in to change notification settings - Fork 286
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
chain: disable goosig after 1 year + 1 month #305
Conversation
Codecov Report
@@ Coverage Diff @@
## master #305 +/- ##
==========================================
+ Coverage 58.71% 59.15% +0.44%
==========================================
Files 129 130 +1
Lines 35802 35970 +168
Branches 6028 6046 +18
==========================================
+ Hits 21022 21279 +257
+ Misses 14780 14691 -89
Continue to review full report at Codecov.
|
If I'm understanding this correctly, does this essentially put a time limit on the airdrops claims of 1 year and 1 month? I instinctively feel that this is a bit too short, but definitely open to setting *some time limit on Goosig. |
Not airdrop claims, just GooSig based claims. People will still be able to claim without using GooSig by using a normal RSA signature after the time period has expired. |
If Goosig is broken, doesn't this result in the same outcome privacy wise? EDIT: (This only applies to RSA/Goosig based claims) Does removing Goosig stop the crypto being broken retroactively? EDIT: I'm understanding now that de-anonymization may not be the only worry of the cryptography being broken. I think this makes a lot more sense in that context so feel free to ignore the above scenarios. |
You also need to consider unforgeability, the event by which somebody without the private key can create a signature that is valid. |
ac97631
to
d3125c0
Compare
Updated the mempool code as well to not allow goosig based airdrops into the mempool after the network defined number of blocks has passed. A peer will be banned if they gossip a goosig based airdrop. |
@tynes since regtest essentially allows for an arbitrary number of blocks to be mined at any point, should we consider enabling this on it as well with similar values to testnet? |
@kilpatty I thought purposefully not disabling GooSig on regtest would be a feature, as people may want to be able to test over time without needing to roll over their chaindb (same with simnet). If there is consensus on also disabling on regtest, I will push up a change for that. |
Good point, and I suppose if someone really wants to test the reverse behavior, they can just adjust the values for their own local regtest network. Quick question: What happens in the case of a node that sends Goosig airdrop proofs 1 block away from the cutoff. Those proofs are then not mined in the cutoff block, and so they become invalid. Does that peer get banned? |
Good thinking. The peer would not get banned, but that transaction would be stuck in the mempool. It seems like it would be ideal to evict any goosig based airdrops from the mempool after goosig has been disabled. That way there is no accidental banning of peers. |
Thinking about how to drop GooSig based airdrops out of the mempool correctly, it feels wasteful to check for the GooSig disabled deployment and then attempt to remove all GooSig airdrops every block that is added to the mempool, since no more GooSig based airdrops will be added after a certain height. Another approach would be to only drop GooSig based airdrops out of the mempool if the block being added is at the height of deployment being activated. This seems like its subject to weird race conditions with reorgs. My main concern is that somebody will end up with a GooSig based airdrop in the mempool during the activation and will not be able to broadcast their normal RSA based airdrop. |
I opted for removing all GooSig based airdrops from the mempool at the height that GooSig is disabled instead of checking for the deployment. This saves some extra checks for all future blocks that come after GooSig is disabled. |
Just thinking about the UX of a user sending a goosig airdrop after the expiration time. With a Full Node, it won't go out ( Lines 416 to 420 in c554a6f
But SPV has no such protection: Lines 343 to 345 in c554a6f
In this case, an SPV node could be aware of the rules it is breaking since its just a chain height. I wonder if we should protect such users from being banned this way. Probably we should update the README in |
I think since this is consensus-critical, it'd be nice to see tests. Could be similar to #330 for the flag-height activation, and similar to #319 for clearing out the mempool. JJ's personal Airdrop is Goosig and can be tested: https://github.com/handshake-org/hsd/blob/master/test/data/airdrop-proof.base64 |
This now has test coverage and is ready for another round of review. Will squash when it looks good. |
This is a great catch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tynes I added some comments and nits re: the test.
This comment has been minimized.
This comment has been minimized.
Squashed 1 commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tynes I left a couple of more comments. This is almost ready to go.
@boymanjor Any more comments on this one? I think its good to be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left one last nit. LGTM.
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #305 +/- ##
==========================================
+ Coverage 58.71% 59.15% +0.44%
==========================================
Files 129 130 +1
Lines 35802 35970 +168
Branches 6028 6046 +18
==========================================
+ Hits 21022 21279 +257
+ Misses 14780 14691 -89 ☔ View full report in Codecov by Sentry. |
Edited 1/24/20
Adds a new hard coded deployment that disables GooSig after 1 year and 1 month of blocktime. This is to prevent the cryptography being broken in an unforseen way or a social attack where somebody claims it is broken when it actually isn't.
TwoOne new field is added tolib/protocol/networks
[network].airdrop.disableGoosig
[network].airdrop.disableGoosigHeight
[network].goosigStop
I used 2 variables to be very explicit,disableGoosig
is a boolean anddisableGoosigHeight
is an integer. We could combine them into a single variable using-1
asdisableGoosig: false
if that is preferred.TheDeploymentState
is updated with a new propertygoobye
and a getterhasGooBye
. I wasn't sure what the best name for this deployment is, so I just went with that. Open to suggestions.The functionality is as of follows:
If the network allows for GooSig to be disabled and the height of the previous block is greater than or equal to the hardcoded network height, then disable GooSig.
TODO: