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 ordering heuristic for transaction
> inputs
Good morning Rusty,
> No, Bob can include the scid he used in the update_add_htlc message, so
> Alice can check.
>
> I'm extremely nervous about custodial lightning services restricting
> what they will pay to. This is not theoretical: they will come under
> immense KYC pressure in the near futur
Good morning lisa,
> > I am unsure what is the purpose of this minus 6.
>
> The original motivation was to keep the funding transaction from being
> rejected from the mempool in the case of a re-org, but as you pointed out,
> the 'next block' is always at -par or ahead of the current chain tip,
Good morning Gabriel,
Interesting idea and it helps to reduce routemap size by completely eliminating
the routemap, and also removes distinctions between published and unpublished
channels by making every channel unpublished.
However there seem to be some considerations as well.
--
A node whi
Good morning Gabriel,
Some further thinking:
--
I notice as well that you propose to add a random number to the initial hop
distance counter.
This does not quite obscure as much as you might think.
Suppose I have two nodes I control in the Lightning Network, which we will
pretend is this blan
Overview of Components
==
Ant Routing
---
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002505.html
Ant Routing is a distributed pathfinding algorithm where nodes emit
"pheromones", which are broadcasted over the entire network.
When a node
Good morning darosior, niftynei, and list,
>
> We could agree on an acceptable number of reuse in case on a non-malicious
> failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj)
The default of 3 for JoinMarket seems reasonable.
>
> Ok, so knowing where PoDLE originate f
Hi darosior, niftynei, and list,
waxwing replied the below text, and asked to propagate as well to lightning-dev.
He has just recently re-subscribed to lightning-dev, but may be waiting for the
necessary subscription notices or whatnot.
Regards,
ZmnSCPxj
---
Re: Venus Flytrap attack an
Good morning niftynei, and waxwing, and list,
> > s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x
>
> > and as before transfer opening: (P, P2, u, s, e) with receiving-node
> > implicitly reconstructed to do the verification of the Schnorr sig. It's
> > basically a message in a signat
regards,
> Cezary Dziemian
>
> pon., 10 lut 2020 o 11:35 ZmnSCPxj via Lightning-dev
> napisał(a):
>
> > Overview of Components
> > ==
> >
> > Ant Routing
> > ---
> >
> > https://lists.linuxfoundation.org/pipermail/l
Good morning again Cezary,
> > That was really interesting to read this.
> > Why you want to send Node ID inside pheromone? Why not to send random
> > number, that would be then passed though invoice?
> > To increase privacy, node could generate new random number every week and
> > distribute p
Good morning The Authors,
> Hello ZmnSCPxj,
> Thank you for your comments, we are glad for your interest in our work.
> Below some answers to your comments.
> Concerning the information that intermediary nodes can gather from
> counters: We are working under the assumption of a large highly
Good morning again The Authors,
> > Concerning the information that intermediary nodes can gather from
> > counters: We are working under the assumption of a large highly connected
> > network (with thousands of nodes and node connection larger than 10, or
> > nodes connected to highly connec
Good morning waxwing,
>
> https://github.com/privacypass/challenge-bypass-extension/blob/master/docs/PROTOCOL.md
>
> While it's very different from our use-case (harder because not
> client-server),
Am still going through the document, but wanted to react to "not client-server"
thing.
Generall
Good morning niftynei, waxwing, and list,
> > Probably so that address reuse is not dinged, i.e. I have two UTXOs with
> > the same address and want to make two different channels with different
> > peers.
>
> Having 2 utxos locked to the same pubkey will map to a single H2 value
> though, whic
Good morning Rusty, niftynei, and list,
> > > - Serial ids should be chosen at random
> > >
> > > - For multiparty constructions, the initiator MUST flip the bottom bit
> > > of any received inputs before relaying them to a peer.
> > >
> > > - Collisions of serial ids between peers is a pro
Good morning t-bast,
> > Propose we take the `z` to use as bolt11 letter, because even the French
> > don't pronounce it in "rendez-vous"!)
>
> As long as Z-man didn't want to claim this bolt11 letter for himself or his
> puppet army, that sounds good :).
That would be too obvious.
What I *am* cl
Good morning Joost and aj,
A thought that arises here is, what happens if I have forwarded a payment, then
the outgoing channel is dropped onchain and that peer disconnects from me?
Since the onchain HTLC might have a timelock of, say, a few hundred blocks from
now, the outgoing peer can claim
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 used each time Alice sends to B
Good morning Rusty,
> > Would it not be better to create a circular path?
> > By this I mean, Alice constructs an onion that overall creates a path from
> > herself to Bob and back, ensuring different nodes on the forward and return
> > directions.
> > The onion hop at Bob reveals that Bob is th
Good morning Christian, and Rusty,
> > > Would it not be better to create a circular path? By this I mean,
> > > Alice constructs an onion that overall creates a path from herself to
> > > Bob and back, ensuring different nodes on the forward and return
> > > directions. The onion hop at Bob revea
Good morning Gleb,
> In this email, myself (gleb) and ariard want to discuss some aspects of the
> LN implementations when it comes to massive channel closing.
>
> LN security model relies on the unilateral capability to timely confirm
> on-chain commitment transaction. Currently, fee rates of b
Good morning Robert,
Unfortunately, this proposal is basically a proposal to split the network into
a central network of specially-chosen nodes surrounded by second-class and
third-class nodes that are utterly dependent on the central network, which I
personally find disturbing.
Of course, it
Good morning Robert,
> How did you know that I'm a closet furry?! ;) I'm shaking in my onesie right
> now...
It was so obvious, my furdar was picking up your furriness just from parsing
the individual bytes arising from your email server.
> It is definitely not my goal to split the network up
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 decrypt enc1).
I confess
Good morning tbast, rusty, and list,
> As for ZmnSCPxj's suggestion, I think there is the same kind of issue.
> The secrets we establish with anonymous multi-hops locks are between the
> *sender*
> and each of the hops. In the route blinding case, what we're adding are
> secrets
> between the *
Good morning Bastien,
> Good morning ZmnSCPxj,
>
> Ok I see what you mean. In that case it would be slightly different from the
> current path blinding proposal.
> The recipient would need to give the sender all the blinding points for each
> hop in the blinded path.
> Currently the recipient on
Good morning Robert,
> > This shows the issue: what they measured was *the number of rat tails
> > shown*, not *the reduction of rats in the city*, and so they got shown a
> > lot of rat tails (at the expense of actively increasing the number of rats
> > in the city, since they were now being
Good morning Subhra,
> Hi,
> I was just playing around with LND and established a channel between 2
> parties A and B. When sending a payment to B via HTLC, B adds an invoice and
> over here I used a different payment hash for A for sendpayment with a delta
> of 144 blocks. The error I got
Good morning Subhra,
> Thanks ZmnSCPxj. Just a clarification on the idea proposed so that means here
> B needs to delay the HTLC acceptance? Pardon my knowledge on c-lightning,
> but what exactly happens upon htlc_acceptance? Release of preimage or just an
> acknowledgment by B reaching to the
Good morning Subhra,
> Another question related to the paper https://arxiv.org/abs/2003.3. Over
> here, it is stated in page 13, "Surge of unresolved HTLCs while probing:
> Recalling steps 5-7 in Figure 4, each probe sets up a chain of irredeemable
> HTLCs (since a matching preimage would h
Introduction
Given the fact that contracts on offchain protocols need to be enforceable
onchain as well, timelocks involved in multi-hop payments are measured in
blocks.
This is because the blockchain can only (third-party-verifiably) enforce
timeouts in units of entire blocks.
Thi
Good morning Subhra,
> Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the same
> kind of issue.
> The secrets we establish with anonymous multi-hops locks are between the
> *sender*
> and each of the hops. In the route blinding case, what we're adding are
> secrets
> between
Good morning Bastien,
> We believe the
> same encoding could be used to compress the bitcoin blockchain. With more
> training
> data, we believe our AI-optimized mapping could allow bitcoin blocks to fit
> in a
> single tweet; we would then be able to use Twitter feeds to store the whole
> bloc
Good morning Subhra,
> Hi ZmnSCPxj,
> Thanks for the explanation. Pardon my knowledge in this domain but what
> I meant is that sender has malicious intent and wants honest parties to
> suffer. So by leaking secrets, I meant not revealing its or receiver's
> identity to the forwarding node
Good morning Nadav,
> Love the idea! I have a couple questions though:
>
> I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't effective.
> Consider a similar network to the one you described where we have channels A
> - B - C and A - E - C but where we add a "fake" channel E - E'
Good morning Subhra,
> Thank you for the clarification. Sorry for misinterpreting the paper of
> anonymous multihop lock. A bit of rephrasing of what I exactly meant and
> apologies for describing vaguely. Following your discussion on griefing
> attack, it is clear the payer and payee wants to
Good morning Nadav,
> I could be missing something, but it seems to me like the proposal to close
> channels after a soft timeout unless non-cooperation can be proven upstream
> adds a cost to the attacker of two on-chain transactions, which they can
> immediately revoke (as they know both piec
Good morning Dave,
> > Ah, right, E knows the revocation for the unilateral close of EE,
> > because it is a self-channel, sigh. And by this revocation clause it
> > can claim the money immediately and put it into a channel as well.
>
> If it's a self channel, E can also just RBF replace the close
Good morning Nadav, and list,
Thinking even further:
* It is trivially cheap for E to start up new nodes F and G and start up
channels FA and GC.
* It then becomes possible for E to lock up funds of B via F->A->B->C->G and
G->C->B->A->F.
* Even closure of FA and GC does not affect EA and EB.
S
44 blocks and D responds after 142 block time elapses, claiming the
> money locked with D?
That ***is*** the griefing attack.
Regards,
ZmnSCPxj
>
> On Wed, Apr 1, 2020, 11:49 ZmnSCPxj via Lightning-dev
> wrote:
>
> > Introduction
> >
> >
> >
> > > griefing in htlc? Like given the path A->B->C->D, what if C and D has a
> > > lock time of 144 blocks and D responds after 142 block time elapses,
> > > claiming the money locked with D?
> >
> > That ***is*** the griefing attack
ossible scenario of
> > > > > griefing attack, does delay in providing the preimage also counted as
> > > > > a form of griefing in htlc? Like given the path A->B->C->D, what if C
> > > > > and D has a lock time of
; > > >
> > > > >
> > > > > On Mon, Apr 13, 2020, 08:21 ZmnSCPxj wrote:
> > > > >
> > > > > > Good morning Subhra,
> > > > > >
> > > > > > > Hello,
> > > > > > > So
Good morning Nadav, and list,
Resurrecting this very old thread, but I have been thinking of barrier escrows
again lately.
The mitigation in
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002215.html
does not work, because one of the participants can always just create
Good morning Matt, and list,
> RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how,
> now?")
> =
>
> You'll note that in the discussion of RBF pinning we were pretty broad,
> and that that discussion seems to in fact cover
> our HTLC
Good morning Laolu, Matt, and list,
> > * 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 HTLC-Timeout (assuming my cached
> > understanding of `SIGHASH_NOINPUT` still hold
Good morning lists et al,
Let me try to summarize things a little:
* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blocksonly`
mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by sendin
Good morning Matt,
> > - C directly contacts miners with an out-of-band proposal to replace its
> > transaction with an alternative that is much smaller and has a low fee, but
> > much better feerate.
>
> Or they can just wait. For example in today’s mempool it would not be strange
> for a t
Good morning David,
Unfortunately this technique does not look like it is compatible to payment
points rather than hashes, and we would really like to upgrade to payment
points sooner rather than later.
Nobody but B can recognize the signature as revealing the scalar behind a
particular point
Good morning Laolu, and list,
> (this may be kind of off-topic, more about DLC deployment than PTLCs
> themselves)
>
> From my PoV, new technologies aren't what has held back DLC deployment to
> this date since the paper was originally released. Tadge has had working
> code than can be deployed t
Good morning ariard and luke-jr
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment services
> > may attract a lot of adopti
Good morning Richard, and all,
> 2) a light client can query an ISP connected full node on the same unmetered
> local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or full
> blocks using a payment channel. Cost is
Good morning Richard,
> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
> concern as: A node without direct internet connectivity can not rely on an
> opportunistically incentivized local network peer for blockchain information
> because the off-grid node's direct LN pee
Good morning Antoine,
> While approaching this question, I think you should consider economic weight
> of nodes in evaluating miner consensus-hijack success. Even if you expect a
> disproportionate ratio of full-nodes-vs-SPV, they may not have the same
> economic weight at all, therefore even
Good morning Antoine,
> Mitigating may come by negotiating a new `max_dust_htlc_value_in_flight_msat`
> enforced by HTLC recipient, therefore expressing its maximum trust tolerance
> with regards to dust. Bearing a cost on a HTLC holder will also render the
> attack more expensive, even if for
Good morning Antoine,
As well, I considered doing state machine shenanigans for this (do not sign for
removal of HTLC in your outgoing channel until you have irrevocable removal of
HTLC in your incoming channel) but this does not work since if you already have
a miner willing to cooperate with
Good morning Subhra et al,
I am unsure whether you actually solve the Reverse-Griefing attack that the
Griefing-Penalty enables.
It seems to me that Reverse-Griefing is worse than Griefing, since it causes
loss of funds already owned, whereas griefing only causes loss of opportunity
to earn.
I
Introduction
Reducing routemap representation size is important to compensate for possible
future increases in public Lightning Network size, and also make it more
practical to run a Lightning Network node on less-capable devices.
In this (mildly deranged) writeup, I propose a rout
> Now the big issue is that Cheney is a semispace collector, which basically
> means that during collection we need twice the memory, which absolutely sucks.
> Obviously ZmnSCPxj has gone insane and just wants us to spend twice as much
> memory on the routemap right after shaving only a few b
Good morning Subhra,
> - Myopic strategy: An adversary makes short-term gain by reverse-griefing
> but loses in the long term because of waiting time involved in earning the
> profit and also due to closure of channel.
>
> - Long-term strategy: If a strategy provides short term gain but incu
Good morning Subhra,
> > Can you describe this in more detail?
>
> Here is our proposal for mitigating reverse-griefing
> https://gist.github.com/subhramazumdar/cf7b043a73db136f6a23091d20e51751
> Looking forward to your comments.
Just to clarify my understanding, during the preprocessing stage
Good morning Subhra,
> There may be other issues as well with the overall setup, please wait, I
> am considering as well what would happen if we correctly establish the
> contracts from S to R.
Unfortunately the Mitigating Reverse-Griefing contract reintroduces griefing.
First, let us simp
Good morning Subhra,
> We had mentioned in the paper under Discussions (Section 6.3) that we do not
> handle attacks concerning soft-griefing, i.e., if a party withholds the
> preimage for a long time but releases just before the expiration of locktime.
> We think with the current set of instru
Good morning Rene,
Thank you for the report, this is good.
> 1. The current solution is to just not use up the max value of htlc's.
> Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from thi
Good morning all,
>
> Fee futures could help against this.
> I remember writing about this some time ago but cannot find where (not sure
> if it was in lightning-dev or bitcoin-dev).
`harding` found it:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
Regards,
Good morning Dave,
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a trans
Good morning again,
> Good morning Dave,
>
> > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> > hoping one of Bitcoin's several inventive cryptographers would come
> > along and describe how someone with an adaptor signature could use that
> > information to create a pubke
conomically more viable which
> > > relies on the same principle)
> >
> > Likely a bit more of fee bikeshedding is something we have to do to make LN
> > secure... Switching fee from pre-committed ones to a single-party, dynamic
> > one.
> >
> > >
Good morning Jeremy,
> My understanding is that you can use the CTV deferral to also get independent
> HTLC relative timelocks start points per output. This would help with this
> sort of issue right?
>
> And you're correct that there's overhead of indirection, but it's not super
> large (minim
Good morning Bastien,
> Thanks for the detailed write-up on how it affects incentives and
> centralization,
> these are good points. I need to spend more time thinking about them.
>
> > This is one reason I suggested using independent pay-to-preimage
> > transactions[1]
>
> While this works as a
Good morning Mr. Lee,
> Sorry. Re-sending with correction to CC bitcoin-dev
>
> I am sorry if this was already brought up in previous threads. If I know
> lightning network correctly then HTLC is used to enforce settlements on
> blockchain if there is a dispute. Could a person lose money if their
Good morning Ankit,
I believe what you describe is a specific form of what is called the Wormhole
attack.
In the general form, the Wormhole attack has two forwarding nodes in a path
that are coordinating with each other, and they can "teleport" the preimage
from one to the other, skipping inter
Good morning Laolu, and list,
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.
Due to the way `SIGHASH_ANYPREVOUT` will be deployed --- requires a new pubke
Good morning laolu,
> 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
Good morning Lightning world,
This was originally written for C-Lightning, hence the C-Lightning-isms, but I
realized the general principles were valid for all LN implementations.
---
First, let us consider some C-Lightning node who, for some reason, only has
unpublished channels to the networ
Good morning Lightning world,
A minor report from the MPP trenches.
One of the resources that the C-Lightning MPP implementation is hitting is the
limit on the number of HTLCs a channel can have.
For the 0.9.0 release, the initial consideration was that we can count the
number of channels with
Good morning Lightning world,
A minor report from the MPP trenches.
One of the resources that the C-Lightning MPP implementation is hitting is the
limit on the number of HTLCs a channel can have.
For the 0.9.0 release, the initial consideration was that we can count the
number of channels with
Good morning once again Lightningfolk,
An idea I have been entertaining is that rather than splitting payments by half
in case of an adaptive split, we should split in terms of a Fibonacci sequence.
Intuitively, if we split payments in half all the time, then it implies that we
have a set of "s
Good morning Antoine,
> Hi Roei,
> You might have a mechanism to lower trust in zero-conf channel opener.
> Actually the local party can be in charge of broadcasting the funding
> transaction, thus ensuring it's well-propagated across network mempools and
> then start to accept incoming payment
Good morning Lloyd,
I think this is excellent work overall.
With that said...
> - It is more elegant as there are half the number of possible transactions.
> I
> expect this will follow through to reduced implementation complexity and
> maybe
> make it easier to explain as well.
I
Good morning Antoine,
> Hi Zeeman,
>
> > i.e. I send my high-fee RBF-enabled channel funding to you, at the same
> > time I send a conflicting low-fee RBF-disabled transaction (that pays the
> > entire channel amount to myself) to all the miners I can find.
> Mapping miners mempools will be a co
Good morning LL, and other LNers...
Since we want to upgrade to Decker-Russell-Osuntokun in the future anyway, we
still need to solve this "simultaneous HTLC" problem.
So here is another cut at this, without the token-passing:
* Perform a coin toss whenever simultaneous HTLC offers occur.
* Typ
Good morning Christian, Nadav, and all,
>
> Escrow collusion
>
> -
>
> While not particularly familiar with SCU, I think the escrow might need
> to be ultimately trusted, since giving it the ability to act as
> co-signer in lieu of a subset of participants, or even sole signature
Good morning Bastien,
> Good morning list,
>
> It seems to me that the "funder pays all the commit tx fees" rule exists
> solely for simplicity
> (which was totally reasonable). I haven't been able to find much discussion
> about this decision
> on the mailing list nor in the spec commits.
Thi
Good morning Antoine, and Bastien,
> Instead of relying on reputation, the other alternative is just to have an
> upfront payment system, where a relay node doesn't have to account for a HTLC
> issuer reputation to decide acceptance and can just forward a HTLC as long it
> paid enough. More, I
Good morning Antoine, Bastien, and list,
> > Instead of relying on reputation, the other alternative is just to have an
> > upfront payment system, where a relay node doesn't have to account for a
> > HTLC issuer reputation to decide acceptance and can just forward a HTLC as
> > long it paid en
Good morning t-bast,
> Please forget about channel jamming, upfront fees et al and simply consider
> the parameters I'm
> mentioning. It feels to me that these are by nature dynamic channel
> parameters (some of them are
> even present in `channel_update`, but no-one updates them yet because dir
Good morning t-bast,
> Hey Zman,
>
> > raising the minimum payment size is another headache
>
> It's true that it may (depending on the algorithm) lower the success rate of
> MPP-split.
> But it's already a parameter that node operators can configure at will (at
> channel creation time),
> so IM
Good morning Joost,
I would like some clarifications on this mechanism.
> A. Prepayment: node pays an amount to its channel peer (for example via
> keysend) and the channel peer deducts the hold fees from that prepaid balance
> until it is at zero. At that point it somehow (in the htlc fail me
Good morning Joost,
> > > A. Prepayment: node pays an amount to its channel peer (for example via
> > > keysend) and the channel peer deducts the hold fees from that prepaid
> > > balance until it is at zero. At that point it somehow (in the htlc fail
> > > message?) communicates Lightning's ve
Good morning Joost,
> > * I convince Rene to make a channel to me.
>
> You may succeed, but Rene is probably not going to pay you a hold fee because
> you're untrusted.
Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene
relationships, not necessarily recouping these funds.
Good morning t-bast,
>
> I've started summarizing proposals, attacks and threat models on github [1].
> I'm hoping it will help readers get up-to-speed and avoid falling in the same
> pitfalls we already
> fell into with previous proposals.
Would my inane incremental routing idea also be in scop
Good morning t-bast,
> Sorry in advance for the lengthy email,
Come on, ZmnSCPxj writes lengthier.
> but I think it's worth detailing my hybrid proposal
> (bidirectional upfront payments), it feels to me like a workable solution
> that builds on
> previous proposals. You can safely ignore the d
Good morning t-bast,
> > And in this case C earns.
>
> > Can C delay the refund to D to after the grace period even if D settled the
> > HTLC quickly?
>
> Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent on
> anyone downstream.
> An honest D should settle the HTLC befo
Good morning Bastien,
> > C can trivially grief D here, making it look like D is delaying, by
> > delaying its own `commitment_signed` containing the *removal* of the HTLC.
>
> You're right to dive into these, there may be something here.
> But I think your example doesn't work, let me know if I'
Good morning Bastien, Joost, and all,
An issue with the bidirectional upfront/hold fees is related to trustless
offchain-to-onchain swaps, like Boltz and Lightning Loop.
As the claiming of the offchain side is dependent on claiming of the onchain
side of the trustless swap mechanism, which is *
Good morning t-bast,
> > An issue with the bidirectional upfront/hold fees is related to trustless
> > offchain-to-onchain swaps, like Boltz and Lightning Loop.
> > As the claiming of the offchain side is dependent on claiming of the
> > onchain side of the trustless swap mechanism, which is *de
Good morning laolu,
Thank you for your hard work!
Is there a documentation for the client/server intercommunications protocol?
How stable is this protocol?
A thought occurs to me:
* The payment of the lease effectively shifts risk from established forwarding
nodes to those purchasing incoming
Good morning laolu,
Sorry for the late reply.
> > A random, possibly-dumb idea is that a leased channel should charge 0 fees
> > initially.
> > Enforcing that is a problem, however, since channel updates are
> > unilateral, and of course the lessee cannot afford to close the channel it
> > leas
501 - 600 of 728 matches
Mail list logo
