{"type":"rich","version":"1.0","author_name":"npub1qp30q8l5nqgsxyw4nxrt8gyge6qjvm4syfg8zpmrc2pg8265s52sw9lsqv","author_url":"https://nostr.ae/npub1qp30q8l5nqgsxyw4nxrt8gyge6qjvm4syfg8zpmrc2pg8265s52sw9lsqv","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-01-09\n📝 Original message:A limitation on most existing micropayment channel ideas is that payments\ncan only flow in one direction. This is because the payment receiver can\nsign -any- transaction you send them, not just the most recent one, and so\nit's possible to just sign the transaction transferring the largest amount\ninto their control. This is easily remedied by opening a second payment\nchannel in the opposite direction, but now both parties have to deposit\nfunds over the lifetime of the two channels. If one party doesn't know\nahead of time whether or not the other party will go into credit, having\nonly one channel may save the use of a deposit.\n\nI propose a way of using CHECKLOCKTIMEVERIFY to allow a reversible payment\nchannel, introducing at most one additional broadcast transaction, with a\nwaiting period before the payment receiver can access deposited funds. The\nextra transaction and waiting period apply only when the depositor doesn't\nco-operate with the receiver.\n\nIn this protocol, the setup is identical, with a deposit made to a P2SH\naddress matching a script allowing either single-party+CHECKLOCKTIME or\n2-of-2. In this case, however, payments made by the depositor occur in the\nform of unbroadcast transactions to special -holding addresses-.\n\nThese holding addresses are themselves P2SH addresses, with scripts known\nto both parties. Each script may be redeemed in one of two ways:\nby the payment receiver, using their signature with a CHECKLOCKTIME\nrestriction that expires some period of time after the restriction on the\ndepositor's refund transaction, or\nby the depositor, using their own signature, together with a hashlock.\n\nIn the second case, we actually use a double hashlock, i.e. the depositor\nmust provide a value which when SHA256-hashed twice produces the value in\nthe script.\n\nThe receiver generates these values according to the following algorithm:\nBeginning with a secret S_0, they double hash S_0 to make the hashlock\nvalue for the first payment, D_0 =H(H(S_0)). Then to make S_i+1 given S_i,\nthey create a public nonce, N_i, and let S_i+1 = H(N_i | H(S_i)), where a|b\ndenotes the string a followed by the string b. The hashlock values D_i are\nnot secret, and can be disclosed in advance or as part of the process of\nreceiving the associated payment.\n\nWhen the receiver wants to refund some amount to the depositor, the\nreceiver finds the last payment which left the depositor with a balance\n-greater- than the desired balance, and negotiates a rewind of the payment\nsequence to that point, with an additional payment of the remainder by the\ndepositor. Suppose the last payment that will remain valid was the i-th\npayment, counting from zero. The receiver creates a new nonce, N'_i,\ncreates the associated new secret value S'_i+1 by S'_i+1 = H(N'_i |\nH(S_i)), and sends D'_i+1 to the depositor with a request for payment of\nthe right amount. This amount will be greater than that associated to D_i,\nbut less than that associated to D_i+1, so the depositor does not need to\ntrust the receiver in order to honour the request. The payment chain is now\nforked at D_i, with a branch D_i+1, D_i+2... and a branch that only has\nD'_i+1. The receiver now unwinds the old branch, back to D_i, by revealing\nS_i+1 to the depositor. The depositor can now generate - and check - the\nsecrets S_i+1, S_i+2..., and so knows that if the receiver attempts to sign\nand broadcast a transaction to an address using one of those secrets, the\ndepositor can take back all their funds before the receiver is able to put\ntheir own (CHECKLOCKTIME restricted) transaction from that address on the\nblockchain. Now the best usable payment to the receiver is the one\nassociated to D'_i+1.\n\nWhen the two parties want to close the payment channel, one party signs a\ntransaction from the deposit address to whatever addresses are desired, and\nsends the transaction to the other party to add their own signature and\npublish. This avoids either party having to wait for CHECKLOCKTIME\nrestrictions to expire. If either party abandons the protocol at this\npoint, the other can use the CHECKLOCKTIME restrictions to ensure they get\nat least as much as they would if both cooperated. Note that the holding\naddresses are only used on the blockchain when the protocol is abandoned.\n\nThis protocol does not deal with the case of malicious attacks on a party's\nnetwork connection, which could keep them offline until CHECKLOCKTIME has\nexpired. This is something that each party should consider when choosing\nhow long the restrictions should be in place for. The protocol improves on\nblueadept's use of a new nLockTime for each reverse payment[1], by keeping\nthe wait time independent of the number of payments, and not requiring\neither party to predict ahead of time how many payments will occur.\n\nA note on generating hashlock secrets: the protocol works perfectly well\nwithout generating them deterministically. Using an HMAC-style derivation\nis more of a convenience than anything else - it saves storing and\ntransmitting all the secrets when a chain needs to be invalidated - but it\ndoes encode the fact that the addresses form a chain into the addresses'\nscripts, which is a nice property to have.\n\n[1] https://bitcointalk.org/index.php?topic=814770.msg9185225#msg9185225\n\nI first posted this at https://bitcointalk.org/index.php?topic=918018.0 and\nhave edited it slightly for posting on this list. Thanks to Peter Todd for\nthe suggestion to submit it here for review.\n\nNathan Cook\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150109/dc18ce68/attachment.html\u003e"}