Paying through payment channels should always not incur ethereum gas fees “in the optimistic case”, since the payment involves just exchanging some messages. In that sense the cost of an ecrecover doesn’t affect the cost of paying through a payment channel. It does affect the kinds of griefing attack one can do through channels, so we would want to optimize it for that situation.
Unless you’re talking about hash locks in some other context?
The only thing I care about is optimizing for griefing - everything else is pretty straightforward, otherwise (imo).
You don’t get perfect fungibility—you get “capped” fungibility. Remember, you can only receive money in a Plasma-Debit-style payment if you have a coin/channel with the operator. Effectively, every incoming payment is actually from the operator, and every outgoing payment is to the operator. These limitations are what allow us to preserve almost all of the per-coin-isolation of Plasma Cash.
Suppose Alice and Bob own coins on a Plasma Debit chain. Alice and Bob are obviously aware of the history of their own coins, and know that they are valid. Bob’s coin has some receiving capacity (i.e., the operator owns some of the balance in that coin).
Alice makes a Plasma Debit payment to Bob. That takes the form of an atomic transaction where Alice pays the operator by decrementing her balance in her coin/channel, and the operator pays Bob by incrementing the balance in Bob’s coin/channel. This transaction is signed by both Alice and Bob. For this transaction, Bob doesn’t care if the history of Alice’s coin is valid! He only cares that his own coin’s history is valid (which he already knows, up to the present), and that the balance in his coin goes up. For this reason, even after this transaction, there is no way for someone to challenge the history of Bob’s coin by showing something invalid in Alice’s coin’s history.
Now suppose you are a later recipient of Bob’s coin, validating its history. You see this transaction where Bob’s balance was incremented—effectively, a payment from the operator to Bob. You shouldn’t (and don’t) have to check anything about Alice’s account (either the validity of its history or even whether the transaction was included in Alice’s slot) to consider this a valid transaction with respect to Bob’s coin, because any malfeasance could only be committed by the operator, and would only hurt the operator.
Next let’s suppose you are a later recipient of Alice’s coin, validating its history. The only thing you need to check is that the transaction was also included in Bob’s slot in the same block. If the history of Bob’s slot is invalid, that’s Bob’s problem! As far as Alice was concerned, she sent him the money.
I’d thought that this requirement would actually need to be more onerous, due to the possibility that the operator could insert an invalid transaction, such as a spend from a prior owner, into Bob’s slot before including this transaction, thus cheating Bob by forcing him to exit from the previous state, where his balance was unincremented. But I just realized that reverting from the exit game that I proposed here to the one initially proposed by Vitalik should address it, because it prevents an exit from being challenged by some non-double-spend invalid transaction inserted between the transaction and its parent.
Mostly agree with this, but I don’t see how this implies that the smaller your (marginal) transactions are, the smaller the griefing bounds have to be for safety reasons. I can have a channel with someone where we collectively own 10 eth, and the fee for resolving any dispute is capped at 0.1 eth (assuming I have a bound I believe gas fees are unlikely to go over), and it is perfectly safe for me to update the balance to transfer 0.00001 eth to my counterparty
So, say that Alice and Bob both join the plasma chain and wish to pay one another but have no receiving capacity - what happens here?
I’m still a bit confused as to why the operator by default has some of the balance of Bob’s coin.
“You shouldn’t (and don’t) have to check anything about Alice’s account (either the validity of its history or even whether the transaction was included in Alice’s slot) to consider this a valid transaction with respect to Bob’s coin, because any malfeasance could only be committed by the operator, and would only hurt the operator .”
Then Alice can’t make a Plasma Debit payment to Bob yet. (She could still make a Plasma Cash payment to him by transferring the entire amount of her channel to him.)
The operator could enable this transaction by depositing some of its own liquidity into Bob’s coin, so that that coin now has some operator-owned balance. (This is different from making a payment to Bob—the operator still owns their ETH, they’re just holding it in that coin, next to Bob’s ETH.) But of course, this does requires the operator to lock up some capital.
The operator is like a Lightning hub. When you open a channel with a Lightning hub, you can’t receive any payments over that channel unless either a) the hub puts some of their own liquidity into that channel, or b) you make some payments through that channel, thus reducing the portion of it that you own and increasing the amount that your counterparty owns, and thus your own receiving capacity.
So enabling Plasma Debit payments requires some liquidity commitment by the operator.
Not by default, just by assumption of the above example. When you initially deposit, you own the entire balance in your coin, until you make a Plasma Debit payment, or the operator commits some of their own capital into the coin. The above example assumed that one of those things had already happened, so Bob already had some receiving capacity.
No, there is no trust requirement.
The reason any malfeasance would hurt the operator is that in the example I was discussing, the malfeasance would basically be “incrementing Bob’s balance without decrementing Alice’s balance,” which is equivalent to “the operator paying Bob, without the operator getting paid by Alice.”
So the repercussions for this misbehavior would be that Bob still gets paid, but the operator is the one bearing the cost of the payment, rather than Alice.
How could the operator deposit liquidity into Bob’s coin if Bob has no receiving capacity and ergo could not receive from Alice?
So if the lightning hub requires liquidity on the part of the operator - the operator will need to have coin(s) as well as receiving capacity. This is fine in the case of plasma cash, because we can reassign owners, but if the operator, bob, and alice have all just started on this plasma chain, how can they free up any space to be able to receive?
Here’s what you stated in the initial post:
In Plasma Debit, each slot would track not only a public key, but a number a between 0 and v , where v is the total amount of ETH that was deposited into that account on the main chain.
Alright, so everyone has deposited and can’t exceed their deposit amount in that slot. So how do they free up any space?
tl;dr - This design starts in a deadlock and I don’t see a way for it to break out of it.
The operator can deposit into any coin from the main chain, which increments v but not a. So if Bob has a 5 ETH coin and a current balance of 5 ETH (i.e. v is 5 and a is 5), then the operator can deposit 1 ETH into the coin, making it a 6 ETH coin where Bob has a balance of 5 ETH (i.e. v is 6 and a is 5), which gives the operator an implied balance of 1 ETH.
(Apologies, I see that this mechanism wasn’t mentioned in the original post. I will edit it to add that.)
I should make clear that the operator does not need any receiving capacity to receive a Plasma Debit payment. Any coinholder can pay the operator any amount simply by signing a transaction that decrements a for their coin. This is an another way that the bootstrap problem can be avoided—when any user makes a Plasma Debit payment to the operator, their coin becomes undercapitalized, allowing them to receive Plasma Debit payments.
So everyone’s collective balance is stored in percentages of coins in slots in the merkle tree - except for the operator.
Well not percentages, balances. And theirs is too, it’s just inverted.
- Where is the operator’s running balance stored?
It’s not stored in any one place. It’s just the sum of v - a across every coin on the Plasma chain.
- If I send something to the operator, they can’t withdraw on the main chain?
They can. See the original post: “When a coin is withdrawn, the coinholder receives a , and the operator receives v – a . (The exit rules need to be altered slightly to allow either the owner or the operator to exit a coin.)”
- I assume the operator has to put up some stake or bond as well, no?
No, not necessarily. At least, nothing depends on that.
- What if I send something to the operator - how do I get it back in the case I want to withdraw from the main chain?
Could you please clarify? If you make a payment to the operator, you can’t get it back.
To all those following, we’re elected to take this discussion offline to avoid further flooding, here. 
We are more so referring to the cost of closing a channel in the happy case. Assuming that you are checking the signatures of state being passed into close a channel. research/mc-multisig/multisig.sol at master · counterfactual/research · GitHub
Ecrecover is certainly painful in dispute cases but can also be in consensus if your channel is only running very low micropayments. However this is probably why we introduced more complex off-chain systems so that transaction value is worth the eventual close out fee.
There are ways to engineer around this and use the ecrecover from the msg.sender, but this would limit the calling parties to only the participants of the channel and possible expose a griefing issue.
I don’t think you have to check any signatures, or even Merkle proofs, in the happy exit case. See Optimistic cheap multi-exit for Plasma (Cash or MVP)
I’m sorry I may have pulled this thread a bit off topic into state-channels land with the “quick” finality exit where the main-chain can require consensus from N parties in the channel by checking the signatures. So to pull off the “fast” exit in a state-channel we seem to hit this cost requirement.
If you are willing to wait then it is cool how you can aggregate the sigs under one exit and only check them if incorrect (i think that’s correct if i understand the plasma optimistic exit)
Ah, I see, right. In Plasma Debit, there is never an option for immediate exit anyway (since the “channels” are assignable, so until the challenge period is over you don’t know who has authority to sign off on the exit).
How would you check that participants want to close a channel, without using ecrecover (including the implicit ecrecover in msg.sender)?
I don’t know of a good way and see these costs as a potential issue to deal with for all layer2 systems, but using msg.sender instead of raw signatures would be like going back to using the old gnosis msig where each party called the tx independently, where state was “preloaded” and agreed to by the calls made by msig owners. This way you wouldn’t have to check the signatures with ecrecover but it’s slower.
EDIT: STK just released their channel code and use what seems to be a “cheap” channel exit doing the above description here. Again this limits exits to the parties involved in the channel.
Curious how the offline conversation went. Do you mind summarizing for us at some point?
From my point of view, the advantage of this construction being able to (eventually, I suppose after everything is thought through) accept new participants to the plasma debit chain without an on-chain transaction. It otherwise is very similar to multi party state channels.
One question for Dan (OP): how would dispute resolution work for the new parties? Say I join and Alice sent me one coin. What’s my onboarding process like – do I accept some voucher for a reserved coin from Alice, and “redeem” it with the operator by registering my on chain payout address?
I think I convinced him it worked!
Yes, correct. I think assignability is the big win. I should note that for the basic case (where the operator is the sole liquidity provider) this is equivalent to many two-party state channels, rather than one multi-party state channel.
That’s a pretty good question. There are a lot of ways for it to work, but the way I see it, Alice will submit the transaction to the operator, telling the operator your public key. The operator includes it in a block. You’ll go to the operator and prove your identity using your public key. The operator gives you a full history proof for that coin, which you can download and verify. You now know that you’ve received that coin, and you’re free to spend it.
I wonder if transactions that involve multiple coins (i.e. atomic swap {a-b, v+b} {c+b, v-b}) need to only be included in plasma blocks when the receiver is offline. If the receiver is online, they could technically create a consensus {operator, receiver} signed update on their coin slot that reflects the swap. In this case the sender can be sure the funds will be received if they witness the state update {c+b, v-b} signed by the receiver and operator rather than witness {a-b, v+b} {c+b, v-b} committed in a plasma block to the parent chain.
If the receiver is offline then the operator needs to commit the balance update {a-b, v+b},{c+b, v-b} so that the receiver may claim that state transition in a plasma exit. The offline participant may come back online and negotiate a consensus update with the operator for that slot that reflects the update to now allow for a quick exit.
To clarify, a sent TX is only considered valid if after the initiator (sender) signs the update to their slot, and the operator either includes {a-b, v+b} {c+b, v-b} in a plasma block or the set {Sender, Operator, Receiver} can sign updates in consensus that update their slots without a plasma chain checkpoint. The process for doing this would look like following.