Fabrice Drouin writes:
> On Mon, 21 Jan 2019 at 08:05, Rusty Russell wrote:
>>
>> Hi all,
>>
>> I have a concrete proposal for feature bits.
>>
>> 1. Rename 'local features' to 'peer features'.
>> 2. Rename 'global features' to 'routing featur
We're pleased to announce c-lightning 0.7, named by Mark Beckwith.
https://github.com/ElementsProject/lightning/releases/tag/v0.7.0
Highlights for Users
* Plugins are here, with frameworks for C, Python and Go! Write your own
cool extensions!
* Much better pay
ZmnSCPxj writes:
> Good morning Rusty,
>
>> So we need a web way of asking a client to send an invoice or offer over
>> HTTPS. Is this a new URI scheme? How would this work?
>
> I thought that offers would work over LN alone?
>
> When you first proposed the offers, I thought it was this way:
>
>
es.
Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
scenario (as well as the second), I'd be content with that proposal.
Future segwit versions may choose to relax it.[1]
Cheers,
Rusty.
[1] Must be consensus, not standardness; my prev suggestion was bogus.
Rusty Russel
nSCPxj
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, March 16, 2019 12:45 PM, Rusty Russell
> wrote:
>
> > Hi all,
> >
> > Linux Foundation (who graciously host this list for us) is
> > deprecating their mailing list
e for HTLC outputs).
This is a much simpler stepping stone, and resolves one immediate
problem.
Suggested-by: @roasbeef
Signed-off-by: Rusty Russell
diff --git a/.aspell.en.pws b/.aspell.en.pws
index b1a1ad3..20664f2 100644
--- a/.aspell.en.pws
+++ b/.aspell.en.pws
@@ -33
Hi all,
Linux Foundation (who graciously host this list for us) is
deprecating their mailing list infrastructure (mailman2 is unmaintained,
apparently v3 is a mess), and migrating lists to groups.io. Apparently
this is the direction that bitcoin-dev is heading.
Unless people raise
ning inventory messages for channel_update messages.
>
> Cheers,
>
> Fabrice
>
>
>
> On Wed, 9 Jan 2019 at 00:44, Rusty Russell wrote:
>>
>> Fabrice Drouin writes:
>> > I think there may even be a simpler case where not replacing updates
>> >
Hi all,
Finally tried to write up the feature bit changes:
https://github.com/lightningnetwork/lightning-rfc/pull/571
And also start on TLV definition for the onion:
https://github.com/lightningnetwork/lightning-rfc/pull/572
Feature bits:
-
1. Rename
Matt Corallo writes:
>>> Thus, even if you imagine a steady-state mempool growth, unless the
>>> "near the top of the mempool" criteria is "near the top of the next
>>> block" (which is obviously *not* incentive-compatible)
>>
>> I was defining "top of mempool" as "in the first 4 MSipa", ie.
Olaoluwa Osuntokun writes:
> 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
This is a recommended upgrade!
https://github.com/ElementsProject/lightning/releases/tag/v0.7.1
We're pleased to announce c-lightning 0.7.1, named by new C-Lightning
Core Team member Lisa Neigut.
Highlights for Users
o Gossip (both serving to others and
Ecurrencyhodler Blockchains writes:
>1. Bob wants to send me 100,000 sats.
>2. My node just came online and has 0 inbound liquidity.
>3. I create an invoice for 100,000 sats. My LN node recognizes I have 0
>inbound liquidity so my wallet also embeds my URI in the invoice.
>4.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Security issues have been found in various lightning projects which
could cause loss of funds.
Full details will be released in 4 weeks (2019-09-27), please uprade
well before then.
Effected releases:
CVE-2019-12998 c-lightning < 0.7.1
Hi all,
The next release of c-lightning will start suppressing gossip
which comes too fast. I have implemented a simple filter which allows
each message (node_announcement or channel_update) ONCE PER DAY on
average, with a burst up to 4 times per day. We will also discard
identical
ZmnSCPxj via Lightning-dev writes:
>> > Typical quotes suggested that commodity hardware would take 2 seconds to
>> > find a route
>>
>> Can you provide a reproducible benchmark or further qualify this number (2
>> seconds)?
>
> No reproducible benchmark.
OK, on my digital ocean 2-cpu 4GB ram
Pierre writes:
> Hi Rusty,
>
> How would bruteforcing on the CSV delay be different from a BIP32
> wallet with look ahead keys? Especially given that we could try with
> most probable values first.
It's a big multiplier, given that CSV can be specified by the
counterparty. If you accept up to
Hi all,
In Adelaide we proposed that CSV delays be symmetric; that the
to-self output would be delayed to avoid weird "no, you close!" games.
Unfortunately, Roasbeef points out that this undermines the
great strength of the option_static_remotekey, which allows a
Pierre writes:
>> > How would bruteforcing on the CSV delay be different from a BIP32
>> > wallet with look ahead keys? Especially given that we could try with
>> > most probable values first.
>>
>> It's a big multiplier, given that CSV can be specified by the
>> counterparty. If you accept up
Hi Ed,
Sorry for the delay.
There's always a tension between safety and disclosure.
In this case, the three implementations agreed that it was best to make
sure everyone had done a release and ensure there were no problem with
upgrades and that the majority of people had upgraded before
ibes the requirement to wait for confirmations[5].
It did NOT, however, require the receiver to actually check that the
transaction is the one promised by the funder: both the amount and the actual
scriptpubkey.
Discovery
-
Rusty Russell (Blockstream) discovered this while working on protocol
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
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
It was pointed out to me[1] at thelightningconference.com that it's often
a legal requirement to list the vendor on a receipt. It also makes
perfect sense.
It can be done in the description field, but that's really supposed to
be a description of the *items*. Dividing it also lets wallets have
Hi all,
This took longer than I'd indicated; for that I'm sorry.
However, this should give us all something to chew on. I've started
with a draft "BOLT 12" (it might be BOLT 13 by the time it's finalized
though!).
I've also appended indications where we touch other BOLTs:
1. BOLT 7
Hi all,
It's been widely known that we're going to have to have up-front
payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
spam).
Since both Offers and Joost's WhatSat are looking at sending
Ross Dyson writes:
> Hi Rusty,
>
> We spoke in detail about this after your presentation at LNconf. I'm one of
> the contributors to LNURL so I am a little familiar with what you're trying
> to achieve and am very grateful you're considering implementing something
> similar to the mainnet
Yaacov Akiba Slama writes:
> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
>> Hi Yaacov,
>> I've been pondering this since reading your comment on the PR!
>>
>> As a fan of standards, I am attracted to UBL (I've chaired an
>> OASI
Anthony Towns writes:
> On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
>> Anthony Towns writes:
>> [ Snip summary, which is correct ]
>
> Huzzah!
>
> This correlates all the hops in a payment when the route reaches its end
> (due to the final pr
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
Anthony Towns writes:
> On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote:
>> Sure: for simplicity I'm sending a 0-value HTLC.
>> ZmnSCPxj has balance 1msat in channel with Rusty, who has 1000msat
>> in the channel with YAIjbOJa.
>
> Alice, Bob and Carol
Olaoluwa Osuntokun writes:
> 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
Joost Jager writes:
>>
>> > Isn't spam something that can also be addressed by using rate limits for
>> > failures? If all relevant nodes on the network employ rate limits, they
>> can
>> > isolate the spammer and diminish their disruptive abilities.
>>
>> Sure, once the spammer has jammed up the
and what should be in a
general UBL field is a question we have to think on further.
Anyway, you'll have to bear with me as I read this 172 page
standard...
Cheers,
Rusty.
> What do you think?
> PS: Sorry for crossposting here and in
> https://github.com/lightningnetwork/l
Anthony Towns writes:
> On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
>> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
>> > field: it says 14, ." but Alice doesn't know anything other than
>> > so can't
ZmnSCPxj writes:
> First, please confirm my understanding of the message flow.
> Suppose I have a donation offer on my website and Rusty wants to donate to me.
> Then:
>
> ZmnSCPxj Rusty
> ||
> +-- `lno`
Yaacov Akiba Slama writes:
> So we can integrate between them without intermixing the semantics of
> the protocols but we need only to define the interaction points between
> them.
>
> In the previous worflow, the seller can for instance add in the LN
> invoice H(Quotation
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
Anthony Towns writes:
> On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote:
>> >> Rusty prepares a nonce, A and hashes it 25 times = Z.
>> >> ZmnSCPxj prepares the onion, but adds extra fields (see below).
>> > It would have made more sen
Joost Jager writes:
> In my opinion, the prepayment should be a last resort. It does take away
> some of the attractiveness of the Lightning Network. Especially if you need
> to make many payment attempts over long routes, the tiny prepays do add up.
> For a $10 payment, it's probably nothing to
Rusty Russell writes:
> Olaoluwa Osuntokun writes:
>> Defaults don't necessarily indicate higher/lower reliability. Issuing a
>> single CLI command to raise/lower the fees on one's node doesn't magically
>> make the owner of said node a _better_ routing node operator.
>
m by forcing the sender to use some resources (instead of sats).
> Maybe this idea has already been proposed and broken, if that's the case
> I'd love to see the
> discussion if someone can surface it.
>
>
> Cheers,
> Bastien
>
> Le lun. 11 nov. 2019 à 00:32, Rusty Russell a
&g
Conner Fromknecht writes:
> Hi all,
>
> I recently revisited the eltoo paper and noticed some things related
> watchtowers that might affect channel construction.
>
> Due to NOINPUT, any update transaction _can_ spend from any other, so
> in theory the tower only needs the most recent update txn
ZmnSCPxj writes:
> Good morning Rusty,
>
>> > Hi all,
>> > I recently revisited the eltoo paper and noticed some things related
>> > watchtowers that might affect channel construction.
>> > Due to NOINPUT, any update transaction can spend from any other, so
>> > in theory the tower only needs the
Yaacov Akiba Slama writes:
> Seller: Quotation (UBL)
>
> Buyer: Order (UBL)
>
> Seller: Prepayment Invoice (UBL)
>
> Seller: Invoice (LN)
>
> Buyer/Seller: Payment & Ack (LN)
>
> Buyer: Receipt (UBL)
>
>
> The advantage of such workflow are that we don't need to add any fields
> to
Hi all,
I've been looking at the current lightning network fees, and it
shows that 2/3 are sitting on the default (1000 msat + 1 ppm).
This has two problems:
1. Low fees are now a negative signal: defaults actually indicate
lower reliability, and routing gets tarpitted trying them
Olaoluwa Osuntokun writes:
> 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
Anthony Towns writes:
> Aside from those philosophical complaints, seems to me the simplest
> attack would be:
>
> * route 1000s of HTLCs from your node A1 to your node A2 via different,
> long paths, using up the total channel capacity of your A1/A2 nodes,
> with long timeouts
> *
Christian Decker writes:
> Rusty Russell writes:
>
>> I like it! The lack of "reply" function eliminates all storage
>> requirements for the intermediaries. Unfortunately it's not currently
>> possible to fit the reply onion inside the existing onion, bu
Anthony Towns writes:
> On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote:
>> And if there is a grace period, I can just gum up the network with lots
>> of slow-but-not-slow-enough HTLCs.
>
> Well, it reduces the "gum up the network for blocks" to &qu
Bastien TEINTURIER writes:
> That's of course a solution as well. Even with that though, if Alice opens
> multiple channels to each of her Bobs,
> she should use Tor and a different node_id each time for better privacy.
There are two uses for this feature (both of which I started implementing):
Rusty Russell writes:
> Bastien TEINTURIER writes:
>> That's of course a solution as well. Even with that though, if Alice opens
>> multiple channels to each of her Bobs,
>> she should use Tor and a different node_id each time for better privacy.
>
> There are two
Bastien TEINTURIER writes:
> Hey again,
>
> Otherwise Mallory gets two invoices, and wants to know if they're
>> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
>> nodeid N2, routehint Bob->C2.
>
> I think this attack is interesting. AFAICT my proposal defends against
Bastien TEINTURIER writes:
> We can easily get rid of (1.) by leveraging the `payment_secret`. The
> improved scheme is:
>
> * Alice draws a random `decoy_key`
> * Alice computes the corresponding `decoy_node_id = decoy_key * G`
> * Alice draws a random `payment_secret`
> * Alice computes
We're pleased to announce 0.8.1, named by @vasild (who last release was
a new committer!)
https://github.com/ElementsProject/lightning/releases/tag/v0.8.1
*Highlights for Users*
- We now support gifting msat to the peer when opening a channel, via
push_msat, providing a brand new way
René Pickhardt writes:
> Hey Rusty,
>
> I was very delighted to read your proposal. But I don't see how you prevent
> message spam. If I understand you correctly you suggest that I can
> communicate to any node along a path of peer connections (not necessarily
> backed by payment channels but
ZmnSCPxj writes:
> Good morning Rusty,
>
> A concern I have brought up in the past is that if this is more than just a
> single request-response, i.e. if this is a conversation where Alice sends to
> Bob, Bob sends back to Alice, Alice sends back to Bob, and so on, then if the
> same path is
Anthony Towns writes:
> On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote:
>> A different way of mitigating this is to reverse the direction in which the
>> bond is paid. So instead of paying to offer an htlc, nodes need to pay to
>> receive an htlc. This sounds counterintuitive, but
Bastien TEINTURIER writes:
>> But Mallory can do the same attack, I think. Just include the P_I from
>> the wrong invoice for Bob.
>
> Good catch, that's true, thanks for keeping me honest there! In that case
> my proposal
> would need the same mitigation as yours, Bob will need to include the
>
lisa neigut writes:
>> With PoDLE this would not be possible I think, as you would not be able
> to open the PoDLE commitment with the other node as the target (if we go
> with the modified PoDLE which also commits to which node an opening is for,
> to prevent the pouncing venus flytrap attack).
Hi all!
It seems that messaging over lightning is A Thing, and I want to
use it for the offers protocol anyway. So I've come up with the
simplest proposal I can, and even implemented it.
Importantly, it's unreliable. Our implementation doesn't
remember across restarts, limits
ZmnSCPxj via Lightning-dev writes:
> Good morning niftynei,
>
>
>> Rusty had some suggestions about how to improve the protocol messages for
>> this, namely adding a serial_id to the inputs and outputs, which can then be
>> reused for deletions.
>>
>> The serial id can then also be used as the
Bastien TEINTURIER writes:
> Hi Rusty,
>
> Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)
... Now -rc2. I actually had a RL use for lightning (OMG!), and sure
enough found a bug.
> I've been thinking more about improving my scheme to not require any sender
> change, but I
I recently hit a dead-end on rendezvous routing; the single-use
requirement is a showstopper for offers (which are supposed to be static
and reusable).
Fortunately, t-bast has a scheme for blinded paths (see
https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf ) so
I've been examining
Hi ZmnSCPxj,
This is a rework of the old unwrap-the-onion proposal, with
some important bits missing.
> Secondly, C needs to prove that the channel it is willing to close involves
> the payment attempt, and is not some other channel closure that it is
> attempting to use to fulfill its
"David A. Harding via bitcoin-dev"
writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in
ZmnSCPxj writes:
> Good morning Rusty, et al.,
>
>
>> Note that this means no payment secret is necessary, since the incoming
>> `blinding` serves the same purpose. If we wanted to, we could (ab)use
>> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's
>> the ECDH for Carol to
We're pleased to announce the 0.9.1 release of c-lightning, named by Jon
Griffiths.
https://github.com/ElementsProject/lightning/releases/tag/v0.9.1
This is a significant release with major bugfixes to multi-part payments
and various notable speedups and improvements across the board.
Joost Jager writes:
>>
>> > A crucial thing is that these hold fees don't need to be symmetric. A new
>> > node for example that opens a channel to a well-known, established
>> routing
>> > node will be forced to pay a hold fee, but won't see any traffic coming
>> in
>> > anymore if it announces
Christian Decker writes:
> I wonder if we should just go the tried-and-tested leader-based
> mechanism:
>
> 1. The node with the lexicographically lower node_id is determined to
> be the leader.
> 2. The leader receives proposals for changes from itself and the peer
> and orders them
Bastien TEINTURIER writes:
> It's a bit tricky to get it right at first, but once you get it right you
> don't need to touch that
> code again and everything runs smoothly. We're pretty close to that state,
> so why would we want to
> start from scratch? Or am I missing something?
Well, if
Hi all,
Our HTLC state machine is optimal, but complex[1]; the Lightning
Labs team recently did some excellent work finding another place the spec
is insufficient[2]. Also, the suggestion for more dynamic changes makes it
more difficult, usually requiring forced quiescence.
The
Joost Jager writes:
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.
...
>
> In both cases the sender needs to trust its peer to not steal the payment
> and/or
Olaoluwa Osuntokun writes:
> After getting some feedback from the Lightning Labs squad, we're thinking
> that it may be better to make the initial switch over double-opt-in, similar
> to the current `shutdown` message flow. So with this variant, we'd add two
> new messages: `commit_switch` and
Bastien TEINTURIER writes:
> Hey Rusty,
>
> Good questions.
>
> I think we could use additive tweaks, and they are indeed faster so it can
> be worth doing.
> We would replace `B(i) = HMAC256("blinded_node_id", ss(i)) * P(i)` by `B(i)
> = HMAC256("blinded_node_id", ss(i)) * G + P(i)`.
>
See:
https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
1. Can we use additive tweaks instead of multiplicative?
They're slightly faster, and supported by the x-only secp API.
2. Can we use x-only pubkeys? It's generally trivial, and a
Christian Decker writes:
>> And you don't get the benefit of the turn-taking approach, which is that
>> you can have a known state for fee changes. Even if you change it to
>> have opener always the leader, it still has to handle the case where
>> incoming changes are not allowed under the new
Lloyd Fournier writes:
> This achieves all properties except for (4 - distinguishable on-chain)
> which is why it was dismissed.
It also seems to require 2 txs per channel open? (Interestingly I
missed that post previously, thanks for the pointer!)
> I think it is possible to extend the idea
Lloyd Fournier writes:
> I think immediate broadcast of signaling TX is a bad idea even if it's done
> over lightning since it leaks that the UTXO associated with the signaling
> TX is creating a channel (even if the channel was meant to be private).
> You could argue that the signaling TX need
I wanted this for my simplified update commitment draft, so here it is.
Would be nice to upgrade those old channels to static remotekey and
anchors (yeah, it's still on my TODO) so we could top the old stuff out
of implementations and finally the spec!
Matt Corallo writes:
> Thanks!
>
> On 6/29/21 01:34, Rusty Russell wrote:
>> Hi all!
>>
>> John Carvalo recently pointed out that not every implementation
>> accepts zero-conf channels, but they are useful. Roasbeef also recently
>> noted that th
Bastien TEINTURIER writes:
> Hi Rusty,
>
> On the eclair side, we instead send `funding_locked` as soon as we
> see the funding tx in the mempool.
>
> But I think your proposal would work as well.
This would be backward compatible, I think. Eclair would send
`funding_locked`, which is perfectly
Hi all!
John Carvalo recently pointed out that not every implementation
accepts zero-conf channels, but they are useful. Roasbeef also recently
noted that they're not spec'd.
How do you all do it? Here's a strawman proposal:
1. Assign a new feature bit "I accept zeroconf channels".
2.
Carla Kirk-Cohen writes:
> Hi all,
Hi Carla,
I apologize for not responding to this earlier, but it was
raised again in the recent spec meeting
(https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-07-05-20.06.log.html).
I love the idea of more specific error
ZmnSCPxj writes:
> Mostly nitpick on terminology below, but I think text substantially like the
> above should exist in some kind of "rationale" section in the BOLT, so ---
>
> In light of dual-funding we should avoid "funder" and "fundee" in favor of
> "initiator" and "acceptor".
Yes, Lisa
Matt Corallo writes:
>> On Apr 24, 2021, at 01:56, Rusty Russell wrote:
>>
>> Matt Corallo writes:
>>> Somehow I missed this thread, but I did note in a previous meeting - these
>>> issues are great fodder for fuzzing. We’ve had a fuzzer which a
there's no debate on the state of the channel when
this is being applied.
Cheers,
Rusty.
Rusty Russell writes:
> Matt Corallo writes:
>>> On Apr 24, 2021, at 01:56, Rusty Russell wrote:
>>>
>>> Matt Corallo writes:
>>>> Somehow I missed this th
Hi all,
You can currently probe for a channel id attached to node N by
sending an HTLC, and seeing whether the error reply comes from the N or
the next hop. The real answer is to get back to blinded paths, BTW.
But Joost pointed out that you need to know the node_id of the next node
Matt Corallo writes:
> Somehow I missed this thread, but I did note in a previous meeting - these
> issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively
> tests for precisely these types of message-non-delivery-and-resending
> production desync bugs for several years.
Joost Jager writes:
>>
>> But Joost pointed out that you need to know the node_id of the next node
>> though: this isn't quite true, since if the node_id is wrong the spec
>> says you should send an `update_fail_malformed_htlc` with failure code
>> invalid_onion_hmac, which node N turns into its
Lloyd Fournier writes:
> Hey Rusty,
>
> Thoughts on each point below.
>
> On Fri, 23 Apr 2021 at 14:29, Rusty Russell wrote:
>
>> OK, I'm now leaning *against* this method.
>>
>> 1. It removes the ability to update a channel without access to the node's
>&
Matt Corallo writes:
> On 4/27/21 17:32, Rusty Russell wrote:
>> OK, draft is up:
>>
>> https://github.com/lightningnetwork/lightning-rfc/pull/867
>>
>> I have to actually implement it now (though the real win comes from
>> making it
Matt Corallo writes:
> On 4/27/21 01:04, Rusty Russell wrote:
>> Matt Corallo writes:
>>>> On Apr 24, 2021, at 01:56, Rusty Russell wrote:
>>>>
>>>> Matt Corallo writes:
>>> I promise it’s much less work than it sounds like, and avoids
We're pleased to announce the 0.10.0 release of c-lightning, named by @jsarenik.
https://github.com/ElementsProject/lightning/releases/tag/v0.10.0
This is a major release, consolidating a number of features, fixes and
experimental extensions.
Highlights for Users
* pay has been refined
Lloyd Fournier writes:
> On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell wrote:
>
>>
>> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?
>>
>> Nice work. This would be a definite recovery win. We should add this
>> to the DF spec, because
Lloyd Fournier writes:
> Hi Rusty,
>
> On Tue, 20 Apr 2021 at 10:55, Rusty Russell wrote:
>
>> Lloyd Fournier writes:
>> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell
>> wrote:
>> >
>> >>
>> >> Say r1=SHA256(ss || cou
Christian Decker writes:
> Rusty Russell writes:
>>> This is in stark contrast to the leader-based approach, where both
>>> parties can just keep queuing updates without silent times to
>>> transferring the token from one end to the other.
>>
>> Yo
https://github.com/lightningnetwork/lightning-rfc/pull/863
I haven't even *started* to implement this, so I could well have missed
something. Let's see.
Cheers!
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
Hi all,
https://github.com/lightningnetwork/lightning-rfc/pull/798/commits/fc8aab72ccdd616301dc200fc124824efe4fbb58
I've just added a simple addition to the proposed BOLT 12 offers spec,
where invoice requests can ask to obsolete old invoices. This allows a
simple workaround in the
n, because it was so clever!
Thoughts?
Rusty.
Rusty Russell writes:
> Lloyd Fournier writes:
>> Hi Rusty,
>>
>> On Tue, 20 Apr 2021 at 10:55, Rusty Russell wrote:
>>
>>> Lloyd Fournier writes:
>>> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell
101 - 200 of 221 matches
Mail list logo
