Add support for open contracts, i.e. dynamic participants

[jeapostrophe]

For example, an auction where we do not know who the participants are before hand. This requires a concept of a "participant class" where our current participants are just a special case of that.

[fare]

I did a simple auction, with open bids before a deadline, whereby each top bidder replaces the previous one. It required only required three participants at any time (seller, previous top bidder, current bidder candidate), though it is a changing set of participants. See archive/simple-auction.ala.

For a closed bid auction, with potentially a lot of participants, we could simply have one deadline to place bids and another deadline to reveal bids. Because in absence of a trusted third-party we can never force the second bid to reveal themselves, we cannot do the "first bidder pays amount of second bid" which is fairer in the centralized case. I will write that auction at some point.

Writing the code should be simple enough. A more interesting question is: what are the properties worth verifying? We might want something like "every bid will either succeed, or the user will get his collateral back", so bidders only pay the participation fee plus some statically bounded gas—per bid. We could have a deadline after which the organizer can close the contract and get all the money left; but if not, there is not necessarily a point in time where the contract has no money left in it—some failing bidders might leave their money in indefinitely (minus lost collateral). And even if there is a deadline, the safety invariant would be for each bidder that they'll get their collateral back if they reveal their bid on time.

[jeapostrophe]

One way to think about this is for there to be a consensual moment when there is a join action where a new party enters the protocol. This participant comes in with some pre-existing information (just like initial participants). Their identity would be a variable in the program and it would be allowed to be mentioned as a sender/transfer target/etc. Their identity would be preserved in as much as it occurs in the continuation. When we do extraction, we do it once for each join point --- that is "Alice" is the first joiner; "Bob" is the second; and so on. Joiners are assumed to follow along in the protocol the entire time (even before they joined!) to know the values of everything.

[fare]

Anyone might be considered a previous participant with 0 stake and 0 collateral so far.

In direct-style dapps (our only kind of dapps so far), a message to the blockchain contract is all that's needed for the new participant to join the interaction with their stake.

In state-channel dapp (that we're working on next), all previously active participants (a small number) sign all messages, and may easily censor a new active participant whose interests are at odds with them. One solution against such censorship might be an asynchronous relationship between the set of new participants who self-select and the set of active participants who are required to acknowledge new participants within some delay—or not, to avoid vulnerability to bad actors joining then stalling (at which point the new participant can "just" leave with their unacknowledged stake). But when possible, it might be simpler to have either one dapp implementation strategy or the other and not mix them unless really necessary.