Re: [Lightning-dev] Commitment delay asymmetry

2018-04-12 Thread Rusty Russell
Jim Posen writes: > I find it easier to analyze the game theory of these situations if the > to_remote output is also time-locked by the to_remote_delay. Making the > consequence of an on-chain settlement symmetric changes the game from > chicken [1] to a tragedy of the commons [2]. I'm curious ho

Re: [Lightning-dev] High level fee mechanics

2018-04-12 Thread Benjamin Mord
Thank you, ZmnSCPxj. "... by adjusting the on-Lightning `fee_base_msat` and `fee_proportional_millionths` of channels." Yes, I agree these prices are a critical signaling mechanism that can have substantial impact on expected channel lifetime and thus economic efficiency of lightning operation ov

[Lightning-dev] Commitment delay asymmetry

2018-04-12 Thread Jim Posen
As specified in BOLT 3, in the commitment transactions the to_local output is time-locked with OP_CSV while the to_remote is a simple P2WPKH. The to_local output must be time-locked in order to allow the other party to come online and sweep funds from a published revoked commitment. In the case of

Re: [Lightning-dev] QR of node information

2018-04-12 Thread Robert Olsson
hello all, yes the biggest advantage of bech32 would be for making small QR codes, where it does much more savings than in ascii. (you could still print the hex underneath the QR code of course if you want to enter it manually. personally i would prefer bech32 there as well because of its advantag