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
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 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
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.
*
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
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
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
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
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.
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
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
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 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
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
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
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
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 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
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
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.
> >
> > > Independently I think we should have a hint in our readme file a
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
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
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
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
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
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
Good morning Andres, t-bast, Gleb, et al,
> > But instead it could be a point-to-point property: each node provides its
> > own stake certificate
> > to the next node (and only to that node). Alice provides a stake
> > certificate to Bob, then Bob
> > provides a stake certificate to Carol, and
Good morning Joao and Bastien,
I believe the `feeadjuster` plugin for C-Lightning, created by Darosior,
already does what you want to do, without a specs change.
* We already know that nodes prefer low-fee routes over high-fee routes.
* `feeadjuster` adjusts our channel feerate according to
Good morning LL,
> > > > I suspect part of the proof-of-discrete-log-equivalance can be gated as
> > > > well by a ZKCP on payment point+scalar the proof is provided only on
> > > > payment.
> > > > The selling node operator does not even need to reveal `z`.
> > >
> > > Actually no -- the fact
Good morning LL,
> > I suspect part of the proof-of-discrete-log-equivalance can be gated as
> > well by a ZKCP on payment point+scalar the proof is provided only on
> > payment.
> > The selling node operator does not even need to reveal `z`.
>
> Actually no -- the fact that you were able to
Good morning LL,
> > > - What do you do if the channel state has HTLCs in flight? I don't know
> > > -- I guess you can just put them onto the settlement tx? That way it's
> > > possible the payment could still go through. Alternatively you could just
> > > gift the money to the party
Good morning LL,
> - What do you do if the channel state has HTLCs in flight? I don't know -- I
> guess you can just put them onto the settlement tx? That way it's possible
> the payment could still go through. Alternatively you could just gift the
> money to the party offering the recovery
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
> >
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
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
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
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
Good morning LL, and happy new year as well,
> # Signaling Transactions
>
> Finally I present a simple but unintuitive protocol that achieves roughly the
> same properties as the PoDLE protocol but without lightning gossip messages.
>
> Whenever the initiator adds an input in the interactive
Good morning LL,
> Hi Z,
>
> I agree with your analysis. This is how I pictured eltoo fast forwards
> working as well.
>
> Another interesting thing about this idea is that it could allow a new type
> of custodial LN provider where the custodian is only in charge of receiving
> payments to the
Good morning LL,
> Hi Z,
>
> Thanks again for getting to the bottom of this. I think we are on the same
> page except for one clarification:
>
> On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote:
>
>
> > Thus, in our model, we have the property that Bob can always recover all
> > signatures sent
Good morning LL and Lee,
> Hi Lee,
>
> You are touching on some very relevant privacy challenges for lightning. To
> your questions:
>
> 1. Is it possible to identify which node funded a lightning channel? (this
> tells you who owns the change output)
> 2. Is it possible to identify who owns
Good morning LL,
> Hi Z,
>
> I just went through the presentation which made your thinking very clear.
> Thanks.
> I will not be able to match this effort so please bear with me as I try and
> explain my own thinking.
> I don't see why fast forwards (FF) need "symmetrically encumbered outputs"?
Good morning again LL,
So I started thinking as well, about Decker-Russell-Osuntokun and the Fast
Forwards technique, as well as your "desync" idea.
And it seems to me that we can also adapt a variant of this idea with
Decker-Russell-Osuntokun, with the advantage of **not** requiring the
Good morning list,
Note that there is a possible jamming attack here.
More specifically, when "failing" an incoming HTLC, the receiver of the HTLC
sends its signature for a transaction spending the HTLC and spending it back to
the sender revocable contract.
The funds cannot be reused until the
Good morning list,
I have decided to dabble in necromancy, thus, I revive this long-dead thread
from two years ago.
Ph34R mE and my leet thread necromancy skillz.
A short while ago, LL and Steve Lee were discussing about ways to reduce the
privkey onlineness requirement for Lightning.
And LL
Good morning LL,
> Hey Z,
>
> Thanks for your analysis. I agree with your conclusion. I think the most
> practical approach is the "ask first" 3 round protocol.
>
> Another option is to have `remote_penaltyclaimpubkey` owned by the node
> instead of the hardware device.
> This allows funds to
Good morning list,
> It may be difficult to understand this, so maybe I will make a convenient
> presentation of some sort.
As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp
The presentation is intended to be seen by semi-technical and technical people,
particular
Good morning Rusty et al,
> Matt Corallo lf-li...@mattcorallo.com 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
Good morning again CAsey,
>
> I believe a major failing of Chaumian mints is that they are, at their core,
> inherently custodial.
> The mint issues blinded minted coins in exchaange for people handing over
> other resources to their custody.
> While the mint itself cannot identify who owns how
Good morning VzxPLnHqr,
This certainly seems workable.
I first encountered similar ideas when people were asking about how to
implement a vending machine with Lightning, with the vending machine being
offline and not having any keys.
The idea was to have the vending machine record
Good morning VzxPLnHqr,
> Dear ZmnSCPxj,
>
> Thank you for your reply. I see how the vending machine can be mapped into
> the Courier role. There are some questions around how to extend this to a
> multi-courier situation, but let us solve that problem later and further
> discuss the nuances
Good morning Casey,
I believe a major failing of Chaumian mints is that they are, at their core,
inherently custodial.
The mint issues blinded minted coins in exchaange for people handing over other
resources to their custody.
While the mint itself cannot identify who owns how much, it can
Good morning lisa,
> A dedicated attacker could probably figure out your UTXO set, but that's not
> much different from the current system; the only difference is the span of
> time
> it takes them to figure it out.
>
> ## Things We've Done to Counter This:
> I had the pleasure of finally
Good morning elsirion,
> Hi ZmnSCPxj,
>
> let me chime in here, I've been working on federated mint for quite some time
> now but only recently began talking about it more publicly.
>
> > WabiSabi "simply" replaces blinded signatures with blinded credentials.
> > Blinded signatures are fairly
Good morning Joost,
Not quite up-to-speed back into this, but, I believe an issue with using
feerates rather than fixed fees is "what happens if a channel is forced
onchain"?
Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
forced onchain, and the blockchain is
Good morning Nadav and Andres,
Thank you for bringing up this topic again.
Let me provide a new twist to this old idea.
This is the entire logic of the contract to the seller:
SELLER && (BUYER || ESCROW)
Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||` which
is
Good morning Pedro,
> Hi Nadav,
>
> You are right that the intermediary (i.e., Ingrid) needs to hold a certain
> amount of coins to allow the virtual channel between Alice and Bob. Some
> comments here:
> - The protocol makes sure that Ingrid will get paid whatever fee she decides
> to charge
Good morning Andres,
> This looks cool but would hinder UX too much for certain scenarios: e.g. if
> the escrow in place is part of a bitcoin exchange, then you require the
> bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
> users (which could maybe only have fiat).
Good morning aj, and list,
> Note that Bob could abort the protocol with a winning bet before
> requesting the payout from Carol -- he already has enough info to prove
> he's won and claim Carol isn't paying him out at this point.
> One way of dealing with this is to vet Bob's claim by sending
Good morning Joost,
> > Not quite up-to-speed back into this, but, I believe an issue with using
> > feerates rather than fixed fees is "what happens if a channel is forced
> > onchain"?
> >
> > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
> > forced onchain, and
Good morning Nadav, and list,
>
> More generally, all Boolean logic can be converted to one of two standard
> forms.
>
> - sum-of-products i.e. `||` over `&&`
> - product-of-sums i.e. `&&` over `||`
>
> For example an XOR can be converted to the sum-of-products form:
>
> A ^ B = (!A
Good morning Nadav, and list,
>
> More generally, all Boolean logic can be converted to one of two standard
> forms.
>
> - sum-of-products i.e. `||` over `&&`
> - product-of-sums i.e. `&&` over `||`
>
> For example an XOR can be converted to the sum-of-products form:
>
> A ^ B = (!A
Good morning Andres,
> > > Is there any disadvantage about using dual-hash HTLCs?
> > > Is it supported by the current LN spec?
> >
> > It is no supported by current LN spec, and PTLCs are overall superior (they
> > are equivalent to having any number of hashes, not just 2 that dual-hash
> >
Good morning Nadav,
> Hey ZmnSCPxj,
>
> Your earlier post about how to accomplish ORing points without verifiable
> encryption was super interesting.
>
> I think this contains a clever general NOT operation where you double the
> payment and use the point as a condition for the "cancellation
Good morning Andres,
> Hey ZmnSCPxj,
>
> On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote:
>
> > Good morning Andres,
> >
> > > This looks cool but would hinder UX too much for certain scenarios: e.g.
> > > if the escrow in place is part of a bitcoin exchange, then you require
> > > the bitcoin
Good morning lisa, aj, et al.,
> The result is that micropayments have a different payment regime than
> “non-micropayments”, (which may still incentive almost irrational behavior)
> but at least there’s no *loss* felt by node operators for handling/supporting
> low value payments. 10k
Good morning matt and aj,
Let me cut in here.
>From my reading of the actual paper --- which could be a massive
>misunderstanding, as I can barely understand half the notation, I am more a
>dabbler in software engineering than a mathist --- it seems to me that it
>would be possible to replace
Good morning Orfeas,
> Such an approach is much more suitable to debian, since they have
> full control and a complete view over their "network" of packages, as opposed
> to LN, which is decentralized, nodes come and go at will and they can be
> private (even from developers!).
Good morning Stefan,
> > For myself, I think a variant of Pickhardt-Richter payments can be created
> > which adapts to the reality of the current network where `base_fee > 0` is
> > common, but is biased against `base_fee > 0`, can be a bridge from the
> > current network with `base_fee > 0`
Good morning Matt and all,
> Please be careful accepting the faulty premise that the proposed algorithm is
> “optimal”. It is optimal under a specific heuristic used to approximate what
> the user wants. In reality, there are a ton of different things to balance,
> from CLTV to feed to
Good morning list,
It seems to me that the cost function defined in Pickhard-Richter
can in fact include a base fee:
-log(success_probability) + fudging_factor * amount * prop_fee +
fudging_factor * base_fee
(Rant: why do mathists prefer single-symbol var names, in software
engineering
Good morning Stefan,
> Good Morning Zmn!
>
> If you'd like to understand the min-cost flow problem and algorithms better,
> I would really recommend the textbook we have been citing throughout the
> paper.
>
> The algorithm you have found has a few shortcomings. It'll only work for the
>
Good morning aj and Rene,
> On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev
> wrote:
>
> > As we thought it was obvious that the function is not linear we only
> > explained
> > in the paper how the jump from f(0)=0 to f(1) = ppm+base_fee breaks
> > convexity.
>
>
Good morning Stefan,
> >I propose that the algorithm be modified >as such, that is, it *ignore* the
> >fee scheme.
>
> We actually started out thinking like this in the event we couldn't find a
> proper way to handle fees, and the real world experiments we've done so far
> have only involved
Introduction
As use of Lightning grows, we should consider delegating more and more tasks to
programs.
Classically, decisions on *where* to make channels have been given to
"autopilot" programs, for example.
However, there remain other tasks that would still appreciate delegation
Good morning Rusty,
> ZmnSCPxj zmnsc...@protonmail.com 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"
Good morning Jeremy,
> one interesting point that came up at the bitdevs in austin today that favors
> remove that i believe is new to this discussion (it was new to me):
>
> the argument can be reduced to:
>
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust
Subject: Fee Budgets: A Possible Path Towards Unified Cost Functions For
Lightning Pathfinding Problems
Introduction
What is the cost of a failed LN payment?
Presumably, if a user wants to pay in exchange for something,
that user values that thing higher than the Bitcoin they
Good morning Daki,
While certainly a very imaginative approach to the problem, do note that there
is a substantive difference between running a Bitcoin fullnode and running a
Lightning forwarding node.
Namely:
* A Bitcoin fullnode does not risk any lockup of its funds just to run.
* A
Good morning aj, et al.
> Hey *,
>
> There's been discussions on twitter and elsewhere advocating for
> setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing
> this to summarise my understanding in a place that's able to easily be
> referenced later.
>
> Setting the base fee to
Good morning Stefan,
> Hi Zmn! That is some amazing lateral thinking you have been applying there.
> I'm quite certain I haven't understood everything fully, but it has been
> highly entertaining to read. Will have to give it a closer read when I get
> some time.
>
> As a first impression,
Good morning Gijs,
> To circumvent the saturated channel D-C, C creates the route C->A->D,
> where node D supports rendezvous routing. C can create a sub-route
> from D to E and treat it as a partial route-to-payee under rendezvous
> routing by using the hop payload found when unwrapping the
Good morning Billy, et al.,
> For sure, CT can be done with computational soundness. The advantage of
> unhidden amounts (as with current bitcoin) is that you get unconditional
> soundness.
My understanding is that it should be possible to have unconditional soundness
with the use of El-Gamal
Good morning all,
Thinking a little more, if the dust limit is intended to help keep UTXO sets
down, then on the LN side, this could be achieved as well by using channel
factories (including "one-shot" factories which do not allow changing the
topology of the subgraph inside the factory, but
Introduction
Lightning provides proof-of-payment for standard forms of payment, but does not
provide it for keysend or non-high hash-based AMP.
Let us consider, then, what exactly a proof-of-payment even *is*.
Lamport Signatures
==
One of the earliest
Good morning Prayank,
> Hello everyone,
>
> I wanted to know few things related to asset issuance on lightning:
>
> 1.Is it possible to issue assets on LN right now? If yes, what's the process
> and is it as easy as few commands in liquid:
>
Good morning Matt,
> 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,
Good morning Matt,
> On 10/13/21 02:58, ZmnSCPxj wrote:
>
> > Good morning Matt,
> >
> > > 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.
Good morning aj,
> On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
>
> > ### Scorched earth punishment
> >
> > Another thing that I'd like to mention is that using revocable signatures
> > enables scorched earth punishments [2].
>
> I kind-of think it'd be more interesting to
Good morning Joost,
> A potential downside of a dedicated probe message is that it could be used
> for free messaging on lightning by including additional data in the payload
> for the recipient. Free messaging is already possible today via htlcs, but a
> probe message would lower the cost to
Good morning Joost,
> On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote:
>
> > Good morning Joost,
> >
> > > A potential downside of a dedicated probe message is that it could be
> > > used for free messaging on lightning by including additional data in the
> > > payload for the recipient. Free
Good morning Joost,
> There could be some corners where the incentives may not work out 100%, but I
> doubt that any routing node would bother exploiting this. Especially because
> there could always be that reputation scheme at the sender side which may
> cost the routing node a lot more in
Good morning Owen,
> C now notes that B is lying, but is faced with the dilemma:
>
> "I could either say 'no' because I can plainly see that B is lying, or
> I could say 'yes' and get some free sats from the failed payment (or
> via the hope of a successful payment from a capacity increase in the
Good morning Owen,
> On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
>
> > So how would things work out with a combination of both of the
> > proposals described in this mail? First we make probing free (free as
> > in no liquidity locked up) and then we'll require senders to pay for
Good morning Pieter,
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's
> consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically
> irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules
Good morning aj,
> On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
>
> > A transaction is required, but I believe it is not necessary to put it
> > onchain (at the cost of implementation complexity in the drop-onchain case).
>
> The trick with that is that if you don't put it on chain,
Good morning aj,
> In order to transition from BOLT#3 format to this proposal, an onchain
> transaction is required, as the "revocable signatures" arrangement cannot
> be mimicked via the existing 2-of-2 CHECKMULTISIG output.
A transaction is required, but I believe it is not
Good morning Prayank,
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
>
> Still trying to understand this problem and possible solutions. Interesting
> email though (TIL), thanks for sharing the link. Found related things
> explained Suredbits blog as
Good morning list,
While discussing something tangentially related with aj, I wondered this:
> Why do we shoot an HTLC first and then ask the question "can you actually
> resolve this?" later?
Why not something like this instead?
* For a payer:
* Generate a path.
* Ask first hop if it can
401 - 500 of 600 matches
Mail list logo
