Corné Plooy [ARCHIVE]

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

Public Key

npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6n

Profile Code

nprofile1qqs0j2xp52z0mkmrpmfr42etle5cz9pr5k05rhvv8eqv27u3d7ad7egd66hmj

Author Public Key

npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6n

Show more details

Last Notes

2023-06-09 12:56:51

- reply

📅 Original date posted:2019-10-25
📝 Original message:
Rusty,
At the recently held Lightning Conference in Berlin you asked for people
to send you use cases / feature requests for the next-generation
Lightning invoicing. I already did some work on this back in 2018; that
work was interrupted when I started working on other ideas. I believe
CDecker is member of some W3C(?) commission on payments, so he may also
have ideas on this.
My earlier work focused on an interactive protocol for direct
communication between payer and payee. This is an old sketch / WIP:
https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
I know some people don't like such interaction, but it does make many
things easier to accomplish, e.g. rendez-vous routing and stuckless
payments.
For now, without doing an actual technology proposal, I'd like to share
a way of thinking about payer/payee interaction.
In my view, a transaction is not a line, it's a circle. Bitcoins go from
payer to payee over the Lightning network, and whatever
assets/goods/services are paid for go from payee to payer - this closes
the circle. Transactions on all hops of the circle should be atomic.
Between Lightning hops this is realized with HTLCs. For the payer-payee
hop this is generally not possible, as non-cryptographic things
generally don't allow you to construct HTLCs on them. Invoices and
proofs of payment act as cryptographic representatives of
non-cryptographic entities.
In a generalized view, the interaction between payer and payee can be
seen as a virtual payment channel. Full refunds, partial refunds, update
of what goods are to be delivered (which may depend on an additional
payment or a partial refund), sending back delivered goods (with
refund), are all updates to this virtual channel. Desirable properties
of such a channel:
* The channel has a state, and that state can be updated.
* A state update invalidates the previous state.
* By default, a state update requires consent of both parties. We may
include a feature where, in the previous state, one party gives consent
to allow the other party to unilaterally perform certain types of state
updates.
* A state update may require a payment of a certain amount in one
direction or in the opposite direction. The state update only becomes
valid in combination with the corresponding proof of payment.
* The state specifies obligations of parties to each other (e.g. "A
shall return <delivered goods> back to B").
* A state can be "final" in the sense that there should be no more
updates in the future. This may not need to be enforced by software or
by protocol: it can simply be by convention. If the "final" state
requires consent of both parties for an update, any participant can make
it final by never signing an update, or even by throwing away the
private key used for the channel.
The state updating mechanism and its properties require special
attention. I think the purpose of the channel is to aid in conflict
resolution - it should provide evidence of what is agreed between both
parties. There is nothing in an old state that makes it inherently
invalid: in fact, at some point in the past it was valid. The only thing
that makes it invalid is the presence of a later version. To reveal the
truth in conflict resolution, it is necessary that
(1) the latest state is revealed
(2) it is clear that this latest state is more recent than all other
states that are revealed
I hope that (1) is likely incentive-wise: typically, incentives of the
parties are each other's opposite, so either one party has an interest
in revealing an update, or the other party has. I haven't worked out
this thought very rigorously though.
I think a bit of cryptography can help with (2). One idea is to include
sequence numbers in states, another is to include the hash of the
previous state. Either way, the possibility remains (cryptographically,
maybe not incentive-wise) to mess up the evidence by "forking" the
channel: making multiple state updates that have the same parent state.
This may be resolved semantically, with rules like "if A unilaterally
makes a fork, and both sides are revealed, B may choose which side of
the fork is to be considered valid".
Some advanced ideas
* Contracts between three or more parties.
* Merging and joining of contracts in state updates
CJP

2023-06-09 12:56:44

- reply

📅 Original date posted:2019-10-25
📝 Original message:
Cool: non-source rendez-vous routing. Getting closer to 2013 Amiko Pay,
with the added experience of 2019 Lightning with Sphinx routing and AMP.
https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf
(esp. section 2.1.3)
Please forgive the use of the term "Ripple". 2013 was a different time.
CJP
On 22-10-19 14:01, Bastien TEINTURIER wrote:
> Good morning everyone,
>
> Since I'm a one-trick pony, I'd like to talk to you about...guess
> what? Trampoline!
> If you watched my talk at LNConf2019, I mentioned at the end that
> Trampoline enables high AMP very easily.
> Every Trampoline node in the route may aggregate an incoming
> multi-part payment and then decide on how
> to split the outgoing aggregated payment. It looks like this:
>
> .-------- 1mBTC --------. .------- 2mBTC -------.
> / \ /
> \
> Alice ----- 3mBTC ------> Ted ------ 4mBTC ----> Terry ----- 6mBTC
> ----> Bob
> \ /
> `------- 2mBTC ----------'
>
> In this example, Alice only has small-ish channels to Ted so she has
> to split in 3 parts. Ted has good outgoing
> capacity to Terry so he's able to split in only two parts. And Terry
> has a big channel to Bob so he doesn't need
> to split at all.
> This is interesting because each intermediate Trampoline node has
> knowledge of his local channels balances,
> thus can make more informed decisions than Alice on how to efficiently
> split to reach the next node.
>
> But it doesn't stop there. Trampoline also enables a better
> rendez-vous routing than normal payments.
> Christian has done most of the hard work to figure out how we could do
> rendez-vous on top of Sphinx [1]
> (thanks Christian!), so I won't detail that here (but I do plan on
> submitting a detailed spec proposal with all
> the crypto equations and nice diagrams someday, unless Christian does
> it first).
>
> One of the issues with rendez-vous routing is that once Alice (the
> recipient) has created her part of the onion,
> she needs to communicate that to Bob (the sender). If we use a Bolt 11
> invoice for that, it means we need to
> put 1366 additional bytes to the invoice (plus some additional
> information for the ephemeral key switch).
> If the amount Alice wants to receive is big and may require
> multi-part, Alice has to decide upfront on how to split
> and provide multiple pre-encrypted onions (so we need 1366 bytes /per
> partial payment/, which kinda sucks).
>
> But guess what? Bitcoin Trampoline fixes that*™*. Instead of doing the
> pre-encryption on a normal onion, Alice
> would do the pre-encryption on a Trampoline onion (which is much
> smaller, in my prototype it's 466 bytes).
> And that allows rendez-vous routing to benefit from
> Trampoline's ability to do multi-part at each hop.
> Obviously since the onion is smaller, that limits the number of
> trampoline hops that can be used, but don't
> forget that there are additional "normal" hops between each Trampoline
> node (and the final Trampoline spec
> can choose the size of the Trampoline onion to enable a good enough
> rendez-vous).
>
> Here is what it would look like. Alice chooses to rendez-vous at
> Terry. Alice wants the payment to go through Terry
> and Teddy so she pre-encrypts a Trampoline onion with that route:
>
> Alice <--- Teddy <--- Terry
>
> She creates a Bolt 11 invoice containing that pre-encrypted onion. Bob
> picks up that invoice and can either reach
> Terry directly (via a normal payment route) or via another Trampoline
> node (Toad?). Bob finalizes the encryption of
> the Trampoline onion and sends it onward. Bob can use multi-part and
> split the payment however he wishes,
> because every Trampoline node in the route will be free to aggregate
> and re-split differently.
> Terry is the only intermediate node to know that rendez-vous routing
> was used. Terry doesn't learn anything about
> Alice because the payment still needs to go through Teddy. Teddy only
> learns that this is a Trampoline payment, so
> he doesn't know his position in the Trampoline route (especially since
> he doesn't know that rendez-vous was used).
>
> I believe this makes rendez-vous routing reasonable to implement: the
> trade-offs aren't as strong as in the normal
> payment case. If I missed something (maybe other issues related to the
> current rendez-vous proposal) please let me know.
>
> Of course Trampoline itself also has trade-offs that in some cases may
> impact privacy (e.g. when paying to legacy nodes
> that don't understand the Trampoline onion). This is why Eclair is
> currently implementing it to identify all the places where
> it falls short, so that we can then leverage the community's amazing
> brain power to converge on a spec that everyone is
> happy with and that minimizes the trade-offs we need to make. Stay
> tuned for more information and updates to the spec PR
> once we make progress on our Trampoline experiments.
>
> Thank you for reading this, don't hesitate to throw ideas and/or
> criticize this proposal.
> Note that all the cryptographic details are left as an exercise to the
> reader.
>
> Bastien
>
> [1] https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:53:48

- reply

📅 Original date posted:2019-01-08
📝 Original message:
True, as soon as this measure gets implemented (which AFAIK is not the
case right now). However, the attack is not free.
The victim interfaces between two different Lightning networks, each
operating a different asset, possibly on a different block chain (so
that proof of channel closuse on one side cannot be understood on the
other side) or even using a completely different technology. The problem
of the victim arises when an exchange transaction arrives from network
A, the victim forwards it on network B, and then the transaction gets
stalled. The victim can demand a proof that something went wrong on
network B, but cannot propagate that proof on network A. Since the
victim cannot propagate a valid proof, the victim will be penalized on
network A.
My point is: the victim can still demand a proof that something went
wrong on network B. To stall the transaction, the attacker must be
controlling the node on network B that is doing the stalling. The same
anti-spam measure that penalizes the victim on network A *also*
penalizes the attacking node on network B.
The penalties may not be the same: maybe on-chain fees are much lower on
chain B than on chain A. Still, the anti-spam measure should somewhat
reduce the attractiveness of this attack.
CJP
On 08-01-19 06:11, Rusty Russell wrote:
> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
>> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network
> Interesting. FWIW, I believe that multi-asset LN will fail for a
> related, but different reason: to prevent long-lived spam payments we
> may require proof that something went wrong (ie. channel unilateral
> close tx). That won't be valid if it's from a different network,
> resulting in the exchange point itself being penalized. Thus they are
> vulnerable to such a DoS.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:53:47

- reply

📅 Original date posted:2019-01-08
📝 Original message:
ZmnSCPxj,
Without reading your proposed solution, I don't understand the problem
you describe here:
> David solution effectively makes the exchange node (OM in CJP terminology) also the RM in the route.
> However, with use of mere preimages and hashes, it is obvious that such a "loop" where the end payee (RM) is also an intermediate node, is foolish, as the end payee will simply claim the payment without letting the loop through.
> And since the payee (S in CJP terminology) is paid via the delta from its incoming to its outgoing HTLC on that loop, then if the RM is the OM then it is possible for the OM To simply steal the payment outright.
>
> (It is helpful to realize that payment routes pay not just the end payee, but all hops in the middle; thus the "real" target of the payment (the one who receives the bulk of the value) need not be at the *end* of the route)
All hops on the route are linked together the same way as hops in a
regular Lightning payment. An intermediate node who is also the end
payee, and therefore knows the preimage, can indeed shortcut the payment
by accepting the payment on the intermediate node instead of forwarding
it; this is true for all Lightning payments [*].
I think the scenario where "the bulk of the value" ends up at one or
more intermediate nodes should not typically apply here. With a
sufficiently low spread and fees, the bulk of the value should be
roughly the same on each hop. The only thing that might be stolen is in
those fees and exchange rate differences.
By design, OT will pay the fees, so its outgoing amount will be higher
than the incoming amount. RM will not want to exclude OT from its route.
If RM is OM, then RM cannot exclude OM from the route either.
Effectively, you end up with a RM-OT-RM route, which is OK if RM is OM.
Minimizing Lightning route length to minimize fees is not a bad thing.
There is a remaining issue though, that if RM is OM, then, obviously, RM
and OM can cooperate to perform a delay attack on OT. I think this is
acceptable, given that in section 4 of my paper[1] I already described
some countermeasures OT can take. I think the attack possibility is
wider: if OT and OM are anonymous / pseudonymous toward each other, then
RM can either be OM and attack OT, or it can be OT and attack OM. I
argued in section 4 that OM is more vulnerable than OT, but luckily the
assumptions to this argument do not apply anymore. OM knows the
attacker: it is RM. RM can perform a single attack on OM, and after
that, OM will refuse incoming exchange transactions that are coordinated
by RM.
So my proposal is not perfect, it does contain the trusted role RM, and
participants have to be somewhat careful which RMs they do business
with. However, it does have the benefit of de-coupling the trusted role
RM from the actual trading roles of OT and OM, so you only need to trust
a few parties and you can trade with lots of parties. Trading parties
can remain anonymous to RM, and they can hide from RM what second asset
they are trading, and to what exchange rate, so there's very little that
can be censored by RM.
CJP
[*] So it is a vulnerability for the idea where you anonymously donate
to an intermediate node by giving it a huge fee. The vulnerability does
not apply if you are the final payee, since nobody else but the final
payee can perform the attack. Other parties might control multiple nodes
on the route, but they only learn the preimage after HTLC acceptance on
all hops.
[1] https://bitonic.nl/public/slowdown_prevention.pdf

2023-06-09 12:53:20

- reply

📅 Original date posted:2018-12-06
📝 Original message:
> * layer 0 (to B): decorrelation_secret = k[b]
> * layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b]
I would have less trouble understanding that if it were layer 1 (to C)
instead of (to B).
> The total_decorrelation_secrets serves as the payer-generated shared secret between payer and payee.
> B cannot learn this, and thus cannot fake its own secret.
> Even if it instead offers ((I + K[A]) + k[z] * G) for a new secret k[z], it cannot know how to change total_decorrelation_secrets from k[a] + k[b] to k[a] + k[z] instead.
>
The way things are now, the ephemeral key generation and the payment
hash/preimage generation are completely unrelated. This is what allows
an attacker to use the same payment hash, and use his own ephemeral key
pair to create a new onion packet around it.
Primarily, path decorrelation replaces the payment hash/preimage part.
Maybe I still don't understand something, but if that's the only thing
(without changing the ephemeral key / onion shared secret generation),
attacking the direct neighbor should still work; in your case, B would
still offer ((I + K[A]) + K[B]) to C, with an onion packet B created
himself. I'm not familiar enough with the path correlation to understand
what happens after step 6, but for C it looks the same, so she should do
the same.
I do see that, if you couple the "H"TLC payment secret generation to the
onion shared secret generation, you can make the attack impossible. Do I
understand correctly that this is the idea? After all, C still needs to
receive k somehow; my crypto math isn't that good, but my intuitive
guess is that i + k is the secret that allows C to claim funds locked in
((I + K[A]) + K[B]) =? (i + (k[a] + k[b])) * G. If k is submitted from A
to C through some mechanism that replaces the current ephemeral key
system, then I understand what you're at.
Assuming this is the case, it's pretty neat. I do wonder how it
interacts with rendezvous routing. If the sender and receiver each
create the k[..] values for their own part of the route, can the
receiver-generated onion packet still use points of the form ((I + K[A])
+ K[B]), including K[..] values related to the sender side? I need to
dig deeper into this path decorrelation idea.
CJP

2023-06-09 12:53:20

- reply

📅 Original date posted:2018-12-04
📝 Original message:
>> I think we could stop this type of attack by including some kind of
>> shared secret in the onion message to the final node:
> I think we get this "for free" if we switch to path decorrelation and points+privkeys instead of hashes+preimages.
>
> Path decorrelation means that each hop is given a random point, to be added to the next SS "HTLC".
> The final node needs to be given the total of the scalars of each hop random point along the route, most likely within the last hop of the onion.
> The final node also cannot differentiate between an incorrect total for this scalar, or an incorrect "invoice hash"/invoice point.
>
> Hence, some intermediate node along the way cannot guess this, and the final node will give the same error, i.e. "invoice point not found".
>
>
That might indeed stop an attacker from testing 2nd-degree, 3rd-degree
etc. neighbors, making the attack much less versatile. However, for his
direct neighbor in the route, the attacker does learn the point to be
used in that hop. Therefore I think the attacker can still test whether
or not the next node is the final hop.
CJP

2023-06-09 12:53:19

- reply

📅 Original date posted:2018-12-04
📝 Original message:
Thanks Christian, that makes sense. Unfortunately it's not very clear
from the BOLT, at least not for me.
Now that I think of this type of attack: *in general* the HMAC prevents
this kind of attack, but isn't the attack still possible in certain
specific cases?
For instance, the attacking intermediate node might guess that the next
node in the route is the final node; it can test this by completely
replacing the onion packet it sends to the next node with a self-written
onion packet that has the next hop as final node, with the same amount
and payment hash as instructed by the incoming payment. If that
succeeds, it has learned that the next node is indeed the final node
(and nobody gets to know about the attack); if that fails, it might
retry the payment with the original onion packet. In that case, it
learned that the next node is *not* the final node. In this case, the
attack is detectable by the next node though: it first receives an
incoming payment with a payment hash it doesn't recognize, and then it
receives a payment forwarding request with the same payment hash.
Given that the attacker has good knowledge of the shape of the Lightning
network, this type of attack can be generalized to test whether a
certain second-degree neighbor, third-degree neighbor etc. is the final
node; it scales pretty badly with increasing network distance though. An
additional advantage for the attacker is that this gives plausible
deniability: if the attack becomes visible, the attacker can always
claim it wasn't him, but some node upstream in the route. A practical
difficulty for the attacker might be that the exact amount forwarded in
further-away hops is unknown, but it's probably not that difficult to guess.
I think we could stop this type of attack by including some kind of
shared secret in the onion message to the final node:
* Payee generates shared secret and passes this to payer, as part of the
invoice
* Payer includes shared secret in the per hop data to payee
* On receiving the incoming message, payee checks whether the received
shared secret corresponds to the generated one. If this is not the case,
behave in exactly the same way as when the payment hash is unrecognized
(including timing, to prevent timing side-channel attacks).
If this shared secret is encrypted like the rest of the per hop data,
the attacker can't learn the shared secret, and can't include it in his
own replacement onion. He can't copy-paste the encrypted shared secret
from the original onion either, since he has to use his own, different
ephemeral key in his own onion. With this protocol in place, a final
node can no longer be distinguished from a non-final node with this attack.
The shared secret doesn't need to be very large: the number of attempts
per second (to guess the shared secret) is limited by network latency,
bandwidth and maybe some artificial rate limiting. If an attacker can do
100 attempts per second, then a 32-bit shared secret will take (on
average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of
which node is the final node. In the mean time, people will have noticed
the ongoing attack and will have taken countermeasures. Besides, the
transaction lock time will likely have expired in the mean time as well.
CJP
On 29-11-18 18:13, Christian Decker wrote:
> Hi Corne,
>
> the HMACs are necessary in order to make sure that a hop cannot modify
> the packet before forwarding, and the next node not detecting that
> modification.
>
> One potential attack that could facilitate is that an attacker could
> learn the path length by messing with different per-hop payloads: set
> n=0 the attacker flips bits in the nth per-hop payload, and forwards
> it. If the next node doesn't return an error it was the final recipient,
> if if returns an error, increment n and flip bits in the (n+1)th per-hop
> payload, until no error is returned. Congratulation you just learned the
> path length after you. The same can probably be done with the error
> packet, meaning you can learn the exact position in the route. Add to
> that the information you already know about the network (cltv_deltas,
> amounts, fees, ...) and you can probably detect sender and recipient.
>
> Adding HMACs solves this by ensuring that the next hop will return an
> error if anything was changed, i.e., removing the leak about which node
> would have failed the route.
>
> Cheers,
> Christian

2023-06-09 12:53:14

- reply

📅 Original date posted:2018-11-29
📝 Original message:
Hi,
Is there a reason why we have HMACs in Sphinx? What could go wrong if we
didn't?
A receiving node doesn't know anyway what the origin node is; I don't
see any attack mode where an attacker wouldn't be able to generate a
valid HMAC.
A receiving node only knows which peer sent it a Sphinx packet;
verification that this peer really sent this Sphinx packet is (I think)
already done on a lower protocol layer.
AFAICS, The only real use case of the HMAC value is the special case of
a 0-valued HMAC, indicating the end of the route. But that's just silly:
it's essentially a boolean, not any kind of cryptographic verification.
CJP

2023-06-09 12:52:38

- reply

📅 Original date posted:2018-11-27
📝 Original message:
The only reasons I see for keeping the global/local distinction is that
you might not want to gossip everything, either to keep the gossip data
small, or for some privacy reasons. Apparently, that's all very
theoretical so far, as current features don't seem to need either.
Ideally you'd like to have a design that requires as little consensus as
possible, but for global feature bits it's clear there has to be
consensus about their meaning. For a moment I thought we'd have more
relaxed requirements for local feature bits (as only peers have to agree
on feature bit meanings), but if we want every peer to be able to
connect to every other peer, we still need global consensus on the
meaning of local feature bits.
I'm not even sure it makes sense to keep certain feature bits local for
privacy reasons. Interested parties can usually just figure out your
local feature bits by connecting to your node. As for the size of gossip
data: the bits themselves shouldn't be the problem. Certain features
might require extra data to be gossiped, but that should be discussed on
a case-by-case data per feature. We might end up with a gossip design
where you'd first receive the basic gossip data, and then try to get
extended data you're interested in, based on what feature bits are
enabled in the basic gossip data.
So, maybe I missed something important, but no, right now I don't see a
good reason for the global/local distinction.
CJP
On 14-11-18 00:50, Rusty Russell wrote:
> Pierre <pm+lists at acinq.fr> writes:
>> Hi Rusty,
>>
>>> The feature masks are split into local features (which only
>>> affect the protocol between these two nodes) and global features
>>> (which can affect HTLCs and are thus also advertised to other
>>> nodes).
>> I don't think that definition makes a lot of sense. For example I
>> probably want to advertise the fact that my node supports
>> option_data_loss_protect, which is a local feature. OTOH why would I
>> *not* want to avertise a feature that I support? I struggle to see
>> what is the point of making the distinction between local/global
>> actually.
> The theory was that local features concern direct peers, global features
> concern others (thus *must* be advertized by gossip).
>
> I *expected* local features to become ubiquitous over time, so by the
> time an implementation decided "I don't even want to talk to nodes
> without feature X" then most nodes would support feature X, so you could
> simply connect and you're probably OK.
>
> So the question becomes:
>
> 1. Do people want to pre-filter by local features?
> 2. If so, only some local features, or all of them?
>
> If only some, then we make those ones global features. If all, then we
> remove the local/global distinction altogether?
>
> Thanks,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:51:23

- reply

📅 Original date posted:2018-08-27
📝 Original message:
> Aside from that, spontaneous payments is amongst the most request feature
> request I get from users and developers.
A while ago I realized that spontaneous payments (without proof of
payment, mostly for donations only) can be realized quite easily if the
payer generates the preimage and hash, and includes the preimage in the
sphinx message to the payee node. If the payee node recognizes the
sphinx message format, it can use the preimage to claim the payment.
CJP

2023-06-09 12:51:23

- reply

📅 Original date posted:2018-08-27
📝 Original message:
Now that you remind me of the wiki: I remember we discussed this before,
so maybe I was just repeating myself (sorry). It is true the wiki should
be more prominent.
CJP
Op 27-08-18 om 15:19 schreef Christian Decker:
> Corné Plooy via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
> writes:
>>> Aside from that, spontaneous payments is amongst the most request feature
>>> request I get from users and developers.
>> A while ago I realized that spontaneous payments (without proof of
>> payment, mostly for donations only) can be realized quite easily if the
>> payer generates the preimage and hash, and includes the preimage in the
>> sphinx message to the payee node. If the payee node recognizes the
>> sphinx message format, it can use the preimage to claim the payment.
>>
>> CJP
> You mean like we describe in the Brainstorming wiki [1]? We definitely
> need to make the Wiki more prominent :-)
>
> [1] https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#passing-a-transfer-secret-in-the-onion

2023-06-09 12:50:45

- reply

📅 Original date posted:2018-05-22
📝 Original message:
Hi,
Lately I've been thinking about de-centralized crypto/crypto exchange
("atomic swap") on the Lightning network. In my view, the main problem
is that participants can delay transactions (up to HTLC time-out, which
can be quite long), in order to speculate on exchange rate changes. I've
been looking for several approaches to deal with this problem.
The first approach[1] is not really interesting anymore in my opinion,
since I now favor the second approach. In essence, the first approach
let a latency monitor service monitor latencies in transactions; this
data can then be used as a source of information for building reputation
of market participants. Dealing with reputation in a community of
easily-created pseudonyms has its own set of issues. I did some analysis
on this and identified some problems.
The second approach[2] doesn't need a reputation network: the trading
parties delegate the job of executing the Lightning transaction to a
trusted third party. The trading parties don't need to trust each other,
and they only need to trust the third party to not cooperate with the
other trading party to perform the delay attack. This is not a perfectly
trust-free decentralized design, but there is no need for the trusted
party to have a monopoly, and compared to traditional exchanges, a lot
is gained: the trusted service provider can not steal customers' funds,
and unless it puts special requirements on performing its service, its
customers can remain anonymous, and it doesn't know which asset is traded.
It may not be needed to let a single Lightning node have channels for
the different cryptocurrencies: you can also have one node for each
currency, and let higher-level exchange software do the forwarding. In
that case, you wouldn't gossip the cross-currency link on Lightning
either: the exchange market has its own gossip mechanisms (the details
are still not worked out).
I doubt decentralized Lightning-based exchange will be competitive for
very high-frequency or high-volume needs, but for casual use by people
who are already on Lightning it might have some use. At least it gets
rid of the need for exchanges with large amounts of stored crypto
assets, which are a very attractive target for hackers.
CJP
[1] A trusted latency monitor service, for preventing abuse in a
Lightning-based peer-to-peer exchange,
https://bitonic.nl/public/latencymonitor.pdf
[2] Preventing transaction delays with a Lightning routing service, for
preventing abuse in a Lightning-based peer-to-peer exchange,
https://bitonic.nl/public/slowdown_prevention.pdf

2023-06-09 12:50:30

- reply

📅 Original date posted:2018-05-22
📝 Original message:
> You missed the vital detail: that you must prove channel closure if you
> can't unpeel the onion further. That *will* hit an unresponsive party
> with a penalty.[1]
Is this specified in a BOLT somewhere? I tried to find it several times,
without success.
CJP

2023-06-09 12:50:22

- reply

📅 Original date posted:2018-05-15
📝 Original message:
Hi Christian, ZmnSCPxj ,
>> - The CSV-encumberance on settlement transactions, which are the ones
>> which carry the contracts in the channel, affects all
>> absolute-timelocked contracts transported on the channel. Compare to
>> Poon-Dryja, where commitment transactions themselves are unencumbered
>> by CSV, and we simply insert the revocation to spends of the contracts
>> being transported (i.e. the reason why we have HTLC-success and
>> HTLC-timeout transactions in BOLT spec).
> True, but as I argued in another mail, this is a fixed offset, that is
> in the same range as today's CLTV deltas for some nodes. So for the
> network of today using eltoo is roughly equivalent of adding another hop
> to our path :-)
Let me think how this is supposed to work (I can't find that other mail
you're referring to):
I assume the HTLC outputs are in the settlement transaction. In case of
a unilateral close while there are HTLCs present, the following sequence
happens:
1. The trigger transaction is broadcasted.
2. One or more update transactions are broadcasted. These are not
affected by the CSV condition and can be confirmed immediately. Once the
last update transaction gets confirmed, its CSV clock for the settlement
transaction starts.
3. The settlement transaction (containing HTLCs) can be broadcasted, but
it will not be confirmed before the CSV time-out of the last update
transaction.
4. At this point, the HTLC conditions become relevant. Before the HTLC
time-out, the receiving side can access the funds with the preimage.
After the timeout, the sending side can access the funds without the
preimage.
If the HTLC time-out is before the start of step 4, then the sending
side can try to get the funds back, even if the preimage was already
released much earlier. For the safety of the receiving side, this
situation must be avoided. So, if T is the (absolute) HTLC time-out
time, S is the CSV time-out period and C is the expected worst-case time
involved in confirming everything, then the receiving side of a HTLC
must drop the channel on-chain before T - S - C. Obviously, HTLCs for
which this time has already passed on creation must be rejected.
Dropping on-chain is no longer needed if the HTLC is removed by a
channel update before T - S - C.
What happens in case of a transaction time-out? Let's number the nodes
0, 1, ... on the route, and Tn the HTLC time-out between nodes n and
n+1. For simplicity, assume the same S+C for all channels. If node n
becomes unresponsive after accepting its incoming HTLC, then two moments
in time are relevant:
* T(n-1)
* T(n-2) - S - C
In case T(n-1) happens first, node n-1 knows it doesn't have to pay
outgoing funds, so it can cooperatively cancel the incoming HTLC. This
will propagate back immediately, keeping all channels open.
In case T(n-2) - S - C happens first, node n-1 has to close its channel
with n-2. On-chain, the HTLC conditions continue to apply, so for the
rest, nothing changes. As soon as T(n-1) is reached, node n-1 knows the
transaction has timed out, but it no longer has a way to propagate this
knowledge to node n-2. For node n-2, two times are relevant:
* T(n-2)
* T(n-3) - S - C
... and the same steps are repeated. In this case, a transaction
time-out leads to closing all channels on the route. This is a major DoS
attack vector, and must be prevented.
Therefore, we must set T(n-1) > T(n-2) - S - C, so the HTLC time-out
increment must be at least S+C.
Theoretically, it seems workable. What would be a practical value for S
(the CSV time-out)? In the absence of watch towers, you'd want to set it
to at least a couple of weeks, to allow yourself to go off-line on
holiday without worrying about computer issues. However, a time-out
increment of a couple of weeks *per hop* for the HTLCs adds up really
quickly to unpractical values. Maybe the conclusion simply is that we
really really need watchtowers? Otherwise, only professional parties
that can manage near-100% uptime can safely perform transaction routing.
CJP

2023-06-09 12:49:52

- reply

📅 Original date posted:2018-04-16
📝 Original message:
Op 10-04-18 om 20:34 schreef Tyler H:
>
> I will continue to approach the problem of securely advertising
> human-understandable node names, and I hope someday soon I will have a
> solution Lightning can use that retains the open, decentralized
> properties of the technology and the underlying blockchains.
>
Two of my favorite approaches:
* Namecoin-style: Register your name first-come-first-serve on a block
chain.
-> Provides no protection against name squatting and attackers
registering similarly-looking names.
* Web of Trust: I tell you I believe this pubkey really corresponds to
this name; someone else might tell you something else. DNS is
essentially a special case of this, where the WoT has a centralized star
shape. TLS is another case, where there is dozens of signing parties
(CAs), and everyone typically gets their keys signed by only one of
them, so anyone verifying keys has to trust all these CAs. More
generally, a WoT can have any shape though.
-> Provides little to no protection against trusted parties lying to you.
CJP

2023-06-09 12:49:46

- reply

📅 Original date posted:2018-04-09
📝 Original message:
Why put everything in bech32? It hurts readability. The only possible
advantage is that data inside the bech32 blob can be digitally signed in
a convenient way. If you don't need that, I'd keep your data ourside the
bech32 blob, in a (expert-)human-readable format.
Why not follow a regular URL format when host and port are involved? I
don't see the advantage of lightning:ln1bech32nodeid/ipnumber/port over
node at ip:port. In practice, I see both C-Lightning and LND also using
node at ip:port, BTW.
Is this really only about reducing the size of QR codes? How many
percent reduction do you think you can accomplish with your approach? I
think, when it comes to reducing QR code size, it makes more sense to
think of a better way to encode the node ID. Hexadecimal isn't exactly
the most space-efficient encoding.
CJP
Op 07-04-18 om 17:17 schreef Robert Olsson:
> Hello all,
>
> I seem to not find a bolt regarding the QR code of node at ip:port
>
> It seems eclair only supports the format hex at ip:port format, and i
> haven't tried any other mobile wallets.
>
> I thought there would be support for bech32 nodeid:s to keep the QR
> small, but it doesn't seem that way.
>
> If it isn't standardized yet, i think we should do it soon so all
> wallets will support it from start and we can avoid bulky QR codes.
>
> To fully utilize QR it should work with charset in text-mode, so i
> would suggest a format like
>
> lightning:ln1bech32nodeid/ipnumber/port
>
> where /port is optional if port is 9735
>
> this is to avoid @ and confusion of : in ipv6 and :portnumber
> (skip '[' and ']' in ipv6)
>
> another approach would be to encode ip and portnumber in bech32 as
> well. my opinion is that everything coded entirely in bech32 shouldn't
> need a protocol so the 'lightning:' part could possibly be omitted as
> well.
>
> or did i just miss a bolt somewhere?
>
> best regards
> Robert Olsson
>
>
>
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:49:42

- reply

📅 Original date posted:2018-04-05
📝 Original message:
If there are censorship concerns, you could opt for a set-up where payer
has an authenticated connection to a trusted server, through the
Internet connection provided by payee. The trusted server can, for
instance, be a full Lightning node running at the payer's home.
The payer then only has to take a very light piece of electronics with
him/her. It will still be larger than a credit card (since
authentication should be done payer-side, e.g. with a PIN code), but it
can be smaller than a smart phone. Personally, I like this kind of
set-up, because I see cell phones as a huge privacy issue (you're
continuously transmitting your rough location to the network).
Why would there need to be a direct channel between payer and payee? We
have the Lightning network to avoid needing direct channels, right?
CJP
Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:
> Good morning Igor,
>
> This is quite an interesting use-case for Lightning.
>
> However it seems to me that the payer will need a direct channel to
> the payee, or at least the payment terminal (of the payee...?).
>
> In addition the payer will need to somehow get blockchain information
> from the payee if the payer itself has no Internet. The payee may
> have an incentive to prevent the payer from knowing that timeouts have
> been reached, for example, and may withhold new blocks (although all
> censorship attacks I know of that could be used on LN target the payee
> and not the payer).
>
> Is my understanding correct?
>
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 5, 2018 5:46 PM, Igor Cota <igor at codexapertus.com> wrote:
>
>> Hello all,
>>
>> I feel that one of the biggest promises of lightning lies in it being
>> used for everyday retail payments.
>>
>> I'd like to see a system that's:
>> 1) instantaneous like the contactless bank cards of today
>> 2) encodes a fancy HTML receipt in bolt11 for the payers future reference
>>
>> QR codes are a bit unwieldy and even more so if you want a nice HTML
>> table description of your grocery shopping with hundreds of items -
>> this relatively large amount of data makes them impractical to scan.
>>
>> To this end I've been running an instance of c-lightning on Android
>> [1][2][3] and experimenting with payments via NFC. I set up a machine
>> with an NFC USB dongle that acts as an point-of-sale terminal [4]. So
>> far so good!
>>
>> There are two basic ways you can use NFC enabled phones today - as
>> passive tag readers or in card emulation mode (not sure if the latter
>> is available on iOS).
>>
>> Passive tags are really simple and encoding bolt11 to them works as
>> expected. If you set the right MIME type Android will open whatever
>> app is registered to handle lightning and you can either pay
>> instantaneously or after user confirmation. Works great provided both
>> the phone and terminal are connected to the network and have a route
>> to each other.
>>
>> Card emulation mode is more interesting because it enables us to have
>> two way communication and therefore an ad hoc connection to the
>> lightning network. After some handshaking, phone can tell the
>> terminal that it wants to connect to lightning via NFC. All
>> communication between these two lightning nodes can be done over NFC
>> or even bluetooth [5]. This might be useful as fallback in situations
>> where mobile data is not available.
>>
>> I settled on a MIME type (application/lightning) and an NFC
>> application id (LIGHTNING). There is also a very simple protocol to
>> forward socket data. For the sake of interoperability it would be
>> great if we agreed on some standards but I'm not sure how to proceed
>> with this. Should these be part of a future BOLT or is mailing list
>> banter enough?
>>
>> I look forward to your views!
>>
>> Cheers,
>> Igor
>>
>>
>> [1]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [2]
>> https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
>> [3]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [4] https://github.com/icota/presto
>> [5] https://github.com/ElementsProject/lightning/pull/1323
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:49:27

- reply

📅 Original date posted:2018-03-19
📝 Original message:
>
> What about enforcing a maximum payment amount that can be refunded?
> Can this help make the amount not a requirement? This way the payment
> amount will still be open to the payer, but it will have a constraint.
I see no use case anymore for leaving out the amount in the invoice. For
any type of transaction where the payer decides the amount, he can do so
by specifying the amount in the invoice request.
>>>      3. True. Right now I'm thinking in the opposite direction:
>>> simplifying
>>>           BOLT 12 by removing the possibility of refunds. We can
>>> always add it
>>>           back later (with a proper set of features for all kinds of
>>> refunds) as
>>>           an optional feature.
>
>
> I want my refund :-) !
I did some further thinking on refunds. Generally speaking, they are a
solution for when Transactions Get Messy, right? You agreed to a
transaction, the Lightning payment happened, but now you want to change
something. That 'something' can be, for instance, a full refund (e.g. if
goods cannot be delivered), a partial refund (e.g. if goods arrived
later than agreed, or with inferior quality), an extra payment by the
payer (e.g. cheaper model out of stock, decided to buy the more
expensive one instead), or no payment at all (e.g. payer changes mind
after the payment, and wants the black/blue model instead of the
white/gold one, which has the same price).
There is some similarity between a "BOLT 12" transaction that allows
refunds and other updates, and a microtransaction channel. Specifically,
I think you want the new state to be signed by whoever may possibly have
a legitimate interest *against* the update, and you want the old state
to be invalidated. In BOLT 12, to support this, a state should typically
contain the description field, a field that invalidates the previous
state, a field that specifies how this state can be invalidated, and
optionally a payment hash(*), which indicates that this state update is
valid only in combination with the corresponding preimage. A transaction
starts in a "null" state (no obligations between participants), and ends
specifying certain obligations that have been fulfilled. TBD: maybe
returning to null state by signing off that all obligations have been
fulfilled? E.g. payer signing off that ordered goods have been received.
Note that this must be different from canceling the transaction, since
you want the payer to keep some kind of proof of ownership. Anyway, I
think returning to null state should not be required on BOLT12 protocol
level: not everybody wants this. Some suppliers may want to require it
though.
Looking at the protocol for this (generalized) refund usage, it seems
clear that, often, you don't want to have to keep the communication line
open the entire time: it can take days, weeks or longer until the final
settlement of a transaction. You should be able to reconnect (typically
in the same direction as the initial connect) and say "hey, let's update
the state of the transaction to this-or-that". So, on re-connecting, you
also need to be able to specify *which* transaction to update.
The format of the "description" field is unspecified for now; I think
it's best to keep it that way. Machine-readable formats for this are a
very complex subject, better solved at a higher level protocol. For now,
assume it to be human-readable; maybe add a MIME type field so that its
format is both unambiguous (technologically) and upgradeable.
TBD: is there a use case for transactions between more than two parties?
Or having smart contract (scriptless?) scripts? These would then
typically be evaluated by a settlement service provider (e.g. the legal
system) instead of a block chain.
> All return onions still have the same problem of capacity though.
A partial onion is a very generic solution. If capacity is your greatest
concern as payee, you just supply a zero-hop partial onion. Minimum
privacy, but maximum ability of the payer to construct a route over
channels with sufficient capacity. The choice is yours.
>>>      4. This depends on the use case. The URL contains an optional
>>> invoice
>>>           ID. A payee can request a payment for a specific, single
>>> transaction
>>>           (for a single instance of delivery of goods/services) by
>>> handing over an
>>>           URL, including an invoice ID, to a single payer. This
>>> provides similar
>>>           functionality as BOLT 11, except that you now have a
>>> well-defined
>>>           channel for transmitting larger invoice descriptions and
>>> for using
>>>           partial onion routes. A payee can also hand over an URL
>>> without invoice
>>>           ID; this can be used and re-used by one or more payers,
>>> whenever they
>>>           want to perform payments to this payee.
>> How does the payer derive the payment hash? Or does the payer have to
>> contact the payee again to get a fresh payment hash specifically for
>> the payer?
Contact the payee again. Or, more generally, one of them knows how to
contact the other to propose updates to the agreement; if the payee of
the update agrees, he will provide the payment hash.
CJP
(*) together with amount and timeout: these allow the payer to know
under what conditions the payee is likely to release the preimage.

2023-06-09 12:49:26

- reply

📅 Original date posted:2018-03-19
📝 Original message:
> It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node.
>
> Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway?
If that payee has a LN node that is 100% a TOR hidden service, and you
don't use a (partially) payee-determined route, the payee has to reveal
its node ID to the payer. This is not the same as revealing the physical
identity of the payee, and having a hidden service may help to keep the
two identities separated, but a LN node is a relatively long-lived
entity. Over time, the risk increases that knowledge about the node ID
(e.g. what kinds of transactions are linked to this ID) leaks out and
gets combined, revealing things you don't want to be revealed.
It may, for instance, be that some of your incoming transactions are
inherently linked to your physical identity (e.g. salary), and some
other you don't want linked to yourself. If you have to reveal your node
ID to all payers, you risk those transactions being linked to you,
either now or in the future. Running a node as a TOR hidden service is
not sufficient. However, if you manage to hide your node ID from payers,
this becomes much more difficult; you really gain some privacy.
In fact, using a TOR hidden service may not always be necessary. In some
cases, you could alternatively set up payer/payee communication over a
more-or-less anonymous physical medium; maybe using a burner phone, WiFi
with a randomized MAC address, NFC, or some other kind of radio
communication.
The alternative approach to partially payee-determined routes would be
to run different nodes for different identities and to regularly shut
down nodes and set up new ones. This requires expensive on-chain actions
though (more expensive than setting up a new TOR hidden service), and I
don't think it's good for the rest of the network either if channels are
regularly shut down. I prefer if people can have lots of privacy, even
when running only a single node.
You could roughly say that TOR is necessary because your IP address can
often be linked to you, and partially payee-determined routes are
necessary because your node ID can often be linked to you.
CJP

2023-06-09 12:49:26

- reply

📅 Original date posted:2018-03-20
📝 Original message:
> I suppose the use-case here is that the payee uses many TOR addresses with only one LN node.
Yes. Use different TOR addresses for things you want to keep separated.
Any TOR address you advertise for channel connections is so widely
shared through gossiping that you can in practice consider such an
address to be the same identity as your peer ID. For the payer/payee
communication (BOLT 12, and other interfaces such as a website) you
should *not* use the same TOR address if you want that activity to
remain unlinked from your node ID. You could use another TOR address, or
any other pseudonymous communication method.
Depending on the transport layer you use (TOR or something else) you end
up with a different type of URL. I think for now it's good enough to
support TCP and TOR.
Another use case could be to use partial onion routes for payments in
the opposite direction. This is, for instance, to refund a payer who
wishes to remain anonymous. The original payee has an URL (can be TOR
hidden service, or even regular TCP), and the original payer connects to
this (using TOR or another anonymizing medium). The original payer can
then remain anonymous by sending an invoice for the refund that uses a
partial onion route on LN. In this use case, the purpose is to keep the
original payer anonymous (not reveal the node ID), not to keep the
original payee anonymous.
CJP

2023-06-09 12:49:25

- reply

📅 Original date posted:2018-03-15
📝 Original message:
Hi Andy,
1. Don't confuse TOR onion routing (used for anonymous/pseudonymous
communication) with Lightning onion routing (used for anonymous
payments). TOR's design is outside the scope of the discussion; as far
as I can see, TOR is only relevant because it exists, it works(*) and it
is useful to us. The "partial onion route" is about Lightning's onion
routing. You could consider the start of the partial route as an
"introduction point"; it is selected by the payee(**). I'm not sure if
it is exactly equivalent to TOR's introduction points though.
2. Good thinking. I guess that, since either payer *or* payee will
decide on the amount, there is no use case for omitting the amount in an
invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So
that's not a problem for the partial onion route. Unknown capacity is an
issue, and I guess it's worse than if the payer is completely free to
choose a route, because the payer is no longer completely free to choose
alternative routes. Giving a batch of alternative routes is one concept
(TBD: can they have the same payment hash?); giving new alternatives
interactively is another option. I think using the same "introduction
point" for all routes is best for privacy: otherwise the payer could
determine the neighborhood of the payee.
3. True. Right now I'm thinking in the opposite direction: simplifying
BOLT 12 by removing the possibility of refunds. We can always add it
back later (with a proper set of features for all kinds of refunds) as
an optional feature.
4. This depends on the use case. The URL contains an optional invoice
ID. A payee can request a payment for a specific, single transaction
(for a single instance of delivery of goods/services) by handing over an
URL, including an invoice ID, to a single payer. This provides similar
functionality as BOLT 11, except that you now have a well-defined
channel for transmitting larger invoice descriptions and for using
partial onion routes. A payee can also hand over an URL without invoice
ID; this can be used and re-used by one or more payers, whenever they
want to perform payments to this payee.
Thanks for the questions; I think I can improve my proposal based on
your feedback.
What should I do with BOLT 12? Have it pulled in
lightningnetwork/lightning-rfc; maybe in a separate branch? Or first
work it out in more detail? How does lightningnetwork/lightning-rfc
distinguish between drafts, finished agreed-on specs and things we
decided we don't want? Is there even a consensus forming mechanism?
CJP
(*) to some degree; there are limits to the privacy provided by TOR.
(**) when extending the current BOLT 12 draft a bit, it might also
optionally be selected by the payer.
Op 10-03-18 om 06:16 schreef Andy Schroder:
> Hello Corné,
>
> I'm glad to see that someone getting this kind of idea started.
>
> I'm still new to some of these topics, but I have a few comments.
> Hopefully I'm not wasting your time if they are too rudimentary!
>
> 1. You mention that the payee gives a URL where the payer can then
> connect to to request invoices. You mention that this can be a tor
> hidden service if the payee needs to remain private. You also
> suggest that the payee can remain private by "payee can send an
> invoice to payer which has a partial onion route as destination
> instead of a node ID". I was reading about tor hidden services
> (https://www.torproject.org/docs/onion-services.html.en), and they
> require an introduction point, and a rendezvous point. Do we not
> need this two step process for the payment route, because we
> already have communication initiated over the anonymous
> communication channel, and the beginning of the partial onion
> route is not publicly available information, and can change with
> every invoice?
> 2. What happens if the capacity of the partial onion route is no
> longer sufficient when the payer is ready to pay? Is there a way
> to provide a few routes just in case? Or, in the case where no
> amount is specified, how is the partial onion route possible if we
> don't even know how much capacity may be needed?
> 3. You say the refund should invalidate the proof of payment of the
> initial transaction. What about partial refunds? I think there are
> a lot of applications where there would be a partial refund.
> 4. You say "this BOLT specifies a protocol where payee gives a URL to
> one or more potential payers". How does the payer identify itself
> to the payee so that the payee knows what goods or services that
> they want an invoice for? Do they send this after making the
> connection, or is it part of the URL?
>
>
>
>
> Andy Schroder
> On 03/08/2018 10:19 AM, Corné Plooy via Lightning-dev wrote:
>> Hi,
>>
>> I was thinking of how to use Lightning for various types of payments,
>> and I think it's currently fine for customer/(web)shop type
>> interactions, but it seems a bit inconvenient for other use cases, e.g.
>> salary payments or direct pay-out of cryptocurrency bought on an
>> exchange. I came up with an idea that addresses some of these issues and
>> more (e.g. payee anonymity) by having a direct line of communication
>> between payer and payee instead of BOLT11-style interaction. It's still
>> a bit half-baked, with many details not worked out yet, but you can read
>> it here, and see if you like where this is going:
>>
>>
>> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
>>
>>
>> In true permissionless fashion, I have been so bolD to register bolT #12
>> for my idea.
>>
>>
>> Please let me know what you think.
>>
>> kind regards,
>>
>> CJP
>>
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

2023-06-09 12:49:24

- reply

📅 Original date posted:2018-03-15
📝 Original message:
Hi ZmnSCPxj,
Thanks for the links. I've done a bit of reading, and this seems to be
the clearest explanation of what the Web Payments Working Group wants to
achieve:
https://www.w3.org/TR/webpayments-overview/
But maybe Christian can give better / more up-to-date info.
From what I can see, their concept is still very much focused on
non-recurring purchases, and then especially on websites. In other
words: the typical web shop use case. The site linked above does however
contain the following text:
"A concern has been raised over the structure of a payment request,
notably that there are other forms of messages that may be initiated by
a payer. There is currently a proposal to modify payment request to a
more generalized "payment instruction" that would be capable of
expressing other messages like subscriptions, preauthorizations,
refunds, and other sorts of payment-related instructions."
So it seems they're thinking about it, but there is no consensus or
standardization yet. The important question: should we wait for this?
How long is this going to take? How bad would it be to first push
forward some simple version of BOLT 12?
CJP
PS. Quote of the day:
"Some aspects of bitcoin are less useful, however. It is currently
impossible to set up recurring payments with the currency, making it
impractical for subscriptions that renew on a short term basis."
Op 09-03-18 om 05:28 schreef ZmnSCPxj:
> Good morning Corne,
>
> You mention URLs in your draft. This made me remember about the Web Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/dbwg/details?group=83744&public=1
>
> My understanding is that Christian aims to make Bitcoin payments (and possibly Lightning invoice payments?) payable over Web payment protocols that W3C group is working on.
>
> Possibly the Web Payments Working Group may provide better perspective on various other payment use cases as well as their subtleties, which can help inform your considerations in your proposed BOLT12.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On March 8, 2018 11:19 PM, Corné Plooy via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I was thinking of how to use Lightning for various types of payments,
>>
>> and I think it's currently fine for customer/(web)shop type
>>
>> interactions, but it seems a bit inconvenient for other use cases, e.g.
>>
>> salary payments or direct pay-out of cryptocurrency bought on an
>>
>> exchange. I came up with an idea that addresses some of these issues and
>>
>> more (e.g. payee anonymity) by having a direct line of communication
>>
>> between payer and payee instead of BOLT11-style interaction. It's still
>>
>> a bit half-baked, with many details not worked out yet, but you can read
>>
>> it here, and see if you like where this is going:
>>
>> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
>>
>> In true permissionless fashion, I have been so bolD to register bolT #12
>>
>> for my idea.
>>
>> Please let me know what you think.
>>
>> kind regards,
>>
>> CJP
>>
>> Lightning-dev mailing list
>>
>> Lightning-dev at lists.linuxfoundation.org
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

2023-06-09 12:49:23

- reply

📅 Original date posted:2018-03-08
📝 Original message:
Hi,
I was thinking of how to use Lightning for various types of payments,
and I think it's currently fine for customer/(web)shop type
interactions, but it seems a bit inconvenient for other use cases, e.g.
salary payments or direct pay-out of cryptocurrency bought on an
exchange. I came up with an idea that addresses some of these issues and
more (e.g. payee anonymity) by having a direct line of communication
between payer and payee instead of BOLT11-style interaction. It's still
a bit half-baked, with many details not worked out yet, but you can read
it here, and see if you like where this is going:
https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
In true permissionless fashion, I have been so bolD to register bolT #12
for my idea.
Please let me know what you think.
kind regards,
CJP

2023-06-09 12:49:12

- reply

📅 Original date posted:2018-02-23
📝 Original message:
Hi Rusty,
> The proof-of-payment here is a red herring, I think. If we remove the
> destination awareness, the privacy issues seem greatly reduced.
>
Red herring = "something that misleads or distracts from a relevant or
important issue"[1]? Do you mean the proof-of-payment is irrelevant for
the privacy issue?
Trying to define proof-of-payment, in the typical use case of payment in
exchange of goods, I'd say that a proof of payment is a piece of data,
known to the payee, that allows the payee to prove that
"[<amount> was paid to <payee>, and in exchange] <payee> agreed to
transfer ownership of <goods> to <payer>".
For services, it would be
"[<amount> was paid to <payee>, and in exchange] <payee> agreed to
provide <services> to <payer>".
Requirements:
1. Proof-of-payment must be available to payer, who has the burden of
proof. By default, ownership of goods is not transferred, and there is
no obligation to provide services. Absence of proof should point to this
default. It is in the interest of payer to deviate from this default; if
he is capable of providing proof, he probably will.
2. The first part, "<amount> was paid to <payee>, and in exchange" is
optional: what I think really matters is the second part. Only in the
case that <payee> turns out to be incapable of delivering goods or
services, a dispute resolution party might be interested in the first
part, to find out what amount of monetary refund would be reasonable.
3. It is necessary that proof-of-payment proves agreement of <payee>:
otherwise, Eve could write "Alice agreed to transfer ownership of
<goods> to Eve" without consent of Alice.
4. It may not be necessary that proof-of-payment itself mentions
identity of <payee>, but it is necessary that <payee> becomes known to
the payer: "somebody agreed to transfer ownership of <goods> to <payer>"
does not indicate an obligation of any specific party. Without knowing
<payee>, it is impossible to verify 3.
5. It is necessary that proof-of-payment mentions the specific
obligation (e.g. delivery of goods/services); otherwise, it doesn't
prove anything useful.
6. It is necessary that proof-of-payment mentions <payer>: otherwise,
multiple potential payer parties could claim goods/services using copies
of a single proof-of-payment. Now that I think of it, it is way more
tricky than this, and I'm not sure that any mention of <payer> solves
anything. What you'd really want is that a single payment only results
in a single obligation of <payee>. However, IDs tend to be copyable,
just like proofs-of-payment. The best you can hope for is
difficult-to-copy IDs (like government-issued IDs) or very
inconvenient-to-copy (e.g. private keys of nodes that have significant
funds). How do you distinguish multiple identical transactions to the
same payer from the same payer making multiple false claims with the
same proof-of-payment? Include the payment hash to make it unique? I'm
not sure we're solving anything here.
The current invoice protocol[2] meets 1,2(optional part is
included),3(*),4(*),5(**), and can possibly meet 6(**), although there
is currently no defined protocol for payee to learn payer's identity.
There *are* some privacy issues with this kind of proof-of-payment:
3. requires payer to learn <payee>, and requires payee to provide
cryptographic proof of his consent to the transaction.
6. requires payee to learn <payer>. Because of its questionable
usefulness, I guess it's good there is no protocol defined for this.
However, 6. remains an open issue that does limit usefulness of
proofs-of-payment. Interestingly, while this knowledge provides
*evidence* for payer's involvement in the transaction, there is no
cryptographic *proof* of payer's involvement.
CJP
(*) the 'n' field is not required, but for routing and for verifying the
signature, payer currently still needs to know payee's node ID.
(**) optional: the 'd' and 'h' fields are free-format, and allow for this.
[1] https://en.wikipedia.org/wiki/Red_herring
[2]
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md

2023-06-09 12:49:11

- reply

📅 Original date posted:2018-02-21
📝 Original message:
Hi,
I am a bit concerned with the privacy implications of having either a
signed invoice + pre-image, or possibly a more powerful proof-of-payment
mechanism. In particular, I am concerned that it might provide
cryptographic evidence to the buyer that a certain seller performed the
transaction, and/or evidence to the seller that a certain buyer
performed the transaction.
In many cases, providing this evidence would be a feature rather than a
bug, allowing third-party dispute settlement (e.g. the legal system).
However, in my opinion, the Lightning network should also (or
especially) be suitable for more "sensitive" transactions. Even when
transactions are not illegal, I believe people still have a need to keep
some transaction information private. You don't want it to be possible
that your transaction history is stored on some company/person's server
for years, and then leaks out when that server gets hacked. Also, in my
opinion, we should *not* create a two-tier system of "sensitive" and
"nothing-to-hide" transactions: that would make the "sensitive"
transactions automatically suspicious, partially negating the whole
objective of being able to do sensitive transactions without
experiencing negative consequences.
To some degree, node IDs can act as pseudonyms, without evidence that
ties them to physical identities. However, I consider them to be
relatively poor pseudonyms: unlike, for instance, Bitcoin addresses,
creating a new node for every new transaction would have a serious
scalability impact, and defeat the whole purpose of Lightning. I think a
typical person would frequently perform transactions that are inherently
tied to their physical identity, e.g. receiving salary. This could give
the counterparty (the employer) a link between physical ID and node ID;
it might be forced to share this e.g. with authorities, further
increasing the odds of leak-out and/or abuse of data.
Maybe the solution is to have multiple nodes: one tied to your physical
ID, and one or more virtual identities? You could then transfer funds
between these nodes, and make sure no outsiders receive any
proof-of-payment info about these transfers. It sounds like an expensive
solution though, since you'd have to operate more channels to give each
node good connectivity.
What are your ideas on this? Should proof of payment be optional? Should
its strength (optionally) be reduced, so that it can only be used in
front of some previously-agreed-on dispute resolution party (is that
even possible)? Should the idea of proof of payment be abandoned
altogether? Is bi-directional routing(*) useful in this?
CJP
(*) Payee first finds a route from a rendezvous node to himself,
onion-encrypts that route, passes it to payer (together with rendezvous
node ID), and payer adds to that route the onion route from payer to
rendezvous point. This way, payer knows the rendezvous node ID, but not
the payee node ID. Payee knows the rendezvous node ID, but doesn't know
payer node ID either. Rendezvous node only knows that it's forwarding a
transaction, not from-where-to-where, or the purpose of the transaction.

2023-06-09 12:49:09

- reply

📅 Original date posted:2018-02-07
📝 Original message:
Hi,
Amiko Pay had this: on an invoice, you could (optionally) specify
through which peer you wanted to be paid; on a payment, you could
(optionally) specify through which peer you wanted to pay. In fact, if
you didn't do this, a payment-to-self would not result in any channel
actions, since the most efficient route to yourself makes zero hops.
There was some weird edge case in this if you had a channel to
yourself(*) and specified it in both the invoice and the payment: the
route would actually be forced to go multiple times through the same
channel.
Routing in Lightning is a bit different than in Amiko Pay, and I never
attempted to adapt Amiko Pay to the Lightning protocol standard. I do
think that Lightning offers *better* possibilities for channel
re-balancing, since it offers source routing: the source can explicitly
specify the entire route. If any channels offer negative fee rates to
have them re-balanced, you might even make money by rebalancing other
peoples' channels.
I'm not sure when channel re-balancing would be useful: if you are able
to pay through the B-A-others-C-B route and through the B-C-anyone
route, then certainly B-A-others-C-anyone would work as well?
Maybe to reduce risk that some channels on the 'others' path might be
saturated at inconvenient moments? If Bob receives monthly salary from
Alice and regularly wants to buy things from Carol, he'd probably want
to transfer his funds from the A-B channel as soon as possible to the
B-C channel. Alternatively, he could speculate on when fees on the
OTHERS route would be optimal to make the transfer.
Another use case could be privacy protection: if Alice is an employer,
she probably knows Bob's identity; Bob probably doesn't want her to know
details about his spending behavior as well. Bob-Carol could be a
pseudonymous contact on the TOR network. On receiving salary from Alice,
Bob would immediately transfer it to the B-C link, and perform
individual payments from there.
CJP
(*) not very useful in practice, but certainly useful for testing.
Besides, *some* user is going to try that sooner or later, so you have
to be robust against it.
Op 06-02-18 om 17:53 schreef Robert Olsson:
> Hello
>
> Let's say Bob opens a channel to Alice for 2BTC
> Carol then opens a channel to Bob for 2BTC.
> Alice and Carol are already connected to Others (and/or eachother even)
> The network and channel balances will look like this:
>
> Alice 0--2 Bob 0--2 Carol
> | |
> +----- OTHERS ------+
>
> Bob for some reason wants the channels to be balanced, so he has some
> better redundancy and it looks better.
>
> So hypothetically Bob solves this by paying himself an invoice of 1BTC
> and making sure the route goes out thru Alice and comes back via
> Carol. Bob pays fees so he isn't ashamed if it disturbs the other
> balances in the network. Should he care?
>
> Alice 1--1 Bob 1--1 Carol
> | |
> +----- OTHERS ------+
>
> Now Bob has two nice balanced channels, meaning he has better
> connectivity in both directions.
>
> Doesn't the protocol already support that kind of solutions, and all
> we need is a function in the CLI allowing Bob to pay to himself, and
> specify which two channels he would like to balance?
>
> Maybe even make it automatically balance.
>
> Is this a good idea of something to support, and/or Is there a risk
> the entire network will start doing this and it will start oscillating?
>
> Best regards
> Robert Olsson
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:49:06

- reply

📅 Original date posted:2018-02-13
📝 Original message:
Hi Conner,
I do believe proof of payment is an important feature to have,
especially for the use case of a payer/payee pair that doesn't
completely trust each other, but does have the possibility to go to court.
However, I'm not convinced by what you wrote. I do think a combination
of signed invoice + preimage is a reliable proof of payment. Strictly
speaking, you are right: it is not so much a proof that they payer
*sent* the funds, but it *is* proof that the payee *received* the funds.
This is because the only scenario where it makes sense for the payee to
reveal the preimage is if it can claim a corresponding incoming HTLC
with (at least) the correct amount of funds. Revealing the preimage in
any other scenario would be stupid(*), and no amount of cryptography can
protect against stupidity. So, when it comes to cryptographic proof,
this is about as good as it gets.
Now, about the difference between the payer having sent the funds and
the payee having received the funds: I'd argue that it's the second that
really matters. If the payer can prove that there is *any* kind of
arrangement that ended up with the payee having received the correct
amount of funds, that should count as payment. Now, if none of the
intermediaries has been stupid, this does imply that the payer ends up
on the sending side of the payment, but even if one if the
intermediaries has been stupid, why should the payer and payee care? All
that matters is that an arrangement has been made to let the payee
receive (at least) the correct amount of funds, and that arrangement has
been proven to be successful. I consider that proof of payment.
CJP
(*) Stupidity includes being hacked, and anything else that can cause
your secrets being used against your own interests.
Op 13-02-18 om 04:29 schreef Conner Fromknecht:
>
> Hi everyone,
>
> I've seen some discussions over losing proofs of payment in the AMP
> setting,
> and wanted to address some lingering concerns I have regarding the
> soundness of using the current invoicing system to prove payments.
>
> In general, I think we are ascribing too much weight to simply having a
> preimage and BOLT 11 invoice. The structure of non-interactive payments
> definitely poses some interesting challenges in adapting the existing
> invoicing
> scheme. However, I believe there exist stronger and better means of doing
> proofs of payment, and would prefer not to tie our hands by assuming
> this is the best way to approach the problem.
>
> IMHO, the current signed invoice + preimage is a very weak proof of
> payment.
> It's the hash equivalent to proving you own a public key by publishing the
> secret key. There is an assumption that the only way someone could get
> that
> preimage is by having made a payment, but this assumption is broken most
> directly by the proving mechanism. Similarly, any intermediary who
> acquires
> an invoice with the appropriate hash could also make this claim since they
> also have the preimage.
>
> Further, I think it's a mistake to conflate
> 1) me being able to present a valid preimage/invoice pair, with
> 2) me having received the correct preimage in response to an onion
> packet
> that I personally crafted for the receiving node in the invoice.
>
> The main issue is that the proof does not bind a specific sender,
> making statement 1 producible by multiple individuals. I think it would be
> potentially worthwhile to explore proofs of stronger statements, such
> as 2,
> that could utilize the ephemeral keys in the onion packets, or even the
> onion as a witness, which is more rigidly coupled to having actually
> completed a payment.
>
> Without any modification to the spec, we can always use something like
> ZKBoo to prove (w/o trusted setup) knowledge of a preimage without
> totally revealing it to the verifier. This isn't perfect, but at least
> gives the
> sender the option to prove the statement without necessarily giving up
> the preimage.
>
> TL;DR: I'm not convinced the signed invoice + hash is really a good
> yardstick
> by which to measure provability, and I think doing some research into
> proofs
> of payment on stronger statements would be incredibly valuable. Therefore,
> I'm not sure if AMPs really lose this, so much as force us to reconsider
> what it actually requires to soundly prove a payment to an external
> verifier.
>
> Best,
> Conner
>
> On Mon, Feb 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org
> <mailto:lightning-dev at lists.linuxfoundation.org>> wrote:
>
> Good morning Christian and Corne,
>
> Another idea to consider, is techniques like ZKCP and ZKCSP, which
> provide atomic access to information in exchange for monetary
> compensation. Ensuring atomicity of the exchange can be done by
> providing the information encrypted, a hash of the encryption key,
> and proofs that the encrypted data is the one desired and that the
> data was encrypted with the given key; the proof-of-payment is the
> encryption key, and possession of the encryption key is sufficient
> to gain access to the information, with no need to bring in legal
> structures.
>
> (admittedly, ZKCP and ZKCSP are dependent on new cryptography...)
>
> (also, AMP currently cannot provide a proof-of-payment, unlike
> current payment routing that has proof-of-payment, but that is an
> eventual design goal that would enable use of ZKC(S)P
> on-Lightning, assuming we eventually find out that zk-SNARKs and
> so on are something we can trust)
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
>
> -------- Original Message --------
> On February 13, 2018 2:05 AM, Christian Decker
> <decker.christian at gmail.com <mailto:decker.christian at gmail.com>>
> wrote:
>
> >Honestly I don't get why we are complicating this so much. We have a
> > system that allows atomic multipath payments using a single
> secret, and
> > future decorrelation mechanisms allow us to vary the secret in
> such a
> > way that multiple paths cannot be collated, why introduce a
> whole set of
> > problems by giving away the atomicity? The same goes for the
> overpaying
> > and trusting the recipient to only claim the owed amount, there
> is no
> > need for this. Just pay the exact amount, by deriving secrets
> from the
> > main secret and make the derivation reproducible by intermediate
> hops.
> >
> > Having proof-of-payment be presentable in a court is a nice
> feature, but
> > it doesn't mean we need to abandon all guarantees we have worked
> so hard
> > to establish in LN.
> >
> > Corné Plooy via Lightning-dev
> lightning-dev at lists.linuxfoundation.org
> <mailto:lightning-dev at lists.linuxfoundation.org>
> >writes:
> >
> >>I was thinking that, for that use case, a different signed
> invoice could
> >> be formulated, stating
> >> - several payment hashes with their corresponding amounts
> >>
> >> - the obligation of signer to deliver Z if all corresponding
> payment
> >> keys are shown
> >>
> >> - some terms to handle the case where only a part of the
> payments was
> >> successful, e.g. an obligation to refund
> >>The third item is a bit problematic: in order to distinguish
> this case
> >> from a complete success, the payee would have to prove absence of
> >> successful transactions, which is hard. Absence of successful
> >> transactions can only be declared by the payer, so in order to
> reliably
> >> settle without going to court first, the payer should sign a
> >> declaration stating that certain transactions were canceled and
> that the
> >> other ones should be refunded. This can be another invoice.
> >>So, the original invoice states:
> >> - several payment hashes with their corresponding amounts
> >>
> >> - if all corresponding payment keys are shown: the obligation
> of <payee>
> >> to deliver Z, UNLESS stated otherwise by an invoice signed by
> <payer>
> >>-- signed by <payee>
> >>But if a payment partially fails, it can be refunded
> cooperatively with
> >> an invoice created by payer:
> >> - declares which of the original payments were successful (with
> payment
> >> keys) and which were not
> >>
> >> - replaces the obligation of <payee> to deliver Z with an
> obligation to
> >> refund the successful transactions
> >>
> >> - several payment hashes with their corresponding amounts
> >>
> >> - if all corresponding payment keys are shown: cancel the
> obligation of
> >> <payee> to refund
> >>-- signed by <payer>
> >>Maybe this can be repeated iteratively if necessary; hopefully the
> >> not-yet-settled amount will converge to zero.
> >>Important advantage: this only requires changes to the invoice
> format,
> >> not to the network protocol.
> >>The point is: in this use case, the court is apparently the
> final point
> >> of settlement for invoices, just like the blockchain is for the
> other
> >> channels in the route. IANAL, but I think the "scripting language"
> >> accepted by courts is quite flexible, and you can use that to
> enforce
> >> atomicity. With the construction described above, you can
> either refund
> >> cooperatively (and collect evidence that refund has happened),
> or, if
> >> that fails, go to court to enforce settlement there.
> >>CJP
> >>Op 12-02-18 om 10:23 schreef Christian Decker:
> >>>CJP cjp at ultimatestunts.nl <mailto:cjp at ultimatestunts.nl> writes:
> >>>>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.
> >>>> The scenario that is commonly used in these cases is a
> merchant that
> >>>> provides a signed invoice "if you pay me X with payment_hash
> Y I will
> >>>> deliver Z". Now the user performs the payment, learns the
> payment_key
> >>>> matching the payment_hash, but the merchant refuses to
> deliver, claiming
> >>>> it didn't get the payment. Now the user can go to a court,
> present the
> >>>> invoice signed by the merchant, and the proof-of-payment, and
> force the
> >>>> merchant to honor its commitment.
> >>>>
> >>>Lightning-dev mailing list
> >>>Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> >>>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>>
> >>Lightning-dev mailing list
> >>Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> >>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >Lightning-dev mailing list
> >Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> >https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto: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

2023-06-09 12:49:04

- reply

📅 Original date posted:2018-02-12
📝 Original message:
I was thinking that, for that use case, a different signed invoice could
be formulated, stating
* several payment hashes with their corresponding amounts
* the obligation of signer to deliver Z if all corresponding payment
keys are shown
* some terms to handle the case where only a part of the payments was
successful, e.g. an obligation to refund
The third item is a bit problematic: in order to distinguish this case
from a complete success, the payee would have to prove *absence* of
successful transactions, which is hard. Absence of successful
transactions can only be declared by the payer, so in order to reliably
settle *without* going to court first, the payer should sign a
declaration stating that certain transactions were canceled and that the
other ones should be refunded. This can be another invoice.
So, the original invoice states:
* several payment hashes with their corresponding amounts
* if all corresponding payment keys are shown: the obligation of <payee>
to deliver Z, UNLESS stated otherwise by an invoice signed by <payer>
-- signed by <payee>
But if a payment partially fails, it can be refunded cooperatively with
an invoice created by payer:
* declares which of the original payments were successful (with payment
keys) and which were not
* replaces the obligation of <payee> to deliver Z with an obligation to
refund the successful transactions
* several payment hashes with their corresponding amounts
* if all corresponding payment keys are shown: cancel the obligation of
<payee> to refund
-- signed by <payer>
Maybe this can be repeated iteratively if necessary; hopefully the
not-yet-settled amount will converge to zero.
Important advantage: this only requires changes to the invoice format,
not to the network protocol.
The point is: in this use case, the court is apparently the final point
of settlement for invoices, just like the blockchain is for the other
channels in the route. IANAL, but I think the "scripting language"
accepted by courts is quite flexible, and you can use that to enforce
atomicity. With the construction described above, you can either refund
cooperatively (and collect evidence that refund has happened), or, if
that fails, go to court to enforce settlement there.
CJP
Op 12-02-18 om 10:23 schreef Christian Decker:
> CJP <cjp at ultimatestunts.nl> writes:
>> 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.
> The scenario that is commonly used in these cases is a merchant that
> provides a signed invoice "if you pay me X with payment_hash Y I will
> deliver Z". Now the user performs the payment, learns the payment_key
> matching the payment_hash, but the merchant refuses to deliver, claiming
> it didn't get the payment. Now the user can go to a court, present the
> invoice signed by the merchant, and the proof-of-payment, and force the
> merchant to honor its commitment.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev