Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
Good morning Matt, > I can't imagine the constants add up that fast... Allow 25 channels per peer > and limit your peers reasonably and the cost should be low enough. Really not > sure why something like a 25 channel limit should limit any usage or > reasonably burden a node, what am I missing? You impose this 25 channels per peer. I start opening a channel to you. Because I did not check mempool or because my fee-estimation algo is bad, I pay too low a fee. I become impatient and bump it up, which you perceive as another open (so it is now 2/25 channels). Unfortunately I only bumped my fee by a tiny amount, because reasons. I bump the fees upwards for example five more times, each of which you perceive as another channel open, so from your side it looks like I am consuming 7/25 channels. Finally the funding transaction confirms, but the 6 previous transactions are perceived by you as unconfirmed channel opens, so you will still keep the 6 channels accounted in your 25-channel-limit. Suppose in a few days (i.e. much less than a week) I decide to have three more channels to you. If I go through all that (starting with low fee, bumping up fee, etc) then I may very well run out of the available 25 channels to you, even though I only really have 1 channel already opened and am trying to make an additional 3 channels only. Granted this is somewhat contrived, but it shows what I wish to avoid with `funding_cancelled`. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
I can't imagine the constants add up that fast... Allow 25 channels per peer and limit your peers reasonably and the cost should be low enough. Really not sure why something like a 25 channel limit should limit any usage or reasonably burden a node, what am I missing? On January 15, 2018 2:14:57 AM UTC, ZmnSCPxj wrote: >Good morning Matt, > >Sent with [ProtonMail](https://protonmail.com) Secure Email. > >> Original Message >> Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` >message >> Local Time: January 15, 2018 9:00 AM >> UTC Time: January 15, 2018 1:00 AM >> From: lf-li...@mattcorallo.com >> To: ZmnSCPxj >> lightning-dev@lists.linuxfoundation.org > >> >> Sounds to me like the lack of a protocol-required minimum timeout is >the issue. Because the cost of tracking an unopened channel is >relatively trivial, I see limited reason to bother notifying the peer >that a channel has timed out. However, due to potentially radically >different concepts for what is and isn't an acceptable wait time, it's >likely useful to have something like "a receiving node MUST keep a >channel ready to be used for at least a week prior to funding >transaction confirmation. Thus, a node creating a funding transaction >SHOULD double-spend and make unconfirmable a funding transaction which >has not confirmed prior to a week." > >Though the cost may be trivial for single channels, the cost can be >made arbitrarily high by a malicious node that just keeps sending >`open_channel` -> `funding_created` with random numbers for transaction >ID. It seems sensible for a node implementation to allow limiting the >number of pending channel opens for each peer to avoid this (e.g. >c-lightning currently limits one-channel-one-peer, even at opening). >The intent of `funding_cancelled` is: an honest party can free up the >limited resource "number of pending channel opens" by using this >message, without having to wait for the timeout, whatever the timeout >is defined to be. > >Regards, >ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
Good morning Matt, Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message > Local Time: January 15, 2018 9:00 AM > UTC Time: January 15, 2018 1:00 AM > From: lf-li...@mattcorallo.com > To: ZmnSCPxj > lightning-dev@lists.linuxfoundation.org > > > Sounds to me like the lack of a protocol-required minimum timeout is the > issue. Because the cost of tracking an unopened channel is relatively > trivial, I see limited reason to bother notifying the peer that a channel has > timed out. However, due to potentially radically different concepts for what > is and isn't an acceptable wait time, it's likely useful to have something > like "a receiving node MUST keep a channel ready to be used for at least a > week prior to funding transaction confirmation. Thus, a node creating a > funding transaction SHOULD double-spend and make unconfirmable a funding > transaction which has not confirmed prior to a week." Though the cost may be trivial for single channels, the cost can be made arbitrarily high by a malicious node that just keeps sending `open_channel` -> `funding_created` with random numbers for transaction ID. It seems sensible for a node implementation to allow limiting the number of pending channel opens for each peer to avoid this (e.g. c-lightning currently limits one-channel-one-peer, even at opening). The intent of `funding_cancelled` is: an honest party can free up the limited resource "number of pending channel opens" by using this message, without having to wait for the timeout, whatever the timeout is defined to be. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [Question] Unilateral closing during fee increase.
Good Morning Richard, > Original Message > Subject: Re: [Lightning-dev] [Question] Unilateral closing during fee > increase. > Local Time: January 14, 2018 8:37 PM > UTC Time: January 14, 2018 12:37 PM > From: richard.ha...@gmail.com > To: Peter Todd > lightning-dev@lists.linuxfoundation.org, Jonathan Underwood > > > Complete n00b question here: if one side of the channel have 100% of the > funds, can the last message give that user complete controll over the channel > (to close it "unilateral" without any interaction from the other side? The only trustless way to transfer control of the funds from one-sided back to both of them would be an on-chain transaction. So it is equivalent to closing the channel, then reopening it when the other side returns to be connected. > And that way change the fee size when that part want's to close the channel? > > Or give the other side the complete controll over a channel if the funds on > one side is less than what is currently needed to close a channel? This puts trust into the system. If you are going to trust anyway,then you can probably trust that the other side will gracefully inform you of pending shutdown on their side and cooperatively close. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
Sounds to me like the lack of a protocol-required minimum timeout is the issue.
Because the cost of tracking an unopened channel is relatively trivial, I see
limited reason to bother notifying the peer that a channel has timed out.
However, due to potentially radically different concepts for what is and isn't
an acceptable wait time, it's likely useful to have something like "a receiving
node MUST keep a channel ready to be used for at least a week prior to funding
transaction confirmation. Thus, a node creating a funding transaction SHOULD
double-spend and make unconfirmable a funding transaction which has not
confirmed prior to a week."
Note that obviously a node can keep the initial commitment transaction around
and just wait forever and if the funding transaction ever confirms it can go
broadcast the initial commitment transaction then, but it's much nicer to be
able to simply double spend via RBF.
Given the relative simplicity on the receiving end, this could even be slipped
in to the spec today prior to v1.1.
Cue bikeshedding.
On January 9, 2018 5:25:29 AM UTC, ZmnSCPxj wrote:
>Good morning Matt,
>
>> Original Message
>> Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled`
>message
>> Local Time: January 8, 2018 10:42 PM
>> UTC Time: January 8, 2018 2:42 PM
>> From: lf-li...@mattcorallo.com
>> To: ZmnSCPxj ,
>lightning-dev\\@lists.linuxfoundation.org
>
>>
>> I have to say I'm rather not a fan of this idea. Adding messages
>which do not result in different node behavior other then waiting for
>the timeout with little overhead on the node to simply keep watching
>for the funding transaction is a recipe for ending up with a needlessly
>complex protocol and misimplementation.
>
>There is no specified timeout for funding transactions, and thus a
>fundee node may keep track of funding transactions until end-of-life.
>This is a concern since replaceable funding transactions require that
>all versions be monitored on the blockchain - there is always the
>possibility that the winning miner got older versions of the funding
>transaction.
>
>To my mind, a sketch of an implementation for `funding_cancelled`
>requires only to delete an entry in a database of transactions to be
>watched.
>
>Implementing replacable funding transactions require an implementation
>to keep track of all versions of the funding transaction, as well as
>the state ("waiting for accept_channel", "waiting for funding_signed",
>"waiting for confirmation") of each funding transaction version. You
>would also link all those versions together - for example you might
>have a separate table containing an ID column that you allocate for
>each channel open attempt, and separate this from the funding
>transaction table (which would have a foreign key to the openings
>table). If one funding transaction confirms "deeply enough", then you
>send `funding_cancelled` for each other funding transaction.
>
>Note that the complexity here for replace-by-fee funding transactions
>is due solely to the fact that miners have the choice of mining any
>version of the transaction. It is possible that a miner deliberately
>chooses an older version, or (more realistically) that a race condition
>occurs where you broadcast the replacement but the miner has already
>won a block before the replacement propagated to it. Thus the funder
>(who initially owns all coins in the channel) needs to keep track of
>all versions of the funding transaction it broadcast, regardless. But
>of course it will want to not consume its own resources watching for
>transactions that can never confirm if another transaction has deeply
>confirmed, and it will delete such entries from its database; sending
>`funding_cancelled` in this case is simply "being nice", and the fundee
>ignores this at its own detriment, wasting resources each block to
>check for a transaction that logically can never confirm.
>
>In any case, how would you implement replace-by-fee funding
>transactions?
>
>Regards,
>ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [Question] Unilateral closing during fee increase.
Complete n00b question here: if one side of the channel have 100% of the funds, can the last message give that user complete controll over the channel (to close it "unilateral" without any interaction from the other side? And that way change the fee size when that part want's to close the channel? Or give the other side the complete controll over a channel if the funds on one side is less than what is currently needed to close a channel? Richard søn. 14. jan. 2018 kl. 13:32 skrev Peter Todd : > On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood wrote: > > Hey everybody. > > > > Say that the last time we updated channel state, we assumed 40 > satoshi/byte > > was enough to get confirmed, then I leave the channel for a few weeks, > come > > back to find my partner fell off the face of the internet. > > > > I perform unilateral close with my output on CSV timelock... but it turns > > out there’s 500 MB of txes at around 100 satoshi/byte and lets say my > > transaction will never get confirmed at 40 sat/byte. > > > > What course of action can I take? > > > > 1. to_local output can't be redeemed until the commitment transaction > > (which will "never confirm") is confirmed + the CSV timeout. > > 2. to_remote output probably won't be redeemed as the other person is > > offline. > > > > The only remedy I can think of is hope that the other person comes back > > online and CPFPs your to_remote output for you... but at that point it > > would be better for them to just amicably close with normal outputs... so > > basically your only hope is wait for other person to come online. > > > > Since CSV will cause script verification to fail, a CPFP transaction will > > not be propagated. > > If we can't CPFP, the CSV timer won't start (it starts once the CSV > > containing output is confirmed). > > > > Seems like a problem. > > > > Anyone have any solutions? > > While not ideal, you can use out-of-band fee payment mechanisms such as > https://confirmtx.com and https://pushtx.btc.com to get the transaction > mined > without an on-blockchain payment. For that matter, you could use a > Lightning > transaction to pay for that service more cheaply than on-chain payments > those > existing accelerators currently use. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [Question] Unilateral closing during fee increase.
On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood wrote: > Hey everybody. > > Say that the last time we updated channel state, we assumed 40 satoshi/byte > was enough to get confirmed, then I leave the channel for a few weeks, come > back to find my partner fell off the face of the internet. > > I perform unilateral close with my output on CSV timelock... but it turns > out there’s 500 MB of txes at around 100 satoshi/byte and lets say my > transaction will never get confirmed at 40 sat/byte. > > What course of action can I take? > > 1. to_local output can't be redeemed until the commitment transaction > (which will "never confirm") is confirmed + the CSV timeout. > 2. to_remote output probably won't be redeemed as the other person is > offline. > > The only remedy I can think of is hope that the other person comes back > online and CPFPs your to_remote output for you... but at that point it > would be better for them to just amicably close with normal outputs... so > basically your only hope is wait for other person to come online. > > Since CSV will cause script verification to fail, a CPFP transaction will > not be propagated. > If we can't CPFP, the CSV timer won't start (it starts once the CSV > containing output is confirmed). > > Seems like a problem. > > Anyone have any solutions? While not ideal, you can use out-of-band fee payment mechanisms such as https://confirmtx.com and https://pushtx.btc.com to get the transaction mined without an on-blockchain payment. For that matter, you could use a Lightning transaction to pay for that service more cheaply than on-chain payments those existing accelerators currently use. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
