Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-09 Thread Conner Fromknecht
t:* Monday, November 5, 2018 3:48:56 PM > *To:* lightning-dev@lists.linuxfoundation.org; Rusty Russell > *Subject:* Re: [Lightning-dev] RFC: simplifications and suggestions on > open/accept limits. > > > Op 1 nov. 2018 om 03:38 heeft Rusty Russell het > volgende geschreven: > &

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-08 Thread alexis petropoulos
; Rusty Russell Subject: Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits. Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-s

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-07 Thread Anthony Towns
On Wed, Nov 07, 2018 at 02:26:29AM +, Gert-Jaap Glasbergen wrote: > > Otherwise, if you're happy accepting 652 satoshis, I don't see why you > > wouldn't be happy accepting an off-chain balance of 652.003 satoshis; > > you're no worse off, in any event. > I wouldn’t be worse off when accepting

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Pierre
Hi Rusty, > funding_satoshis > > > c-lightning: must be >= 1000 (after reserve subtracted) > Eclair: must be >= 10 > lnd: any > > SUGGESTION: At 253 satoshi/kSipa, and dust at 546, 1000 is too low to be > sane (one output would always be dust). Eclair seems pessimistic >

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Gert-Jaap Glasbergen
> On 7 Nov 2018, at 12:01, Anthony Towns wrote: > > I don't think it quite makes sense either fwiw. Glad it’s not just me :) > What's enforcable on chain will vary though -- as fees rise, even if the > network will still relay your 546 satoshi output, it may no longer be > economical to claim

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Anthony Towns
On Tue, Nov 06, 2018 at 10:22:56PM +, Gert-Jaap Glasbergen wrote: > > On 6 Nov 2018, at 14:10, Christian Decker > > wrote: > > It should be pointed out here that the dust rules actually prevent us > > from creating an output that is smaller than the dust limit (546 > > satoshis on Bitcoin).

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Gert-Jaap Glasbergen
> On 6 Nov 2018, at 14:10, Christian Decker wrote: > > It should be pointed out here that the dust rules actually prevent us > from creating an output that is smaller than the dust limit (546 > satoshis on Bitcoin). By the same logic we would be forced to treat the > dust limit as our atomic

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Christian Decker
Gert-Jaap Glasbergen writes: > Op 1 nov. 2018 om 03:38 heeft Rusty Russell > mailto:ru...@rustcorp.com.au>> het volgende geschreven: >> I believe this would render you inoperable in practice; fees are >> frequently sub-satoshi, so you would fail everything. The entire >> network would have to

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-05 Thread Gert-Jaap Glasbergen
Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-01 Thread Rusty Russell
Gert-Jaap Glasbergen writes: > As for htlc_minimum_msat I would not feel good about it being dropped. > It is the only protection measure I saw in the standard against > producing trimmed HTLCs. In my view the safe default is to set it above > the dust limit to avoid it to get trimmed, and

[Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-10-16 Thread Rusty Russell
Hi all, Everywhere in the protocol where we negotiate, we've had problems: what do you do if you can't agree? In most cases, we've settled on defacto generally-accepted values which aren't mentioned anywhere in the spec (I've skimmed codebases below, looked at defaults). I'd like to