-
Notifications
You must be signed in to change notification settings - Fork 8
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
Stop conflating initiating-participant with first-active-participant #412
Comments
It might be that the first-depositing-participant could be the one to create the contract on an Account model, but not on a UTXO model. But the first-depositing-participant might not necessarily be the "initiating-participant" or the "first-active-participant". |
In these events:
There is a constraint that But there is no intrinsic constraint between |
An alternative version??
Here there is a constraint that all 4 of the events above the line must happen before both of the events below the line. In the case where Question: if the program is written like this, but without explicit escrow... assuming the escrow is always inferred properly... could the various backends optimize this same program to use their respective advantages? The compilation strategy for the Account model to optimize-away the B-commit? The compilation strategy for the UTXO model to use off-chain communication to combine the reveals in the best case? |
We can make the initiating participant on Ethereum the first-depositing-participant, and worry about other backends later, and worry about being flexible with order later. |
Related to issue #188 for 0-transaction interactions, more important for future
race
construct plans where the first-active-participant may be any of the competitors in the race.The first-transaction-optimization should only even be considered when the initiating-participant and the first-active-participant are the same.
The text was updated successfully, but these errors were encountered: