Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2020-01-21 Thread Joost Jager
> > By my calculations, at minfee it will cost you ~94 satoshis to spend. > Dust limit is 294 for Segwit outputs (basically assuming 3x minfee). > > So I'm actually happy to say "anchor outputs are 294 satoshi". These > are simply spendable, and still only $3 each if BTC is $1M. Lower is >

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-11-18 Thread David A. Harding
On Thu, Nov 14, 2019 at 10:56:05AM +0100, Joost Jager wrote: > Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is > `dustRelayFee` really never going to change? It even is a (hidden) cmd line > parameter that can be set easily. > > If the fee market would rise and stay high for an

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-11-15 Thread Matt Corallo
Regarding the dust relay limit, there may be a little bit of a misunderstanding as to a few important details. The purpose of it (much like the dust output values in the anchor outputs) is to discourage outputs which are not ever economically spendable, not short-term uneconomically spendable.

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-11-11 Thread Rusty Russell
Joost Jager writes: >> >> > We could >> > simplify this to a single to_self_delay that is proposed by the >> initiator, >> > but what was the original reason to allow distinct values? >> >> Because I didn't fight hard enough for simplicity :( >> > > But the people you were fighting with, what

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-11-07 Thread Joost Jager
> > > We could > > simplify this to a single to_self_delay that is proposed by the > initiator, > > but what was the original reason to allow distinct values? > > Because I didn't fight hard enough for simplicity :( > But the people you were fighting with, what reason did they have? Just

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-11-05 Thread Rusty Russell
Joost Jager writes: >> >> > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` >> > output. `to_remote_delay` is the csv delay that the remote party accepted >> > in the funding flow for their outputs. This not only ensures that the >> > carve-out works as intended, but

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-11-01 Thread Rusty Russell
Matt Corallo writes: > Why not stick with the original design from Adelaide with a spending path > with a 1CSV that is anyone can spend (or that is revealed by spending another > output). The original design IIRC was a single anyone-can-spend anchor output. If we need two anchor outputs, and

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-31 Thread Joost Jager
> > On Oct 30, 2019, at 06:04, Joost Jager wrote: > > > For the anchor outputs we consider: >> > >> > * Output type: normal P2WKH. At one point, an additional spending path >> was >> > proposed that was unconditional except for a 10 block csv lock. The >> > intention of this was to prevent utxo

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-30 Thread Matt Corallo
(resend from the right src) >> On Oct 30, 2019, at 06:04, Joost Jager wrote: >> > For the anchor outputs we consider: >> > >> > * Output type: normal P2WKH. At one point, an additional spending path was >> > proposed that was unconditional except for a 10 block csv lock. The >> > intention of

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-30 Thread Matt Corallo
> On Oct 30, 2019, at 03:04, Rusty Russell wrote: > > Joost Jager writes: >> * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of >> the HTLC outputs. > >> For the anchor outputs we consider: >> >> * Output type: normal P2WKH. At one point, an additional spending path

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-30 Thread Joost Jager
> > > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` > > output. `to_remote_delay` is the csv delay that the remote party accepted > > in the funding flow for their outputs. This not only ensures that the > > carve-out works as intended, but also removes the incentive to

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-30 Thread Rusty Russell
Joost Jager writes: > We started to look at the `push_me` outputs again. Will refer to them as > `anchor` outputs from now on, to prevent confusion with `push_msat` on the > `open_channel` message. > > The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been > merged and for

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-26 Thread Joost Jager
> > * Output type: normal P2WKH. At one point, an additional spending path was > proposed that was unconditional except for a 10 block csv lock. The > intention of this was to prevent utxo set pollution by allowing anyone to > clean up. This however also opens up the possibility for an attacker to

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2019-10-26 Thread Joost Jager
We started to look at the `push_me` outputs again. Will refer to them as `anchor` outputs from now on, to prevent confusion with `push_msat` on the `open_channel` message. The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been merged and for reasons described earlier in this

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-29 Thread Matt Corallo
For the low low cost of 3 witness bytes, I think the simplification of analysis/separation of concerns is worth it, though I agree it is probably not strictly required. On 11/26/18 3:12 AM, Rusty Russell wrote: Matt Corallo writes: Hmm, are we willing to consider CLTV sufficient? In case

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-25 Thread Rusty Russell
Matt Corallo writes: > Hmm, are we willing to consider CLTV sufficient? In case you have two > HTLCs, one of medium-small value that has a low CLTV and one of high > value that has a higher CLTV, you could potentially use the soon-CLTV to > delay the commitment transaction somewhat further if

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-25 Thread Matt Corallo
Indeed, this change assumes (a) the change in relay policy around CPFP that is discussed on this thread, and (b) some kind of (at least very basic) package relay in Bitcoin Core. (a) requires some discussion, but people seem at least not entirely against it when I've discussed it with people,

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-25 Thread David A. Harding
On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote: > I'm also starting to implement this, to see what I missed! > > - Feerate is fixed at 253 [satoshis per 1,000 weight] IIUC, this is just over Bitcoin Core's default minimum relay fee of 0.1000 BTC/vByte. That works right now,

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-22 Thread Rusty Russell
Matt Corallo writes: > Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(. OK, let's walk through this: Locally offered HTLC: - Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay. Remote offered HTLC: - Local HTLC-Success tx can be done without

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-20 Thread Matt Corallo
Not sure if others already realized this, but in thinking about our RBF policy hack from Adelaide a bit more, to allow the carve-out exception of "last tx in a package, which has only one unconfirmed ancestor" to always be available for the "honest party" when broadcasting a commitment

[Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-20 Thread Rusty Russell
I'm also starting to implement this, to see what I missed! Original at https://github.com/lightningnetwork/lightning-rfc/pull/513 Pasted here for your reading convenience: - Option is sticky; it set at open time, it stays with channel - I didn't want to have to handle penalty txs on channels