--- Day changed Wed Oct 28 2015
00:07 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 250 seconds]
00:11 -!- fkhan [weechat@gateway/vpn/mullvad/x-icewhpcrqzxqibbq] has joined #lightning-dev
00:25 -!- crescendo [~mozart@unaffiliated/crescendo] has quit [Remote host closed the connection]
00:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xpskpfushuyiirxv] has joined #lightning-dev
00:41 -!- matsjj [~matsjj@213.205.251.87] has joined #lightning-dev
01:11 -!- pepesza [~pepesza@bjf102.neoplus.adsl.tpnet.pl] has joined #lightning-dev
01:51 -!- matsjj [~matsjj@213.205.251.87] has quit [Remote host closed the connection]
02:04 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev
02:13 -!- matsjj [~matsjj@79.173.166.74] has joined #lightning-dev
02:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
02:25 -!- mode/#lightning-dev [+o rusty] by ChanServ
02:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
02:53 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #lightning-dev
04:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
04:42 -!- JackH_ is now known as JackH
05:05 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
05:19 -!- AaronvanW [~ewout@x55b280ec.dyn.telefonica.de] has joined #lightning-dev
05:19 -!- AaronvanW [~ewout@x55b280ec.dyn.telefonica.de] has quit [Changing host]
05:19 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
05:43 -!- JackH_ [~Jack@host-80-43-142-186.as13285.net] has joined #lightning-dev
05:45 -!- JackH [~Jack@host-80-43-142-204.as13285.net] has quit [Ping timeout: 256 seconds]
06:11 -!- esneider [~esneider@181.29.97.100] has joined #lightning-dev
06:38 -!- esneider [~esneider@181.29.97.100] has quit [Remote host closed the connection]
06:40 -!- esneider [~esneider@181.29.97.100] has joined #lightning-dev
06:57 -!- esneider_ [~esneider@181.29.97.100] has joined #lightning-dev
07:00 -!- esneider_ [~esneider@181.29.97.100] has quit [Remote host closed the connection]
07:00 -!- esneider [~esneider@181.29.97.100] has quit [Ping timeout: 250 seconds]
08:11 -!- esneider [~esneider@181.29.97.100] has joined #lightning-dev
08:32 -!- esneider [~esneider@181.29.97.100] has quit [Remote host closed the connection]
08:34 -!- pepesza_ [~pepesza@bjs18.neoplus.adsl.tpnet.pl] has joined #lightning-dev
08:37 -!- esneider [~esneider@181.29.97.100] has joined #lightning-dev
08:37 -!- pepesza [~pepesza@bjf102.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 250 seconds]
08:38 -!- esneider [~esneider@181.29.97.100] has quit [Remote host closed the connection]
08:44 -!- esneider [~esneider@181.29.97.100] has joined #lightning-dev
08:45 -!- esneider [~esneider@181.29.97.100] has quit [Remote host closed the connection]
08:45 -!- esneider [~esneider@181.29.97.100] has joined #lightning-dev
09:14 -!- esneider [~esneider@181.29.97.100] has quit []
09:31 -!- pepesza_ [~pepesza@bjs18.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 250 seconds]
10:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
10:54 -!- mode/#lightning-dev [+o rusty] by ChanServ
11:00 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
11:10 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
11:22 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Read error: Connection reset by peer]
11:23 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
11:25 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Read error: Connection reset by peer]
11:26 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
11:26 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Read error: Connection reset by peer]
11:27 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
11:52 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev
12:10 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Read error: Connection reset by peer]
12:11 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
12:45 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 250 seconds]
13:11 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
13:13 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
13:45 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
13:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
15:12 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
15:17 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
15:28 -!- matsjj [~matsjj@79.173.166.74] has quit [Remote host closed the connection]
15:36 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev
15:38 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 250 seconds]
15:46 -!- Abby_ [~abby@176.194.233.156] has joined #lightning-dev
15:50 -!- Abby_ [~abby@176.194.233.156] has left #lightning-dev ["Weechat 0.4.3"]
16:04 < CJP> I just did a presentation about transaction malleability, and it made me wonder what would be the best way to solve the remaining malleability problems for Lightning.
16:05 < CJP> Especially the malleability of ECDSA signatures seemed to be a hard problem to me, since you can't get rid of the random k value input.
16:07 < CJP> The easiest(!) way out would be if Bitcoin added op-codes for different types of signatures, that are fully deterministic (same data + same privkey -> always same signature).
16:09 < belcher> how does someone verify that a signature with the opcode for using deterministic k actually use deterministic k?
16:10 < CJP> I don't know if that is possible. I was thinking more in a direction of not using ECDSA at all, but another signing algorithm.
16:12 < instagibbs> CJP, Segregated Witness looks like a great way, but that's probably a hard fork
16:14 < belcher> CJP could you make it that you only create time locked refund txes from a 2-of-2 address ? so both parties have to collude to indefinitely lock the funds
16:16 < CJP> If you're going hard fork, then a more elegant way to get rid of tx malleability seems to be to change the way how transaction IDs are calculated: exclude signature data from the tx ID, so signature malleability does not invalidate follow-up transactions.
16:17 < CJP> How would this "segregated witness" thing work?
16:21 < aj> CJP: the other option is to do signatures that don't care if the txn being spent is malleated -- ie, sign the incoming amounts and output scripts, but not the incoming txid or any signatures that were on the incoming tx
16:22 < CJP> True. Could that lead to other problems?
16:23 < aj> CJP: i think http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011563.html is proposing a soft-fork along those lines
16:27 < CJP> If it can be done with a soft fork (as suggested there), that sounds really cool.
16:27 < aj> CJP: but i think a one-sided anchor transaction and an atomic swap by htlc (blockchain/lightning) can be used to fund a channel without malleability risks now?
16:30 < CJP> The problem with the "not signing input TxIDs" concept is that it makes the transaction MORE malleable, so it may solve one step, but causes more trouble in the next transaction. Then again, if you do this for all transactions in the channel, maybe you're out of trouble?
16:35 < CJP> And of course, in the "not signing input TxIDs" concept, you'd better use different private keys for every output, if not to avoid unexpected abuse cases, then at least to avoid confusion when an attacker modifies the TxID and suddenly spends a different output transaction. :-)
16:36 < CJP> How would the "one-sided anchor transaction and an atomic swap by htlc" solution solve malleability risks? I'm afraid I'm not familiar with what you mean.
16:37 < aj> CJP: so a one-sided anchor transaction lets you fund a channel without malleability risks, but all the funds are on one side
16:38 < aj> CJP: ie, i propose spending 1 BTC i already have to you and my multisig address as an anchor. i get you to sign it. i sign it, but don't send you a copy, but i know the txid now, and only i can malleate the tx. i get you to sign a refund tx. i publish the anchor. we have a channel, with 1 BTC for me and 0 BTC for you
16:38 < CJP> you mean the channel is only funded by one of the two parties, so the initial balance is 100% asymmetrical?
16:38 < aj> CJP: atomic swap then lets you send me some btc via the blockchain, while i send you the same amount via lightning
16:40 < aj> CJP: so i send you 0.5 BTC over lightning, redeemable by R=some secret i made up and you don't know. you send me 0.5 btc over the blockchain redeemable by the same R. i claim the 0.5 btc on the blockchain, revealing R, you claim it on lightning, and we now have a a balanced channel, 0.5 btc each
16:41 < CJP> OK. For simplicity's sake, let's skip the atomic swap part for now: I'd like to know if there already is malleability in the initial channel creation.
16:42 < aj> CJP: setup cost is three blockchain transactions (anchor, 0.5 btc offer, 0.5 btc acceptance), rather than one if malleability weren't an issue
16:42 < aj> CJP: malleability is an issue if you're not doing 100% funds on onee sidee of the channel
16:43 < CJP> With "only i can malleate the tx" you mean: the ECDSA signature malleability can only be applied by me, since I'm the only one who has the private key?
16:44 < aj> CJP: yeah: the anchor tx only spends my funds, so only needs my signature
16:45 < CJP> OK, then it seems the anchor tx is safe.
16:46 < aj> CJP: which gives you the initial refund, so you can publish the anchor tx, and once it's confirmed it's not malleable
16:47 < CJP> In the original Lightning channel design, there were two levels of non-published transactions, to refund the depositing party. I don't know about the latest designs, but suppose they also have two levels: how about malleability of the first level non-published tx (I think it's called the commit tx)?
16:47 < aj> CJP: (assuming all the 3rd party malleability is solved -- maybe it'd be clever to get refund txs for both highS and lowS versions of the sig for now...)
16:48 < aj> CJP: the deployable-lightning variant (with OP_CLTV and OP_CSV assumed) only has a single commitment-tx layered on top of the anchor tx
16:50 < aj> CJP: the original design didn't assume OP_CLTV so had extra layers using nLockTime directly; i think it was malleability-safe because each party keeps different commitment txs
16:50 < CJP> So does the initial version of the commitment-tx have an output that sends all funds directly back to the funding party?
16:51 < aj> CJP: yeah, anchor = X btc from A + Y btc from B --> X+Y btc to A+B multisig; commitment 1 = X+Y btc from A+B multis -> X btc to A, Y btc to B
16:51 < aj> CJP: with Y=0 for a one-sided anchor transaction
16:53 < CJP> Well, at least that indeed sounds safe for one-sided funding. Assuming all 3rd party malleability problems are solved.
16:53 < aj> yeah
16:54 < aj> bip 62 supposedly does that
16:55 < CJP> Existence of malleability seems to put a limit on how you can design safe "transaction circuits": a design with two levels of non-published transactions is likely to lead to trouble.
16:55 < CJP> ...two or more, that is.
16:57 < aj> exactly -- https://diginomics.com/interview-joseph-poon-lightning-network/ talks about "adversarial multisig" which is this sort of concept i think
17:02 < CJP> Thanks for the link. I've had a quick look at it, but it's a bit too late in the night now to fully digest it.
17:03 < maaku> instagibbs: Luke-Jr found a way to make segregated witness a soft-fork
17:03 < CJP> Bye
17:04 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Ik ga weg]
17:04 < maaku> basically you deploy a P2SH like construct that requires scriptSig to be empty (the redeem script is put somewhere else in the block, not in the transaction)
17:15 < instagibbs> maaku, ah
17:54 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
18:05 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
18:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xpskpfushuyiirxv] has quit [Quit: Connection closed for inactivity]
19:05 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
22:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
22:06 -!- mode/#lightning-dev [+o rusty] by ChanServ
22:21 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has quit [Ping timeout: 244 seconds]
22:24 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #lightning-dev
22:38 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
23:08 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
23:17 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
23:23 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
23:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]