Good morning mailing list, et al.,
Let me explain the various possible mitigations and their drawbacks.
Many of these are either "LSP trusts client" or "client trusts LSP", in the
sense that it is possible for the second mover (client in "LSP trusts client";
LSP in "client trusts LSP") to
Good morning Matt, and t-bast,
Your proposal basically means "do not dual-fund 0-conf".
You might as well use the much simpler openv1 flow in that case, just because
it is simpler.
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, May 9th,
Good morning benthecarman and SomberNight,
As noted by SomberNight, PTLCs does not quite fix this, as the client can still
wait out the inbound PTLC of the LSP and force the LSP to perform an onchain
action to ensure it does not give a channel for free.
Another wrinkle here is that the LSP can
Good morning t-bast, and list,
Dual-funded 0-conf can be made safe in the following case:
* If the initiator uses swap-in-potentiam addresses (with initiator as Alice,
acceptor as Bob).
If the initiator stalls, then the acceptor can retaliate by refusing to sign
the swap-in-potentiam UTXOs
Good morning list,
I would like to point out that one of the main issues with LSPs is that most of
them are designed to lock in their customers to their platform.
Hopefully, with a common open specification like this, it becomes significantly
more feasible for Lightning end-user clients to
Good morning again ariard and t-bast,
>
> For cases where the one doing splice-in is an LSP and the other side is a
> client of that LSP, also consider this proposal:
> https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24
>
> While it is designed for 0-conf channel funding, the actual
Hi ariard and t-bast,
I would like to point out that spends from swap-in-potentiam addresses are
safely 0-conf if Bob is the other signatory in the swap-in-potentiam address.
On the other hand swap-in-potentiam is arguably cheating, since sending to a
swap-in-potentiam address is actually a
Good morning 10k1,
> The use case is related to my work on Indranet, where channel sizes are going
> to be a lot lower than normal because they only have to transport very small
> payments (in the hundreds of sats at a time) and maintaining balance of the
> channels to keep them as much
Good morning 10k1,
> Currently, LN primarily uses 2 of 2 multisig channel, though I have heard
> people talk about opening channels in more complex transactions than 2 of 2
> multisigs.
>
> Thinking through all the topology and number theory aspects of it, I think
> that if channels were
Good morning all,
> > First of all let's see what types of reputation system exist (and yes,
> > this is my very informal categorization):
> >
> > - First hand experience
> > - Inferred experience
> > - Hearsay
> >
> > The first two are likely the setup we all are comfortable with: we ourselves
Good morning Laolu,
> Hi Z,
>
> > * Submarine swap/peerswap: Requires confirmation before the swap service
> > will send out the HTLC on Lightning.
>
> I might be missing something, but I don't see how this is different from a
> normal on-chain to off-chain swap (calling this Loop In for
Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning
by Jesse Posner, ZmnSCPxj
Introduction
Moving funds from an onchain-only address to Lightning Network is slow,
especially if you desire trust-minimization (which removes solutions
relying on 0-conf).
Good morning Antoine,
> About secondary-markets, the credentials themselves are subject to the
> classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
> both to Bob and Caroll, without any of them getting knowledge of the
> duplication. So it could be expected secondary
Good morning Antoin, Dave, et al.,
> Hi Dave,
>
> I think the issue you're describing about credential tampering by
> intermediary nodes is correct. If Alice controls Y along the path
> W->X->Y->Zed, she can waste the credentials value provided. Indeed, this
> issue generalizes for any
Good morning David,
> On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
>
> > If I am an LSP, and I know my competitor LSP distributes their
> > credentials, then I can simply apply to be a spoke on my competitor
> > and then make several payments to my n
Good morning Antoine,
> It should be noted, this current reputation-credential architectural
> framework assumes credentials distribution at the endpoint of the network.
> However, the framework should be flexible enough for the credentials to be
> harvested by the LSPs, and then distributed
Good morning list,
I saw elsewhere that there are plans to move peerswap to *two* hops, but no
further, as reliability is a concern.
The logic behind allowing up to two hops distance is that the two endpoints
know the state of the channels to the intermediate node.
But we should also consider
Good morning Joe,
> > Unfortunately, only the first sub-protocol (onchain-to-offchain)
> > is actually forwardable.
>
>
>
> I think it's possible to forward offchain-to-onchain swap as well, by
> just making a payjoin tx by net receiver (initiator) and net sender.
>
> Let me explain it in a
Good morning list,
I have also seen elsewhere someone expressing the idea that "rebalancing is not
exploitative, as the low-fee nodes are freely allowing use of their capacity at
low feerates".
First, let me make the strong claim that I am in fact a 100% human being, and
very specifically
Good morning list,
I saw elsewhere that there are plans to move peerswap to *two* hops, but no
further, as reliability is a concern.
The logic behind allowing up to two hops distance is that the two endpoints
know the state of the channels to the intermediate node.
But we should also consider
Good morning Joe,
> > Unfortunately, only the first sub-protocol (onchain-to-offchain)
> > is actually forwardable.
>
>
>
> I think it's possible to forward offchain-to-onchain swap as well, by
> just making a payjoin tx by net receiver (initiator) and net sender.
>
> Let me explain it in a
Introduction
First, a joke:
> Once upon a time, an economist and its friend, both of
> them being 100% human and not at all AIs out to take
> over the Bitcoin world, were walking on a street using
> 100% meat legs.
>
> They spotted a 1 Bitcoin Casascius coin on the street,
> and
Subject: Forwardable Peerswaps
Introduction
[Peerswap](https://peerswap.dev) is a protocol for swapping onchain funds
and offchain in-Lightning funds.
The intent of this protocol is to allow managing the inbound and outbound
capacities of your node without having to perform
Good morning aj,
> > Forwarding nodes sell liquidity.
> > If a forwarding node runs out of stock of liquidity (i.e. their channel is
> > unbalanced against the direction a payment request fails) they earn 0
> > profit.
>
>
> I get what you're saying, but I don't think a "stock of liquidity"
>
Good morning aj, Rene, and all,
So let me discuss a little more about how I model the forwarding nodes.
Forwarding nodes want to maximize profit.
Forwarding nodes sell liquidity.
If a forwarding node runs out of stock of liquidity (i.e. their channel is
unbalanced against the direction a
Good morning aj,
> > Basically, the intuition "small decrease in `htlc_max_msat` == small
> > decrease in payment volume" inherently assumes that HTLC sizes have a flat
> > distribution across all possible sizes.
>
>
> The intuition is really the other way around: if you want a stable,
>
Good morning again aj, and Rene,
> Good morning aj, and Rene,
>
> > * you're providing a way of throttling payment traffic independent of
> > fees -- since fees are competitive, they can have discontinuous effects
> > where a small change to fee can cause a large change to traffic volume;
> >
Good morning aj, and Rene,
> * you're providing a way of throttling payment traffic independent of
> fees -- since fees are competitive, they can have discontinuous effects
> where a small change to fee can cause a large change to traffic volume;
> but this seems like it should mostly have a
Good morning Dave,
> On 2022-09-13 11:15, lisa neigut wrote:
>
> > Hi all,
>
>
> Hi Lisa,
>
> Thank you for describing this idea in detail on the mailing list.
>
> > A ratecard is a set of four values, positive or negative, that price
> > different bands of available liquidity for a channel.
Good morning Martin,
> Hi folks,
>
> I think I've seen wallets supporting "send max" when a zero-amount invoice
> was used. So isn't it a problem with the custodial service not supporting it?
> Whatever idea we figure out they can just refuse to implement it so we can't
> force them into
Good morning Rene,
> Dear fellow Lightning Developers,
>
> I was recently on an event where the visitors have been gifted 10k sats on a
> custodial wallet. They could spend those sats via some web interface and an
> NFC card. During the event I was contacted by several plebs who were confused
Good morning Michael,
> Hey ZmnSCPxj
>
> It is an interesting topic. Alex Bosworth did a presentation at the Lightning
> Hack Day last year with a similar attempt at categorizing the different
> strategies for a routing/forwarding node (Ping Pong, Liquidity Battery,
> Inbound Sourcing,
Good morning aj,
> On Wed, Jun 29, 2022 at 12:38:17PM +, ZmnSCPxj wrote:
>
> > > > ### Inverting The Filter: Feerate Cards
> > > > Basically, a feerate card is a mapping between a probability-of-success
> > > > range and a feerate.
> > > > * 00%->25%: -10ppm
> > > > * 26%->50%: 1ppm
> > > >
Good morning aj,
> On Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote:
>
> Just sharing my thoughts on this.
>
> > Introduction
> >
> > Optimize for reliability+
&g
Good morning list,
This is a short (relative to my typical crap) writeup on some strategies that
Lightning forwarding nodes might utilize.
I have been thinking of various strategies that actual node operators (as I
understood from discussing with a few of them) use:
* Passive rebalance /
> ## Lightning Gossip
>
> # Gossip V2: Now Or Later?
> A proposal for the "re-design the entire thing" was floated in the past by
> Rusty [6]. It does away with the strict coupling of channels to channel
> announcements, and instead moves them to the _node_ level. Each node would
> then
Introduction
Bell Curve Meme (LEET ASCII ART SKILLZ)
Optimize for reliability+
uncertainty+fee+drain+uptime...
.--~~--.
/\
/ \
/\
/ \
Good morning devrandom,
It seems to me that a true validating Lightning signer would need to be a
Bitcoin node with active mitigation against eclipse attacks, the ability to
monitor the blockheight, and the ability to broadcast transactions.
Otherwise, a compromised node can lie and tell the
Good morning John,
Thank you for clarifying.
> Zman,
> I was not arguing for moving things from the edge, nor was I arguing to make
> Taro a BOLT. Laolu is misinterpreting my message.
> I was explaining that the capabilities that would allow Taro to interact with
> LN have no special
Good morning John, and Laolu,
> > but instead the requirement to add several feature concepts to LN that
> > would allow tokens to interact with LN nodes and LN routing:
>
> From this list of items, I gather that your vision is actually pretty
> different from ours. Rather than update the core
Good morning pushd,
> > Source routing means that Boltz Exchange can report your onchain address,
> > but cannot correlate it with your published node.
>
> I used boltz onion link:
> http://tboltzzrsoc3npe6sydcrh37mtnfhnbrilqi45nao6cgc6dr7n2eo3id.onion however
> I still need to trust boltz
Good morning pushd,
> Good morning,
>
> Things that affect privacy particularly when large sums of money are involved
> in bitcoin:
>
> Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime
> and Version
>
> I have left out things that aren't part of bitcoin protocol or
Good morning Rene, sorry for the lateness,
> Last but not least, please allow me to make a short remark on the (still to
> me very surprisingly controversial) base fee discussion: For simplicity I did
> not include any fee considerations to the published code (besides a fee
> report on how
Good morning Paul,
> I don't think I can stop people from being ignorant about Drivechain. But I
> can at least allow the Drivechain-knowledgable to identify each other.
>
> So here below, I present a little "quiz". If you can answer all of these
> questions, then you basically understand
Good morning lightning-dev and bitcoin-dev,
Recently, some dumb idiot, desperate to prove that recursive covenants are
somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caused
Paul Sztorc to [revive][1] and make the following statement:
> As is well known, it is easy for
Good morning Jeremy,
> opt-in or explicit tagging of fee account is a bad design IMO.
>
> As pointed out by James O'Beirne in the other email, having an explicit key
> required means you have to pre-plan suppose you're building a vault meant
> to distribute funds over many years, do you
Good morning DA,
> Agreed, you cannot rely on a replacement transaction would somehow
> invalidate a previous version of it, it has been spoken into the gossip
> and exists there in mempools somewhere if it does, there is no guarantee
> that anyone has ever heard of the replacement transaction
Good morning Peter and Jeremy,
> Good morning Peter and Jeremy,
>
> > On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote:
> >
> > > > Necromancing might be a reasonable name for attacks that work by
> > > > getting an
> > > > out-of-date version of a tx mined.
> > >
> > > It's not an
Good morning Peter and Jeremy,
> On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote:
>
> > > Necromancing might be a reasonable name for attacks that work by getting
> > > an
> > > out-of-date version of a tx mined.
> >
> > It's not an "attack"? There is no such thing as an out-of-date
Good morning shymaa,
> I just want to add an alarming info to this thread...
>
> There are at least 5.7m UTXOs≤1000 Sat (~7%),
> 8.04 m ≤1$ (10%),
> 13.5m ≤ 0.0001BTC (17%)
>
> It seems that bitInfoCharts took my enquiry seriously and added a main link
> for dust analysis:
>
Channel Eviction From Channel Factories By New Covenant Operations
==
N-of-N channel factories have an important advantage compared to N-of-N
offchain CoinPools or statechains: even if one participant in the channel
factory is
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?
Instead of a UTXO serving as a bond to allow advertisement of a *single*
channel, allow it to advertise *multiple* channels.
This does not
Good morning Ronan,
> If there is a payment to go from party A to be split between parties B & C,
> is it possible that only one of B or C would need a plugin?
>
> If all receiving parties need a plugin that is quite limiting. Thanks, Ronan
Given N payees, only N - 1 need the plugin.
The last
Good morning cdecker,
> I was looking into the docs [1] and stumbled over `createinvoice` which does
> almost what you need. However it requires the preimage, and stores the
> invoice in the database which you don't want.
Indeed, that is precisely the issue, we need a `signfakeinvoice`
Good morning William,
> Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
> it be, could it be done with a clightning plugin perhaps?
Probably not *yet*; it needs each intermediate payee (i.e. the one that is not
the last one) to sign an invoice for which it does not know
Good morning Bastien,
> * it's impossible for a node to prove that it did *not* receive a message:
> you can prove knowledge,
> but proving lack of knowledge is much harder (impossible?)
Yes, it is impossible.
If there could exist a proof-of-lack-of-knowledge, then even if I personally
Good morning t-bast,
> I believe these new transactions may require an additional round-trip.
> Let's take a very simple example, where we have one pending PTLC in each
> direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.
>
> Now A makes some unrelated updates and wants
Good morning LL, and t-bast,
> > Basically, if my memory and understanding are accurate, in the above, it is
> > the *PTLC-offerrer* which provides an adaptor signature.
> > That adaptor signature would be included in the `update_add_ptlc` message.
>
> Isn't it the case that all previous PTLC
Good morning t-bast,
Long ago:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html
And I quote:
>> A potential issue with MuSig is the increased number of communication rounds
>> needed to generate signatures.
>
>I think you can reduce this via an alternative
Good morning Jeremy,
> Just a minor curiosity I figured was worth mentioning on the composition of
> delegations and anyprevout...
>
> DA: Let full delegation be a script S such that I can sign script R and then
> R may sign for a transaction T.
> DB: Let partial delegation be a script S such
Good morning x raid,
> We are talkin interoperability among impl not individual node operators
> version management of chosen impl.
>
> where Pierre of Acinq says
> "So we eat our own dog food and will experience force closes before our users
> do.."
> hahaha made my day ...
>
> a node operator
Good morning x-raid,
> so You propose Acinq / Blockstream / Lightning Labs do not have funds to run
> a box or 2 ?
Not at all, I am proposing that these people, who have already done the effort
to release working Lightning Network Node implementations free of charge to
you, are not obligated
Good morning x-raid,
> what i can imagine is each team should provide boxes and channel liquidity as
> stake on mainnet for tests before announce a public realise as to feel the
> pain first hand instead of having several K´s of plebs confused and at worst
> have funds in channelclosed etc.
Good morning again x-raid,
Are you proposing as well to provide the hardware and Internet connection for
these boxes?
I know of one person at least who runs a node that tracks the C-Lightning
master (I think they do a nightly build?), and I run a node that I update every
release of
Good morning x-raid,
> I propose a dialog of the below joint effort ...
>
> thanks
> /xraid
>
> ***
> A decentralised integration lab where CL Eclair LDK LND (++ ?) runs each the
> latest release on "one box" rBOX and master.rc on "another box" rcBOX.
I believe Electrum also has its own bespoke
Good morning Dave,
> If LN software speculatively chooses a series of attempts with a similar
> 95%, accounting for things like the probability of a stuck payment (made
> worse by longer CLTV timeouts on some paths), it could present users
> with the same sort of options:
>
> ~1 second, x fee
>
Good morning Joost,
> What I did in lnd is to work with so called 'payment attempt cost'. A virtual
> satoshi amount that represents the cost of a failed attempt.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003191.html
And I quote:
> Introduction
>
>
>
Good morning again list,
>
> > We could use an identicon, we do that with the lightningnetwork repository.
> > An official logo is probably better - give the project a real symbol.
>
> I attached an SVG file I have been working on for some time, for the
> amusement of all.
>
> It is
Good morning list,
> We could use an identicon, we do that with the lightningnetwork repository.
> An official logo is probably better - give the project a real symbol.
I attached an SVG file I have been working on for some time, for the amusement
of all.
It is unfortunately not square, and
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,
> 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,
> 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 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 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 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 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 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 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 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 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 shymaa,
> The suggested idea I was replying to is to make all dust TXs invalid by some
> nodes.
Is this supposed to be consensus change or not?
Why "some" nodes and not all?
I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is
Good morning e,
> mostly thinking out loud
>
> suppose there is a "lightweight" node:
>
> 1. ignores utxo's below the dust limit
> 2. doesn't validate dust tx
> 3. still validates POW, other tx, etc.
>
> these nodes could possibly get forked - accepting a series of valid,
> mined
Introduction
In some direct discussions with me, ajtowns recently came up with a fairly
interesting perspective on implementing Fast Forwards, which I thought deserved
its own writeup.
The idea by aj is basically having two CSV-variant Spillman unidirectional
channels hosted by a
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
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 Joost,
> > > preimage = H(node_secret | payment_secret | payment_amount |
> > > encoded_order_details)
> > > invoice_hash = H(preimage)
> > >
> > > The sender sends an htlc locked to invoice_hash for payment_amount and
> > > passes along payment_secret and encoded_order_details in
Good morning again Joost,
> However, we can do "pay for signature" protocols using PTLCs, and rather than
> requesting for a scalar behind a point as the proof-of-payment, we can
> instead ask for a signature of a message that attests "this recipient got
> paid `payment_amount` with
Good morning Joost,
> It could be something like this:
>
> payment_secret = random
> preimage = H(node_secret | payment_secret | payment_amount |
> encoded_order_details)
> invoice_hash = H(preimage)
>
> The sender sends an htlc locked to invoice_hash for payment_amount and passes
> along
Good morning SomberNight,
> Good morning ZmnSCPxj,
>
> > > Solutions:
> > >
> > > 1. Naively, we could just derive a static key to be used as
> > > payment_basepoint, reused between all our channels, and watch the
> > > single resulting p2wsh script on-chain.
> > > Clearly this has
Good morning John Law,
> (at the expense of requiring an on-chain transaction to update
> the set of channels created by the factory).
Hmmm this kind of loses the point of a factory?
By my understanding, the point is that the set of channels can be changed
*without* an onchain transaction.
Good morning SomberNight,
> Solutions:
>
> 1. Naively, we could just derive a static key to be used as
> payment_basepoint, reused between all our channels, and watch the
> single resulting p2wsh script on-chain.
> Clearly this has terrible privacy implications.
If the only problem
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 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 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 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,
> 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 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,
> 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,
1 - 100 of 596 matches
Mail list logo
