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

Support new Bulletproof rewind scheme #2848

Merged
merged 11 commits into from
Jun 12, 2019

Conversation

jaspervdm
Copy link
Contributor

@jaspervdm jaspervdm commented May 26, 2019

Changes to the keychain and builders that are needed for mimblewimble/grin-wallet#105.

I introduce a new ProofBuild trait, that is used in building and rewinding a proof. At the moment there are two of them, LegacyProofBuilder and ProofBuilder. Wallets can supply the transaction build functions with any struct that implements ProofBuild. grin-wallet v2.0.0 will only use ProofBuilder for creating new outputs, but use LegacyProofBuilder to rewind proofs before the hard fork height.

I also did some refactoring around switch commitments. With the new rewind scheme there is a version byte specifically for the switch commitment, which means we have the possibility to turn switch commitments off or use a different type for specific outputs, without requiring additional grinding.
For now all outputs that are created will use the Regular type. In the future we could have full support on the wallet level for this, but this will have to be done in another PR.

This PR also has a ViewKey struct, that can be used to scan the chain. Currently it cannot detect switch commitment outputs because it requires 2 extra functions to be added to libsecp. See here for more information

@jaspervdm
Copy link
Contributor Author

@cadmuspeverell thanks for checking the code, however I did some big refactoring on it. I decided that the keychain should be a general key derivation tool, it shouldn't even be aware of the fact of "legacy" proofs. This is why I created a ProofBuild trait, see edited opening post. Happy to hear your thoughts on it!

Regarding switch commitments: I agree in general switch commitments should be used. However in some very specific scenario's wallet implementators might not want to use them. For this reason and having the possibility to move to a different scheme in the future I added a SwitchCommitmentType enum. The proofs decode and encode them, but for now on the wallet level it is assumed that they are always of the SwitchCommitmentType::Regular type.

@yeastplume
Copy link
Member

Still a ways to go, but I've had a look over it and absolutely happy with the approach, I likely would have done something similar. Totally in agreement with not loading up the keychain with too much more functionality at this stage (given we've been talking a bit about where it should ultimately go)

@jaspervdm jaspervdm changed the title Update keychain with new rewind scheme Support new bulletproof rewind scheme May 27, 2019
@jaspervdm jaspervdm changed the title Support new bulletproof rewind scheme Support new Bulletproof rewind scheme May 27, 2019
@yeastplume yeastplume added this to the 2.x.x milestone Jun 6, 2019
@jaspervdm jaspervdm changed the base branch from master to milestone/2.0.0 June 6, 2019 12:12
@quentinlesceller quentinlesceller modified the milestones: 2.x.x, 2.0.0 Jun 10, 2019
@jaspervdm jaspervdm marked this pull request as ready for review June 11, 2019 16:58
@yeastplume yeastplume merged commit e3f3064 into mimblewimble:milestone/2.0.0 Jun 12, 2019
yeastplume added a commit that referenced this pull request Jun 27, 2019
* create 2.0.0 branch

* fix humansize version

* update grin.yml version

* PoW HardFork (#2866)

* allow version 2 blocks for next 6 months

* add cuckarood.rs with working tests

* switch cuckaroo to cuckarood at right heights

* reorder to reduce conditions

* remove _ prefix on used args; fix typo

* Make Valid Header Version dependant on ChainType

* Rustfmt

* Add tests, uncomment header v2

* Rustfmt

* Add FLOONET_FIRST_HARD_FORK height and simplify logic

* assume floonet stays closer to avg 60s block time

* move floonet hf forward by half a day

* update version in new block when previous no longer valid

* my next commit:-)

* micro optimization

* Support new Bulletproof rewind scheme (#2848)

* Update keychain with new rewind scheme

* Refactor: proof builder trait

* Update tests, cleanup

* rustfmt

* Move conversion of SwitchCommitmentType

* Add proof build trait to tx builders

* Cache hashes in proof builders

* Proof builder tests

* Add ViewKey struct

* Fix some warnings

* Zeroize proof builder secrets on drop

* Modify mine_block to use wallet V2 API (#2892)

* update mine_block to use V2 wallet API

* rustfmt

* Add version endpoint to node API, rename pool/push (#2897)

* add node version API, tweak pool/push parameter

* rustfmt

* Upate version api call (#2899)

* Update version number for next (potential) release

* zeroize: Upgrade to v0.9 (#2914)

* zeroize: Upgrade to v0.9

* missed Cargo.lock

* [PENDING APPROVAL] put phase outs of C32 and beyond on hold (#2714)

* put phase outs of C32 and beyond on hold

* update tests for phaseouts on hold

* Don't wait for p2p-server thread (#2917)

Currently p2p.stop() stops and wait for all peers to exit, that's
basically all we need. However we also run a TCP listener in this thread
which is blocked on `accept` most of the time. We do an attempt to stop
it but it would work only if we get an incoming connection during the
shutdown, which is a week guarantee.

This fix remove joining to p2p-server thread, it stops all peers and
makes an attempt to stop the listener.

Fixes [#2906]

* rustfmt
@jaspervdm jaspervdm deleted the rewind branch July 6, 2019 15:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants