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

Chained JoinSplits #555

Closed
ebfull opened this issue Dec 22, 2015 · 9 comments
Closed

Chained JoinSplits #555

ebfull opened this issue Dec 22, 2015 · 9 comments
Assignees
Labels

Comments

@ebfull
Copy link
Contributor

ebfull commented Dec 22, 2015

PourTxs should be able to anchor to an incremental merkle tree produced by a previous PourTx.

This ticket is about both:

  • making sure that chained pours are verified correctly by consensus checks;
  • supporting construction of chained pours in the RPC interface.
@daira
Copy link
Contributor

daira commented Mar 5, 2016

@ebfull is this implemented?

@ebfull
Copy link
Contributor Author

ebfull commented Mar 13, 2016

This is not implemented and needs to be implemented for 1.0. It won't be that hard.

@ebfull ebfull modified the milestones: Trafford spec and stuff, 1.0 Mar 15, 2016
@ebfull
Copy link
Contributor Author

ebfull commented Mar 20, 2016

I want to implement this after #788 lands.

@nathan-at-least nathan-at-least modified the milestones: 1.0, Consensus Feature Implementation Deadline Mar 28, 2016
@ebfull ebfull removed their assignment Apr 5, 2016
@daira daira added this to the Protocol 2.0 Implementation milestone Apr 25, 2016
@nathan-at-least nathan-at-least modified the milestones: Protocol 2.0-alpha-9bb4410 Implementation, Protocol 2.1 Implementation Apr 25, 2016
@ebfull ebfull self-assigned this May 6, 2016
@ebfull
Copy link
Contributor Author

ebfull commented Jun 1, 2016

The interaction of this feature with the existing RPC design is a bit tricky.

The current design is mostly stateless; you have a transaction, you use zcrawpour to "add" a JoinSplit to it, and you have almost total control over the JoinSplit being added. In this spirit, cryptographic binding is implemented statelessly -- we throw away the private key instead of returning it from the API. The anchor selection routine diverges from this slightly; we don't offer users a way to choose the treestate they build on top of.

In order to retain that design but offer this feature in the API, we have to let users of zcrawpour specify arbitrary inputs and outputs. The pain point here is how vpub_old and vpub_new are exposed.

My idea is to stop offering vpub_old and vpub_new and just infer them from the deficit or surplus of funds from the inputs and outputs. This also avoids the problem of misusing the RPC by specifying vpub_old and vpub_new incorrectly -- we have a consensus rule which requires that they are not both nonzero.

The rest of the approach is just a somewhat-tricky algorithm for efficiently chaining all the inputs together.

@ebfull
Copy link
Contributor Author

ebfull commented Jun 1, 2016

The alternative approach is to figure this mess out when we are working on the payment API, and leave the existing API the same way it is. I've already implemented the consensus rules for it, so I'm pretty happy with going that route.

@ebfull
Copy link
Contributor Author

ebfull commented Jun 8, 2016

I would prefer this be reviewed as-is by at least two engineers on the team.

@ebfull
Copy link
Contributor Author

ebfull commented Jun 8, 2016

(Referring to #973)

@daira
Copy link
Contributor

daira commented Jun 8, 2016

What approach does #973 use for vpub_old/new?

@daira
Copy link
Contributor

daira commented Jun 8, 2016

Oh, it doesn't change the RPC. Yes that's fine.

zkbot pushed a commit that referenced this issue Jun 8, 2016
Add chained `JoinSplit`s

Closes #555
@zkbot zkbot closed this as completed in #973 Jun 8, 2016
@daira daira changed the title Chained pours Chained JoinSplits Jun 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants