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 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 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 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 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 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 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 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
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 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
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 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 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 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 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,
> > 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,
> - 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
> 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
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
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
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 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,
> 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 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 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 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 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 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 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 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 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 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 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
; > > >
> > > > >
> > > > > On Mon, Apr 13, 2020, 08:21 ZmnSCPxj wrote:
> > > > >
> > > > > > Good morning Subhra,
> > > > > >
> > > > > > > Hello,
> > > > > > > So
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
> > > 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
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
> >
> >
> >
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
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,
> 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 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,
> 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,
> 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 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,
> 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
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,
> 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
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,
> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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
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 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
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 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 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 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 t-bast,
> > This is relevant if we ever want to hide the node id of the last node: Bob
> > could provide a symmetric
> > encryption key to all its peers with unpublished channels, which the peer
> > can XOR with its own true
> > node id and use the lowest 40 bits (or 46 bits or 58
Good morning Rusty,
> Bastien TEINTURIER bast...@acinq.fr 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
Good morning darosior,
> Hi ZmnSCPxj,
>
> Using joinmarket's PoDLEs is a great idea, and it seems preferable to using a
> transaction chain with a distinguishable SIGHASH.
>
> Just a naive question, what is described in
> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-
Good morning darosior, ariard, niftynei, and list,
> We could also consider PoDLE as used in JoinMarket, which solves a similar
> problem.
> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
> Basically, a PoDLE co
Good morning darosior,
> Hi Lisa and all,
>
> Given the discussion about utxos snooping, I wondered if there was any
> obvious drawbacks of using a transaction chain construction ?
>
> Since the obvious target of the probing is the accepter, it seems that the
> opener needs to at least have so
Good morning Matt,
Thread-hijack...
> route-hijacks (aka someone providing routing for a lower fee
> and users happily taking it)
I observe that this is something of a catch-22.
If users *notice* lower fees and go to lower-fee channels, then route-hijacking
is possible and surveillors can pay
Good morning Subhra,
> So introducing proof of knowledge of fund locked instead of revealing the
> amount of fund locked by counterparties will introduce added complexity while
> routing but how effective is this going to be against handling attacks like
> hijacking of routes and channel exhaus
Good morning Subhra,
The paper does not describe how Lightning works today, so I was confused.
It seems to claim to have a constant *lock time*, but still a decrementing
*amount*, across the entire payment attempt.
In any case: any offchain updateable cryptocurrency system can host any
contract
Good morning list,
> Good morning David, and list,
>
> It seems to me possible (though potentially undesirable) to have a "maximally
> private" channel that uses only absolute locktimes.
>
> For maximum privacy, you would need to sign new pairs of commitment
> transactions at every block anyway.
Good morning Subhra,
This does not seem to make sense?
For a payment that is less than the channel funds on your side, only that
amount is locked behind an HTLC, and the rest remains useable for other HTLCs.
What exactly are you referring to?
Regards,
ZmnSCPxj
> Hi,
> I was wondering when
Good morning David, and list,
It seems to me possible (though potentially undesirable) to have a "maximally
private" channel that uses *only* absolute locktimes.
For maximum privacy, you would need to sign new pairs of commitment
transactions at every block anyway.
And if you sign a new pair "t
Good morning Subhra,
Refer to this protocol instead of DLAS:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html
In this protocol, an *encrypted* form of the *entire file* is sent.
Consequently, a *single* payment is made, where the payment preimage is the
decryption
Good morning list,
Few people have responded to this topic, but when has that ever stopped me from
spamming the mailinglist?
Analysis of Path Extension for Privacy
==
As mentioned before, increasing the path length deliberately, by any means,
intuitively mak
Good morning ZmnSCPxj,
>
> > It need not store the whole state: for example, it could store just a
> > commitment to the current state (and have the software store the entire
> > state).
> > In fact, it is best for the hardware to store the signature for the
> > commitment transaction:
>
> I wo
Good morning list,
I have been thinking of this for some time without really getting any good
results, and in any case [this C-Lightning mailing list
post](https://lists.ozlabs.org/pipermail/c-lightning/2019-December/000172.html)
brings up similar topic.
As well, 0 or more people have asked me
Good morning David,
> On Tue, Jan 07, 2020 at 12:26:05AM +, ZmnSCPxj wrote:
>
> > For `nSequence` relative-locktime transactions that protect the
> > security of the channel mechanism, these are used in unilateral
> > closes. The issue is that a unilateral close might occur far, far in
> > th
Good morning,
Another point regarding the use of "purely scriptless" (i.e. using pre-signed
`nLockTime` and `nSequence`d transactions) is that there are significantly more
signatures to be generated cooperatively.
We need to use MuSig for these in order to hide in the much larger 1-of-1
anonymi
Good morning again Rene,
An observation I would like to make is that, as I understand it, the model
inherently assumes that all nodes are equally likely to be payer and equally
likely to be payee.
While in a complete economy this is to be expected (the "customer" of a
"merchant" will be an "em
Good morning Rene,
I am glad my question has triggered such interest from you!
I will confess that I do not yet understand the math you demonstrated and have
not seen your program at all yet.
It is a good thing as well that it can be used to derive routehints for
invoices.
I do have a follow-u
Good morning Subhra,
> Is there any literature available on how protocols would get affected in
> presence of Byzantine nodes ?
I am unaware of such.
In any case, when considering Byzantine faults, a Byzantine fault occurs where
one node appears functional to some subset of the the system, bu
Good morning Rene, and list,
It seems to me that the rule used here might be useful to guide how to split a
payment for multipath as well.
For example, consider the case where a payer Alice has channels to Bob and
Charlie.
* Alice-Bob has A=0.5, B=0.5
* Alice-Charlie has A=0.5, C=0.5
In that
Good morning David,
> On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote:
>
> > Hi ZmnSCPxj and Aj,
> > Thanks for starting this discussion ZmnSCPxj. Although transactions with
> > relative lock times are easily distinguishable today, couldn't this
> > situation be improved? Even just
201 - 300 of 728 matches
Mail list logo
