--- Day changed Sun Oct 04 2015 00:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kqsnzgpiibxmoshm] has joined #lightning-dev 02:12 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has joined #lightning-dev 03:07 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] 03:26 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev 03:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 04:29 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds] 05:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kqsnzgpiibxmoshm] has quit [Quit: Connection closed for inactivity] 05:49 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has joined #lightning-dev 06:15 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has quit [Remote host closed the connection] 06:15 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has joined #lightning-dev 06:20 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has quit [Ping timeout: 250 seconds] 06:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 06:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 07:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yxuhcfgwwtehnofk] has joined #lightning-dev 07:29 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has joined #lightning-dev 08:25 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 08:46 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has quit [Remote host closed the connection] 08:46 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has joined #lightning-dev 08:51 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 08:51 -!- CodeShark_ is now known as CodeShark 08:51 -!- matsjj [~matsjj@x55b0bae6.dyn.telefonica.de] has quit [Ping timeout: 272 seconds] 09:05 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds] 09:08 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 09:18 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 09:29 -!- matsjj [~matsjj@p5B2094FC.dip0.t-ipconnect.de] has joined #lightning-dev 09:29 -!- mjerr [~mjerr@p5B2094FC.dip0.t-ipconnect.de] has joined #lightning-dev 09:55 -!- matsjj [~matsjj@p5B2094FC.dip0.t-ipconnect.de] has quit [] 09:58 -!- matsjj [~matsjj@p20030089EA54A66934B4D71137313E82.dip0.t-ipconnect.de] has joined #lightning-dev 10:02 -!- matsjj [~matsjj@p20030089EA54A66934B4D71137313E82.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 10:06 -!- matsjj [~matsjj@p5B2094FC.dip0.t-ipconnect.de] has joined #lightning-dev 10:08 -!- matsjj_ [~matsjj@178.162.199.95] has joined #lightning-dev 10:10 -!- matsjj [~matsjj@p5B2094FC.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 10:32 -!- matsjj [~matsjj@178.162.199.95] has joined #lightning-dev 10:32 -!- mjerr [~mjerr@p5B2094FC.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds] 10:33 -!- matsjj_ [~matsjj@178.162.199.95] has quit [Ping timeout: 246 seconds] 10:33 -!- mjerr [~mjerr@p5B2095B2.dip0.t-ipconnect.de] has joined #lightning-dev 10:37 -!- mjerr [~mjerr@p5B2095B2.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 10:39 -!- matsjj [~matsjj@178.162.199.95] has quit [Ping timeout: 255 seconds] 10:41 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has joined #lightning-dev 11:51 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev 12:22 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 12:29 -!- aj_ [aj@cerulean.erisian.com.au] has joined #lightning-dev 12:30 -!- ftlio [~ftlio@ftlio.com] has quit [Ping timeout: 260 seconds] 12:32 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 240 seconds] 13:53 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 13:54 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 14:06 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 14:06 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 14:12 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has joined #lightning-dev 15:21 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 15:23 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 240 seconds] 15:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 15:35 -!- fkhan [weechat@gateway/vpn/mullvad/x-sctfgutvdtvqpuex] has quit [Read error: Connection reset by peer] 15:54 -!- fkhan [weechat@gateway/vpn/mullvad/x-gprnhghujoehtoec] has joined #lightning-dev 16:25 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 16:29 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Read error: Connection reset by peer] 16:37 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 16:41 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 16:55 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 17:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yxuhcfgwwtehnofk] has quit [Quit: Connection closed for inactivity] 17:15 -!- CodeShark is now known as CodeShark_ 17:15 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 18:20 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 18:21 -!- CodeShark_ is now known as CodeShark 18:30 -!- matsjj [~matsjj@p5B209E34.dip0.t-ipconnect.de] has joined #lightning-dev 18:34 -!- matsjj [~matsjj@p5B209E34.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 18:35 -!- droark [~droark@caraway.whatbox.ca] has joined #lightning-dev 18:37 -!- maaku_ [~quassel@c-50-156-64-222.hsd1.ca.comcast.net] has joined #lightning-dev 18:55 -!- maaku_ [~quassel@c-50-156-64-222.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 18:59 -!- maaku_ [~quassel@2601:646:8080:59:d250:99ff:fe27:3cff] has joined #lightning-dev 19:47 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 20:14 -!- CodeShark is now known as CodeShark_ 20:14 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 21:27 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 22:12 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev 22:27 -!- matsjj [~matsjj@p20030089EA564347880295CACE6FC334.dip0.t-ipconnect.de] has joined #lightning-dev 22:33 -!- matsjj [~matsjj@p20030089EA564347880295CACE6FC334.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 22:48 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 240 seconds] 22:49 -!- esneider [~esneider@181.94.16.90] has quit [] 22:55 < CodeShark> does anyone have a simple example of an atomic swap using HTLCs handy? 22:55 < aj_> CodeShark: with an altchain? 22:56 < aj_> altcoin, whatever 22:56 < CodeShark> yes 22:56 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev 22:57 -!- matsjj [~matsjj@p20030089EA564347880295CACE6FC334.dip0.t-ipconnect.de] has joined #lightning-dev 22:57 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has joined #lightning-dev 22:58 < aj_> CodeShark: just publish an HTLC on both chains, one paying B bitcoin to Alice for R (known by Bob) with timeout T; Alice observes that, and publishes the other paying N altcoins to Bob for R with timeout T-1; Bob collects that revealing R on the altchain; Alice collects the original 22:59 -!- aj_ is now known as aj 23:02 < aj> CodeShark: HTLC = OP_IF OP_HASH160 OP_EQUALVERIFY OP_DUP OP_HASH160 ; OP_ELSE OP_CTLV OP_DROP OP_DUP OP_HASH160 OP_ENDIF ; OP_EQUALVERIFY OP_CHECKSIG 23:03 < aj> CodeShark: (doesn't need lightning style revocation hash branches if it's directly on the chains) 23:03 < aj> oh should've been an in before first OP_EQUALVERIFY 23:05 -!- esneider [~esneider@181.94.16.90] has quit [Remote host closed the connection] 23:06 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev 23:08 < CodeShark> so it requires a total of two transactions on each chain, right? 23:10 -!- esneider [~esneider@181.94.16.90] has quit [Ping timeout: 255 seconds] 23:11 < aj> CodeShark: yeah 23:12 < CodeShark> is it possible to reduce it to three transactions total by doing something clever like using a 2-of-2 on one of the chains? 23:13 < aj> CodeShark: (or you could do it across a multichain lightning network and not hit either chain, i guess) 23:13 < CodeShark> yeah, but I guess alice and bob still need an anchor transaction in each chain 23:15 < CodeShark> so regardless you need two transactions per chain (although by keeping the channels open they can do multiple trades without hitting the blockchains anymore) 23:16 < aj> CodeShark: so going with Alice and Xavier (Xavier being a currency exchange) 23:17 < aj> CodeShark: if Alice trusts Xavier to be reliable, she could make the first transaction payable to X,R unconditionally (no timeout/refund) 23:17 < CodeShark> that's not an interesting case, though ;) 23:17 < aj> CodeShark: but you still need two more transactions, one for X to offer A some funds, and one for A to reveal R's preimage so X can claim the original funds 23:18 < aj> CodeShark: but if you want to cope with X being unreliable, you need refundability which uses the extra transaction... i think. 23:19 < CodeShark> yeah 23:20 < aj> CodeShark: /but/ if Xavier does volume, his transaction that claims the original funds could /also/ be a transaction that ACKs a conversion with Bob 23:20 < aj> CodeShark: that could get it down to 3 tx's on average 23:20 < aj> well, 3.something 23:22 < CodeShark> and it seems that for this we need absolute time lock, not relative time lock 23:23 < CodeShark> for the first example you gave 23:23 < aj> yeah, absolute time lock would be fine afaics 23:23 < CodeShark> fine? or preferable? 23:23 < CodeShark> or required? 23:24 < CodeShark> in the case of actual markets, there's obviously slippage and currency risk 23:24 < aj> if currency rates change and you don't like what Xavier offered, you don't reveal R and just reclaim your funds 23:25 < CodeShark> then there's the time value of funds 23:25 < CodeShark> is there a way to vet other bids concurrently? 23:26 < aj> i think relative timelock would be mildly useful if there's a stress test and you're not sure wheen you'll get confirmed, but currency rates are static 23:26 < aj> maybe you could pay n bitcoins to {X1,R1}, {X2,R2}, {X3,R3}, {X4,R4} and then wait to see what each of them offered and only reveal Rn based on the best offer 23:28 < CodeShark> right 23:29 < CodeShark> but you'd need a lot of funds to be able make a lot of bids 23:29 < aj> no, just one bid from Alice to X1||X2||X3||X4... 23:30 < aj> but many responses from X1 to Alice, X2 to Alice, X3 to Alice 23:30 < CodeShark> oh, yeah...true.., 23:31 < aj> with real crypto ops in script you could have an open offer from Alice 23:31 < CodeShark> what do you mean by "real crypto ops"? 23:32 < aj> OP_CHECK_STACK_MSG_SIG 23:34 < CodeShark> oh, right - the bitcoin script doesn't separate signature checking from SIGHASH 23:35 < aj> yeah; if alice could pay to "anyone who signs the txn with a key that i sign at some later date" then X4 could say "here's $5 in altcoins for Alice if she signs my key" 23:35 < CodeShark> is there a reason OP_CHECKSIG was done that way rather than, say, OP_SIGHASH_ALL OP_CHECKSIG? 23:36 < CodeShark> seems like putting the sighash on the stack offers greater flexibility 23:36 < aj> dunno 23:37 < aj> there's lots of ways of getting crypto wrong, so maybe less flexibility is helpful to get it right? 23:37 < CodeShark> yeah, my guess is allowing this opens up some security hole...but I'm wondering how it could be exploited 23:37 < aj> (like "my key is actually the same as the hash of that 1000 bitcoin tx of alice's, pls sign it alice, muahahaha") 23:39 < CodeShark> heh 23:40 < CodeShark> well, it could sign HMAC(SIGHASH, msg) or something 23:40 < CodeShark> making it very hard in practice to use the same signature in two different transactions 23:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dfmjfxoomdutbdff] has joined #lightning-dev 23:41 < CodeShark> OP_CHECK_STACK_HMAC_SIG 23:44 < CodeShark> seems like there should be a way to allow this without opening up a gaping hole...but perhaps I'm wrong 23:45 < aj> it's just math; if you create a new keypair for every transaction it's pretty safe i think 23:46 < aj> if you have bad random numbers, or reuse things it probably gets pretty hairy pretty quick; but that seems true in general anyway 23:46 < aj> i thought there was already proposals for general crypto opcodes, but i'm not finding it/them 23:47 < CodeShark> I suppose it depends on how many safeguards you want at the consensus layer 23:48 < CodeShark> there are already holes here, though - for instance, signing an input without having the transaction for the output it spends 23:49 < CodeShark> if we were to put safeguards at the consensus layer, it should be to allow signers to be as barebones as possible 23:55 < CodeShark> in general, the less state a signer requires the better 23:55 < CodeShark> where the worst thing that can happen is the signer signs something useless