rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 Original date posted:2017-02-06 📝 Original message: I created a possible step by step protocol with checks that each step is safe. I think your scheme needs a 2nd timeout, so Bob has a time between Alice broadcasting AliceSecret and Alice closing the channel with TX2. TX1 Input 1 from Alice 1 from Bob Output 1: (Alice + Bob + timeout(2T)) OR (Bob + AliceSecret) 1: (Bob + timeout(T)) OR (Alice + AliceSecret) TX2 Input TX1:1: signed by (Alice + Bob) Output Initial channel paying Alice 100% Process: Step 1 Alice creates TX1, signs it and sends it to Bob. If Alice refuses this step, then nothing has happened, so it is a safe abort. Step 2 Bob signs it and sends Alice the tx hash. Bob could sign and broadcast it. If he does that, then Alice spends her output to get her money back, so it is a safe abort. If Bob refuses to complete this step, Alice should spend her input to prevent Bob broadcasting the TX1 later. This is also a safe abort. NOTE: * This is an ongoing check Alice must perform. * If (timeout / 2) passes before all the steps are completed, Alice should try to ** double spend her input into TX1 ** spend her output from TX1 Step 3 Alice creates TX2, signs it and sends it to Bob. If Alice refuses to complete this step, then Bob simply discards TX1. Alice can't broadcast it since she does not have a fully signed version of TX1. Step 4 Bob signs TX2 and sends it to Alice. If Bob refuses to complete this step, the Alice should spend her input or her output of TX1 (if Bob has broadcast TX1). This is a safe abort. Step 5 Bob broadcasts TX1 If Bob refuses to complete this step, the Alice should spend her input. This is a safe abort. Step 6 Alice should make sure TX1 is included in the chain without mutation. If it is ok, then Alice does nothing. If it is mutated, then Alice should spend her output immediately. If Alice refuses to complete this step, then Bob can reclaim his money after the timeout and Alice loses access to her money. Alice has an incentive to complete this step. Step 7 (mutated TX only) Bob can spend his output using AliceSecret. If Bob refuses to complete this step, then he doesn't get his money, but Alice is not harmed. Step 7 (valid setup) Bob spends his output after the timeout. Once he has spent his output, then the channel is setup. There is a potential race condition here. After the timeout has expired, Alice could broadcast 2 transactions - TX2 (to close the channel paying Alice 100%) - transaction to spend TX1/1 (i.e. Alice + Alice secret) Bob would be broadcasting his transaction to claim TX1/1 at around the same time. The network might accept Alice's 2 transactions, before Bob has a chance to claim TX1/0 (with Bob + AliceSecret). Adding an extra timeout with the later expiry to TX1/0 means that Alice cannot broadcast TX2 until Bob has a chance to claim his output. On Mon, Feb 6, 2017 at 2:25 AM, Nicolas Dorier <nicolas.dorier at gmail.com> wrote: > Alice opening channel of 1BTC > > Input: > 1 BTC From Alice > 1 BTC From Bob > Output: > 1 BTC Alice+Bob OR Bob+AliceSecret > 1 BTC Bob+Timeout OR Alice+AliceSecret (aka the bounty) > > If bob is unresponsive, Alice can get the bounty. > If Alice unresponsive, bob can get the bounty after timeout. > If Alice takes the bounty, Bob can take the escrow . > > If Alice responsive, bob wait for getting the bounty. The use of the > channel will start after bob get the bounty back. > > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170206/ea7b8785/attachment.html>