Hi!
I've read the start of the paper on my vacation, and am still
digesting it. But even so far, it presents some delightful
possibilities.
As with some other proposals, it's worth noting that the cost of
enforcement is dramatically increased. It's no longer one or two txs,
it's 10+.
Runes today are often bound to the BOLT8 nodeid, giving both (otherwise
you need to protect your rune from being read).
I like this model *but* it requires two-way comms for setup (the HSM
tells the node its id, the node gives the HSM the rune).
Fortunately, it's trivial to support runes as an
https://github.com/lightning/bolts/pull/1096
This is a "can't fail!" close protocol, as discussed at the NY Summit, and on
@Roasbeef's wishlist. It's about as simple as I could make it: the only
complexity comes from allowing each side to indicate whether they want to omit
their own output.
Um, this is a super-weird setup AFAICT.
You generate an invoice, but you don't remember anything about it? Um,
OK, stateless invoices are a thing, but there's a metadata field for
that?
Someone pays an invoice, you don't check the place it's going (which,
y'know, signed it), you check some
https://github.com/lightning/bolts/pull/1092
02-peer-protocol.md | 74 ++---
03-transactions.md | 389 ---
05-onchain.md| 17 --
07-routing-gossip.md | 52 +-
09-features.md | 30 +--
5 files changed, 48
Hi all,
All posts will be reviewed by a moderator, and I will not be
approving posts which are not directly concerned with Lightning
development.[1]
I'll review this decision sometime next week.[2]
Sorry for the inevitable latency!
Rusty.
[1] Except this one.
[2] Yeah, and I guess that
Joost Jager writes:
> Hi list,
>
> I wanted to get back to a long-standing issue in Lightning: gaps in error
> attribution. I've posted about this before back in 2019 [1].
Hi Joost!
Thanks for writing this up fully. Core lightning also doesn't
penalize properly, because of the
Olaoluwa Osuntokun writes:
> Hi Rusty,
>
> Thanks for the feedback!
>
>> This is over-design: if you fail to get reliable gossip, your routing will
>> suffer anyway. Nothing new here.
>
> Idk, it's pretty simple: you're already watching for closes, so if a close
> looks a certain way, it's a
Hi Roasbeef,
This is over-design: if you fail to get reliable gossip, your routing
will suffer anyway. Nothing new here.
And if you *know* you're missing gossip, you can simply delay onchain
closures for longer: since nodes should respect the old channel ids for
a while anyway.
Matt's proposal
Matt Corallo writes:
>>> I agree there should be *some* rough consensus, but rate-limits are a
>>> locally-enforced thing, not a
>>> global one. There will always be races and updates you reject that your
>>> peers dont, no matter the
>>> rate-limit, and while I agree we should have guidelines,
Matt Corallo writes:
> On 4/26/22 11:53 PM, Rusty Russell wrote:
>> Matt Corallo writes:
>>>> This same problem will occur if *anyone* does ratelimiting, unless
>>>> *everyone* does. And with minisketch, there's a good reason to do so.
>>>
&
We're pleased to announce the 0.11.0 release of c-lightning, named on
behalf of @SimonVrouwe.
This release is the first under the rebranded "Core Lightning" name.
(Note: binaries are labelled v0.11.0.1 due to a minor bugfix required
for reproducible builds).
Highlights for Users
Matt Corallo writes:
>> Allowing only 1 a day, ended up with 18% of channels hitting the spam
>> limit. We cannot fit that many channel differences inside a set!
>>
>> Perhaps Alex should post his more detailed results, but it's pretty
>> clear that we can't stay in sync with this many
Matt Corallo writes:
> Sure, if you’re rejecting a large % of channel updates in total
> you’re gonna end up hitting degenerate cases, but we can consider
> tuning the sync frequency if that becomes an issue.
Let's be clear: it's a problem.
Allowing only 1 a day, ended up with 18% of channels
pay someone to sign their
>> UTXO for your node_announcement, with some level of trust.
>
> I'm not sure this is entirely a *good* thing, as the graph becomes more
> decoupled with the _actual_ on-chain relationships...
Which is the aim (though not sure how many ppl would do it in
p
Olaoluwa Osuntokun writes:
> 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
ZmnSCPxj writes:
> Good morning rusty,
>
> If we are going to switch to a new gossip version, should we prepare now for
> published channels that are backed by channel factories?
This is already true with the new proposal: channels don't have to be
"real". It's possible to raise the required
Joost Jager writes:
> Hi Rusty,
>
> Nice to see the proposal in more concrete terms. Few questions:
>
> - The total proved utxo value (not counting any utxos which are spent)
>> is multiplied by 10 to give the "announcable_channel_capacity" for that
>> node.
>>
>
> Could this work as a dynamic
Hi all,
I've floated this idea before, but this is a more concrete
proposal for a "v2" gossip protocol.
It assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses
modern TLVs for all optional or extensible fields. Timestamps are
replaced with block heights.
1. Nodes send
Matt Corallo writes:
> The Obvious (tm) solution here is PTLCs - just have the sender always add
> some random nonce * G to
> the PTLC they're paying and send the recipient a random nonce in the onion.
> I'd generally suggest we
> just go ahead and do this for every PTLC payment, cause why
Sorry this took so long.
https://github.com/lightningnetwork/lightning-rfc/pull/895
This changed quite a bit, based on discussion here and more coherent
thinking.
1. You can simply send funding_locked early, no feature needed.
2. It's a bit useless unless you are the (sole) funder or you trust
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:
> 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.
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:
> 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
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
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
>&
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
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
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
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.
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
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
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
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
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
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
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:
> 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
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
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
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
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
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
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.
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
"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
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
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
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
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
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
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
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
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
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
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
>
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
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:
> 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):
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
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
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
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
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
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
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
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
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
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
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
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`
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
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
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
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
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
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
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
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.
>
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
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
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
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
1 - 100 of 221 matches
Mail list logo
