Author: Nathan Cook 2015-01-09 11:40:53
Published on: 2015-01-09T11:40:53+00:00
The proposed micropayment channel idea introduces a reversible payment channel that allows payments to flow in both directions by using CHECKLOCKTIMEVERIFY. This protocol uses holding addresses that are P2SH addresses with scripts that can be redeemed in one of two ways: by the payment receiver (using their signature) or by the depositor (using their own signature together with a hashlock). The receiver generates these values according to an algorithm that begins with a secret S_0, doubles hash it to make the hashlock value for the first payment, and creates a public nonce to make subsequent secret values. When the receiver wants to refund some amount to the depositor, they find the last payment which left the depositor with a balance greater than the desired balance, negotiate a rewind of the payment sequence to that point, and send D'_i+1 to the depositor with a request for payment of the right amount. The payment chain is then forked at D_i, with a branch D_i+1, D_i+2… and a branch that only has D'_i+1. The receiver now unwinds the old branch back to D_i by revealing S_i+1 to the depositor. The depositor can now generate and check the secrets S_i+1, S_i+2…, and so knows that if the receiver attempts to sign and broadcast a transaction to an address using one of those secrets, the depositor can take back all their funds before the receiver is able to put their own (CHECKLOCKTIME restricted) transaction from that address on the blockchain.When the two parties want to close the payment channel, one party signs a transaction from the deposit address to whatever addresses are desired and sends the transaction to the other party to add their own signature and publish. This avoids either party having to wait for CHECKLOCKTIME restrictions to expire. If either party abandons the protocol at this point, the other can use the CHECKLOCKTIME restrictions to ensure they get at least as much as they would if both cooperated. The limitation of most existing micropayment channel ideas is that payments can only flow in one direction. This is because the payment receiver can sign any transaction sent to them, not just the most recent one, and so it's possible to just sign the transaction transferring the largest amount into their control. This is easily remedied by opening a second payment channel in the opposite direction, but now both parties have to deposit funds over the lifetime of the two channels. If one party doesn't know ahead of time whether or not the other party will go into credit, having only one channel may save the use of a deposit. The proposed protocol improves on blueadept's use of a new nLockTime for each reverse payment by keeping the wait time independent of the number of payments and not requiring either party to predict ahead of time how many payments will occur. The protocol does not deal with the case of malicious attacks on a party's network connection, which could keep them offline until CHECKLOCKTIME has expired. Each party should consider this when choosing how long the restrictions should be in place for. Using an HMAC-style derivation is more of a convenience than anything else - it saves storing and transmitting all the secrets when a chain needs to be invalidated - but it does encode the fact that the addresses form a chain into the addresses' scripts, which is a nice property to have.
Updated on: 2023-06-09T15:19:15.404516+00:00