CJP [ARCHIVE]

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

Public Key

npub13q863scgpsaanrjhfn7dd4h48lgnupgkcs828arzj4pckrq8hh6s4cuzdm

Profile Code

nprofile1qqsgsragcvyqcw7e3et5elxk6m6nl5f7q5tvgr4r733f2sutpsrmmagjm2n4u

Author Public Key

npub13q863scgpsaanrjhfn7dd4h48lgnupgkcs828arzj4pckrq8hh6s4cuzdm

Show more details

Last Notes

2023-06-09 12:56:41

- reply

📅 Original date posted:2019-10-19
📝 Original message:
(Note to IAEA & others: this is not about nuclear technology. Feel free
to read it though.)
(Note 2: beware of awkward misspellings like atomic secret sexchange or
the like. I have no idea how to fix this.)
Hi,
I admit I spend way too little time reading this mailing list, but in
my recent futile attempt to get up-to-date, I got inspired by the
recent elliptic curve based smart contracting discussions. I'd like to
present my still somewhat half-baked solution to a problem I found in
the discussion. I believe my solution, Atomic Secrets Exchange, is
likely to have applications beyond this particular problem. In the
description below, I am assuming some future Lightning where elliptic
curve payment points are already used which allow EC arithmetic.
# The use case
The problem I'm trying to solve is in the proposed protocol for placing
bets, as described by Nadav[1]. The idea is:
* There is an oracle that promises to either publish p, or publish q,
at a certain point in time, for instance, based on some real-world
information.
* Alice and Bob place bets on what the oracle will publish: Alice pays
Bob if the oracle publishes p; Bob pays Alice if the oracle publishes
q.
* This can be realized by locking funds in two Lightning transactions:
one from Alice to Bob, which can be redeemed by Bob with knowledge of
p, and one from Bob to Alice, which can be redeemed by Alice with
knowledge of q. The time-out of these transactions must be after the
point of publication of the oracle.
The problem is that one of the two transactions will always be created
first; if, for instance, the tx from Alice to Bob is the first, then
Bob no longer has an incentive to create his tx to Alice. Not creating
the second tx results in a one-sided bet; this makes it risky to take
part in the protocol (in this case, Alice is the victim).
Nadav proposed a solution with a partially trusted escrow party. I will
try to find a solution without an escrow party.
#Solution outline
In my approach, the payment from Alice to Bob requires Bob to know p
*and* know a secret sa, which is initially only known by Alice.
Similarly, the payment from Bob to Alice requires Alice to know q *and*
a secret sb, which is initially only known to Bob. As long as they
don't reveal these secrets to anyone, these are bound to time out (or
voluntarily canceled), even after the oracle has spoken. This makes
them safe to be locked in in any order. After locking in the
transactions, Alice and Bob must reveal their secrets to each other, to
make the locked-in transactions equivalent to an honest, two-sided bet.
This changes the problem of atomically locking two transactions into
atomically exchanging two secrets.
Maybe the problem of atomically exchanging two secrets has already been
solved in a more elegant way (ECDH, anyone?), but I came up with this
method:
* Alice locks in a Lightning tx to Bob that requires Bob to know sa and
sb, and reveal at least sb to Alice.
* Bob then locks in a Lightning tx, with a similar amount of funds,
back to Alice that requires Alice to know sa and reveal sa to Bob. This
must time out sooner than the first tx.
* Alice redeems the second tx, revealing sa to Bob.
* Bob redeems the first tx, revealing sb to Alice.
Note that Bob can actually 'split the atom' by not redeeming the first
tx, but he receives a penalty for this that roughly equals the tx
amount. This amount can be made sufficiently large (in comparison to
e.g. the bet) as required to move Bob's incentives towards honest
behavior.
#Some details
In the application of paid bets, one detail is time-outs of the three
transactions. I believe this is the correct order:
* Locking in the bet txes
* Locking in the secrets exchange txes
* Time-out of the secrets exchange txes
* Publication by the oracle
* Time-out of the bet txes
Another "detail" is how to do the elliptic curve magic. This is my
beginners' attempt:
P = p*G
Q = q*G
SA = sa*G
SB = sb*G
Bet txes: PP_b0 = P+SA, PP_b1 = Q+SB
Secrets Exchange txes: PP_x0 = SA+SB, PP_x1 = SA
Bob has to know SA to verify the value of PP_x0, and to generate PP_x1.
I don't know if a subtract operation exists for elliptic curve points;
in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could
just tell Bob SA, e.g. as meta-data included in the first bet tx.
Similarly, Alice has to know SB to generate PP_x0; Alice could
calculate SB = PP_b1 - Q, or Bob could tell Alice SB, e.g. as meta-data
included in the second bet tx.
CJP
[1] idea 2 in https://lists.linuxfoundation.org/pipermail/lightning-dev
/2019-October/002213.html

2023-06-09 12:53:43

- reply

📅 Original date posted:2019-01-02
📝 Original message:
Regarding this subject, I believe I should disclose that my current
employer, Bitonic, operates an evil, centralized, trusted exchange, and
that the ideas discussed in this thread may be related to concepts that
are actually being developed by my employer.
So, am I biased? Who knows? Does it matter? Can you trust me? Maybe,
but I guess you shouldn't anyway. In my view, words should be
convincing or unconvincing regardless of who speaks them.
CJP
CJP schreef op vr 28-12-2018 om 09:27 [+0100]:
> Hi ZmnSCPxj,
>
> I think we've already addressed this issue before:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/00
> 12
> 92.html
>
> and especially this proposal of me:
> https://bitonic.nl/public/slowdown_prevention.pdf
>
> It's not completely trustless, but I tend to see trustlessness in a
> very pragmatic sense anyway. Trust creates a risk, but if the
> alternative trustless system is very impractical, and the risk is
> small
> enough, the benefits might simply be worth the risks. Note that this
> is
> a completely subjective trade-off, so it is only acceptable on an
> individual, voluntary basis.
>
> CJP
>

2023-06-09 12:53:42

- reply

📅 Original date posted:2019-01-02
📝 Original message:
ZmnSCPxj schreef op wo 02-01-2019 om 13:02 [+0000]:
> I wonder however if this is a "small enough" hole that leaving it is
> an acknowledged security vulnerability may be better than replacing
> it with a trusted third party.
> One may compare with the SSH "trust the first pubkey, verify the
> second onwards" weakness, to SSL "trust the certificate authority to
> say whose pubkey is whose".
SSH's problem (non-authenticated initial key exchange) is small,
because there is a very small time window for an attack, and an
attacker has to place itself in the route *and* stay in the route to
not be detected later.
SSL's problem (trusted third parties for key authentication) is big,
because each website only uses a single certificate issuer, so you need
to trust every certificate issuer to be able to visit every website,
even the more questionable certificate issuers; the combined security
is as strong as the weakest certificate issuer.
Route Makers (RM) (maybe I should change that name) are not a big
problem, because, unlike websites, OMs and OTs are very fungible
towards each other, especially on popular asset pairs: it's not a big
deal if you lose, say, 10% of potential trading partners because you
don't want to use a certain RM. Also, a single attack by a RM is not
typically a big deal, and it is easily detectable. False positives are
possible though (both accidental and deliberate), so you might want to
suspend a RM after abuse detection for a while, and then give it
another chance after some time.
> The hop node just before the RM can provide proof that it offered an
> HTLC and the RM allowed the HTLC offer to be made.
> It can provide a commitment transaction signed by itself and the RM,
> with that commitment transaction containing the HTLC in question.
> This is proof that the RM *could* pull the HTLC, but did not do so
> quickly enough.
>
> Since RM nodes are publicly known, perhaps we can make a different
> routing from S to RM, one that reveals (to hop nodes) their distance
> to RM, but not to S.
> RM nodes provide a service to the network and we can argue that the
> loss of their privacy here is acceptable, as long as the payee S is
> still able to keep its privacy, as an acceptable cost to ensuring
> that RM behaves honestly.
>
> If the just-before-last node (let us call this G or "guard" node) can
> monitor the time that RM pulls the HTLC, then it can provide proof
> that RM had the ability to pull the HTLC but did not do so.
This, and the rest of your proposal, sounds like a lot of trouble,
while it hardly solves anything.
RM can have its node surrounded by other nodes also controlled by
itself. So it is possible that RM controls all nodes that can possibly
fulfill the 'G' role, and thereby stop any evidence being generated
against the RM node. If you then want to build evidence against the G
nodes, you end up recursively involving every single Lightning node in
trying to solve your problem. Maybe it is possible, but I'd like not to
do that. I like to see the exchange function as a higher layer (layer
3) on top of the Lightning layer, and have each layer solve its own
problems in a clean and elegant way. I prefer that nodes that aren't
involved in exchanging assets don't need to deal with its complexities
either.
CJP

2023-06-09 12:53:40

- reply

📅 Original date posted:2018-12-29
📝 Original message:
> 1.  It seems to me that there is still friction here.
>     RM, being a trusted third party, may very well charge as much as
> the market will bear. https://nakamotoinstitute.org/trusted-third-par
> ties/
>     This seems to me to imply that OM (i.e. exchange nodes) will be
> unable to extract any sizable fee, i.e. any fees that the market
> would be willing to pay to exchange between assets will be taken by
> RM as rent, and not by the OM who actually makes the market exist in
> the first place.
You may be right about the fees, but that doesn't necessarily make it
an unattractive proposition for the OM party.
When looking at different alternatives by sorting them in a
better/worse fashion rather than a perfect/imperfect fashion, I see
this:
* No exchange: unattractive, because there is significant demand for
this.
* Regular Lightning-based or other HTLC-like atomic swap: unattractive,
because of the exploitable "American Call Option" nature (as we both
described). May only function with a very high spread, compensating for
OM's risk.
* Regular, centralized exchanges: current situation. Third party is
trusted with holding funds and executing trade orders.
* My proposal: third party is trusted with executing transactions
properly (not performing the delay attack).
* Trustless exchange: holy grail, but I don't know how to do that.
So I don't claim my proposal is perfect, but I'd like to argue it is
the best known system because it's an improvement over the current
situation where most people use centralized exchanges, at least in
terms of trust required(*). To compare the two:
I'd like to compare the RM role in my proposal to that of a centralized
exchange. Both need to be trusted to some degree, and since trust
doesn't scale very well (you can't keep track of thousands of parties),
both are probably a natural oligopoly market. As you wrote, these are
the parties that are capable of extracting the majority of transaction
fees. Still, as centralized exchanges show, people are prepared to
trade this way, so apparently it's still an attractive market for both
offer-makers and -takers.
I think the market for RM services in my proposal is more competitive
(and therefore has lower fees) than regular, centralized exchanges,
because:
* trust requirements are lower, so people are more likely to trust a
small, unknown company offering RM services. People using smaller
parties = more parties in the market = lower fees.
* OMs can easily offer the same funds for use with different RM
parties. This is not possible with regular exchanges(**): if you
deposit funds on one exchange, you can't also deposit them on another
exchange, so you have to commit your funds to a single exchange.
Finally, I think the attack RMs can perform on trading parties is an
order of magnitude smaller than the attack a regular exchange can
perform by stealing deposited funds: a RM can only steal the *exchange
rate change* of funds offered for trade, not the full value.
Now, if an RM can be punished, it would be even better. I was thinking
in the direction of collecting proof of misbehavior, which can then
help make the RM lose its (lucrative!) business, but I doubt this is
possible.
CJP
(*) not necessarily in latency: the low latency of centralized
exchanges can be hard to match, even on Lightning.
(**) as long as you can't go short

2023-06-09 12:53:39

- reply

📅 Original date posted:2018-12-28
📝 Original message:
Hi ZmnSCPxj,
I think we've already addressed this issue before:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/0012
92.html
and especially this proposal of me:
https://bitonic.nl/public/slowdown_prevention.pdf
It's not completely trustless, but I tend to see trustlessness in a
very pragmatic sense anyway. Trust creates a risk, but if the
alternative trustless system is very impractical, and the risk is small
enough, the benefits might simply be worth the risks. Note that this is
a completely subjective trade-off, so it is only acceptable on an
individual, voluntary basis.
CJP
ZmnSCPxj via Lightning-dev schreef op do 27-12-2018 om 05:43 [+0000]:
> HTLCs as American Call Option, or, How Lightning Currently Cannot
> Work Across Assets, or, An Argument For Single-Asset Lightning
> Network
>
> Introduction
> ============
>
> In theory, the Lightning Network could potentially perform "seamless"
> currency conversions, allowing a payer to spend one currency to pay a
> payee requesting for another currency.
> However, a significant technical barrier prevents implementation of
> such feature as of current designs (late 2018) for Lightning.
>
> The root cause of this significant technical barrier is the use of
> hashlocked timelocked contracts to route payments.
> HTLCs can be used across cryptocurrency systems to transfer value
> between them.
> From this point-of-view, every single Lightning Network channel is a
> cryptocurrency system whose custodians are two entities, who are the
> only entities who can use the system (the single Lightning Network
> channel).
> HTLCs allow cross-system trades to be performed, so that
> participation on any single Lightning Network channel can be
> leveraged to participation over the entire Lightning Network.
>
> However, HTLCs can also be used to construct American Call Options.
> Further, due to UX concerns, on the Lightning Network, there is no
> cost incurred in merely setting up HTLCs for routing.
> By using the low-level HTLCs provided as primitives by Lightning
> Network, one can set up American Call Options.
> These on-Lightning American Call Options, however, can be "purchased"
> for free (gratis), thus potentially earning money in a completely
> risk-free manner.
> Abusing this gratis ability means that any Lightning Network node
> advertising cross-asset on-Lightning exchange will find large amounts
> of its liquidity tied up in stalled forwarding payments (in reality,
> American Call Options) with a risk of monetary loss in case of large
> fluctuations in exchange rate.
>
> Hashlocked Timelocked Contracts as American Call Options
> ========================================================
>
> An American CallOption is a right (but not obligation) to purchase an
> asset at a specific price, on or before an expiration date.
> HTLCs allow building American Call Options.
>
> Suppose we have Bitcoin, and some other asset, and both are on
> blockchains that support the same hash function and can define HTLCs.
> It is unimportant if both are on the same blockchain, or on different
> blockchains, since HTLCs can work across cryptocurrency systems.
>
> An American Call Option has these properties:
>
> 1.  `P` = the price at which the asset can be purchased.
> 2.  `E` = the date at which the option expires.
>
> Suppose I, ZmnSCPxj, wanted to sell you an American Call Option  for
> 1 Widget (WJT) on the WJT blockchain.
> We would then do the below ritual:
>
> 1.  You provide me a hash of some secret preimage that only you know.
> 2.  You make an HTLC on the Bitcoin blockchain.
>     The value of this HTLC is `P`, the hash is the hash you gave
> above, and the timelock is `E` + 1 day.
> 3.  I make an HTLC on the WJT blockchain.
>     The value of this HTLC is 1, the hash is the hash you gave, and
> the timelock is `E`.
>
> On or before `E`, you can claim the WJT on the WJT blockchain by
> providing a transaction that reveals the preimage.
> Since the preimage is now revealed, I can then claim the Bitcoins of
> price `P` on the Bitcoin blockchain.
> Alternately, you can simply not exercise this right, and at time `E`
> I would then reclaim my WJT, and at time `E` + 1 day you would
> reclaim your bitcoins.
>
> Of course, I want to *sell* this contract to you, so you would have
> to pay me some bitcoins before we set up the above.
> A multi-stage construction of transactions that go through HTLC-like
> constructs can be done on both blockchains to ensure that the above
> contracts appear on both chains only if the payment for the actual
> contract (i.e. the "premium") is done, and to enforce that both
> contracts appear if the premium is paid, but that is beyond the scope
> of *this* writeup, which will focus on how Lightning Network HTLCs
> can form the above construction without any premium being paid.
>
> HTLCs For Routing
> =================
>
> HTLCs can be used to enforce trades across different cryptocurrency
> systems.
> This property is used to allow routing of payments across different
> channels.
> Each channel is its own cryptocurrency system.
>
> Suppose I, ZmnSCPxj, am an intermediate node on Lightning, and I
> wanted to sell you my service of facilitating payments on Lightning.
> Suppose you want to pay to somebody, who, for the sake of
> convenience, we shall randomly call YAIjbOJA.
> As it happens, I have a channel with you, and a channel with
> YAIjbOJa.
>
> You need to pay YAIjbOJA `P` bitcoins.
> We then perform the below ritual:
>
> 1.  YAIjbOJA provides you a hash, whose preimage only YAIjbOJA knows.
> 2.  On your channel with me, you set up an HTLC.
>     The value is `P`+1 bitcoin (the 1 being my fee), the hash is the
> hash you were given, and the timelock is 2 days from now.
> 3.  On my channel with YAIjbOJA, I set up an HTLC.
>     The value is `P`, the hash is the same hash as above, and the
> timelock is 1 day from now.
>
> (in reality, the timelocks are parameterized and selected by the
> payer (you), and LN nodes will impose some "reasonable" limits on the
> timelocks; but the first HTLCs set up must have longer timelocks than
> the later HTLCs)
>
> Afterward, YAIjbOJA may claim, or may not claim, the money in the
> HTLC by releasing (or not releasing) the hash to me.
> If YAIjbOJA claims the money, then I can take the hash and claim the
> money, plus fee, from you.
> If not, then this is a payment failure and I will then cancel the
> HTLC you offered using standard Lightning Network primitives.
>
> In general, we expect that YAIjbOJA wants to have the money because
> every randomly-generated imaginary entity likes money.
> Thus, in the case of payments, YAIjbOJA has a strong incentive to
> claim the money without waiting for the timelock to expire or nearly
> expire.
> We can see that in practice, on the current Lightning Network, HTLCs
> are often very transient and will be quickly claimed, despite having
> long timelocks.
>
> This speed may mislead us into thinking that such convenience may be
> possible across different assets.
>
> Cross-Asset Lightning Nodes Offer Premium-Free American Call Options
> ====================================================================
>
> Suppose that Lightning Network supports multiple assets.
> Each channel has a single asset.
> Some nodes will advertise themselves as providing exchange
> capability, taking one asset on one channel and exchanging it for
> another asset on a different channel.
>
> Suppose I advertise myself as such an exchange.
> Suppose you want to pay to YAIjbOJA for 1 WJT, but have no WJT on
> hand to pay YAIjbOJA, only bitcoins.
> As it happens, I have a bitcoin channel with you and a WJT channel
> with YAIjbOJA.
> I advertise myself as exchanging `P` bitcoins for 1 WJT as of the
> current time.
>
> Further suppose that in reality, YAIjbOJA is *you*, random Internet
> person reading my thoughts.
>
> You, your fake persona YAIjbOJA, and me, then perform the following
> ritual:
>
> 1.  YAIjbOJA (really you) provides you with a hash whose preimage
> only YAIjbOJA (actually you) know. (i.e. you just make it up)
> 2.  On the bitcoin channel with me, you set up an HTLC.
>     The value is `P`+1 bitcoin (the 1 being my fee), the hash is the
> hash that "YAIjbOJA" gave you (i.e. you really just made it up), and
> the timelock is 2 days from now.
> 3.  On the WJT channel with YAIjbOJA (really you), I set up an HTLC.
>     The value is 1 WJT, the hash is the hash you gave me, and the
> timelock is 1 day from now.
>
> The above is now the same as the setup for an American Call Option
> with expiration of 1 day from now.
> Further, within certain limits, you can set up the expiration of the
> American Call Option to be longer or shorter.
> Thus, I have inadvertently given you an American Call Option, for *no
> premium* (completely gratis), when my only intent was to facilitate
> cross-currency Lightning Network payments.
>
> Suppose that the price of 1 WJT rises far above the price of `P`+1
> bitcoins before the expiration (1 day from now).
> In such a case, "YAIjbOJA" (really you) will then release the hash
> and acquire the 1 WJT.
> You then close this channel and claim the WJT onchain, then sell it
> immediately to earn more than the `P`+1 bitcoins you paid.
> Alternatively, presumably I would have a new exchange rate I would be
> willing to exchange WJT for, and you can just send the WJT with the
> new exchange rate immediately over the Lightning Network.
>
> Suppose that the price of WJT does not rise.
> Since this is an option and *not* a future, "YAIjbOJA" (really you)
> will simply claim that the payment errored somewhere and cancel the
> HTLCs.
> Since even payment errors are not unwrappable and are onion-wrapped,
> I cannot determine whether the payment really errored, or you were
> just setting up an American Call Option that you have now decided not
> to exercise.
>
> Premium-free American Call Options Are Risk-free Earning Pumps
> ==============================================================
>
> Traditionally, options are analyzed assuming that the option itself
> has a price, the premium.
> This premium is the risk of the user of the option.
> If the user of the option does not exercise the option before the
> expiration, then the premium is a pure loss of the user.
>
> However, the above setup does not involve any payment when the option
> is not exercised.
> Payment failures are "free" (gratis) on the Lightning Network.
> However, payment failures are also the non-exercised branch of the
> American Call Option that can be set up on a cross-currency on-
> Lightning exchange.
>
> Because the American Call Option is premium-free, even if the
> expiration is very near, rational entities will still construct such
> options.
> Extreme volatility may occur in short time frames, especially in the
> realm of digital assets.
>
> Thus, it is strongly likely that, if cross-asset exchange nodes on
> Lightning Network exist, they will be exploited to create risk-free
> American Call Options.
> They will find that significant liquidity will be tied up in such
> American Call Options, and find that they will lose funds especially
> at times of volatility.
>
> We can try to mitigate this, but the solutions below all have
> significant drawbacks.
>
> 1.  We could force that setting up the HTLCs requires payment.
>     This forces the above American Call Options to have a premium.
>     The effect, however, is that routing failure is not free.
>     The current Lightning Network works despite not everyone
> publishing the balances of channels, precisely because routing
> failure is free.
>     We only need to have one route succeed in order to actually
> successfully pay to the payee.
>     With non-free routing failure, we cannot try many routes until
> one succeeds.
>     * Suppose we limited this only to cross-asset exchanges.
>       It would still require accurate knowledge of channel balances.
>       This is because if a payment fails on a hop *after* the
> exchange, the payer still loses money from that attempt to the
> exchange node.
> 2.  Exchange nodes could increase their fees.
>     This would create a wider "spread" of buying and selling assets.
>     This spread would increase friction in crossing assets.
>     Also, this would only reduce risk; if the exchange rate is
> volatile enough, then the option could still be exercised for
> riskless earnings.
>     Rational entities will still tie up most of the liquidity on the
> exchange on riskless American Call Options; even if the exchange rate
> is very stable, they lose nothing.
> 3.  Exchange nodes could limit the timelock of cross-asset swaps.
>     This would increase friction in crossing assets, since a timelock
> limit also imposes a limit to the route length.
>     If one asset is much stronger than the other, then the weaker
> asset will find its part of the Lightning Network to be strongly
> centralized around the exchanges between the two assets.
>     Payees of the weaker asset will strongly prefer to be at most one
> hop away from exchanges in order to viably receive payments from
> payers who are using the stronger asset.
>     Again, rational entities will also still tie up most of the
> liquidity on the exchange on riskless American Call Options; again,
> even if the exchange rate is very stable in short time frames, they
> lose nothing anyway.
>
> Conclusion
> ==========
>
> HTLCs allow creation of American Call Options.
> The same HTLCs are used in Lightning Network to route across
> channels.
> If using a single asset, there is no issue related to time.
> Regardless of the value of bitcoin relative to any other asset, in
> the future, 1 BTC is 1 BTC.
>
> However, across assets, the ability of HTLCs to create American Call
> Options becomes troublesome.
> These can then be exploited to earn money from exercise of the
> option.
> Further, because Lightning UX would be degraded otherwise, payment
> failures are free (gratis), leading to the American Call Options also
> being free of premium.
> This means that creating such options would be riskless, allowing
> potential earnings upon any strong volatility of exchange rates.
>
> This implies that a multi-asset Lightning Network may not be
> economically viable.
> Instead, Lightning Network would strongly prefer having a single
> asset across the network.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:52:10

- reply

📅 Original date posted:2018-11-05
📝 Original message:
I think it's true that most of my proposal can be achieved by writing
such things in human-readable form in the description field. Mostly,
the only thing my proposal does is to put things into a machine-
readable form; this may aid in automated processing and maybe a better
UI experience.
Maybe the least trivial thing is the inclusion of a payer pubkey in the
original invoice; this is the least trivial both in protocol complexity
and in potential benefits. One benefit is that it turns a "proof-that-
someone-paid" into a "proof-that-I-paid"; another benefit is that it
becomes clear who is authorized to issue another invoice that says
"this original invoice is nullified".
Now that I think of it: my proposal has something important that yours
doesn't: the requirement to have *two* signatures (both payer and
payee) on each update. Without that requirement, there is one party who
can nullify the old contract by making a unilaterally signed invoice
and a self-generated payment preimage. Not even a need to do a payment
to self to "fake" a sort of a refund payment or so. This may be OK as
long as there is only one party who has obligations: then the other
party may partially or completely nullify those obligations, optionally
dependent on a payment. Requiring two signatures (and thereby
consensus) on each update is more generic though: it allows for
obligations on both parties.
Even more generic could be to allow more than two parties. I'm sure
there are complex business arrangements that have a need for this, but
I think we can always develop that later. Let's first tackle this
relatively simple case.
CJP
ZmnSCPxj schreef op ma 05-11-2018 om 01:20 [+0000]:
> Good morning CJP,
>
> It seems to me, naively, that we can encode the description "the
> obligation in the invoice whose hash is <h> is nullified", whose
> meaning then is promoted to "if payment happens, payee has an
> obligation to ensure that the obligation in the invoice whose hash is
> <h> is nullified", then we have revokable payments already.  Such a
> payment may itself be revoked, ad infinitum.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, November 5, 2018 5:08 AM, CJP <cjp at ultimatestunts.nl>
> wrote:
>
> > Right now, the only defined semantics of the description field in
> > BOLT11 is that it SHOULD be "a complete description of the purpose
> > of
> > the payment". I think this is a bit vague; maybe this is
> > deliberate?
> >
> > Anyway, you may also think of a BOLT11 payment request as an option
> > contract. If the payment is performed (which can be proven by
> > showing
> > the preimage), then payee is bound to the terms and conditions in
> > the
> > description. So, then the meaning of a description "one cup of
> > coffee"
> > becomes "if payment happens, payee has an obligation to deliver one
> > cup
> > of coffee".
> >
> > A known issue is that payer is not identified in the contract, so
> > it is
> > not clear to who the payee has this obligation. As far as I can
> > see,
> > the only way to fix this is to have two-way communication, where
> > first
> > the payer sends some data to payee (e.g. public key), and then
> > payee
> > makes the payment request, including this data. With this
> > established,
> > we turn the preimage + payment request from a "proof that someone
> > paid"
> > into a "proof that I paid", and therefore also a "proof that payee
> > has
> > this obligation to me".
> >
> > I'm a bit afraid that such proofs are a bit too inflexible for
> > real-
> > life applications. I think in real-life there are many cases where
> > you
> > need to update / revoke agreements, even after payment.
> >
> > One example is a full refund: if goods/services cannot be delivered
> > somehow, payer+payee might agree to a full refund instead of
> > delivery
> > of goods/services. The refund is another payment, with a payment
> > request made by the original payer; its contract should state that
> > the
> > original payee is no longer bound by the obligations in the
> > original
> > contract.
> >
> > Another example is a partial refund, for instance if only a lower
> > quantity or a lower quality of goods/services is delivered. This is
> > another payment, but now the new contract replaces the old contract
> > and
> > specifies a new, lower set of obligations for the original payee.
> >
> > Another example is a change of conditions without change of
> > payment,
> > for instance when a white/gold dress was ordered, but turned out to
> > be
> > unavailable, and payer finds a black/blue dress acceptable as well,
> > at
> > equal price. Then you'd just want to replace white/gold in the
> > contract
> > by black/blue, without any payment.
> >
> > I think nearly all cases (including ones not mentioned here) are
> > covered by a "contract update" format which includes:
> >
> > -   the new obligations of the two parties to each other
> > -   a secure hash of the previous contract version that is replaced
> > by
> >     this one
> >
> > -   optionally, a payment hash
> > -   signatures from both parties
> >
> >     The contract update is considered valid if and only if
> >
> > -   the signatures correspond to the pubkeys in the original
> > contract
> >     (the first in the chain)
> >
> > -   the signatures are valid signatures on this contract
> > -   the previous contracts in the chain are all valid (except for
> > being
> >     invalidated by contract updates)
> >
> > -   there is no known valid contract that replaces this one
> > -   if a payment hash is included, a corresponding payment preimage
> > is
> >     provided as well
> >
> >     The original contract is different in that
> >
> > -   It does not have a previous contract version (may be zeroed if
> > you
> >     want to keep the same format)
> >
> > -   A set of pubkeys is provided (one of payer, one of payee)
> > -   Only payee has obligations, so payee never needs to receive a
> >     signature from payer. Payer needs to receive payee's signature,
> > and can
> >     trivially add his own signature whenever needed.
> >
> >     Whenever one payee has obligations to another, the pubkey of
> > the party
> >     with obligations has to be verified through some PKI. I
> > consider this
> >     to be outside the scope of this concept. Especially in the case
> > that
> >     one of the parties never has any obligations, that party may
> > use a new,
> >     non-PKI-verified pubkey for the transaction, as a temporary
> > pseudonym.
> >
> >     There is some conceptual similarity between an updateable proof
> > of
> >     payment and a payment channel.
> >
> >     A potential issue is that, theoretically, the "contract update
> > chain"
> >     can fork. The simple solution is "don't do that": either party
> > can stop
> >     it from happening by not signing the forking update.
> >
> >     CJP
> >
> >
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>

2023-06-09 12:52:09

- reply

📅 Original date posted:2018-11-04
📝 Original message:
Right now, the only defined semantics of the description field in
BOLT11 is that it SHOULD be "a complete description of the purpose of
the payment". I think this is a bit vague; maybe this is deliberate?
Anyway, you may also think of a BOLT11 payment request as an option
contract. If the payment is performed (which can be proven by showing
the preimage), then payee is bound to the terms and conditions in the
description. So, then the meaning of a description "one cup of coffee"
becomes "if payment happens, payee has an obligation to deliver one cup
of coffee".
A known issue is that payer is not identified in the contract, so it is
not clear to who the payee has this obligation. As far as I can see,
the only way to fix this is to have two-way communication, where first
the payer sends some data to payee (e.g. public key), and then payee
makes the payment request, including this data. With this established,
we turn the preimage + payment request from a "proof that someone paid"
into a "proof that I paid", and therefore also a "proof that payee has
this obligation to me".
I'm a bit afraid that such proofs are a bit too inflexible for real-
life applications. I think in real-life there are many cases where you
need to update / revoke agreements, even after payment.
One example is a full refund: if goods/services cannot be delivered
somehow, payer+payee might agree to a full refund instead of delivery
of goods/services. The refund is another payment, with a payment
request made by the original payer; its contract should state that the
original payee is no longer bound by the obligations in the original
contract.
Another example is a partial refund, for instance if only a lower
quantity or a lower quality of goods/services is delivered. This is
another payment, but now the new contract replaces the old contract and
specifies a new, lower set of obligations for the original payee.
Another example is a change of conditions without change of payment,
for instance when a white/gold dress was ordered, but turned out to be
unavailable, and payer finds a black/blue dress acceptable as well, at
equal price. Then you'd just want to replace white/gold in the contract
by black/blue, without any payment.
I think nearly all cases (including ones not mentioned here) are
covered by a "contract update" format which includes:
* the new obligations of the two parties to each other
* a secure hash of the previous contract version that is replaced by
this one
* optionally, a payment hash
* signatures from both parties
The contract update is considered valid if and only if
* the signatures correspond to the pubkeys in the original contract
(the first in the chain)
* the signatures are valid signatures on this contract
* the previous contracts in the chain are all valid (except for being
invalidated by contract updates)
* there is no known valid contract that replaces this one
* if a payment hash is included, a corresponding payment preimage is
provided as well
The original contract is different in that
* It does not have a previous contract version (may be zeroed if you
want to keep the same format)
* A set of pubkeys is provided (one of payer, one of payee)
* Only payee has obligations, so payee never needs to receive a
signature from payer. Payer needs to receive payee's signature, and can
trivially add his own signature whenever needed.
Whenever one payee has obligations to another, the pubkey of the party
with obligations has to be verified through some PKI. I consider this
to be outside the scope of this concept. Especially in the case that
one of the parties never has any obligations, that party may use a new,
non-PKI-verified pubkey for the transaction, as a temporary pseudonym.
There is some conceptual similarity between an updateable proof of
payment and a payment channel.
A potential issue is that, theoretically, the "contract update chain"
can fork. The simple solution is "don't do that": either party can stop
it from happening by not signing the forking update.
CJP

2023-06-09 12:52:08

- reply

📅 Original date posted:2018-11-05
📝 Original message:
Rusty,
In your proposal, I guess it is more or less widely known that Bob is
providing this forwarding service. Wouldn't Bob risk being excluded
from the side of the network with the more harsh regulatory conditions,
based on this knowledge? Bob might actually face even worse penalties
for providing such a service.
The nice thing about rendez-vous routing is that *any* forwarding node
can be a rendez-vous point, and even the node itself wouldn't know
about it. The case where a payment is routed from and to the same
channel could be a hint though: normally that makes no sense, but if
payer and payee make their part of the route independently, the
combined route can often end up like that. TODO: check if forwarding
nodes are currently cool with such weird forwarding requests.
CJP
Rusty Russell schreef op ma 05-11-2018 om 10:56 [+1030]:
> CJP <cjp at ultimatestunts.nl> writes:
> > > Looking through BOLT 4, the text assumes inherently that source
> > > routing is done, and even has a shared secret between hop and
> > > source.  However, it may be possible in rendezvous routing to
> > > simply
> > > provide the blinding key (while hiding everything beyond the
> > > first
> > > hop on the destination half of the route).
> >
> > Sounds like it makes sense; I need to look into it.
>
> Here's my attempt to design a "merchant forward" service using stuff
> we
> have today.
>
> Alice wants to remain anonymous, even from the lightning
> network.  Bob's
> node offers a forwarding service.  Alice pays Bob (base +
> percentage?),
> gives a path Bob->Alice, and Bob gives Alice a short-channel-id
> (BobAliceSCID) and privkey to use (BobAliceSecretKey).  Anything sent
> from Bob to this short channel id and pubkey is in fact forwarded via
> a
> new HTLC to Alice.
>
> Alice identity BobAliceKey to create an invoice, with a route-hint to
> say pubkey=Bob, short_channel_id=BobAliceSCID.  Alice can sign
> that invoice, and Bob can decode the incoming payment, from which it
> creates a new HTLC to pay Alice.  The payer doesn't even know this
> arrangement exists: it looks exactly like Alice has a private channel
> with Bob.
>
> The minor downside: because we conflate invoice keys (Alice needs)
> and
> onion keys (Bob needs), Bob can now issue invoices as Alice.  It's
> not
> very useful, since Alice won't honor them, but it is an argument for
> a separate invoice key in future.
>
> Cheers,
> Rusty.

2023-06-09 12:52:07

- reply

📅 Original date posted:2018-11-04
📝 Original message:
Imagine a future where some powerful participant in the Lightning
network starts enforcing KyC requirements on Lightning nodes. It
requires its direct neighbors to reveal their identity or else closes
channels to them. Next, it asks its direct neighbors to reveal the
identity of their direct neighbors (or close their channels), with the
threat of either channel closure, or (using the now-known identity)
more extreme penalties.
I guess this would lead to a split of the Lightning network into a
compliant and a non-compliant part, with no ability to perform payments
between the two. If we want to keep the Lightning network inclusive,
anonymous and free of central authorities who can impose arbitrary
rules, this is an undesirable scenario.
The enabler of this scenario is the fact that, to allow source routing,
we need a public channel map of the network.
We have a sort-of-a counter measure called "private channels", which
are channels that exist, but whose existence is not published. A
private channel might bridge the gap between a compliant and a non-
compliant part of the network, but it has a problem: in order to allow
payments from one side to the other, the payer has to know about the
private channel. If there are lots of payers who have to cross the gap
and use the private channel, the existence of the private channel will
leak out sooner or later. The node owner on the compliant side of the
private channel, presumably having violated the rules by operating a
private channel, risks penalties. Therefore, I think private channels
are not a very suitable way to keep the network undivided and inclusive
and to bridge the gap between different regulatory/non-regulatory
domains.
I propose another solution: rendez-vous routing. The idea is that the
payee chooses one or more routes from certain third-party nodes in the
network to himself and passes sphinx-encrypted blobs for those routes
to the payer (for instance, as part of a payment request). The payer
completes the route by finding routes from himself to those third-party
nodes, and tries to perform the payment over these routes. Of course,
payee has to tell payer how many hops payer may add to a route,
somewhat revealing how much privacy payee wants for himself.
I believe this approach has the following properties:
* It is a superset of the regular approach to routing: the old approach
is simply the special case where payee defines 0 of the 20 hops.
* Payee may lead the route over private channels without revealing the
existence of those private channels to payers. Of course the private
channel still needs to be known to payee; it is probably most realistic
that such private channels are operated by payee himself.
* The payee node may still be a node inside the "compliant" section of
the network; it's just that nobody (not even payer) can see which node
it is. So, even when your node is linked to your identity, your
activities (even as payee) are not linked to your identity.
I guess we already discussed this before, but I just wanted to have a
clear place to discuss this idea, and I couldn't find any clear past
discussion about this in the mailing list.
There might be alternative approaches, such as not routing between
incompatible regulatory domains, but simply having nodes on each
network if you need to, and simply move funds on-chain between your
nodes whenever needed. That will require on-chain mixing though.
CJP

2023-06-09 12:52:07

- reply

📅 Original date posted:2018-11-04
📝 Original message:
ZmnSCPxj schreef op zo 04-11-2018 om 14:34 [+0000]:
> Good morning CJP,
>
> I believe this is a desirable feature, although...
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, November 4, 2018 2:26 PM, CJP <cjp at ultimatestunts.nl>
> wrote:
>
> > Imagine a future where some powerful participant in the Lightning
> > network starts enforcing KyC requirements on Lightning nodes. It
> > requires its direct neighbors to reveal their identity or else
> > closes
> > channels to them. Next, it asks its direct neighbors to reveal the
> > identity of their direct neighbors (or close their channels), with
> > the
> > threat of either channel closure, or (using the now-known identity)
> > more extreme penalties.
> >
>
> For this particular scenario, it seems to me that it would be better
> for the rest of the network to punish this participant by closing any
> channel to this KYC-requiring participant, and also to do retaliatory
> preemptive closing of any channel to any participant publicly
> connecting, directly or indirectly, to that participant.  Or in
> short, to let that participant enforce whatever it wants to
> close.  This will greatly lower its fee earnings as well as its
> ability to monitor or control the network.  If every Lightning node
> refuses to reveal their identity (etc.) to this participant, then the
> participant will close all its channels and it will no longer be a
> powerful **participant** of Lightning, thus removing itself and its
> influence from Lightning in the most satisfying way possible, i.e.
> through shooting itself in the foot.
I disagree: you may not be in a position to freely close such channels
and remove your ability to transact with this party, similar to how you
may not be in a position to refuse to pay taxes. Also, since it is hard
to avoid (in the current situation) that some Lightning nodes have a
known link to legal entities like companies or persons, there are ways
outside the Lightning network to put pressure on node owners,
especially non-pseudonymous high-profile ones. This is, however, a non-
technical discussion; since we already agree on the desirability of the
feature, I suggest to keep it at this and focus on the technical
details.
> Nonetheless, I believe this feature is desirable, not for the above
> scenario, but simply so that a payee is not required to maintain even
> a pseudonym on the Lightning Network (the payee will still have to be
> somehow contactable so it can generate an invoice somehow, but at
> least it will not even have an identifiable pseudonym on-Lightning;
> perhaps it may have a pseudonym on some other network with better
> privacy).  If all its generated invoices use rendezvous routing, then
> while it, obviously, must have a Lightning node somewhere, that node
> is not easily identifiable among all Lightning nodes.
I guess that for most use cases a payee pseudonym is needed, unless
your use case is donating to random strangers. I only found one
exception: where the thing you pay for is cryptographically linked to
the Lightning payment (effectively, an atomic swap, like in a
Lightning-based decentralized exchange). In that case, a truly
anonymous (as opposed to pseudonymous) payee makes sense.
However, for use cases where the payee needs a pseudonym, it might
still be desirable to decouple that pseudonym from a location in the
Lightning network. Rendezvous routing can do that.
> Looking through BOLT 4, the text assumes inherently that source
> routing is done, and even has a shared secret between hop and
> source.  However, it may be possible in rendezvous routing to simply
> provide the blinding key (while hiding everything beyond the first
> hop on the destination half of the route).
Sounds like it makes sense; I need to look into it.
> I also think that, as the destination is choosing the nodes on its
> half of the route, that it should pay for fees, and thus the source
> is only required to deliver the specified amount to the first hop
> node of the destination half of the rendezvous route.
Agreed. The price agreed between payer and payee is the incoming amount
at the rendezvous point. In the "original" case that the payee-side
route is 0 hops long, the payee is the rendezvous point, and we're
equal to the original concept where the agreed-on price is the incoming
amount at the payee.
CJP

2023-06-09 12:50:58

- reply

📅 Original date posted:2018-06-27
📝 Original message:
Hi,
Currently, in Lightning, you need to get an invoice from the receiver
to be able to send a payment. But what if you want to do a payment
spontaneously, e.g. as a gift? I just realized this use case can be met
in quite a simple way.
You simply route the payment to the receiver's Lightning node (so you
do need to know the node ID). The routing message to the receiver's
node is of a special form, and includes the preimage. It might also
contain some (small!) other data: maybe the hash of a signed
description?
Anyway, if the receiver's node recognizes this routing message format,
it can then use the preimage to finish the transaction. It may also
cancel the transaction instead, if the node owner doesn't want to
receive unsolicited money.
The fun thing is, none of the intermediate nodes can use the preimage
to steal funds, since the routing data is encrypted.
I do realize that spontaneous payments can also be done with a "payment
to self" that just happens to give a very large fee to a particular
intermediate node. The new protocol has the advantages that it doesn't
need the second half of the route (back to self), it is clear to the
receiving node that this is in fact intended as a payment, and you may
be able to include a small message.
CJP

2023-06-09 12:50:44

- reply

📅 Original date posted:2018-05-12
📝 Original message:
Hi,
Maybe this is a stupid question, and it is late so maybe I'm
overlooking something, but I don't want to lose a potentially good
idea, so here it goes:
Right now, BOLT#3 imposes a certain algorithm for fee estimation. This
algorithm is likely to be sub-optimal: fee estimation is a difficult
subject, and may involve subjective situation-specific considerations
of participants. I guess it's only there to achieve some kind of
consensus between the peers.
But why do we need consensus at all? There are two versions of each
commitment transaction: one to be used for unilateral close by one peer
(A), and one to be used by the other (B). Peer A has an interest in
"commit transaction A", so I'd consider it fair to let peer A pay the
transaction fee for that commit tx (subtracted from its part of the
channel funds), and also to let peer A determine the amount of that
fee. If A wants a different fee for whatever reason, it should simply
be able to ask B for a signature on an updated "commit transaction A".
B shouldn't care about that fee, as long as its own funds, HTLCs etc.
are OK.
I guess, when only changing the fee, you don't even need to use a new
revocation secret. Your peer may have different versions which only
differ in how much fees your peer pays, and you 'll never care which of
them will be used by your peer. Not using a new revocation secret may
or may not be a premature optimization though.
If a peer doesn't have enough funds to pay a reasonably effective tx
fee, normally that shouldn't be a problem, because then it doesn't have
a significant financial interest in having a usable commit tx either.
The only exception is if there are significant HTLCs. Is this where the
idea breaks down? As far as I can see, this is an exceptional (but
important) case, but during normal operation, peers should be free to
choose the fee for their own commit tx.
You'd have to deal with any follow-up transactions as well: changing a
fee changes the txID, so you need to update follow-up transactions.
regards,
CJP

2023-06-09 12:49:01

- reply

📅 Original date posted:2018-02-09
📝 Original message:
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

2023-06-09 12:47:24

- reply

📅 Original date posted:2017-06-13
📝 Original message:
Hi,
=======
Problem
=======
One major vulnerability of the Lightning network is that, if someone
wants to perform a DoS attack on the network, that possible for the
attacker by sending many large transactions to himself, over a long
route, and letting them time out (never reveal the payment pre-image).
Nobody (including the attacker) gains or loses any funds, but a lot of
funds get locked up, and the total cost of lost opportunity to innocent
nodes is a lot higher than that of the attacker.
In Milan, we came to a solution for this DoS mode, where nodes require
either a fast commit or roll-back within a short amount of time (say 30
seconds), or a proof that another channel was closed. This increases the
cost for the attacker with the cost of closing a channel.
I've always disliked this approach a bit, since a "proof that another
channel was closed" can only be accepted by other nodes in the route if
all those nodes can understand such proof; this means that if a route
hops over channels on different block chains (e.g. alt coins or side
chains), or different channel designs, some nodes have to understand all
these varieties. This limits freedom of node pairs to join the network
with new / unusual channels in a useful way.
So far, I had accepted this, as the DoS-protection really seemed
necessary.
================
Another approach
================
Last week, Michiel de Jong (CC'ed) presented Interledger at a local
cryptocurrency meet-up here in Delft. Since Interledger's core feature
is the routing between different 'ledgers' (including block chains, but
also banks), using HTLCs on different hops in the same way as Lightning,
I asked him how they were planning to avoid this DoS mode.
His answer was basically that transactions were being sent in really
small parts at a time, so that, at any given point in time, only a small
amount would be locked. If it turns out to be locked for a long time,
that would not be a problem since it's only a small amount. I suggested
that, if you do transactions this way, you might as well just add the
locked amount to the channel transaction fee, and thereby avoid the
complexity of the HTLC.
=============
Will it work?
=============
Initially, my concern with splitting a tx into many small parts was that
it creates the possibility that only a part of the funds gets
transferred. I now think that, in most cases, that will not be an issue,
since usually a certain amount of trust is already required between the
endpoints of a transaction, e.g. when you pay for physical goods, you
have to trust they will be delivered. Based on the same trust, the
endpoints of the transaction can cooperate to resolve the situation,
e.g. with an attempt to refund through Lightning, or by paying through a
new channel.
But: does this really resolve the DoS attack mode? I suppose that, after
locking funds in one small transaction, an attacker can easily lock
funds in another small transaction, and so on; in the end locking up the
same amount of funds for the same amount of time as in the original
attack. Once you detect that one small transaction doesn't unlock, you
have to somehow stop all subsequent transactions from the attacker.
If, on a channel-level, you just say "I'll no longer accept any new
transactions as long as one transaction keeps being locked", I think
you'll end up worse: it will allow an attacker to disable entire
channels (potentially very high-capacity channels) with very small
attack funds, for all users, for the same lock time. So, to prevent
this, you have to distinguish the attacker from regular users; this is
difficult in a network where the identity of source and destination are
protected , e.g. by Sphinx routing.
**Maybe this is where Lightning and Interledger are different? I don't
know enough about Interledger.**
==========
Solutions?
==========
Maybe this can be resolved by requiring nodes to "unwrap the onion" in
case of a transaction that stays locked for too long? This would be
mostly useful towards the payee, since the payee side is responsible for
either showing the hash pre-image, or voluntarily canceling the
transaction. This could identify the "closest non-cooperating node" in
the route, but it wouldn't prevent the next locked transaction, since
you can't see in advance where an onion-routed transaction is going.
The next thing you could say is "the last cooperating node in the route
(a direct neighbor of the closest non-cooperating node) is no longer
allowed to forward payments through the non-cooperating node". Instead,
he has to immediately roll back any transaction that is aimed in that
direction.
If the otherwise cooperative node fails this rule, you mark it as
non-cooperative; the next time, the second-last cooperating node is no
longer allowed to forward payments through that node. This may continue
a couple of times, until a truly cooperative node follows all the rules,
and attacker transactions are canceled in a fast an efficient manner by
that node.
This might work if there is only a single route on the network
(line-shaped network), but I'm afraid an attacker can significantly
delay being blocked, by creating a part of the network under his own
control, which has at least one "cooperating" node as gateway, followed
by large numbers of non-cooperating nodes, which are continuously being
replaced once old ones are being flagged as non-cooperating. Also, it
could force Lightning nodes to keep very large lists of which nodes have
to block which of their neighbors.
Do you have any thoughts on this?
CJP
PS.
I couldn't find anything related to this in the Lightning RFC:
https://github.com/lightningnetwork/lightning-rfc

2023-06-09 12:46:54

- reply

📅 Original date posted:2016-11-10
📝 Original message:
Hi,
The problem
===========
One major vulnerability of the Lightning network is that, if someone
wants to perform a DoS attack on the network, that possible for the
attacker by sending many large transactions to himself, over a long
route, and letting them time out (never reveal the payment pre-image).
Nobody (including the attacker) gains or loses any funds, but a lot of
funds get locked up, and the total cost of lost opportunity to innocent
nodes is a lot higher than that of the attacker.
In Milan, we came to a solution for this DoS mode, where nodes require
either a fast commit or roll-back within a short amount of time (say 30
seconds), or a proof that another channel was closed. This increases the
cost for the attacker with the cost of closing a channel (I'm not sure
if it actually decreases the cost for honest nodes: a channel close is
no proof that the pre-image won't be revealed, so the funds probably
have to stay locked up until the time-out anyway).
I disliked this approach right from the moment it was proposed: it
forces nodes to reveal, in certain situations, their channel state, to
remote nodes, in a format that has to be understandable to those remote
nodes. This basically limits the freedom in channel design to a design
space that can be understood by all nodes in the network. Any design
outside that space requires all other nodes to upgrade; such an upgrade
would be very hard to deploy. Instead of being an individual decision
between two peers, channel design now becomes a collective network
decision.
This interferes with my vision, presented in Montreal, of a
heterogeneous network. Some examples of things that will become
impossible, or very difficult to accomplish:
* Transparent routing between side chains: nodes that don't know about a
certain side chain can't verify a channel close on that side chain.
* Trust-free de-centralized exchange between different block chains:
different block chains, so same story.
* Trust-free de-centralized exchange of different assets on the same
block chain (e.g. colored coins): other nodes might reject this if they
don't understand the amount locked in the HTLC.
* Channel design upgrade: we're probably first going to deploy Rusty's
channel design; I suppose some variation of the Poon/Dryja design will
have benefits over Rusty's design, once Bitcoin is ready for it. I
expect there will probably be other channel design upgrades in the
future.
Proposed solution
=================
As an alternative to the protection mechanism discussed in Milan, I
explored the possibility to let the payer of the transaction pay (a part
of) the transaction fees at the start of the transaction (when locking
funds into HTLCs), such that, even in case of a roll-back, intermediate
nodes would receive transaction fees. This could accomplish two goals:
* compensate intermediate nodes for the damage inflicted on them by a
DoS attack
* put these costs onto the DoS attacker, thereby making the attack
unattractive.
Two variations are explored: one where the in-advance fee is constant,
and one where it depends on the time it takes for the transaction to
roll back. The consequences for the intermediate node incentives in all
steps of the transaction are evaluated.
Results
=======
https://cornwarecjp.github.io/amiko-pay/doc/lightning-incentives.ods
The spreadsheet is based on a rough estimate of what Lightning market
conditions can look like.
The initial conclusion was optimistic: it is indeed possible to add such
fees, up to a certain amount, without disturbing the incentives.
However:
* Given the assumptions in the spreadsheet, these fees can not be made
high enough to fully compensate the intermediate nodes.
* Since these fees are much smaller than the time value of the locked up
money for a single node, they do not significantly impact an attacker
who is already prepared to bear these costs for his own node.
* Since there is an upper limit to the size of the total fee, and the
total fee increases with the length of the route, this solution does not
scale well with the length of the route.
* Even if it would work (with different parameters), having a security
solution that depends so much on market conditions is probably a bad
idea, if we aren't really sure about these market conditions.
Conclusions / discussion
========================
Although I'd really like to see alternative ways to address this DoS
mode, I don't see how this solution could help. So, sorry, it's a
negative result.
The only alternative I see so far is that peer relationships become
somewhat trusted, so that peers (implicitly) trust each other not to
expose each other to large numbers of long-duration transactions. It's
not clear though how nodes can live up to that expectation, especially
when onion routing removes all information on the origin of
transactions.
To add a positive note: the way how the spreadsheet is set up might be
of interest to you. Maybe you'd like to do some exploration of
incentives for yourself in the future. The spreadsheet adds some insight
in the orders of magnitude we could expect for certain parameters
(although, ultimately, it will be up to the market to decide these). For
instance:
* I expect both the occupation rate of channels and the fee rate of
nodes to be pretty low, and still investing your funds in channels is
quite profitable. This is because transactions tend to be pretty fast,
so their fees add up pretty quickly when doing that over the course of a
year.
* The time value of money lost to transactions that block all the way to
their HTLC time-out is pretty huge compared to the tx fees. This is
because HTLC time-out is typically a very long time compared to typical
successful transaction durations: in order to avoid DoS->theft
escalation, intermediate nodes have to have a significant time-out
increment, so they can handle e.g. a local internet outage. This might
be different with Tadge's channel watching delegation though.
If you think I did anything wrong, or if you have any suggestions, let
me know.
- CJP

2023-06-09 12:46:50

- reply

📅 Original date posted:2016-10-10
📝 Original message:
I can think more clearly when no one is talking, so I took advantage of
the evening to work out my fee proposal in more detail. :-)
A deposits into channel, as a way of paying B.
Amount to be paid to B: 1.000 BTC
Extra amount stored in channel: 1.997 BTC
Fee required for commit tx: 0.003 BTC
Anchor tx output size: 3.000 BTC
Commit tx outputs:
to A: 1.997 BTC
to B: 1.000 BTC
fee: 0.003 BTC
Next, A makes microtx to B:
Amount to be paid to B: 0.500 BTC
Extra fee required for HTLC: 0.001 BTC
Commit tx outputs while tx is locked:
to A: 1.497 BTC
HTLC: 0.499 BTC
to B: 1.000 BTC
fee: 0.004 BTC
Commit tx outputs when tx is released to B:
to A: 1.497 BTC
to B: 1.500 BTC
fee: 0.003 BTC
Commit tx outputs if tx were returned to A:
(just like before tx was locked)
Next, B makes microtx to A:
Amount to be paid to A: 1.000 BTC
Extra fee required for HTLC: 0.001 BTC
Commit tx outputs (while tx is locked):
to A: 1.497 BTC
HTLC: 0.999 BTC
to B: 0.500 BTC
fee: 0.004 BTC
Commit tx outputs (if tx is released to A):
to A: 2.497 BTC
to B: 0.500 BTC
fee: 0.003 BTC
Commit tx outputs (if tx is returned to A):
(just like before tx was locked)
So, summarizing the algorithm:
* Initially, the channel creator pays the fee (presumably, he has an
interest in creating the channel, and this is consistent with regular
BTC payments).
* Generally speaking, while using the channel, you're just shifting
around the non-fee part, without touching the fee itself.
* For as far as adding an HTLC requires extra fees (since it makes the
tx larger), that fee is deducted from the HTLC itself. Dust-sized txes
would create negative-size HTLCs; of course you'd just not create the
HTLC at even larger tx sizes (the fees of follow-up txes would not make
the HTLC worth the effort).
Not yet covered: how to change the fee size when on-blockchain fee
market conditions change.
Comments?
CJP

2023-06-09 12:46:44

- reply

📅 Original date posted:2016-09-27
📝 Original message:
You mentioned two examples of out-of-band distribution of the pre-image:
from B (role 2) to B (role 1), and as a scenario assumption of C
receiving the pre-image out-of-band. I think there is no risk in this.
I think out-of-band distribution of the pre-image is not only harmless:
it is even desirable. If one of the intermediate nodes blocks the
regular distribution, the other ones can commit the transaction on their
channels as soon as they receive the pre-image (in- or out-of-band). The
node on the payee-side of the blocking node can enforce being paid by
the HTLC mechanism, and the node on the payer-side doesn't mind not
having to pay (but can still pay voluntarily). The only nodes
potentially losing funds are the ones that don't follow the regular
protocol.
If you don't have out-of-band distribution of the pre-image, one
blocking node can potentially keep all HTLCs on his payer-side locked
for quite some time (until their time-outs). Eventually they end up
being rolled back, with the blocking node again being the only one
losing funds (which is good).
The advantage of having your HTLCs resolved quickly, so those funds can
flow in the opposite direction quickly, might be a sufficient incentive
for non-regular distribution of the pre-image. In Amiko Pay,
payer->payee distribution is added next to payee->payer distribution,
but it's a voluntary thing, and people might decide to remove it from
their version of Amiko Pay, without any real harm being done.
CJP
Rusty Russell schreef op di 27-09-2016 om 11:33 [+0930]:
> Imagine the simple case where I pay C $4 in fees, via B:
>
> $5 $5 $1 $1
> A ---> B ---> C ---> B ---> A
> 4days 3days 2days 1day
>
> B can simply use the H-preimage it gets from A to fulfill the HTLC A
> offered, gaining $4 and ignoring C. If C somehow gets the preimage
> out-of-band, it can claim the $5 from B and then B can get its $1 from
> C.
>
> The risk (for B) is that C will wait until the C->B HTLC has expired,
> *then* use the B->C HTLC to collect $5, leaving B out-of-pocket.
>
> Now, there's nothing special about this: the game happens for normal
> fees too, especially since we don't know if two apparently-distinct
> nodes are actually identical. It's just more tempting when the fees are
> high.
>
> Fun!
>
> Thanks,
> Rusty.

2023-06-09 12:46:44

- reply

📅 Original date posted:2016-09-23
📝 Original message:
Hi,
I just woke up with a new thought:
With source routing and explicit fee payment, you can actually
atomically pay multiple parties, by letting all but one of the
recipients be intermediate parties in the route, and just paying them a
very high transaction fee. With "atomically" I mean it is impossible
that payment to one of the recipients succeeds and payment to another
fails.
Payment amount can be obfuscated by letting yourself (the sender) be the
final recipient, so none of the intermediate nodes sees the actual
amount being transferred.
It isn't rocket science (or advanced cryptography), but I hadn't
realized this before.
- CJP

2023-06-09 12:46:19

- reply

📅 Original date posted:2016-06-26
📝 Original message:
Hi,
I'm about to start implementing an encryption layer for Amiko Pay, and
since there already is a BOLT for encryption, I thought I might as well
see if I can use it. Now that I've read it[1], I have some questions.
But first, let me comment that, in general, I like the general design of
the encryption layer. It's generic and simple, making it easy to
analyze, which is A Good Thing.
My first question is: would it be possible / useful for a node to use
different public keys for different links? I guess it is possible: the
node that's establishing the connection knows what link it tries to
connect, so it can already send out an authenticate message. The other
node initially doesn't know what link the new connection belongs to,
but, after receiving the authenticate message, it knows, so it can
select its own corresponding key and reply with its own authenticate
message. Then again, I'm not sure if this is very useful. Using
different keys could be good for privacy (not revealing that both links
go to the same node), but a node that listens for multiple links on the
same network location (e.g. host:port in TCP) already shows to its peers
that both links have a shared identity. The key used for authentication
could be different from keys used for other things, like routing
addresses or output addresses of microtransaction channels, maybe linked
in master/slave key configurations (one key signs the other). Maybe
there still is a deniability problem (your peer reveals data and you
want to say 'it wasn't me') but I'm not sure that can be solved.
I was wondering to what degree communication truly looks like random
data, or can be distinguished from it. I guess that the very first 4
bytes, usually being the little-endian value 33, already gives away that
this protocol is being used. Furthermore, timing analysis could reveal
the size of messages being sent, possibly revealing information about
what is being done with the payload protocol inside the encryption
layer. Is there a way to protect against that? You might want to append
unused data to messages to make them fixed size (or at least multiples
of a fixed size), or random size, but that reduces bandwidth efficiency,
and the required amount of padding depends on the payload protocol.
How is the authenticate message distinguished from other messages? I
don't see something like a message type ID. Is it simply that the first
message in a session is ALWAYS an authenticate message, and other
messages are NEVER an authenticate message?
Right now, the description of session_sig in the authenticate message
says: "session_sig is the signature of the SHA256 of SHA256 of the
receivers node_id, using the secret key corresponding to the sender's
node_id". I am not sure how that is useful. More importantly, I don't
understand what stops someone from performing a MITM attack. Shouldn't
you include something like a signature of your sessionpubkey, signed
with your node_id key?
Assuming that a MITM attacker can guess the boundaries of messages, what
stops him/her from duplicating messages, or removing messages? Is a
certain state preserved between encryption/authentication of different
messages?
What is the meaning of the ack field in the authenticate message? The
number of non-authenticate messages before an authenticate message *in a
session* is always zero, isn't it? I see it's the number of messages
*received and processed*. Since, to my knowledge, data streams in both
directions are asynchronous, that could be a non-deterministic value,
right? What should a receiving node check about the ack value? If it
can't check anything, then what is the use of the value? Is this about
message re-transmission across multiple sessions? In that case, please
think about wrap-around behavior. I'm not sure a 64-bit counter will
ever wrap around, but we should make sure the first time it happens
won't be "in the field".
thanks,
CJP
[1]
https://github.com/rustyrussell/lightning-rfc/blob/master/bolts/01-encryption.md

2023-06-09 12:46:07

- reply

📅 Original date posted:2016-04-07
📝 Original message:
CJP schreef op di 02-02-2016 om 18:56 [+0100]:
>
> > > * Reserving before locking: this is an optimization, to reduce the risk
> > > of locking funds in payment channels on a part of the route, and then
> > > having to undo the locking when it turns out that the remaining part of
> > > the route doesn't exist (anymore). Reserving is an informal(*),
> > > temporary locking of funds for use in the transaction, and can be done
> > > and undone very fast, without any channel operations. It is done
> > > together with route searching + establishment.
> >
> > I think that trades one DoS for another, though. It saves cryptographic
> > constructs, but latency is the real cost, and this increases it.
> >
> > Of course, we'll have to revisit that if the network in practice proves
> > subject to these problems...
>
> For one category of channel designs, reserving is absolutely essential:
> channels where bi-directional payments are made possible with a
> decrementing lock time. There, you want to make sure that failed routing
> attempts don't cause lock time decrements, since that would reduce the
> channel lifetime more than necessary. I'd have to check whether there is
> still any use case for this channel design, and whether the reserving
> step is important for some other reason.
After actually implementing some of these things, I'd like to revisit
this discussion.
The "reserving" stage used to be important for channel types where the
bi-directional nature of the channel is realized with decreasing lock
times (see above). Now that a large part of the community has put its
hope on Lightning, it's more likely that the extensions required for
better channel types will be included in Bitcoin, so this issue has
become less important.
Another reason why the "reserving" stage is important, is that it it
necessary for bi-directional routing. In order to make both payer and
payee anonymous, we need to provide this feature, where both route to a
meeting point. For the part between meeting point and payee, routing
goes from payee to meeting point(*), but locking goes from meeting point
to payee, so they can't be done in the same stage.
Finally, the "reserving" stage allows you to set a tighter value on the
HTLC time-outs. If you do routing together with locking, then routing
has to go in the payer->payee direction; the time-out has to be reduced
on every hop. Assuming(**) the payer doesn't know the number of hops in
advance, the time-out has to be set to a very high value by the payer,
to maximize chances of a successful transaction. If you do routing in
the reverse direction (payee->payer), you can start with a very low
time-out, and increment it on every hop. This will generally result in
lower time-out values, which is desirable.
That's about it, for the advantages offered by the separate reserving
stage in Amiko Pay. Let me finish with an attempt to make an ASCII-art
sequence diagram of reserving, bi-directional routing and locking in
Amiko Pay:
H(R) = the transaction hash (also included in other messages)
MR() = MakeRoute message without time info
MR(t) = MakeRoute message with time info
HR() = HaveRoute message without time info
HR(t) = HaveRoute message
L(t) = Lock message (adds HTLC to channel)
A = Alice (payer)
B = Bob (meeting point)
C = Carol (intermediate node). There can be many intermediate nodes
between A and B, and between B and D.
D = Dave (payee)
A B C D
|<------------------ H(R) --------------------|
|------MR()---->| |<-MR(T0+dt)--|
|<-MR(T0+2*dt)--|
|<-HR(T0+3*dt)--|--HR(T0+2*dt)->|
|--HR(T0+dt)->|
|<------------------ HR() --------------------|
|--L(T0+3*dt)-->|--L(T0+2*dt)-->|--L(T0+dt)-->|
(...and then the sequence continues with removing the HTLCs and
releasing funds towards payee-side of each channel.)
CJP
(*) It can't go in the other direction, since the meeting point should
not know the identity (or network address) of the payee.
(**) This is the case for non-source routing. One advantage of
non-source routing is that nodes don't need a map of the entire network;
this improves privacy, and could help to keep the network open to new
participants, even against the will of many powerful existing
participants. In the end, I imagine a system where a mix of
source-routing and non-source routing can be used, to get the best of
both worlds.

2023-06-09 12:45:55

- reply

📅 Original date posted:2016-03-08
📝 Original message:
I was wondering: how does deriving R values from a tree structure work
for larger Lightning networks? I guess it could work between two nodes,
if they keep track of the same tree, but if different transactions
follow different routes, does that mean the tree structure somehow has
to be shared across all nodes? The alternative is that intermediate
nodes still have to remember old R values.
CJP
Nicolas Dorier schreef op di 08-03-2016 om 13:53 [+0900]:
> Great, indeed we had same idea, I don't see how it solve the hashes in
> advance.
> As Alice knows
> H(1000000) = <random secret seed>).
> If she need the hash to the first commitment she need to hash the random secret
> seed 1000000 times. I think it is exactly the same problem as it is the exact
> same idea said differently.
>
> On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> > One way deterministic RValue Generation
>
> Hi Nicolas,
>
> Yes, in fact shachain is a variant of this which
> avoids
> generating several million hashes in advance. Interesting, I
> suggested
> using hashing in the Deployable Lightning paper but didn't
> actually
> spell out the idea. Hmm....
>
> Seems like it orignated from Adam Back:
>
> https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
>
> Cheers,
> Rusty.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:45:44

- reply

📅 Original date posted:2016-02-11
📝 Original message:
> Yes, unfortunately they're intertwined. I was sure we'd discussed
> this before, and I found it.
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000077.html
>
> We keep rediscovering this problem so I need to document it somewhere.
Ah, I see. I think, at the time that message was sent, I didn't
understand it yet. Now that I did the thinking myself, I guess I do.
Cool to see that the alternative solution (never completely depleting
ones channel balance, to have some 'collateral') was also mentioned. I'm
not sure yet which is better; if there is a demand for it, both types
could be implemented and used next to each other in Amiko Pay.
CJP

2023-06-09 12:45:43

- reply

📅 Original date posted:2016-02-09
📝 Original message:
Rusty Russell schreef op di 09-02-2016 om 10:09 [+1030]:
>
> For this reason, the rule is that all outputs to A in A's commit
> transaction must be delayed (via OP_CSV). This includes HTLC outputs.
>
> Referring to Appendix A of the paper, under "HTLC Receiver Redeemscript"
> (since Alice offers Eve the HTLC, Eve is B):
> [..]
So, summarized, the "HTLC Receiver Redeemscript" is actually something
like:
R-VALUE & OP_CSV & SIG-PAYEE
OR
HTLC-TIMEOUT & SIG-PAYER
OR
REVOCATION-B & SIG A
Now, I thought it wouldn't be OK to add an OP_CSV there, so let's see if
I can exploit it.
Same situation: Alice and Eve, connected with two channels. Eve performs
a payment to herself, routed through these two channels.
Now, Eve allows the transaction to succeed on the channel where she
receives: Eve sends the R value to Alice, and Alice sends Eve a commit
transaction update where the HTLC is removed and Eve receives the funds.
On the other channel, Alice sends the R value to Eve, but Eve does not
send Alice a commit transaction update. In fact, Eve becomes completely
unresponsive on this channel. This forces Alice to broadcast her commit
transaction, containing the HTLC. She has to do this *before* the CLTV
of the HTLC times out, or otherwise Eve can try to claim the HTLC funds.
Now, the question is: which times out first, Alice's CSV or Eve's CLTV?
The one that times out first will be the first to be able to claim the
funds. This *should* of course be Alice, so Alice's CSV should be the
first to time out.
Let's assume the HTLC timeout is T0 + 1 day on the channel where Eve
receives, T0 + 2 days on the channel where Eve sends. Eve wants to delay
Alice's commit transaction as long as possible, so she sends the R value
just before T0 + 1 day. That means Alice's CSV should have a delay *less
than* one day. If the CSV delay is set to 0.5 day, that means Alice has
a remaining 0.5 day time window in which her node must be up and running
and connected to the Bitcoin network, to claim the HTLC funds.
So, I think it *is possible*. However, this leads to some uncomfortable
time trade-offs. The CSV delay determines how often your node must be up
and running, to catch the use of revoked commit transactions. Longer is
better: I'd be much more comfortable with 30 days than with 1 day. The
HTLC timeout increment determines how long funds can be locked up and
payment status can stay undetermined (worst-case); it adds up over the
entire route. For this, shorter is better: 1 day would be much better
than 30 days.
Even if you assume "always-on, always connected" nodes, e.g. cell
phones, service providers and home servers, you have to take into
account that systems can fail, and manual intervention may be needed to
restore them. The downtime / DoS attack -> theft escalation is something
we don't want to happen.
CJP

2023-06-09 12:45:42

- reply

📅 Original date posted:2016-02-08
📝 Original message:
> See:
>
> https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
Sorry for replying to a very old e-mail, but I've finally had a really
close look at this, and the way I see it, there could be a potential
problem.
Suppose Eve (E) has two channels with Alice (A). She intends to steal
funds from Alice. This is what she does:
She performs a payment to herself, routed through Alice with the two
channels. When the funds are locked in the two channels, she is supposed
to reveal the transaction R value as a payee, but she doesn't. So, the
transaction times out on both channels, leading to a channel update on
both: the HTLCs are removed, reverting back to the original situation.
The following actions primarily take place on the channel where Eve was
on the RECEIVING side of the transaction. First, Eve spends all her
coins on that channel, e.g. by sending them to herself on the other
channel. This way, she doesn't risk losing them.
Next, on the channel where Eve was on the RECEIVING side of the
transaction, Eve signs and broadcasts the version of the commit
transaction that contained the HTLC. Of course, since revocation
pre-images have been exchanged, Alice can immediately spend the HTLC,
using either the HTLC-TIMEOUT & SIG-PAYER clause or the REVOCATION-E &
SIG A clause. However, this is not guaranteed to work: Eve has the
transaction R value, so Eve can *also* try to spend it, using the
R-VALUE & SIG-PAYEE clause. In fact, since Eve knows sooner about the
commit transaction than Alice, Eve is more likely to be the first to
spend the HTLC, especially when Alice is offline for a moment (Eve can
know that).
Now, if Eve succeeds in spending the HTLC, what can Alice do? She can of
course claim her own balance, and using the revocation pre-image, claim
Eve's balance in the commit transaction, but that way, she receives less
than the total channel capacity, which is what she should have received.
On the other channel, Alice could try to perform the same trick on Eve
that Eve performed on her, since Alice now has the transaction R value.
However, that is not guaranteed to work. Worse: Eve could also have
depleted her own balance on *that* channel, e.g. with a payment to
herself through a third party. That way, Alice will never be able to get
all the funds that belong to her, and Eve gets more than she deserves.
How to solve this issue? My first thought was that we should add an
OP_CSV to the R-VALUE & SIG-PAYEE clause, but that would break its
legitimate use. I don't see how this can be solved without having a
two-transaction set-up, and hence something like SIGHASH_NOINPUT (or
maybe SegWitness?). So it would have to be a bit more like "Poon-Dryja
channels".
Maybe a "never completely deplete the channel" rule could be a
work-around? You could define a maximum for the sum of all active HTLCs
in one direction in a commit transaction, and require the other side to
always have at least one or two times that maximum as remaining balance.
Would that work?
BTW, apologies if this was already known. In that case, my question is:
where can I find an updated design?
CJP

2023-06-09 12:45:38

- reply

📅 Original date posted:2016-02-11
📝 Original message:
Hi,
I've had another look at C-Lightning protocol description[1], in the
hope to make a sort of match between your message types and the message
types in Amiko Pay. In the best case, there would be a near-perfect
match; in the worst case, the entire sequence would be different
(unlikely, since we try to accomplish similar things).
The result was a bit unexpected: there was hardly any match at all, but
this was not due to solving things in different ways, but because of
implementing nearly opposite subsets of the functionality of Lightning.
In Amiko Pay, the core protocol is mostly concerned with multiplexing
multiple channels of potentially different types, opening/closing
channels, doing a little bit of routing and following the payment
sequences (reserving/route finding, route canceling, fund locking, fund
releasing etc.). Channel implementation details, such as what messages
to exchange in case of opening/closing a channel, or in the different
steps of a transaction, depend on the different channel types, and no
Lightning-style channel type has yet been implemented.
On the other hand, the C-Lightning protocol description basically *only*
deals with the channel implementation details (what data is exchanged in
case of opening/closing a channel, or in the different steps of a
transaction). I don't see much about routing, for instance. The
C-lightning message structures would be perfect to put inside Amiko
Pay's ChannelMessage messages, and together they would make a more
complete protocol.
To make a (pretty weak) analogy: maybe you can see C-Lightning's
protocol as a fundamental building block of Lightning networks, in the
same way as you can see bi-directional byte streams as a fundamental
building block of computer networks. Then, the 'raw' protocol used by
C-lightning would be a bit like a serial point-to-point connection, and
C-lightning inside Amiko Pay would be a bit like a TCP/IP connection.
They deliver the same core functionality on application level, but
TCP/IP, being more layered, provides more versatility. It adds
multiplexing of different streams, and alternative communication
concepts (e.g. UDP).
For me, this was a bit of an eye-opener, though I should have expected
it, from what I know about C-Lightning. C-Lightning's protocol
description will be a nice guide for developing a true Lightning style
channel in Amiko Pay. Judging the development time and lines of code in
C-lightning, I guess the part that is implemented in C-lightning has
quite a bit of complexity, so I hope to build on Rusty's experience and
expertise, to do things a bit faster in Amiko Pay. I'd like to use some
C-lightning code as well, but I doubt it will be easy to integrate
(Amiko Pay is quite a restrictive framework for channel implementations,
and we have a language barrier between C and Python). Maybe we could
start with a 'dirty hack'-style of gluing things together, for a proof
of concept.
CJP
[1]
https://github.com/ElementsProject/lightning/blob/master/lightning.proto

2023-06-09 12:45:37

- reply

📅 Original date posted:2016-02-02
📝 Original message:
> > * Message confirmation: this is done manually (instead of relying on
> > TCP), so that a node knows which messages were received / need to be
> > re-transmitted, even after a crash + restart.
>
> I think the protocol itself needs to be robust against retransmissions.
> There's no way to know if the other side received your acknowledgement
> before a crash, so you will always need to handle duplication on
> re-establishment.
Yes. Amiko Pay does that: It assigns a number to every message, and the
receiving side can confirm "I've received up to this number".
Not-yet-confirmed messages will be retransmitted, and the receiving
sides will ignore duplicates (except it will send a confirmation again,
in case the previous confirmation was lost).
> > * There is not only two-way communication between linked peers, but also
> > between payer and payee. This is necessary for Amiko Pay's
> > bi-directional routing, but also useful e.g. for transmitting meta-data
> > that doesn't fit in a QR code. Amiko Pay transmits an arbitrary-contents
> > "receipt" from payee to payer; in the future, this might be digitally
> > signed by the payee, as a "proof of transfer of ownership" of
> > non-cryptographic goods.
>
> I agree. There's room in the initial onion design for payer -> payee
> messages, but we don't have a channel for responses.
>
> I can't see an easy way to implement the payee --> payer comms reliably:
> to be reliable it would have to be published on-chain in the commit tx.
> (Which we could do by constructing HTLCs such that they require a blob
> signed by the payee, but that's tracable ...).
>
> Mats and Laolu wanted to add an arbitrary comms protocol layer, but I
> think that's something we can defer.
In Amiko Pay, payer <-> payee communication is done on a direct TCP
stream between them. Note that this also reduces latency: once
transaction locking reaches the payee, the payee knows (s)he's capable
of claiming the money, and can tell the payer that the payment is
completed. If reduced latency is in the interest of the payee, this is
likely to happen.
> > * Reserving before locking: this is an optimization, to reduce the risk
> > of locking funds in payment channels on a part of the route, and then
> > having to undo the locking when it turns out that the remaining part of
> > the route doesn't exist (anymore). Reserving is an informal(*),
> > temporary locking of funds for use in the transaction, and can be done
> > and undone very fast, without any channel operations. It is done
> > together with route searching + establishment.
>
> I think that trades one DoS for another, though. It saves cryptographic
> constructs, but latency is the real cost, and this increases it.
>
> Of course, we'll have to revisit that if the network in practice proves
> subject to these problems...
For one category of channel designs, reserving is absolutely essential:
channels where bi-directional payments are made possible with a
decrementing lock time. There, you want to make sure that failed routing
attempts don't cause lock time decrements, since that would reduce the
channel lifetime more than necessary. I'd have to check whether there is
still any use case for this channel design, and whether the reserving
step is important for some other reason.
Note that reserving is necessary for bi-directional routing: on the
payee side of the meeting point, routing happens in the payee -> meeting
point direction, but locking has to happen in the meeting point -> payee
direction. So, they have to be different steps.
On latency: what latency do you think is needed for different use cases,
and what can we reach? Does this extra step really make a difference?
My estimate is that we'll typically have 10 hops ("six degrees of
separation" theory), and 100ms to transmit a message(*) over one hop.
Without reserving, you need to traverse all hops once(**) (the locking
operation) before payer(***)+payee know that the transaction has
succeeded. Actual settlement on the channels happens afterwards, but is
no longer critical for the latency as seen by payer+payee.
With reserving, you need to traverse all hops three times(**), in the
worst case that the meeting point is on one of the end points of the
route: once for making the route and reserving funds, once for
confirming that the route has been established and once for locking.
So, instead of one second, a transaction might take three seconds. Is
that a game changer? Maybe it is for e.g. public transport access gates,
where passenger throughput is essential. But then, people could reduce
latency a lot by having a direct channel with the public transport
operator.
For some use cases, e.g. high-frequency trading, people might of course
manually optimize their network and physical location to get better
figures than this.
CJP
(*) Not counting sending the confirmation back: a node that receives a
message can immediately forward a message on the next hop; message
confirmation on the receiving side can occur in parallel.
(**) Not counting failed routing attempts
(***) Assuming the payee tells the payer directly about the payment
succes, over a low-latency connection

2023-06-09 12:45:36

- reply

📅 Original date posted:2016-01-27
📝 Original message:
> I'm sure I've missed things; what are they?
The lazy answer is to tell you to read the Amiko Pay protocol
description.[1] :-P Note that it is (of course) already outdated. To
give you some of the concept choices in there:
* Transport layer: TCP. We don't need its retransmission features (since
it's not good enough and we'll re-implement it in a higher layer), but
unlike UDP it works well over TOR.
* Serialization: JSON, with some conventions added on top of it, e.g.
for more efficient transfer of binary data. It is bloated, but easily
debuggable and easily extensible. Good for prototypes, maybe not so good
for high-performance production code.
* Message confirmation: this is done manually (instead of relying on
TCP), so that a node knows which messages were received / need to be
re-transmitted, even after a crash + restart.
* There is not only two-way communication between linked peers, but also
between payer and payee. This is necessary for Amiko Pay's
bi-directional routing, but also useful e.g. for transmitting meta-data
that doesn't fit in a QR code. Amiko Pay transmits an arbitrary-contents
"receipt" from payee to payer; in the future, this might be digitally
signed by the payee, as a "proof of transfer of ownership" of
non-cryptographic goods.
* Bi-directional routing: both payer and payee route towards a "meeting
point". This way, neither payer nor payee has to have a routable address
on the network. This is good for both payer and payee privacy; also, in
case of a semi-centralized network with a couple of large hubs, this
allows the network to grow without the large hubs noticing it, both in
payer and in payee direction.
* Multiple channels per link: useful to be able to route transactions
the usual way while one of the channels is (temporarily) closed. It's
also the easy way of adding more funds to an existing link, or funds
from both sides.
* Different channel classes: the micro-transaction design, and its
implications on what info needs to be transferred in which situations,
is a separate, higher-level protocol layer on top of a more generic
protocol that takes care of routing.
* Reserving before locking: this is an optimization, to reduce the risk
of locking funds in payment channels on a part of the route, and then
having to undo the locking when it turns out that the remaining part of
the route doesn't exist (anymore). Reserving is an informal(*),
temporary locking of funds for use in the transaction, and can be done
and undone very fast, without any channel operations. It is done
together with route searching + establishment.
CJP
PS. Don't trust a protocol spec that doesn't have an implementation,
since it's probably missing a couple of essential things. Don't use an
implementation that doesn't have a protocol spec, since you're likely to
run into future compatibility issues.
(*)informal = without cryptographic commitment, and without actual
channel update.
[1]https://github.com/cornwarecjp/lightning/tree/cornwarecjp/communications

2023-06-09 12:45:36

- reply

📅 Original date posted:2016-01-27
📝 Original message:
There are a couple of subjects where new concepts are being worked out,
or where alternative concepts exist; these things are likely to continue
to evolve after you finish the first version of the protocol.
It would be great if concept changes in one subject can be made more or
less independently from concept changes in another subject. In order to
make this possible, I suggest to de-couple certain things, and let each
subject have its own sub-protocol, with version number / protocol
identifier.
The way I see it, the following subjects have ongoing design /
alternative concepts, more or less independently from each other:
* Micro-transaction channel design: e.g. several variations on the
Lightning channel design, and Amiko Pay's escrow-based HTLC emulation
and IOU semi-channel.
* Commit conditions: traditional definition consists of a hash value and
a time-out. For practical purposes, Amiko Pay also adds a "start time",
and there is an alternative concept of using keypairs instead of hash
values to de-correlate a transaction in different links.
* Routing: how to exchange routing info. For source routing: informing
each other about Lightning nodes that exist. For source and non-source
routing: informing each other about availability of routes, expected
capacity and fees. The type of routing info depends on the routing
algorithm in use by a node.
In Amiko Pay, the micro-transaction channel design is already separated
from the rest of the protocol; commit conditions are not (yet), and
exchange of routing info doesn't really exist yet, since it's still
doing "dumb" non-source routing (trying every possible route).
CJP
Rusty Russell schreef op wo 27-01-2016 om 13:37 [+1030]:
> Hi all!
>
> As more code emerges, I'd like to try to nail down a "1.0"
> version of the inter-node protocol as much as possible. Since I'm most
> familiar with my own code (c-lightning[1]), I'll use that as a basis and
> discuss differences (esp. vs lnd[2]).
>
> For this email I'll simply list the changes or proposals I'm aware of,
> then we can dissect and comment on each one: defer, accept or close.
>
> Direct wire format stuff
> ------------------------
>
> - Protobufs vs open-coded structures
> - lnd open-coded their own protocol; I haven't finished reading their
> code though.
> - protobufs are easy to extend with new fields; with an open-coded
> proto we simply need a rule that too-long packets are valid.
> - protobufs are annoying for fixed-length blobs which we use a lot
> (keys, signatures, hashes).
> - The protocol is currently simple with very few variable-length fields.
>
> - Length prefix for initial key exchange
> - Both lnd and c-lightning begin by exchanging a 33-byte EC key for DH.
> - We should prefix with a length word, so we can extend this later
> (eg. for new crypto)
>
> - Length prefix for other packets
> - lightning-c sends an 8 byte prefix indicating the offset of the end of
> the current packet: this effectively encodes both length and ordering.
> - lnd uses a 4 byte network ID, 4 byte type, 4 byte length.
>
> - HTLC pipelining
> - lnd's protocol supports multiple in-flight HTLC negotiations; this
> would allow much greater throughput, with some complexity.
> - lightning-c uses a simple one-at-a-time scheme, with alternating
> priority in case of simultaneous sends.
>
> - HTLC abort stage
> - Setting up a new HTLC involves both sides accepting, then revocation
> message exchange. Currently there's no way to abort this process.
> - Allow the initator to abort any time before the revocation exchange,
> for weird corner cases such as timeouts.
>
> - Version bits
> - If we use an open-coded protocol, initial handshake after key setup
> should exchange two sets of version bits: one for compulsory
> features, one for optional features. You hang up if there's a
> compulsory feature you don't grok.
>
> Wire protocol crypto
> --------------------
> - Crypto AES/HMAC-SHA256 or Chacha20/Poly1305
> - AES has the word Standard in the name, but chacha20 is faster w/o
> accel (ie. ARM) and almost as widely supported.
>
> - Use separate encoding stream for packet lengths
> - Laolu's suggestion; encode the packet lengths as well which makes
> traffic analysis a bit harder.
> - Makes it a bit harder to detect re-transmissions (required on node
> restart), but probably not enough to kill the idea?
>
> Misc
> ----
> - shachain vs elkrem
> - We use this to generate the revocation secrets, to minimize storage
> and computation for a huge number of old commitment txs.
> - They're actually very similar, but elkrem is much easier to grok.[6]
>
> - Anchor tx renegotiation
> - We should allow re-anchoring of channels, to add or remove funds.
> - This would allow easy payment from lightning channel to normal
> bitcoin addresses, for example.
> - During transition, signatures for both commit txs must be exchanged.
>
> - R value vs keypair
> - Using a simple secret "redeemhash" allows easy tracing of
> transactions through the network.
> - Mats Jeratsch proposed a keypair scheme which decorrelates them[3],
> Greg Maxwell optimized it slightly, and Anthony Towns[4] and Andrew
> Poelstra independently came up with a way to do it without any
> bitcoin mods.
>
> - Multi-sig txs
> - Joseph pointed out that by simply allowing more than one signature on
> commit txs[5], we can enable escrow-style services (including things
> like GreenAddress.it which does this for normal wallets).
>
> I'm sure I've missed things; what are they?
>
> Thanks!
> Rusty.
>
> [1] https://github.com/ElementsProject/lightning
> [2] https://github.com/LightningNetwork/lnd
> [3] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000314.html
> [4] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
> [5] http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html
> [6] https://github.com/LightningNetwork/lnd/blob/master/elkrem/elkrem.go
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:45:07

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Wow, that was unexpected.
Is there a place where I can see the discussion that concluded in
withdrawing BIP62? The only thing I found with a quick search was this:
https://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9
All of BIP62's (including the only-new-transactions) are currently
enforced
as standardness rules, but it seems hard to push it further. Every new
type
of complex transaction may require new extra rules, and some important
types
of malleability cannot be addressed by it (for example, a single
participant
in a multisig spend creating a new signature with a different nonce).
It seems wiser to pursue normalized txid or segregated witness-based
solutions, which do solve this problem more fundamentally.
The reasoning seems to assume that "normalized txid or segregated
witness-based solutions" will become available in the future. Aren't
these features harder to introduce (hard fork)? Is there a backup plan
for when these somehow don't get implemented? That could be e.g.
un-withdrawing BIP62. If miners / pool operators see value in reducing
tx malleability, I don't see how the core developers could stop such a
movement.
BIP62 may not solve all cases (and is, in that sense, inferior to more
fundamental solutions), but from what I can see, it was already good
enough for certain types of smart contract constructions. I think the
Amiko Pay "HTLC emulation" design would be secure against malleability
under the conditions that
* BIP62 is in effect
* Every channel is only funded by one of the two sides (so e.g. the "New
signatures by the sender" case can't be abused)
CJP
Rusty Russell schreef op do 19-11-2015 om 13:23 [+1030]:
> Hi all!
>
> As you know, I designed a lightning variant which used only
> non-experimental, in-planning BIPs[1]. One assumption was BIP62: in
> particular, that anchor malleability wouldn't be an issue. This was
> flawed; BIP62 will never be deployed.
>
> There are several options from here:
>
> 1) Ignore it. Malleated txs are non-standard.
> 2) Add a timeout to the anchor. Limits the lifetime of the channel, and
> still means if it does happen you have to wait for the timeout.
> 3) Propose a reduced BIP62 which (say) only protects P2PKH, for a
> specific transaction version.
> 4) Take a leap of faith and assume Segregated Witness fixes all
> malleability.
>
> I was debating between #1 and #3 for a while, but eventually settled on
> #4. Here's why:
>
> 1) While still pre-BIP, Pieter Wuille is working on a prototype now
> (Luke Jr came up with a sanish way of softforking it in).
> 2) Other parts of the lightning code (in particular, watching bitcoin
> transactions) become significantly simpler if malleability is
> ignored.
> 3) It's the right thing for Bitcoin; all smart contract systems want
> this.
>
> This result is NOP for lightning in the short term; assuming SW is the
> same as pretending malleability doesn't exist. But if we need to add
> malleability support later, it's going to be painful, since handling it
> correctly in all the places it's missing will be hard.
>
> Cheers,
> Rusty.
> PS. Remember, every project has 3 major disasters. Just wait until you
> see the next two!
>
> [1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:45:01

- reply

📅 Original date posted:2015-10-27
📝 Original message:
> Alternatively, maybe it means that
> miners aren't an effective cartel, and thus can't force fees to
> rise to maximise revenue; that doesn't seem likely to me though...
Why not?
Anyway, it will most likely be the case if we somehow manage to
re-decentralize mining (e.g. let individual miners make the blocks
instead of letting pool operators do that).
So, how do your calculations work out if the miners are not a cartel,
but instead completely non-organized? What if, in the style of the
prisoners dilemma / tragedy of the commons, each miners' actions are
targeted towards maximizing its own profits, even if that comes with a
disproportional cost for other miners?
For a miner it makes sense to include transactions that have much lower
fees than the "cartel optimum": if you don't do that, you don't get the
fees, but some other miner will still include them and "spoil the
market", so it might as well be you who takes the profit. This is how a
free market with many independent actors leads to lower prices than a
market operated by a monopoly / cartel.
Still, even under such conditions, there will be natural limits, since
there are costs related to including transactions in your own blocks. I
made some estimations based on the assumption that, in the absence of an
artificial block size limit, the limiting factor is how long it takes
other miners to download+verify your block, which is assumed to be
proportional to block size. Long download+verification times reduce the
chance that other miners start building on top of your block before
another block is found.
My conclusion was that miners will continue to include transactions
until it takes almost ten minutes to download + verify a block. The
"almost" is a bit dependent on the distribution of fees people are
prepared to pay: if all transactions use the same fee/kB it equals 10
minutes; if a small part of the transactions pays the majority of the
fees, miners are better off including those transactions but excluding
most of the rest. The same is true in the presence of a large
inflationary block reward (current situation): that is effectively a
single transaction with a very large transaction fee. Miners don't want
to risk losing that reward by including lots of low-fee transactions.
I haven't taken into account that it takes different miners different
times to download+verify blocks.
CJP

2023-06-09 12:44:21

- reply

📅 Original date posted:2015-09-21
📝 Original message:
On returning home from the Scaling Bitcoin workshop, I thought it was
great meeting some people in real life and discovering we basically all
want to achieve the same things. Still, I think there are some
differences in how we think certain problems should be addressed.
Design decisions in Lightning don't suffer from the same "consensus"
necessity as the block validity rules in Bitcoin, but still, some
decisions carry a strong network effect, and might be hard to reverse
once made. The people I talked to felt the need to make no mistakes on
these design decisions, but at the same time I feel the need to make
them ASAP, so we can quickly launch a prototype and convince the world
of how great this is.
Because of this, I'd like to have a well-organized process of collecting
and documenting design ideas and trade-off argumentation, and hopefully
reach some consensus on what are good and bad ideas. This should also
serve to increase interoperability between the several pieces of
software that are being developed. Some of my ideas on how to shape
this:
We could have a Git repository, containing all concepts and standards.
New ideas, amendments & so on can be exchanged like pull requests. We
may / may not also need a process to make actual design decisions, but
assigning one Git clone to be the "true" one might be too simplistic (I
don't want to have a dictator). As long as the Lightning dev community
is small, a "100% consensus" rule might still be workable though.
I'd like to make a distinction between concepts and standards. The idea
is that a concept is a non-trivial design decision; typically people can
have strong preference between different alternative, mutually
incompatible concepts. Standards are based on concepts, and fill in all
the trivial design decisions that have to be made to make different
pieces of software inter-operable. For concept choices, I made the
following template:
https://gist.github.com/anonymous/51631fe56f1f83e4af0a
What do you think?
CJP
PS. Rusty suggested something like an RFC-like process for Lightning.
I'm not an expert on RFCs, and my proposal is probably a bit different
from the RFC process. I'm open to other ideas and I'd like to be
informed about why we should use an RFC-like process or something else.

2023-06-09 12:44:18

- reply

📅 Original date posted:2015-09-01
📝 Original message:
Anthony Towns schreef op di 01-09-2015 om 17:56 [+1000]:
> On 1 September 2015 at 17:07, CJP <cjp at ultimatestunts.nl> wrote:
>
> Anthony Towns schreef op di 01-09-2015 om 07:08 [+1000]:
> > On 31 August 2015 at 04:01, CJP <cjp at ultimatestunts.nl>
> wrote:
> > > A - b - c - D - e - F - g - H
> No. H just tells A he can route this particular transaction to
> D. A
> doesn't know H.
>
>
> That doesn't make sense to me -- if A doesn't know H, how can H tell
> A anything?
Sorry, that must have been confusing.
The way I see it (and the way it's implemented in Amiko Pay), payer and
payee (A and H in the scenario) have a direct communication link between
each other (temporary, for the duration of the payment), to coordinate
the payment. They exchange things like the hash of R, the to-be-paid
amount and the address of the meeting point (D).
Currently, it's a normal TCP connection, so they know each others' IP
address, but I guess that, even without changes to the Amiko Pay code,
you could run Amiko Pay as a TOR hidden service (payer connects to
payee, so payee has to be the hidden service). Or they could meet each
other physically (without knowing each other), and communicate over a
temporary link (WiFi, Bluetooth or something else).
There is no technical reason why they should know each others' identity,
IP address or any routable address on the Lightning / Amiko network.
I guess your further questions followed from this issue. Is it all clear
now?
CJP
>

2023-06-09 12:44:17

- reply

📅 Original date posted:2015-09-01
📝 Original message:
Anthony Towns schreef op di 01-09-2015 om 07:08 [+1000]:
> On 31 August 2015 at 04:01, CJP <cjp at ultimatestunts.nl> wrote:
> > A - b - c - D - e - F - g - H
> > H pays 0.003 mBTC to F (explicit source routing fee;
> H
> > selected F for
> > onion-routing towards D, without A's knowledge)
> > You mean "D selected F for onion-routing towards H" here,
> surely?
> No :-)
> Both sides of a payment may value their privacy, so both sides
> may want
> to perform onion routing independently.
>
> It's a bit similar to TOR hidden
> services: you route from both sides towards a "meeting point"
> somewhere
> on the route, which is not necessarily one of the end points.
>
>
> Hmm. I would look at that more like:
>
>
> Setup:
> - H wants to be secretive.
> - H establishes a channel with g
Yes.
> - H tells F he can route to H via g
> - H tells D he can route to H via F
No. If H has a routable address (which is optional in this scenario,
since it's not used here), it would be "g tells F he can route to H via
g". But that information isn't used here, and the transaction isn't tied
to H's routable address, since there is no "routing to H" in this
scenario: there is only routing from A to D and from H to D through F.
> Announcement:
> - H tells other people (such as A) they can route to H via D
No. H just tells A he can route this particular transaction to D. A
doesn't know H.
>
> Then A sends a txn for H to D as instructed, and D chooses to forward
> it on via F.
No. The sequence is:
- A establishes a route to D as instructed
- H establishes a route to F, and instructs F to establish a route to D
- F establishes a route to D as instructed
- D matches the two sides, and informs both sides that a route is
present.
- The transaction is locked (HTLC created), starting on the A-b link,
then b-c, and so on, all the way to the g-H link.
>
> (Hmm. In that scenario, if e tried to send a txn to H, she would route
> via D, then find D routed the txn back to it -- using the same R --
> and that F was the next destination. This would be an information
> leak, arguably. Likewise for anyone whose cheapest path to D was
> through e)
Does not apply to the way I describe how it should work.
>
> Note that, because locking of transaction funds is always done
> in payer
> -> payee direction, this requires a separate routing phase
> before the
> locking. So, first you find a route (where all parties say
> they agree to
> fees, tx amount, timeouts and other conditions), and then you
> start
> performing transaction-channel actions.
>
>
> Isn't that a bit circular -- "you obtain the route by sending messages
> along the route" ?
No. Route finding can consist of several attempts, and each attempt
consists of sending messages between nodes. Once you find a route
(probably the first attempt in a well-optimized routing system), you can
send further messages along the route, but you did in fact already send
messages along the route prior to knowing that it will become your
route.
>
> It also relies on end-to-end communication in realtime, which wouldn't
> work for paying to a cold-wallet lightning channel that's only
> occassionally online.
I don't see how lightning could pay to a cold wallet. I assume that, at
least when starting a transaction, all nodes on the route are online.
>
> If you *did* assume everything is in realtime, you could avoid fines
> entirely just by having the protocol be something like:
>
>
> - the official timeout was 4 days, the unofficial timeout is 4
> minutes
> - ...
> - okay 4 minutes is up, do you know R?
> - no, okay, we're revoking the transaction.
> - you don't want to? fine, channel is closed.
I assume the "official" timeout is the one mentioned in the HTLC; it has
to be large (several days) to avoid nodes becoming vulnerable due to
loss of connectivity in the middle of a transaction: it might take you
some time to establish an alternative internet connection, and it has to
happen before the official timeout.
Neighbors can always try to impose shorter unofficial time-outs, with
the sanction that the channel will be closed. The consequence is that
both sides, and the network as a whole, lose a link, so it should be
avoided if possible.
>
> Maybe that's what the default protocol should be anyway, and fines are
> just an extension to that to bribe the payer not to close the
> channel...
Yes.
> You could of course ignore source routing for the fines, and
> distribute
> the fines as if it is only a non-source routing path. The
> problem is
> that an attacker can create an arbitrarily long path with
> source
> routing, thereby creating arbitrarily large total damage to
> the network,
> corresponding to arbitrarily large total fines.
>
>
> I don't think it can go arbitrarily large -- if the recipient is
> paying the fines at each point, then the scenario is:
I don't understand how an intermediate point (D or F) can enforce
payment of fines by A or H.
You could of course pre-pay the fines with a separate transaction, which
has D or F as payee endpoint, and send the fines back in case of a
successful transaction. This assumes the intermediate nodes are trusted
with the fine amounts.
CJP

2023-06-09 12:44:08

- reply

📅 Original date posted:2015-08-30
📝 Original message:
> Well-behaving nodes will always pay the fine, thereby keeping
> their link
> intact and keeping a healthy network of well-behaving nodes.
>
>
> The thing that I can't get to work out here is when you have a
> misbehaving node at the end of a chain, who doesn't pay their fine,
> but well-behaved nodes making up the rest of the chain.
>
If all fines are accumulated towards the payee side, the effect would be
that the last well-behaving node has to pay the fine. So we've punished
an innocent party. Luckily, this innocent party can prevent further
damage by closing the channel to the real bad guy. If the risk of paying
fines because of mis-behaving neighbors is really significant, you could
demand non-trusted (e.g. anonymous) neighbors to pre-pay a fine fund to
you, before you start routing payments towards them.
Of course you could also try to design a cryptographic payment channel
method for enforcing fine payment, but I think that, by now, we're
already so deep into 2nd-order, 3rd-order etc. effects that it might not
be worth the added complexity. You should keep things simple to make
them work reliably and have them implemented in time.
CJP

2023-06-09 12:44:08

- reply

📅 Original date posted:2015-08-30
📝 Original message:
> A - b - c - D - e - F - g - H
> H pays 0.003 mBTC to F (explicit source routing fee; H
> selected F for
> onion-routing towards D, without A's knowledge)
>
>
> You mean "D selected F for onion-routing towards H" here, surely?
No :-)
Both sides of a payment may value their privacy, so both sides may want
to perform onion routing independently. It's a bit similar to TOR hidden
services: you route from both sides towards a "meeting point" somewhere
on the route, which is not necessarily one of the end points.
Note that, because locking of transaction funds is always done in payer
-> payee direction, this requires a separate routing phase before the
locking. So, first you find a route (where all parties say they agree to
fees, tx amount, timeouts and other conditions), and then you start
performing transaction-channel actions.
>
> A pays 0.002 mBTC to b (non-source routing fee)
> b pays 0.001 mBTC to c (non-source routing fee)
> D pays 0.001 mBTC to c (non-source routing fee)
> D pays 0.001 mBTC to e (non-source routing fee)
> F pays 0.001 mBTC to e (non-source routing fee)
> F pays 0.001 mBTC to g (non-source routing fee)
> H pays 0.001 mBTC to g (non-source routing fee)
>
>
> These fees still don't vary with time, so a 30s result versus a 4 day
> result still has a factor of 10k difference in cost vs revenue. I
> think over 4 days, a 0.20% fee is about reasonable matching the 0.002
> fees that c, e and g end up with above (0.20%/4 days works out to a
> 20% ROI per annum if all your channels are constantly at 100% use), so
> linearising to an hour that's a 0.002% fee, which works out to 2
> satoshi per mBTC per hour.
Yeah, after writing that e-mail, I realized I was contradicting myself a
bit. That system is OK for normal tx fees, but it doesn't seem to work
for "delayed tx fines". It's a bit of an open question for me how to
distribute these fines on a mixed source/non-source routing network.
On the non-source routed parts, you can't check whether intermediate
nodes are honest when calculating the to-be-paid fines. Is that a
problem, or is it good enough to let the free market do its job, so that
nodes who demand too high fines will lose connections, just like with tx
fees? Anyway, I think that for the non-source routing parts, the height
of the fine (as a function of tx amount and delay) should be agreed
prior to performing a transaction. An intermediate node can demand a
payee-side fine that includes a weighed average of the fines it has to
pay payer-side on its other links, to stay profitable. This is the same
as with regular tx fees.
On the source-routed parts, the fines seem to end up with the end
points. Problems:
1. There is no persistent business / trust relationship and no payment
channel between endpoint and intermediate source-routed node. So there
is no way to enforce fine payment?
2. The payee endpoint is not always the bad guy in a delayed payment
scenario. It could be that fund locking from payer to payee stopped
somewhere in the middle of the route: in that case, the payee endpoint
rightfully never discloses R.
You could of course ignore source routing for the fines, and distribute
the fines as if it is only a non-source routing path. The problem is
that an attacker can create an arbitrarily long path with source
routing, thereby creating arbitrarily large total damage to the network,
corresponding to arbitrarily large total fines. If you use
pre-calculated fine amounts, an attacker can always make a route that
will result in a (large) loss for some intermediate nodes.
CJP

2023-06-09 12:44:07

- reply

📅 Original date posted:2015-08-30
📝 Original message:
>
> I'm not sure the fine is necessarily small relative to the blockchain
> fees, though (especially if the blockchain fee is zero...)? A long
> chain might get fees into the 1% range, and for a moderate sized
> payment ($5 coffee, 20 mBTC) that would be .2 mBTC, exceeding a 1kB
> txn fee of .1 mBTC...
You assume the present-day exchange rate. When scaling towards larger
numbers of users and transactions, the exchange rate will increase a
lot. This will make the blockchain tx fee much worse. With increasing
numbers of users the route length in Lightning might also increase a bit
(hence increase its tx fee too), but the situation is much better than
with in-blockchain transactions.
A very simplistic estimate of the exchange rate in a very ambitious
scenario: assume a future world of 10e9 people, who have all reached
developed-nation wealth, and who use Bitcoin for all their finances.
Each of them can have 2.1 mBTC of savings. Assuming the average
developed-nation person has about $10e3 savings in today's dollars, 2.1
mBTC savings in our scenario should be equivalent to $10e3 in today's
dollars. So that is $4800 / mBTC = $4.8 mln / BTC! Note that the actual
exchange rate in our hypothetical scenario will be much higher, since
the dollar will have become worthless.
CJP
>

2023-06-09 12:44:07

- reply

📅 Original date posted:2015-08-29
📝 Original message:
> So, with some prompting from AJ who has been working on node
> incentives, I realized there's a nasty attack available to the network.
> You simply route a payment back to another channel you own, then refuse
> to dislose R.
>
> You have to lock up N bitcoins, but so does every node in the path (and
> nobody gets paid!). Onion routing means nobody knows who to blame (you
> can simply claim there's another hop after you).
Yes, that's a nasty one: the total damage to the network is much larger
than the damage to the attacker, especially when the attacker is free to
choose a very long route. This could be used to perform a DoS attack on
the network.
> I think in this case we need to peel the onion[1]: if a payment takes
> too long you tell the previous node where you sent it (and relay where
> it sent it, etc.) If you're the last in the queue, you also need to
> prove that you closed the channel to the offender[2] (which costs you a
> txfee, providing disincentive).
>
> Anyone see any other problems?
I don't like the "peeling the onion" idea, since it breaks down a very
important privacy layer. This privacy is necessary e.g. to make sure the
network remains open for new participants to start routing, even against
the will of an existing cartel of routers.
Maybe I'm overlooking something, but wouldn't it be enough to add a
fine, to be paid from payee-side of a single link to the payer-side of
the link, if the R value is delayed? It wouldn't even be necessary to
cryptographically enforce such a fine: if the fine isn't paid, the other
node can simply close the channel, isolating the misbehaving node.
Well-behaving nodes will always pay the fine, thereby keeping their link
intact and keeping a healthy network of well-behaving nodes.
In order to punish the attacker, these fines should be accumulated
towards the payee side of the route; this sounds like a similar problem
as the accumulation of ordinary transaction fees across a route.
Intuitively I'd say that, for a mixed source/non-source routing network,
it'd be reasonable that the endpoints of the transaction (final payer
and payee) explicitly pay fees to the source-routed nodes in a route,
and that any fees of non-source routed nodes are covered by the fees
paid to their closest source-routed nodes(**). Explicitly paying fines
to source-routed nodes also provides an incentive(*) to keep routes
short.
CJP
(*) unless the explicit fee is negative of course, but that's a feature,
not a bug.
(**) Example (for ordinary fees, but could be similar for fines):
capitals are source-routed nodes
A - b - c - D - e - F - g - H
A pays 1.000 mBTC to H (main payment from payer A to payee H)
A pays 0.003 mBTC to D (explicit source routing fee; D is the "meeting
point" agreed by A and H)
H pays 0.003 mBTC to F (explicit source routing fee; H selected F for
onion-routing towards D, without A's knowledge)
A pays 0.002 mBTC to b (non-source routing fee)
b pays 0.001 mBTC to c (non-source routing fee)
D pays 0.001 mBTC to c (non-source routing fee)
D pays 0.001 mBTC to e (non-source routing fee)
F pays 0.001 mBTC to e (non-source routing fee)
F pays 0.001 mBTC to g (non-source routing fee)
H pays 0.001 mBTC to g (non-source routing fee)
Net result:
A: -1.005
b: +0.001
c: +0.002
D: +0.001
e: +0.002
F: +0.001
g: +0.002
H: +0.996

2023-06-09 12:43:37

- reply

📅 Original date posted:2015-07-07
📝 Original message:
> Since we use "revocation preimages" to revoke transactions (rather than
> sending pubkeys as the original draft paper)
I remember the original paper mentioned sending private keys. I suppose
you mean that the preimages replace the *private* keys, not the pubkeys?
I was not aware of that design change, but it sounds like an
improvement.
CJP

2023-06-09 12:43:35

- reply

📅 Original date posted:2015-07-15
📝 Original message:
> > You could even offer negative fees for transactions that bring a channel
> > back to equilibrium. There could be a market for people making money
> > from bringing other peoples' channels back to equilibrium. This would
> > require either to step away from "net neutrality" (so, not the same fee
> > for every route / destination), or it would require some form of source
> > routing and explicitly setting the fees of intermediate nodes.
>
> Yes, this was suggested to me by Joseph Poon in a face-to-face
> conversation we had in San Francisco. It kind of blew my mind,
> actually. The fact that you discovered it too provides fairly
> convincing proof that you're smarter than me :)
Maybe :), but I'm not sure I invented it myself. I had a talk about
Amiko Pay at the Bitcoinference in Amsterdam, and someone in the
audience actually came up with this idea. I vaguely remember I was
already playing with the idea at that time, but I'm not really sure.
CJP

2023-06-09 12:43:34

- reply

📅 Original date posted:2015-07-15
📝 Original message:
Nick ODell schreef op di 14-07-2015 om 18:29 [-0600]:
> >I like to think of fees in the same way as we pay for Internet access.
> >Every physical hop in the Internet has related costs, e.g. in placing
> >the cables and upgrading the cables when new technology becomes
> >available and when demand grows.
>
> What sort of fee would this be? A percentage fee? A per-transaction fee? Both?
>
> I can see a compelling case for any of the three.
Rusty has argued for a fee that scales with Satoshi-seconds, so the
to-be-transferred amount times the amount of time it takes to finish the
transaction. The reason for that would be because then the fee scales
with the actual scarce good you're consuming (the ability to lock a
certain amount of funds for a certain amount of time on a channel is the
thing that's scarce).
Personally, I'd like to keep participants as free as possible in
choosing the right fee structure; the technology platform shouldn't
stand in the way. Virtually any fee structure is possible anyway, as
long as some trust exists between two sides of a link, but in order to
make fees trust-free, some fee structures require special features from
the underlying technology. Per-transaction fees that can be determined
in advance are easy to do, but e.g. the Satoshi-seconds structure is
something that requires an extension of the micro-transaction channel
design.
CJP

2023-06-09 12:43:33

- reply

📅 Original date posted:2015-07-14
📝 Original message:
> Fees are a real issue. Without source routing the client is guessing
> how much fees will be, and there'll be a lot of gaming to decide how
> much of the pie to take (take too much, you get none as payment fails to
> route). I think you'll end up asking your provider how you should to
> pay, and that's a pretty horrible model for privacy.
>
> With source routing and onion it's a little better; you can explicitly
> state what each hop gets. Of course, if your route/payment information
> is out of date you lose, too.
I like to think of fees in the same way as we pay for Internet access.
Every physical hop in the Internet has related costs, e.g. in placing
the cables and upgrading the cables when new technology becomes
available and when demand grows. Yet it doesn't matter for your Internet
bill how many hops your packets make, or which route they follow. Your
ISP will just average out all the costs it has to make on its
interfaces, and present a fraction of that to each customer. At some
points in the middle between providers, there are places where both
sides have an equal interest in maintaining their link, and no fees are
charged.
One major difference with the Internet is that we already have a
micro-transaction infrastructure in place, which is something the
Internet has never had (until now). This means it is possible to do
instant per-transaction payment of transaction fees. The fact that we
CAN do it doesn't mean we SHOULD, but I think there are advantages:
non-immediate payment models always require some form of trust from at
least one of the sides. Immediate payment of a transaction fee is as
simple as updating the micro-transaction channel with a slightly larger
amount than the to-be-forwarded transaction amount.
An interesting question is whether nodes will be prepared to forward
payments at a net loss (the to-be-paid fee is higher than the
to-be-received fee); maybe they will, if they can compensate the losses
with higher profits on other transactions. Fee differences could play a
role in routing decisions.
That brings me to another point: fees could be used as a way to
incentivize people to bring channels back to equilibrium. When a
channel's funds are almost fully assigned to one of its sides, further
payments towards that side become nearly impossible. Increasing fees in
that direction and decreasing fees in the opposite direction should
incentivize people to perform more transactions that bring the channel
back to equilibrium, and to perform less transactions that bring it
further out of equilibrium, or find alternative routes for those
transactions.
You could even offer negative fees for transactions that bring a channel
back to equilibrium. There could be a market for people making money
from bringing other peoples' channels back to equilibrium. This would
require either to step away from "net neutrality" (so, not the same fee
for every route / destination), or it would require some form of source
routing and explicitly setting the fees of intermediate nodes.
My "neutral meeting point" routing design, which is effectively a
two-hop source routing, is already good enough: a node in the middle of
the network is advertising that it can benefit from a negative fee, and
it invites people to perform transactions and to share the profit. It
creates two routable addresses (one for the negative-fee interface (A)
and one for all other interfaces (B)). Other people can then perform a
payment-to-self, with payee side routing to A and payer-side routing to
B. Payee-side can then have a larger payment amount than payer-side, as
agreed with the meeting point, to transfer a part of the profit to the
person performing the transaction.
CJP

2023-06-09 12:43:33

- reply

📅 Original date posted:2015-07-14
📝 Original message:
> OK, so this is why I proposed an onion routing system.
>
> Basically: each node sees the next hop, the R hash, the amount, the
> timeout, the fee being offered. It doesn't see the source, nor the
> final destination.
>
> This, however, requires source routing.
Ah, now I understand a bit better what you mean with onion routing. Yes,
that requires source routing, and it is another way of anonymizing the
route. A disadvantage of this approach is that it requires the source of
a route (so basically everyone) to know the shape of the network (who is
connected to who), which is a privacy disadvantage. This is not
necessary in TOR, since in TOR, every node can (usually) connect to
every other node, so finding a route is trivial.
At the risk of making things too complicated: it is possible to combine
both concepts in a single design. Source routing just requires the
protocol to be able to carry arbitrary payload data to the next
waypoint, so that the waypoint (which is supposed to understand the
arbitrary payload data) can determine how the route should be continued.
It's perfectly fine if the final waypoint of the route is a "neutral
meeting point" somewhere in the middle, as in my concept. In-between
waypoints, routers are free to use non-source routing, as long as the
waypoints can report with reasonable accuracy which other waypoints are
reachable, so that other nodes know the high-level shape of the network
for use in their source routing.
I don't see the "several thousand hubs" model as more sensitive to
centralization/censorship than other routing models, as long as there is
no barrier to creating your own hub and to start using new hubs. Any
routing model has routable addresses and risks addresses being censored
by a part of the network.
There is one other attack mode I see, which is independent of the
routing method: a powerful attacker (read: government) could be
monitoring transactions on several "regulated" nodes. It could also gain
the ability, every once in a while, to initiate transactions from an
"illegal" node that should have been censored (e.g. by physical access
to its hardware). If such transactions are routed over "regulated"
nodes, it would immediately recognize this, because the transaction hash
would be the same. The attacker can then identify the node that allows
"illegal" transactions to enter the regulated network, and punish it.
Even if we find a way to somehow use a different hash on every hop of a
transaction, it can still do this based on the exact payment amount, or
based on timing. I don't see right now how this attack mode can be
eliminated; maybe it should be accepted as a risk inherent in the design
of the network. Let's hope that the freedom-loving part of the network
will always be so large that censorship-loving parts will just hurt
themselves by isolating themselves.
> In summary:
>
> 1) Each-hop routing:
> - Final destination hub is revealed to all nodes.
> - May be forwarded, though.
Yes, may be forwarded, as in the "hybrid design" I described here. Also,
bi-directional routing towards a meeting point in the middle doesn't
reveal the final destination of the route as a whole.
> - Source may be revealed to all nodes?
Not necessary. You just need to keep the route open for a while, so that
messages towards the source can follow it back.
> - Fees are tricky.
> - Too low will fail
> - How to estimate?
I'll make another reply about fees; that's a whole subject on its own.
> - Adaptable to changing network conditions
> - Intermediary nodes can reroute.
> - End clients need not know anything.
>
> 2) Source routing:
> - Neither final source nor dest revealed to intermediary nodes.
> - Fees are known in advance.
> - Requires retransmission from source if routes change.
> - End clients need routing/fee information.
> - Allows selection of nodes from source
> - May let you avoid bad/tracking/unreliable nodes?
CJP

2023-06-09 12:43:32

- reply

📅 Original date posted:2015-07-07
📝 Original message:
The routing design has important implications for privacy, but also for
the enforcement of regulations on the Lightning network.
Imagine, for instance, that a couple of large nodes start requiring
their neighbors to provide identity information (KYC-style regulation),
and then require them to recursively provide identity information for
all their neighbors' neighbors, and so on. If it is visible to
intermediate nodes which other nodes participate in a transaction, this
would cause the Lightning network to split into a regulated and a
non-regulated part: nobody would dare to interface between the two,
since that would prove to the regulated side that they illegally provide
connectivity on the non-regulated side.
So, I don't want nodes to explicitly know the shape of the entire
network. Based on how Wikipedia explains source routing to me, I think
it is incompatible with what I want. Please also note that IP almost
never uses source routing.
Also, as a counter-measure against censorship (or persecution) based on
destination address, I think the function of "destination address of a
route" should be de-coupled from the function of "payer endpoint" or
"payee endpoint" of a route. In many cases, the "payer endpoint" or
especially the "payee endpoint" will also fulfill the role of
"destination address", but they may also choose a neutral "meeting
point" node in the middle, and both route towards its address. This will
allow nodes to secretly interface between regulated and non-regulated
parts of the network, for transactions going in both directions.
The time-out value is a bit of a problem in this concept, since it is an
indication of the number of hops from the payee endpoint. However, if
nodes are free to choose the time-out increment for themselves, they
could choose to make that increment smaller, to be able to route through
a node that provides an interface to the regulated part.
An additional advantage of separating destination addresses from the
payment endpoints is that routing tables can be much smaller. Most
consumers, and a lot of small shops can choose not to have their own
destination address, but instead route through the destination address
of their Lightning provider (a bit like a NAT router's IP address).
In my view, routing tables are a sort of a heuristic, that tells you how
likely a payment (of a certain amount!) to/from a certain destination
address is to succeed on one of your interfaces. It is an optimization
over the dumb algorithm of simply trying out all your interfaces one by
one(*). It is TBD how to determine these heuristics, and how to exchange
them between nodes.
This is probably quite different from how routing on the Internet works,
and I'm not sure how it will scale and how it can be defended against
DoS attacks, but it sort of follows automatically from the desire to
keep the network free.
CJP
(*) Which is currently the only routing method implemented in Amiko Pay.
Rusty Russell schreef op vr 03-07-2015 om 11:40 [+0930]:
> Hi all,
>
> One of the fun open questions for LN is how routing will work.
> I'd like to kick off that discussion now, to see if we can create a
> strawman which doesn't immediately collapse.
>
> Assumptions:
> 1. I'm assuming each node is known by its pubkey.
>
> 2. Source routing seems the easiest route; best for privacy, best for
> any tradeoffs between reliability/price etc.
>
> 3. We should do onion routing: each node knows the source and next step.
> This is not perfect: R values trivially identifies connections (if
> you own two nodes on the path, you can connect them), and the timeout
> implies a minimum TTL.
>
> 4. A recipient gives the payer 100 routes from some nodes to them. The
> payer hopefully can route to one of the mentioned nodes (probably the
> cheapest). This also means that if the payer has to do some route
> query it doesn't trivially reveal who the recipient is.
>
> Route broadcast is more fun. It's not like BGP where you have useful
> subnets; even if you did, you need the pubkey of every node.
>
> My original idea was a subset of hubs (a few thousand?) to which you
> would connect: that makes full discovery routing fairly easy within that
> network, and you report your address as "client XXXXX via hub <pubkey>".
> Your hub(s) keep the routing tables, you just query them mostly.
>
> A more ambitious idea would be to select N "beacons" based on the block
> hash which every node figures out their best routes to/from. That's
> actually really efficient for broadcasting: you can guess whether a node
> is a likely beacon based on previous results, and only broadcast likely
> winners. It also means each node only has to remember N * 144 routes
> each way if we want beacons to expire after a day.
>
> But could also result in the beacons (and their neighbors) getting
> slammed. Maybe beacons only become usable after 10 blocks, so they have
> a chance to boost their connections in preparation? I'd have to
> simulate it...
>
> Joseph also pointed out that the anchor transactions in the blockchain
> imply the network topology. That's kind of cool, but I'll let him
> explore that.
>
> Cheers,
> Rusty