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+. I
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 ex
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.
It
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 other
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 insertions(
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 attributi
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 spli
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.
>>>
>&
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.
>
> None of this seems like a good argument for *not* taking the "send updates
> since the last sync in
> the minisketch" approach
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 differenc
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 hi
lly missing them.
Yeah, we may also want the 2week / 2000 block refresh here as well?
>> It also allows "leasing" of UTXOs: you could pay someone to sign their
>> UTXO for your node_announcement, with some level of trust.
>
> I'm not sure this is entirely a *
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 identi
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 ra
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 v
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 o
Christian Decker writes:
>> I noticed the commando c-lightning plugin just uses the JSON-RPC
>> payload, but perhaps something more compact and rpc-friendly like grpc
>> would be better... which is why this cln-grpc PR peaked my curiosity.
>
> Yep, JSON-RPC is rather bad with binary data, and does
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 not
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 t
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 has
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.
Just a quick note that I have a signficant simplification of this,
because I started implementing and I hated it.
This time I'll finish implementing it before I post the spec :)
Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoun
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!
https://github.com/lightningnetwork/l
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 hav
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
means 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
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 aggress
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 o
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. When
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
thou
least one peer is honest.
Damn, 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, 2
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.
>>
>> You
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
https://lists
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 || counter ||
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 Lis
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 case
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
TL;DR: We had a user promise the wrong txid for a funding tx[1]. This of
course requires remote cooperation to get their funds back. This lead
me to a temporary solution, but Christian suggested a more wideranging
one.
The problem
---
With single-sided[2] funding, the opener gives the tx
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 no
Lloyd Fournier writes:
> I think PoDLE might actually have an advantage in parallel attacks if the
> scheme was changed a bit. A weakness of the lightning proposal as compared
> to the joinmarket idea is that the `h2` point is not broadcast immediately
> -- rather you wait for failure and then bro
Lloyd Fournier writes:
> Rusty, Zman,
>
> A concern I have with only doing one signaling transaction out of the whole
> group of inputs is that it means you don't prove ownership of the other
> inputs.
But that's by design. You can contact two peers and middleman between
them to produce a single
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 to
Lloyd Fournier writes:
> Hi list,
>
> I've been considering the problem of recovering lightning channels after
> losing channel state in a boating accident. The modern way of doing this
> seems to be "static channel backups" -- these are essentially lists of
> channel ids and the nodes you had the
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)`.
> Intuitivel
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 fe
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 a
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 int
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 you've
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 artificia
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 following
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.
*D
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 `co
"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 si
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 t
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
> * hav
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,
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 for
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 kind
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 us
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 us
Bastien TEINTURIER writes:
> Exactly what Matt said.
>
> I would also add that libp2p aims to be a kind of swiss-army knife for p2p
> networking: that's nice for many use-cases, but when security is your main
> focus, it's not.
> Look at TLS: most attacks are downgrade attacks because the protocol
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 t
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 do
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 this
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 tw
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 `decoy_s
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 t
Hi Sergi!
Great to see progress on this! Detailed comments below.
Sergi Delgado Segura writes:
> ## Sending and receiving appointments
>
> Once the client is aware of the services provided by the server, the former
> can start sending appointments to the latter.
>
> +---+
n system.
>
> We fight spam 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 l
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 (UBL)||Order(UBL)||Prepa
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 the
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 reas
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
>
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 protocol
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 preima
in the invoice/offer 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://gith
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
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 w
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 WhatS
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
1 - 100 of 290 matches
Mail list logo