Cezary Dziemian [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-10-08 to 2020-02-11
💬 Posted a total of 31 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:54:15

- reply

📅 Original date posted:2019-02-14
📝 Original message:
Hi,
Not sure if this topic was mentioned, but is there any plan to provide
payment solution in witch Payee pay fee instead of payer?
The issue I found is on our exchange, when user can withdraw funds using
LN. If we don't know fee in advance, he can't just withdraw everything what
he has. We can assume, that he can withdraw up to 99,5% of his funds, but
it would be nice, if he can just withdraw everything and what he receives
is just his funds minus fee.
Did you discussed this before?
Best Regards,
Cezary Dziemian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190214/9f774bee/attachment.html>

2023-06-09 12:54:15

- reply

📅 Original date posted:2019-02-19
📝 Original message:
Thanks for answer ZMNSCPxj,
Sad to hear that you have anything non LN-related to do that has higher
priority.
What, can't this this be done in easier way? For example:
1. Payee provides fee limit along with with Invoice. This can be amount
percentage or absolute value in msats.
2. Payer in order to pay just finds route, that do not exceed limit from
invoice
3. Payer just pays invoice
Solution above do not solve all issues, but at least it is easy to
implement and can be provided quite fast. I think, this is quite important,
because right now I see a lot of services that just cover fee costs, what
makes it easy to steal. I'm afraid that sooner or later someone will use
this method to steal some funds, what undermines LN confidence.
Best regards,
Cezary Dziemian
pt., 15 lut 2019 o 06:40 ZmnSCPxj <ZmnSCPxj at protonmail.com> napisał(a):
> Good morning Cezary,
>
> I have alluded to this issue before:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html
> See "Withdrawing funds from a service".
>
> From my point-of-view, the proper solution would involve the payee
> providing one or more complete paths from the payer to the payee node.
> These will be provided as fully encrypted onions to the payer, providing
> the following benefits:
>
> 1. The payee knows exactly how much it will lose in fees, since it is the
> one providing the path.
> 2. The payer cannot correlate a particular user with its LN node,
> improving privacy.
> 3. The payer cannot bias the route towards other nodes it controls that
> happen, completely for no good reason, to charge high LN fees; the payee
> generates the route and controls its fees.
>
> The use-case is where the payer is a publicly-useable service (an exchange
> as you gave example to).
> In this case, the payer provides its node address to the user, but the
> user never provides its node address to the service.
>
> There is no spec yet, and I am too busy with other considerations to
> actually work on anything Lightning-related, but perhaps you can pick up
> this, and continue its development.
>
> We need:
>
> 1. Some standard of transporting multiple *encrypted* onions from the
> user (payee) to the service (payer).
> 2. Some implementation must provide some method of generating multiple
> routes from the user (payee) to the service (payer).
> Importantly, this must compute "forwards", i.e. a constant amount will
> be released by the payer, and the payee will take whatever value remains
> after fees.
> This is more difficult than it seems due to how LN fees are computed,
> unfortunately (it is based on the outgoing amount; while mathematically it
> is possible to just manipulate the equations, in practice roundoffs will be
> different in some edge cases between the "backwards" and "forwards"
> methods).
> In addition, the implementation needs to have some heuristic, i.e. if
> it finds a route that loses more than 1% of the value being paid
> (overrideable by the user), then it probably should reject that route and
> not provide it to the service (payer).
>
> In essence, this issue shows the "other side" of merchants, which is
> exchanges.
> Current LN is biased towards merchants: the merchant exposes its node ID
> (on the invoice it provides to the user).
> For exchanges, we need to perform a dual transformation, where the
> exchange exposes its node ID somehow (via a mechanism that does not yet
> exist).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, February 14, 2019 10:06 PM, Cezary Dziemian <
> cezary.dziemian at gmail.com> wrote:
>
> > Hi,
> > Not sure if this topic was mentioned, but is there any plan to provide
> payment solution in witch Payee pay fee instead of payer?
> >
> > The issue I found is on our exchange, when user can withdraw funds using
> LN. If we don't know fee in advance, he can't just withdraw everything what
> he has. We can assume, that he can withdraw up to 99,5% of his funds, but
> it would be nice, if he can just withdraw everything and what he receives
> is just his funds minus fee.
> > Did you discussed this before?
> > Best Regards,
> > Cezary Dziemian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190219/e501c3ef/attachment.html>

2023-06-09 12:53:16

- reply

📅 Original date posted:2018-12-02
📝 Original message:
Hello guys,
I red BOLT. Do I understand correctly, that max_accepted_htlcs means that
for single channel there is possibility to have such amount of transactions
pending at the same time?
Best Regards,
Cezary Dziemian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181202/c5988f00/attachment.html>

2023-06-09 12:49:02

- reply

📅 Original date posted:2018-02-11
📝 Original message:
That would be great improvement, if AMP could work this way:
1. I would like to send 0.1 BTC, so I split this to 5 payment 0.02 BTC each
+ one extra 0.02 BTC payment.
2. When recipient received 6 htlcs, he is able to spend only 5 of them.
If recipient receives, only 5 of them, it is still fine, and payment is
success.
In such scenario, single route/payment would fail, and payment as whole
would still be success. Do you think that would be possible? It could
greatly increase reliability of LN payments.
2018-02-09 11:15 GMT+01:00 CJP <cjp at ultimatestunts.nl>:
> Can you give a use case for this?
>
> Usually, especially in the common case that a payment is done in
> exchange for some non-cryptographic asset (e.g. physical goods), there
> already is some kind of trust between payer and payee. So, if a payment
> is split non-atomically into smaller transactions, and only a part
> succeeds, presumably they can cooperatively figure out some way to
> settle the situation.
>
> I spoke to people of the "interledger" project, and what they are
> planning to do is to non-atomically split *every* transaction into lots
> of micro-payments. In fact, they consider it unnecessary to enforce
> HTLCs with scripts, because their amounts are so small(*). If one
> micro-payment fails, that just makes them learn that a certain channel
> is unreliable, and they'll send further payments (and even the remaining
> part of the same payment) through a different route.
>
> CJP
>
> (*) not worth the extra on-blockchain fee due to the increased tx size.
>
> Olaoluwa Osuntokun schreef op di 06-02-2018 om 05:26 [+0000]:
> > Hi Y'all,
> >
> >
> > A common question I've seen concerning Lightning is: "I have five $2
> > channels, is it possible for me to *atomically* send $6 to fulfill a
> > payment?". The answer to this question is "yes", provided that the
> > receiver
> > waits to pull all HTLC's until the sum matches their invoice.
> > Typically, one
> > assumes that the receiver will supply a payment hash, and the sender
> > will
> > re-use the payment hash for all streams. This has the downside of
> > payment
> > hash re-use across *multiple* payments (which can already easily be
> > correlated), and also has a failure mode where if the sender fails to
> > actually satisfy all the payment flows, then the receiver can still
> > just
> > pull the monies (and possibly not disperse a service, or w/e).
> >
> >
> > Conner Fromknecht and I have come up with a way to achieve this over
> > Lightning while (1) not re-using any payment hashes across all payment
> > flows, and (2) adding a *strong* guarantee that the receiver won't be
> > paid
> > until *all* partial payment flows are extended. We call this scheme
> > AMP
> > (Atomic Multi-path Payments). It can be experimented with on Lightning
> > *today* with the addition of a new feature bit to gate this new
> > feature. The beauty of the scheme is that it requires no fundamental
> > changes
> > to the protocol as is now, as the negotiation is strictly *end-to-end*
> > between sender and receiver.
> >
> >
> > TL;DR: we repurpose some unused space in the onion per-hop payload of
> > the
> > onion blob to signal our protocol (and deliver some protocol-specific
> > data),
> > then use additive secret sharing to ensure that the receiver can't
> > pull the
> > payment until they have enough shares to reconstruct the original
> > pre-image.
> >
> >
> >
> >
> > Protocol Goals
> > ==============
> > 1. Atomicity: The logical transaction should either succeed or fail in
> > entirety. Naturally, this implies that the receiver should not be
> > unable to
> > settle *any* of the partial payments, until all of them have arrived.
> >
> >
> > 2. Avoid Payment Hash Reuse: The payment preimages validated by the
> > consensus layer should be distinct for each partial payment.
> > Primarily,
> > this helps avoid correlation of the partial payments, and ensures that
> > malicious intermediaries straddling partial payments cannot steal
> > funds.
> >
> >
> > 3. Order Invariance: The protocol should be forgiving to the order in
> > which
> > partial payments arrive at the destination, adding robustness in the
> > face of
> > delays or routing failures.
> >
> >
> > 4. Non-interactive Setup: It should be possible for the sender to
> > perform an
> > AMP without directly coordinating with the receiving node.
> > Predominantly,
> > this means that the *sender* is able to determine the number of
> > partial
> > payments to use for a particular AMP, which makes sense since they
> > will be
> > the one fronting the fees for the cost of this parameter. Plus, we can
> > always turn a non-interactive protocol into an interactive one for the
> > purposes of invoicing.
> >
> >
> >
> >
> > Protocol Benefits
> > =================
> >
> >
> > Sending pay payments predominantly over an AMP-like protocol has
> > several
> > clear benefits:
> >
> >
> > - Eliminates the constraint that a single path from sender to
> > receiver
> > with sufficient directional capacity. This reduces the pressure to
> > have
> > larger channels in order to support larger payment flows. As a
> > result,
> > the payment graph be very diffused, without sacrificing payment
> > utility
> >
> >
> > - Reduces strain from larger payments on individual paths, and
> > allows the
> > liquidity imbalances to be more diffuse. We expect this to have a
> > non-negligible impact on channel longevity. This is due to the
> > fact that
> > with usage of AMP, payment flows are typically *smaller* meaning
> > that
> > each payment will unbalance a channel to a lesser degree that
> > with one giant flow.
> >
> >
> > - Potential fee savings for larger payments, contingent on there
> > being a
> > super-linear component to routed fees. It's possible that with
> > modifications to the fee schedule, it's actually *cheaper* to send
> > payments over multiple flows rather than one giant flow.
> >
> >
> > - Allows for logical payments larger than the current maximum value
> > of an
> > individual payment. Atm we have a (temporarily) limit on the max
> > payment
> > size. With AMP, this can be side stepped as each flow can be up
> > the max
> > size, with the sum of all flows exceeding the max.
> >
> >
> > - Given sufficient path diversity, AMPs may improve the privacy of
> > LN
> > Intermediaries are now unaware to how much of the total payment
> > they are
> > forwarding, or even if they are forwarding a partial payment at
> > all.
> >
> >
> > - Using smaller payments increases the set of possible paths a
> > partial
> > payment could have taken, which reduces the effectiveness of
> > static
> > analysis techniques involving channel capacities and the plaintext
> > values being forwarded.
> >
> >
> >
> >
> > Protocol Overview
> > ==================
> > This design can be seen as a generalization of the single,
> > non-interactive
> > payment scheme, that uses decoding of extra onion blobs (EOBs?) to
> > encode
> > extra data for the receiver. In that design, the extra data includes a
> > payment preimage that the receiver can use to settle back the payment.
> > EOBs
> > and some method of parsing them are really the only requirement for
> > this
> > protocol to work. Thus, only the sender and receiver need to implement
> > this
> > feature in order for it to function, which can be announced using a
> > feature
> > bit.
> >
> >
> > First, let's review the current format of the per-hop payload for each
> > node
> > described in BOLT-0004.
> >
> >
> > ┌───────────────┬───────────────────┬────────────────┬──────
> ─────────────────┬─────────────────┬─────────────────┐
> > │Realm (1 byte) │Next Addr (8 bytes)│Amount (8 bytes)│Outgoing CLTV (4
> > bytes)│Unused (12 bytes)│ HMAC (32 bytes) │
> > └───────────────┴───────────────────┴────────────────┴──────
> ─────────────────┴─────────────────┴─────────────────┘
> > ■───────────────────────────────────────────────────────────
> ─────────────────────────────────────────────────────■
> > ┌─────────────────┐
> > │65 Bytes Per Hop │
> > └─────────────────┘
> >
> >
> > Currently, *each* node gets a 65-byte payload. We use this payload to
> > give
> > each node instructions on *how* to forward a payment. We tell each
> > node: the
> > realm (or chain to forward on), then next node to forward to, the
> > amount to
> > forward (this is where fees are extracted by forwarding out less than
> > in),
> > the outgoing CLTV (allows verification that the prior node didn't
> > modify any
> > values), and finally an HMAC over the entire thing.
> >
> >
> > Two important points:
> > 1. We have 12 bytes for each hop that are currently unpurposed and
> > can be
> > used by application protocols to signal new interpretation of bytes
> > and
> > also deliver additional encrypted+authenticated data to *each* hop.
> >
> >
> > 2. The protocol currently has a hard limit of 20-hops. With this
> > feature
> > we ensure that the packet stays fixed sized during processing in
> > order to
> > avoid leaking positional information. Typically most payments won't
> > use
> > all 20 hops, as a result, we can use the remaining hops to stuff in
> > *even
> > more* data.
> >
> >
> >
> >
> > Protocol Description
> > ====================
> > The solution we propose is Atomic Multi-path Payments (AMPs). At a
> > high
> > level, this leverages EOBs to deliver additive shares of a base
> > preimage,
> > from which the payment preimages of partial payments can be derived.
> > The
> > receiver can only construct this value after having received all of
> > the
> > partial payments, satisfying the atomicity constraint.
> >
> >
> > The basic protocol:
> >
> >
> > Primitives
> > ==========
> > Let H be a CRH function.
> > Let || denote concatenation.
> > Let ^ denote xor.
> >
> >
> >
> >
> > Sender Requirements
> > ===================
> > The parameters to the sending procedure are a random identifier ID,
> > the
> > number of partial payments n, and the total payment value V. Assume
> > the
> > sender has some way of dividing V such that V = v_1 + … + v_n.
> >
> >
> > To begin, the sender builds the base preimage BP, from which n partial
> > preimages will be derived. Next, the sender samples n additive shares
> > s_1,
> > …, s_n, and takes the sum to compute BP = s_1 ^ … ^ s_n.
> >
> >
> > With the base preimage created, the sender now moves on to
> > constructing the
> > n partial payments. For each i in [1,n], the sender deterministically
> > computes the partial preimage r_i = H(BP || i), by concatenating the
> > sequence number i to the base preimage and hashing the result.
> > Afterwards,
> > it applies H to determine the payment hash to use in the i’th partial
> > payment as h_i = H(r_i). Note that that with this preimage derivation
> > scheme, once the payments are pulled each pre-image is distinct and
> > indistinguishable from any other.
> >
> >
> > With all of the pieces in place, the sender initiates the i’th payment
> > by
> > constructing a route to the destination with value v_i and payment
> > hash h_i.
> > The tuple (ID, n, s_i) is included in the EOB to be opened by the
> > receiver.
> >
> >
> > In order to include the three tuple within the per-hop payload for the
> > final
> > destination, we repurpose the _first_ byte of the un-used padding
> > bytes in
> > the payload to signal version 0x01 of the AMP protocol (note this is a
> > PoC
> > outline, we would need to standardize signalling of these 12 bytes to
> > support other protocols). Typically this byte isn't set, so the
> > existence of
> > this means that we're (1) using AMP, and (2) the receiver should
> > consume the
> > _next_ hop as well. So if the payment length is actually 5, the sender
> > tacks
> > on an additional dummy 6th hop, encrypted with the _same_ shared
> > secret for
> > that hop to deliver the e2e encrypted data.
> >
> >
> > Note, the sender can retry partial payments just as they would normal
> > payments, since they are order invariant, and would be
> > indistinguishable
> > from regular payments to intermediaries in the network.
> >
> >
> >
> >
> > Receiver Requirements
> > =====================
> >
> >
> > Upon the arrival of each partial payment, the receiver will
> > iteratively
> > reconstruct BP, and do some bookkeeping to figure out when to settle
> > the
> > partial payments. During this reconstruction process, the receiver
> > does not
> > need to be aware of the order in which the payments were sent, and in
> > fact
> > nothing about the incoming partial payments reveals this information
> > to the
> > receiver, though this can be learned after reconstructing BP.
> >
> >
> > Each EOB is decoded to retrieve (ID, n, s_i), where i is the unique
> > but
> > unknown index of the incoming partial payment. The receiver has access
> > to
> > persistent key-value store DB that maps ID to (n, c*, BP*), where c*
> > represents the number of partial payments received, BP* is the sum of
> > the
> > received additive shares, and the superscript * denotes that the value
> > is
> > being updated iteratively. c* and BP* both have initial values of 0.
> >
> >
> > In the basic protocol, the receiver cache’s the first n it sees, and
> > verifies that all incoming partial payments have the same n. The
> > receiver
> > should reject all partial payments if any EOB deviates. Next, the we
> > update
> > our persistent store with DB[ID] = (n, c* + 1, BP* ^ s_i), advancing
> > the
> > reconstruction by one step.
> >
> >
> > If c* + 1 < n, there are still more packets in flight, so we sit
> > tight.
> > Otherwise, the receiver assumes all partial payments have arrived, and
> > can
> > being settling them back. Using the base preimage BP = BP* ^ s_i from
> > our
> > final iteration, the receiver can re-derive all n partial preimages
> > and
> > payment hashes, using r_i = H(BP || i) and h_i = H(r_i) simply through
> > knowledge of n and BP.
> >
> >
> > Finally, the receiver settles back any outstanding payments that
> > include
> > payment hash h_i using the partial preimage r_i. Each r_i will appear
> > random
> > due to the nature of H, as will it’s corresponding h_i. Thus, each
> > partial
> > payment should appear uncorrelated, and does not reveal that it is
> > part of
> > an AMP nor the number of partial payments used.
> >
> >
> > Non-interactive to Interactive AMPs
> > ===================================
> >
> >
> > Sender simply receives an ID and amount from the receiver in an
> > invoice
> > before initiating the protocol. The receiver should only consider the
> > invoice settled if the total amount received in partial payments
> > containing
> > ID matches or exceeds the amount specified in the invoice. With this
> > variant, the receiver is able to map all partial payments to a
> > pre-generated
> > invoice statement.
> >
> >
> >
> >
> > Additive Shares vs Threshold-Shares
> > ===================================
> >
> >
> > The biggest reason to use additive shares seems to be atomicity.
> > Threshold
> > shares open the door to some partial payments being settled, even if
> > others
> > are left in flight. Haven’t yet come up with a good reason for using
> > threshold schemes, but there seem to be plenty against it.
> >
> >
> > Reconstruction of additive shares can be done iteratively, and is win
> > for
> > the storage and computation requirements on the receiving end. If the
> > sender
> > decides to use fewer than n partial payments, the remaining shares
> > could be
> > included in the EOB of the final partial payment to allow the sender
> > to
> > reconstruct sooner. Sender could also optimistically do partial
> > reconstruction on this last aggregate value.
> >
> >
> >
> >
> > Adaptive AMPs
> > =============
> >
> >
> > The sender may not always be aware of how many partial payments they
> > wish to
> > send at the time of the first partial payment, at which point the
> > simplified
> > protocol would require n to be chosen. To accommodate, the above
> > scheme can
> > be adapted to handle a dynamically chosen n by iteratively
> > constructing the
> > shared secrets as follows.
> >
> >
> > Starting with a base preimage BP, the key trick is that the sender
> > remember
> > the difference between the base preimage and the sum of all partial
> > preimages used so far. The relation is described using the following
> > equations:
> >
> >
> > X_0 = 0
> > X_i = X_{i-1} ^ s_i
> > X_n = BP ^ X_{n-1}
> >
> >
> > where if n=1, X_1 = BP, implying that this is in fact a generalization
> > of
> > the single, non-interactive payment scheme mentioned above. For
> > i=1, ...,
> > n-1, the sender sends s_i in the EOB, and X_n for the n-th share.
> >
> >
> > Iteratively reconstructing s_1 ^ …. ^ s_{n-1} ^ X_n = BP, allows the
> > receiver to compute all relevant r_i = H(BP || i) and h_i = H(r_i).
> > Lastly,
> > the final number of partial payments n could be signaled in the final
> > EOB,
> > which would also serve as a sentinel value for signaling completion.
> > In
> > response to DOS vectors stemming from unknown values of n,
> > implementations
> > could consider advertising a maximum value for n, or adopting some
> > sort of
> > framing pattern for conveying that more partial payments are on the
> > way.
> >
> >
> > We can further modify our usage of the per-hop payloads to send
> > (H(BP), s_i) to
> > consume most of the EOB sent from sender to receiver. In this
> > scenario, we'd
> > repurpose the 11-bytes *after* our signalling byte in the unused byte
> > section
> > to store the payment ID (which should be unique for each payment). In
> > the case
> > of a non-interactive payment, this will be unused. While for
> > interactive
> > payments, this will be the ID within the invoice. To deliver this
> > slimmer
> > 2-tuple, we'll use 32-bytes for the hash of the BP, and 32-bytes for
> > the
> > partial pre-image share, leaving an un-used byte in the payload.
> >
> >
> >
> >
> > Cross-Chain AMPs
> > ================
> >
> >
> > AMPs can be used to pay a receiver in multiple currencies
> > atomically...which
> > is pretty cool :D
> >
> >
> >
> >
> > Open Research Questions
> > =======================
> >
> >
> > The above is a protocol sketch to achieve atomic multi-path payments
> > over
> > Lightning. The details concerning onion blob usage serves as a
> > template that
> > future protocols can draw upon in order to deliver additional data to
> > *any*
> > hop in the route. However, there are still a few open questions before
> > something like this can be feasibly deployed.
> >
> >
> > 1. How does the sender decide how many chunked payments to send, and
> > the
> > size of each payment?
> >
> >
> > - Upon a closer examination, this seems to overlap with the task of
> > congestion control within TCP. The sender may be able to utilize
> > inspired heuristics to gauge: (1) how large the initial payment
> > should be
> > and (2) how many subsequent payments may be required. Note that if
> > the
> > first payment succeeds, then the exchange is over in a signal
> > round.
> >
> >
> > 2. How can AMP and HORNET be composed?
> >
> >
> > - If we eventually integrate HORNET, then a distinct communications
> > sessions can be established to allow the sender+receiver to
> > exchange
> > up-to-date partial payment information. This may allow the sender
> > to more
> > accurately size each partial payment.
> >
> > 3. Can the sender's initial strategy be governed by an instance of the
> > Push-relabel max flow algo?
> >
> >
> > 4. How does this mesh with the current max HTLC limit on a commitment?
> >
> >
> > - ATM, we have a max limit on the number of active HTLC's on a
> > particular
> > commitment transaction. We do this, as otherwise it's possible
> > that the
> > transaction is too large, and exceeds standardness w.r.t
> > transaction
> > size. In a world where most payments use an AMP-like protocol,
> > then
> > overall ant any given instance there will be several pending
> > HTLC's on
> > commitments network wise.
> >
> >
> > This may incentivize nodes to open more channels in order to
> > support
> > the increased commitment space utilization.
> >
> >
> >
> >
> > Conclusion
> > ==========
> >
> >
> > We've presented a design outline of how to integrate atomic multi-path
> > payments (AMP) into Lightning. The existence of such a construct
> > allows a
> > sender to atomically split a payment flow amongst several individual
> > payment
> > flows. As a result, larger channels aren't as important as it's
> > possible to
> > utilize one total outbound payment bandwidth to send several channels.
> > Additionally, in order to support the increased load, internal routing
> > nodes
> > are incensed have more active channels. The existence of AMP-like
> > payments
> > may also increase the longevity of channels as there'll be smaller,
> > more
> > numerous payment flows, making it unlikely that a single payment comes
> > across unbalances a channel entirely. We've also showed how one can
> > utilize
> > the current onion packet format to deliver additional data from a
> > sender to
> > receiver, that's still e2e authenticated.
> >
> >
> >
> >
> > -- Conner && Laolu
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180211/27d3755e/attachment-0001.html>

2023-06-09 12:48:25

- reply

📅 Original date posted:2018-01-11
📝 Original message:
I made issue 5 days ago: https://github.com/lightningnetwork/lnd/issues/564
2018-01-11 0:21 GMT+01:00 Olaoluwa Osuntokun <laolu32 at gmail.com>:
>
> Hi Cezary,
>
> I invite you to make an issue on lnd's issue tracker: https://github.com/
> lightningnetwork/lnd/issues. This list isn't the place for support
> requests/features for individual implementations.
>
> On Tue, Jan 9, 2018 at 5:21 AM Cezary Dziemian <cezary.dziemian at gmail.com>
> wrote:
>
>> Good news, thanks.
>>
>> Do Lightning Labs also have plan to introduce this soon? I prefer to stay
>> with lnd, as we already know this implementation better, but if this option
>> will not be introduced soon, we have to switch to use c-lightning.
>>
>> Cheers,
>> Cezary
>>
>> 2018-01-09 5:31 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
>>
>>> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
>>> writes:
>>>
>>> > Good morning Cezary,
>>> >
>>> > Currently, c-lightning can PAY amountless invoices via the "pay"
>>> command, but cannot CREATE them via the c-lightning "invoice" command.
>>>
>>> Good point, I've filed an issue for this, so we don't lose it:
>>>
>>> https://github.com/ElementsProject/lightning/issues/534
>>>
>>> > To pay an amountless invoice lntb... 4 satoshis in c-lightning:
>>> lightning-cli pay lntb.. 4000
>>>
>>> Note that I'd prefer the "msatoshi" field to be a magic string
>>> (eg. "any") rather than omitting the parameter, since it's too easy for
>>> a bug to omit the parameter.
>>>
>>> Cheers,
>>> Rusty.
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180111/c3982401/attachment.html>

2023-06-09 12:48:24

- reply

📅 Original date posted:2018-01-06
📝 Original message:
Hello,
It looks "amount" is optional for invoice:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
The issue is I cannot generate such invoice using lnd. This is very
important for what we are tryiong to do with LN. Can you confirm, that
value will be optional for LN invoice.
Or at least, thet there is some other way to send payment when sender
specifies amount.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180106/d7a97460/attachment.html>

2023-06-09 12:48:24

- reply

📅 Original date posted:2018-01-09
📝 Original message:
Good news, thanks.
Do Lightning Labs also have plan to introduce this soon? I prefer to stay
with lnd, as we already know this implementation better, but if this option
will not be introduced soon, we have to switch to use c-lightning.
Cheers,
Cezary
2018-01-09 5:31 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
> writes:
>
> > Good morning Cezary,
> >
> > Currently, c-lightning can PAY amountless invoices via the "pay"
> command, but cannot CREATE them via the c-lightning "invoice" command.
>
> Good point, I've filed an issue for this, so we don't lose it:
>
> https://github.com/ElementsProject/lightning/issues/534
>
> > To pay an amountless invoice lntb... 4 satoshis in c-lightning:
> lightning-cli pay lntb.. 4000
>
> Note that I'd prefer the "msatoshi" field to be a magic string
> (eg. "any") rather than omitting the parameter, since it's too easy for
> a bug to omit the parameter.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180109/8620ec4c/attachment.html>

2023-06-09 12:47:36

- reply

📅 Original date posted:2017-11-03
📝 Original message:
Thank you very much for answers. It is honor that you answered and it is
also very important for us in Poland. My friend is building Bitcoin ATMs
and off-course plan to use LN. BTW: In Poland a lot of people believe that
LN is the next big thing. We have huge pro-LN community and even have LN
whitepaper translated to polish.
So for 1.1 such scenario will not be possible?:
We have such network with such payment channel opened:
Hub A
/ \
Payer Merchant
\ /
Hub B
Hub A and Hub B belong to the same person, who will try to cheat us. Now
Payer try to send payment through Hub A to Merchant. Hub A updates HTLC
contract with Payer for this payment but never updates HTLC contract to
Merchant so payment cannot be processed and is "pending". Because payer see
that payment is pending, tries to make payment using Hub B based on the
same invoice. After Marchant reveals secret number to Hub B, Hub A also can
use it to steal funds from first pending payment.
2017-11-03 2:20 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> Somewhat, but not that low, because you still need a margin to turn
> around payments.
>
How big this margin would be? If we have crypto with 5 seconds block
confirmation time, how big such timelocks could be? I quess it is hard to
answer precisely, but could you give at least estimated value?
Best Regards,
Cezary
2017-11-03 12:25 GMT+01:00 Johan Torås Halseth <johanth at gmail.com>:
> I think this might have been discussed somewhere, sometime before:
> couldn’t we add an lightning parameter to the bitcoin: url, making the QR
> codes backwards compatible?
>
> - Johan
>
> On Fri, Nov 3, 2017 at 2:20, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> Hi Cezary,
>
> This is indeed the right place for such questions at the moment.
>
> Cezary Dziemian <cezary.dziemian at gmail.com> writes:
> > 1. After LN starts, some group of users will use it, other not. If for
> > example, I would like to receive payment for coffee from some user, I
> don't
> > know if user uses LN or not. So, when someone buy something from me, do I
> > need to ask him what kind of payment he would like to use (LN or
> on-chain)?
> > The best would be, if I show him some qr code contains both public
> address
> > and LN invoice and his wallet could choose how to pay. But this cannot be
> > done this way, right?
>
> Yes, the transition is kind of painful. You can use a BOLT 11 QR code,
> which can contain a fallback address, but that still requires their app
> understand BOLT11 enough to extract it.
>
> If they understand the BIP70 payment protocol, it could include an
> alternate payment mechanism, but it seems nobody actually uses this.
>
> > 2. Lets imagine, that someone send me invoice. I send payment and someone
> > in the middle doesn't cooperate fast. My payment is waiting and until
> time
> > lock period lapse I don't know if my payment will be processed or not.
> What
> > to do then?
>
> This is the worst case, yes. It's actually two cases: one where the
> payment has failed, and one where it has succeeded and you don't know
> yet.
>
> If it's succeeded you'll get your goods (the recipient sees nothing
> wrong), so you don't care that you have to wait for the money to be
> deducted.
>
> If it hasn't, it's almost certainly going to fail, and you can either
> wait or try again with a new invoice (your wallet won't let to pay the
> same one twice unless it's definitely failed). For 1.1 you'd be able to
> reuse the same invoice safely, as long as the merchant was honest if it
> received two payments and rejects the second.
>
> > 3. Am I right that this decremental time lock is strongly related with
> > block confirmation time? If there would be currency that have very fast
> > confirmation time (like 5 seconds) then time lock period could be short
> > what can potentially solve problem described in paragraph 2?
>
> Somewhat, but not that low, because you still need a margin to turn
> around payments. In practice, if payments are so unreliable that you
> have to worry about this case, then something's horribly wrong!
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171104/141ab6d5/attachment-0001.html>

2023-06-09 12:47:35

- reply

📅 Original date posted:2017-11-01
📝 Original message:
Hello,
I'm a big fan of LN technology for over than one year. I have few questions
and I thing this group is the best place to ask them. Would be great if
some of you could find few minutes to answer them.
1. After LN starts, some group of users will use it, other not. If for
example, I would like to receive payment for coffee from some user, I don't
know if user uses LN or not. So, when someone buy something from me, do I
need to ask him what kind of payment he would like to use (LN or on-chain)?
The best would be, if I show him some qr code contains both public address
and LN invoice and his wallet could choose how to pay. But this cannot be
done this way, right?
2. Lets imagine, that someone send me invoice. I send payment and someone
in the middle doesn't cooperate fast. My payment is waiting and until time
lock period lapse I don't know if my payment will be processed or not. What
to do then?
3. Am I right that this decremental time lock is strongly related with
block confirmation time? If there would be currency that have very fast
confirmation time (like 5 seconds) then time lock period could be short
what can potentially solve problem described in paragraph 2?
Best Regards,
Cezary Dziemian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171102/235e9dd9/attachment.html>