Hi Dan,
> I'm trying to understand what the correct behaviour is when two nodes
> (Alice and Bob) have an open channel, and one of the channels (Alice)
> loses their IPv4 lease,
> 1. Is there a specific behaviour prescribed in any spec in this scenario?
Assuming one of the nodes has a public lis
> Some folks indicated they'd like to interact with it via the supposed
> "mailing list mode", but sadly AJ indicated it may not be super reliable
> (and seems to be disabled on delvingbitcoin.org). I've asked AJ to enable
> it so people can maybe try it out but we'll see if it works. Sadly if you
Hi y'all,
Re Google Groups:
It appears that one can join a Google Group without a _gmail_ account by
sending a special subscribe email to a certain Google Groups endpoint:
https://webapps.stackexchange.com/a/126053. FWIW, this won't let you use the
web UI directly (useful for searching, the archi
> Let's say you have Alice, Bob and Caroll all "honest" routing hops
> targeted by an attacker. They all have 3 independent 10 000 sats HTLC
> in-flight on their outbound channels.
> It is replaced by Mallory at T+2 with a HTLC-preimage X of 200 000 sats (+
> rbf penalty 1 sat / vb rule 4). Alice'
Hi Antoine,
Thanks for this great write up, and also your diligence in reporting this
issue to the various implementations, and game planning with us re
mitigations and attack scenarios.
One small clarification: all of lnd's relevant mitigations were in place by
lnd v0.16.1-beta [1], which was re
I'm excited to finally publish a draft bLIP describing how to map the
Taproot Asset Protocol onto the existing BOLT channel/invoice format,
specifically building on the active proposal for simple taproot channels!
https://github.com/lightning/blips/pull/29
This bLIP describes a variant on the "si
Hi David,
Happy to see that you're still working to push the state-of-the-art when it
comes to mixnets!
> Sphinx is essentially twice as fast if we eliminate the "blinding trick"
> and only have one group operation per hop, the DH. In order to make that
> work you'd also have to store the group
Hi Z,
Or you can just use AMP and call it a day:
https://github.com/lightning/bolts/pull/658
-- Laolu
On Fri, Jul 28, 2023 at 12:24 AM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
> Good morning list,
>
> I would like to share a simple scheme for creating a `keys
lnd supports paying invoices it generates, you just need to set the
`allow_self_payment` field using this
API: https://lightning.engineering/api-docs/api/lnd/router/send-payment-v2.
This _does_ end up actually finding a circular route through the network
though, it's most commonly used to implemen
> Their website shows an invoice to the user, whose wallet that is agnostic
> about the swap, and it would be unpractical for them to show two invoices
> to be paid simultaneously
In order to be properly non-custodial, a submarine swap client needs to be
able to unilaterally sweep or timeout an
Hi Val,
Happy to see ppl continue to work on the problem space after discussions and
brainstorming we had at the past LN Summit in Oakland.
> The open research question relates to how the sender will get an invoice
> from the receiver, given that they are offline at sending-time
One existing pro
Hi Z,
> Quick question: is the address given by the `loop in --external` command
safe
> for reuse?
Thx for this question, I think this is the key difference I was looking for
(not the aspect about confirmations, since that's no different). Since that
address contains a swap hash in the script, it
Hi Z,
> * Submarine swap/peerswap: Requires confirmation before the swap service
> will send out the HTLC on Lightning.
I might be missing something, but I don't see how this is different from a
normal on-chain to off-chain swap (calling this Loop In for short in the
remainder of the email).
Giv
Hi tbast,
FWIW, we haven't had _too_ many issues with the additional constraints
anchor channels bring. Initially users had to deal w/ the UTXO reserve, but
then sort of accepted the trade-off for the safety that actually being able
to dynamically bump the fee on your commitment transaction and HT
Hi Johan,
I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However, by
Hi Alex,
This is a super cool project! I've shared some thoughts here in a comment on
the draft PR:
PR:
https://github.com/lightningnetwork/lnd/pull/6843#issuecomment-1234933319
Also I cc'd the lnd mailing list on this reply, perhaps we can move the
discussion over there (or in the issue) since t
Hi Matt,
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable cost that an attacker cares about without
> impacting the system's usability due to said cost.
Applying this statement to related a area, would you also agree that
proposals
to introduce
Hi Val,
> Another huge win of backpressure is that it only needs to happen in DoS
> situations, meaning it doesn’t have to impact users in the normal case.
I agree, I think the same would apply to prepayments as well (0 or 1 msat in
calm times). My main concern with relying _only_ on backpressure
er channel.
-- Laolu
On Wed, Jun 29, 2022 at 5:35 PM Rusty Russell wrote:
> Olaoluwa Osuntokun writes:
> > Hi Rusty,
> >
> > Thanks for the feedback!
> >
> >> This is over-design: if you fail to get reliable gossip, your routing
> will
> >> suffer a
Hi Lisa,
> Adding a noticeable on-chain signal runs counter to the goal of the move
> to taproot / gossip v2, which is to make lightning's onchain footprint
> indistinguishable from any other onchain usage
My model of gossip v2 is something like:
* there's no longer a 1:1 mapping of channels a
Hi y'all,
Quick post...
A few weeks ago, some of the dlcspecs developers reached out to ask for
feedback on this PR [1] that attempts to specify a way to send messages
larger
than 65 KB using BOLT 8 (Noise based encrypted transport). After taking a
glance at the PR, I realized that it isn't total
Hi t-bast,
Happy to see this finally written up! With this, we have two classes of
proposals for rate limiting onion messaging:
1. Back propagation based rate limiting as described here.
2. Allowing nodes to express a per-message cost for their forwarding
services, which is described here
to simply defer treating onchain closes is elegant and
> minimal. We could go further and relax requirements to detect onchain
> closes at all, and optionally add a perm close message.
>
> Cheers,
> Rusty.
>
> Olaoluwa Osuntokun writes:
> > Hi y'all,
> >
&g
Hi y'all,
This mail was inspired by this [1] spec PR from Lisa. At a high level, it
proposes the nodes add a delay between the time they see a channel closed on
chain, to when they remove it from their local channel graph. The motive
here is to give the gossip message that indicates a splice is in
Hi Michael,
> A minor point but terminology can get frustratingly sticky if it isn't
> agreed on early. Can we refer to it as nested MuSig2 going
> forward rather than recursive MuSig2?
No strong feelings on my end, the modifier _nested_ is certainly a bit less
loaded and conceptually simpler, so
Hi y'all,
Last week nearly 30 (!) Lightning developers and researchers gathered in
Oakland, California for three day to discuss a number of matters related to
the current state and evolution of the protocol. This time around, we had
much better representation for all the major Lightning Node impl
Hi John,
> That said, I believe that the correct approach to supporting "tokens on
> Lightning" is to make it a separate concern from Taro, and that LL should
> create a separate BOLT proposal from the current Taro BIPs to ensure it LN
> standards have a genericized protocol that all LN implementa
Hi Ruben,
> Also, the people that are responsible for the current shape of RGB aren't
> the people who originated the idea, so it would not be fair to the
> originators either (Peter Todd, Alekos Filini, Giacomo Zucco).
Sure I have no problems acknowledging them in the current BIP draft. Both
the
Hi Harding,
Great questions!
> anything about Taro or the way you plan to implement support for
> transferring fungible assets via asset-aware LN endpoints[1] will address
> the "free call option" problem, which I think was first discussed on this
> list by Corné Plooy[2] and was later extended b
simultaneously guarantee that you
> haven't committed to the same asset twice (i.e. the SMT guarantees each
> asset gets a specific location in the tree)? Or is there another reason?
>
> And the second question – when transferring Taro token ownership from one
> Bitcoin UTXO to
Hi y'all,
I'm excited to publicly publish a new protocol I've been working on over the
past few months: Taro. Taro is a Taproot Asset Representation Overlay which
allows the issuance of normal and also collectible assets on the main
Bitcoin
chain. Taro uses the Taproot script tree to commit extra
22 at 3:52 PM Olaoluwa Osuntokun
wrote:
> Hi y'all,
>
> ## Dynamic Commitments Retrospective
>
> Two years-ish ago I made a mailing list post on some ideas re dynamic
> commitments [1], and how the concept can be used to allow us to upgrade
> channel types on the fly, and
Hi y'all,
## Dynamic Commitments Retrospective
Two years-ish ago I made a mailing list post on some ideas re dynamic
commitments [1], and how the concept can be used to allow us to upgrade
channel types on the fly, and also remove pesky hard coded limits like the
483 HTLC in-flight limit that's p
nt key aggregation
(FROST?) all together).
-- Laolu
On Wed, Mar 23, 2022 at 2:02 PM David A. Harding wrote:
> On 22.03.2022 15:10, Olaoluwa Osuntokun wrote:
> > ### Should the proof+verification strongly bind to the LN context?
> > Today, nodes use the two bitcoin keys and constru
Hi Rusty,
> Timestamps are replaced with block heights.
This is a conceptually small change, but would actually make things like
rate limiting updates for implementations easier and more uniform. A simple
rule would be only allowing an update per block, which cuts down a lot on
potential chatter
Hi y'all,
On the lnd side we've nearly finished fully integrating taproot into the
codebase [1] (which includes the btcsuite set of libraries and also full
btcwallet support), scheduled to ship in 0.15 (~April), which will enable
existing users of lnd's on-chain wallet and APIs to start getting ta
ssaging sessions to be created, which
means mo sats as revenue. I think we're seeing a similar dynamic play out to
day in the network, as path finding algorithms continue to evolve to factor
in "reliability" information (usually some derived probability of success),
which can tend to fav
Hi y'all,
(TL;DR: a way to nodes to get paid to forward onion messages by adding an
upfront session creation phase that uses AMP tender a messaging session to a
receiver, with nodes being paid upfront for purchase of forwarding
bandwidth, and a session identifier being transmitted alongside onion
Hi Jozef,
> I'm working on a project that uses LND with Atomic Multi-path Payments
> (AMP) invoices. It seems there isn't any mobile lightning wallet that is
> able to send sats to AMP invoices.
Any mobile wallet built on lnd v0.14 should be able to send to the
reusable invoices (has the required
en). Since the new state
> is already guaranteed by the previous commitments and revocations, what
> purpose do the additional commitments and revocations provide?
>
>
> Thanks again!
> Ben
>
> --
> Ben Weintraub
> PhD Student
> Khoury College of Computer
Hi Benjamin,
> 1) Multiple sources indicate that after Alice sends the `update_add_htlc`,
> she should then send the `commitment_signed`, but why is it important that
> she sends it first (before Bob)? As far as I understand, as long as she
> doesn't revoke the old state before Bob commits to the
t/org has no
avatar.
-- Laolu
On Tue, Nov 2, 2021 at 7:34 PM Olaoluwa Osuntokun wrote:
> Circling back to close the loop here:
>
> * The new Github org (https://github.com/lightning) now exists, and all
> the
> major implementation maintainers have been added to the organizat
during the recent protocol dev meetup!), happy we were able to resolve
things
and begin the next chapter in the evolution of the Lightning protocol!
-- Laolu
On Fri, Oct 15, 2021 at 1:49 AM Fabrice Drouin
wrote:
> On Tue, 12 Oct 2021 at 21:57, Olaoluwa Osuntokun
> wrote:
> > Also not
Hi y'all,
A few weeks ago over a dozen Lightning developers met up in Zurich for two
days to discuss a number of matters related to the current state and
evolution of the protocol. All major implementations were represented to
some degree, and we even had a number of "independent"
developers/resea
Hi Fabrice,
> I believe that was a mistake: a few days ago, Arcane Research published a
> fairly detailed report on the state of the Lightning Network:
> https://twitter.com/ArcaneResearch/status/1445442967582302213. They
> obviously did some real work there, and seem to imply that their report
>
Hi Joost,
> The conventional approach is to create a lightning invoice on a node and
> store the invoice together with order details in a database. If the order
> then goes unfulfilled, cleaning processes remove the data from the node
> and database again.
> The problem with this setup is that it
Hi Ole,
It's generally known that one can use out of band transaction construction,
and the push_amt feature in the base funding protocol to simulate dual
funded channels.
The popular 'balanceofsatoshis' tool has a command that packages up the
interaction (`open-balanced-channel`) into an easier
Earlier this week I was helping a user debug a Tor related issue, and
realized (from the logs) that some newer Tor clients are already refusing to
connect out to v2 onion services.
On the lnd side, I think we'll move to disallow users creating a v2 onion
service in our next major release (0.14), a
Matt wrote:
> I'm frankly still very confused why we're having these conversations now
1000% this!!
This entire conversation strikes me as extremely premature and backwards
tbh. Someone experimenting with a new approach shouldn't prompt us to
immediately modify the protocol to better "fit" the a
n a BOLT can be changed to just reference
>> the BIP as mandatory. There isn't anything wrong with this.
>>
>> All of the above would work exactly the same if there was a bLIP
>> repository instead. I don't see the value in having both bLIPs and
>> BIPs sinc
ubject to change, and more people were
> strongly encouraged to write specs for new lightning features
> elsewhere (like the BIP repo) then you would see this issue of growing
> BOLTs resolved.
>
> Cheers
> Ariel Lorenzo-Luaces
>
> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa
> That being said I think all the points that are addressed in Ryan's mail
> could very well be formalized into BOLTs but maybe we just need to rethink
> the current process of the BOLTs to make it more accessible for new ideas
> to find their way into the BOLTs?
I think part of what bLIPs are try
> I think the problem of accidental channel closure is getting ignored by
> devs.
>
> If we think any anti-DoS fee will be "insignificant" compared to the cost
> of closing and reopening a channel, maybe dev attention should be on
> fixing accidental channel closure costs than any anti-DoS fee mech
Hi Z,
Thanks for such kind words!
> Is there a documentation for the client/server intercommunications
> protocol?
Long form documentation on the client/server protocol hasn't yet been
written. However, just like Loop, the Pool client uses a fully-featured gRPC
protocol to communicate with the s
Hi y'all,
We've recently released a new system which may be of interest to this list,
Lightning Pool [1]. Alongside a working client [2], we've also released a
white paper which goes deeper into the architecture of the system.
Pool builds on some earlier ideas that were tossed around the ML conce
> I suggest adding tlv records in `commitment_signed` to tell our channel >
> peer that we're changing the values of these fields.
I think this fits in nicely with the "parameter re-negotiation" portion of
my
loose Dynamic commitments proposal. Note that in that paradigm, something
like this would
> It seems to me that the "funder pays all the commit tx fees" rule exists
> solely for simplicity (which was totally reasonable).
At this stage, I've learned that simplicity (when doing anything that
involves multi-party on-chain fee negotiating/verification/enforcement can
really go a long way).
Hi Antoine,
Great findings!
I think an even simpler mitigation is just for the non-initiator to _reject_
update_fee proposals that are "unreasonable". The non-initiator can run a
"fee leak calculation" to compute the worst-case leakage of fees in the
revocation case. This can be done to day witho
Hi Z,
> Probably arguably off-topic, but this post triggered me into thinking
> about an insane idea: offchain update from existing Poon-Dryja to newer
> Decker-Russell-Osuntokun ("eltoo") mechanism.
Ooo, yeh I don't see why this would be possible assuming at that point
no_input has been deployed
ly to have the initiator
> just
> ignore these messages, and the non-initiator enqueue these un-acked
> messages
> and replay them after the commitment format update completes (or just drop
> them
> and cancel corresponding upstream HTLCs if needed).
>
> Regarding initiati
ail.
Thoughts?
-- Laolu
-- Laolu
On Mon, Jul 20, 2020 at 6:18 PM Olaoluwa Osuntokun
wrote:
> Hi y'all,
>
> In this post, I'd like to share an early version of an extension to the
> spec
> and channel state machine that would allow for on-the-fly commitment
> _form
Hi y'all,
In this post, I'd like to share an early version of an extension to the spec
and channel state machine that would allow for on-the-fly commitment
_format/type_ changes. Notably, this would allow for us to _upgrade_
commitment types without any on-chain activity, executed in a
de-synchron
Hi Jeremy,
The up-front costs can be further mitigated even without something like CTV
(which makes things more efficient) by adding a layer of in-direction w.r.t
how
HTLCs are manifested within the commitment transactions. To do this, we add
a
new 2-of-2 multi-sig output (an HTLC indirect block)
Hi Rene,
IMO this is mostly mitigated by anchor commitments. The impact of this
attack is predicated on the "victim" paying 5x on-chain fees (for their
confirmation target) to sweep all their HTLCs. Anchor commitments let the
initiator of the channel select a very low starting fee (just enough t
Hi Antoine,
> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients [0] each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the back
> would need to change in the BOLTs, which does actually seem relatively
> minimal (although as you mention, these minimal changes to the BOLTs do
> trigger large changes in many implementations). Also, good point on how
> BOLT 11 (invoicing) will have to be altered as well, must'
Hi Nadav,
Thanks for the updates! Super cool to see this concept continue to evolve
and integrate new technologies as they pop up.
> I believe this would only require a few changes to existing nodes:
Rather than a "few changes", this would to date be the largest network-level
update undertaken t
this
progressive absolute fee increase, it's likely that the war terminates
with _one_ of them getting into the block, which seems to resolve
everything?
-- Laolu
On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo
wrote:
>
>
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote:
>
>
inning.
As long as one of them confirms within the CLTV-delta, then everyone is
made whole.
[1]: https://github.com/bitcoin/bitcoin/pull/18191
On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo
wrote:
> A few replies inline.
>
> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> > Hi Matt,
, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun
wrote:
> Hi Z,
>
> > It seems to me that, if my cached understanding that `<0>
> > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then
> adding
> > that to the hashlock branch (2 witness bytes, 0.5 weight) w
Hi Z,
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
pretty
> low-weight mitigation against this attack.
I think this works...so they're
> So what is needed is to allow B to add fees to HTLC-Timeout:
Indeed, anchors as defined in #lightning-rfc/688 allows this.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of
Hi Matt,
> While this is somewhat unintuitive, there are any number of good anti-DoS
> reasons for this, eg:
None of these really strikes me as "good" reasons for this limitation, which
is at the root of this issue, and will also plague any more complex Bitcoin
contracts which rely on nested tre
Hi y'all,
We've been discussing the current state of the spec and implementation
readiness of anchor outputs for a few week now on IRC. As detailed
conversations are at times difficult to have on IRC, and there's no true
history, I figured I'd start a new discussion thread where we can hammer out
Hi y'all,
A new paper analyzing the security of the Sphinx mix-net packet format [1]
(and also HORNET) has recently caught my attention. The paper is rather long
and very theory heavy, but the TL;DR is this:
* The OG Sphinx paper proved various aspects of its security using a
model for
Hi Rusty,
Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other
alternatives for a few years now, and none of them seems to resolve the
series of routing related incentive issues that prepaid HTLCs would.
> Since both Offers and Joost's WhatSat are looking at sending messages,
> i
Hi t-bast,
> She creates a Bolt 11 invoice containing that pre-encrypted onion.
This seem insufficient, as if the prescribed route that Alice selects fails,
then the sender has no further information to go off of (let's say Teddy is
offline, but there're other pats). cdecker's rendezvous sketch u
Hi Rusty,
I think this change may be a bit misguided, and we should be careful about
making sweeping changes to default values like this such as fees. I'm
worried that this post (and the subsequent LGTMs by some developers)
promotes the notion that somehow in Lightning, developers decide on fees
(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
We've confirmed instances of the CVE being exploited in the wild. If you’re
not on the following versions of either of these implementations (these
versions are fully patched), then you need to upgrade now to avoid risk of
funds loss:
* lnd v0.7
> I found out recently (mid-2019) that mainnet Lightning nodes take an
> inordinate amount of time to find a route between themselves and an
> arbitrary payee node.
> Typical quotes suggested that commodity hardware would take 2 seconds to
> find a route
Can you provide a reproducible benchmark or
Hi y'all,
I'm not sure how good defenses are on implementations other than lnd, but
all implementations *should* be keeping a Sphinx reply cache of the past
shared secrets they know of [1]. If a node comes across an identical shared
secret of that in the cache, then they should reject that packet.
Hi y'all,
Recently we've started to do more design work related to the Sphinx packet
(EOB format, rendezvous protocol). This prompted me to re-visit the original
Sphinx paper to refresh my memory w.r.t some of the finer details of the
protocol. While I was re-reading the paper, I realized that we
Hi Andrea,
> This saves the receiving node from doing a database lookup
Nodes can and eventually should start using bloom filters to avoid most
database lookups for incoming payment hashes. The false positive rate can be
set to a very low value as the bloom filter doesn't need to transmitted, and
It isn't mandatory. It can be left blank, none of the existing wallets
require users to input a description when they make an invoice.
On Mon, Jan 14, 2019, 3:28 PM Francis Pouliot I'm currently in the process of building the Lightning Network payout
> feature which will allow users to purchase b
> OG AMP is inherently spontaneous in nature, therefore invoice might not
exist
> to put the feature on.
That is incorrect. One can use an invoice along with AMP as is, in order to
tag
a payment. As an example, I want to deposit to an exhcange, so I get an
invoice
from them. I note that the invoic
I realized the other day that the wumbo bit should also likely encompass
wumbo
payments. What good is a wumbo channel that doesn't also allow wumbo
payments?
Naturally if the bit is signalled globally, then this should also signal the
willingness of the node to forward larger payments up to their m
> If I'm not mistaken it'll not be possible for us to have spontaneous
> ephemeral key switches while forwarding a payment
If this _was_ possible, then it seems that it would allow nodes to create
unbounded path lengths (looks to other nodes as a normal packet), possibly
by controlling multiple no
Was approaching more so from the angle of a node new node with no existing
channels seeking to bootstrap connections to the network.
-- Sent from my Spaceship
On Fri, Nov 9, 2018, 9:10 AM Anthony Towns On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote:
> > > A node,
> A node, via their node_announcement,
Most implementations today will ignore node announcements from nodes that
don't have any channels, in order to maintain the smallest routing set
possible (no zombies, etc). It seems for this to work, we would need to undo
this at a global scale to ensure thes
Hi Fabrice,
I think HORNET would address this rather nicely!
During the set up phase (which uses Sphinx), the sender is able to get a
sense
of if the route is actually "lively" or not, as the circuit can't be
finalized
if all the nodes aren't available. Additionally, during the set up phase,
the
peed up the process if I want to queue another operation up
right afterwards.
-- Laolu
On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell wrote:
> Olaoluwa Osuntokun writes:
> > Hi Rusty,
> >
> > Happy to get the splicing train rolling!
> >
> >> We've had inc
Hi tomokio,
This is so dope! We've long discussed creating canned protocol transcripts
for
other implementations to assert their responses again, and I think this is a
great first step towards that.
> Our proposal:
> Every implementation has compile option which enable output key
information
> fi
> However personally I do not really see the need to create multiple
channels
> to a single peer, or increase the capacity with a specific peer (via
splice
> or dual-funding). As Christian says in the other mail, this
consideration,
> is that it becomes less a network and more of some channels to
> This seems at odds with the goal of "if the remote party force closes,
then
> I get my funds back immediately without requiring knowledge of any secret
> data"
Scratch that: the static back ups just need to include this CSV value!
-- Laolu
On Tue, Nov 6, 2018 at 3:29 PM
Hi Rusty,
I'm a big fan in general of most of this! Amongst many other things, it'll:
simplify the whole static channel backup + recovery workflow, and avoid all
the fee related headaches we've run into over the past few months.
> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPA
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling),
The on-chain footprint is a shame, and also it gets worse if we start to
allow multiple pending splices. Also the lack of a non-blocking splice in is
a big draw back IMO.
> but mostly
Hi Rusty,
Happy to get the splicing train rolling!
> We've had increasing numbers of c-lightning users get upset they can't
> open multiple channels, so I guess we're most motivated to allow splicing
of
> existing channels
Splicing isn't a substitute for allowing multiple channels. Multiple
chan
ng in an HTLC
timeout), as if you cancel back, then they know that you had enough
bandwidth to _accept_ the HTLC in the first place.
-- Laolu
On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell wrote:
> Olaoluwa Osuntokun writes:
> >> That might not be so desirable, since it leaks th
> That might not be so desirable, since it leaks the current channel
> capacity to the user
>From my PoV, the only way a node can protect the _instantaneous_ available
bandwidth in their channel is to randomly reject packets, even if they have
the bandwidth to actually accept and forward them.
Ob
send the regular lightning `error`
> message from BOLT #1
>* If the error is not specific to any channel: set channel_id to 0.
>
> A receiving node
>* If experiment_name_hash is unknown:
> - MUST fail the channel.
>* If channel_id is 0
> - MUST fai
1 - 100 of 134 matches
Mail list logo