Next, a detailed explanation:
New idea 2: you don't have to put all bitcoins of a link at stake when performing a transaction. You can also make a "promise T2" with outputs like this:
1. 89.99 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
3. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
This can be generalized to allow multiple transactions happening simultaneously on the same channel, even in opposite directions.
I'm not sure I understand what you're proposing. If you have time and are still interested in developing this new idea further, I'd love it if you could explain it in more detail.
Take the same scenario as on your Wiki page with Alice-Carol-Bob.
Alice and Carol have previously set up a micropayment channel. T2 contains the following:
1. 90.00 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
Next, Alice wants to pay 0.01 BTC through the channel, using the hash value "Hashm". To do this, she signs the following T2 update and sends it to Carol:
1. 89.99 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
3. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
If the transaction is committed, m becomes known to Carol, so she can redeem both 2 and 3. If the transaction is aborted, Carol signs the following T2 update and sends it to Alice:
1. 90.00 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
(note: this equals the original T2, but the sequence number is higher and (if necessary) nLockTime has been decreased as well.)
Note: I'm not sure, but it might be necessary to also give Alice a stake in making the transaction committed. In that case, the T2 containing the undecided transaction could look like this:
1. 89.98 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyAlice CHECKSIGVERIFY
3. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
4. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
In the rest of this post I'll assume this is not necessary.
Now imagine, while transaction "m" is still undecided, Alice (or someone else on her side of the network) wants to make another payment "n" through Carol (this time 0.02 BTC). This can be done with the following T2 update:
1. 89.97 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
3. 00.02 BTC to: SHA256 Hashn EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
4. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
Now suppose that "m" finishes but "n" is still undecided. Nothing needs to be updated for that. Suppose that, after "m" finishes, a new transaction "p" (0.03 BTC) is started through this link, this time from Carol to Alice. Carol can make the following update:
1. 89.97 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.02 BTC to: SHA256 Hashn EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
3. 00.03 BTC to: SHA256 Hashp EQUALVERIFY PubkeyAlice CHECKSIGVERIFY
4. 09.98 BTC to: PubkeyCarol CHECKSIGVERIFY
Note that, since "m" is finished, its amount is merged with the "inactive" output of Carol. If Alice knows that "m" is finished, she should accept this; otherwise, she should not accept the update, and abort "p" until Carol sends either "m" or a T2 update where "m" is still undecided.
The advantages of this approach are:
- You can do multiple transactions over the same link simultaneously
- If a single transaction doesn't commit, it only locks up that transaction's amount of BTC, and not the entire link
Note that this can also be applied to my own original concept, except that it would either require an extension to the Bitcoin scripting language (trust-free solution), or it would require the "undecided" part to be held under a 2-of-2 or 2-of-3(*) script, and have the two parties cooperatively figure out whether they consider it committed or rolled back. For that last concept I think it
is useful to let both parties have a stake in agreeing on the commit state.
My own concept has the disadvantage of having a quite complicated way of reaching commit consensus, but the advantage is still that consensus (between parties who follow the protocol) is guaranteed within a couple of hours, even if nLockTime is a year ahead. Luckily, the differences are quite small, so I think both concepts can be combined in the same software without too much effort.
(*) with escrow to prevent a "hijacking" attack between neighbors. This would be an extra protection besides letting both parties have a stake in agreeing with each other.