Anthony Towns [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-18 to 2023-04-20
💬 Posted a total of 441 messages
📚 Participated in the following categories: bitcoin-dev, BIP, Lightning-dev, PROPOSAL, Opt-in full-RBF, BOLT RFC#1, try2
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h

Profile Code

nprofile1qqs0plk6dt2ca205smjxn7rm8wvevj2rvw3xnq4cv3n8chv2evz592c7e4vc9

Author Public Key

npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h

Show more details

Last Notes

2023-09-12 08:59:58

- reply

📅 Original date posted:2023-09-10
🗒️ Summary of this message: There is a tradeoff between trust and capital efficiency when it comes to UTXOs and lightning updates. If a user cheats, it can result in a large number of on-chain transactions. The impact of these transactions depends on the timeframe and can affect fees. Users can calculate the number of transactions based on their desired timeframe and adjust their rollover accordingly. This reduces the capital efficiency for the user who cheated. Casual users cannot easily reduce their timeout by splitting into different UTXOs.
📝 Original message:
On Fri, Sep 08, 2023 at 06:54:46PM +0000, jlspc via Lightning-dev wrote:
> TL;DR
> =====
I haven't really digested this, but I think there's a trust vs
capital-efficiency tradeoff here that's worth extracting.
Suppose you have a single UTXO, that's claimable by "B" at time T+L,
but at time T that UTXO holds funds belonging not only to B, but also
millions of casual users, C_1..C_1000000. If B cheats (eg by not signing
any further lightning updates between now and time T+L), then each
casual user needs to drop their channel to the chain, or else lose all
their funds. (Passive rollovers doesn't change this -- it just moves the
responsibility for dropping the channel to the chain to some other
participant)
That then faces the "thundering herd" problem -- instead of the single
one-in/one-out tx that we expected when B is doing the right thing,
we're instead seeing between 1M and 2M on-chain txs as everyone recovers
their funds (the number of casual users multiplied by some factor that
depends on how many outputs each internal tx has).
But whether an additional couple of million txs is a problem depends
on how long a timeframe they're spread over -- if it's a day or two,
then it might simply be impossible; if it's over a year or more, it
may not even be noticable; if it's somewhere in between, it might just
mean you're paying a modest amount in additional fees than you'd have
normally expected.
Suppose that casual users have a factor in mind, eg "If worst comes to
worst, and everyone decides to exit at the same time I do, I want to be
sure that only generates 100 extra transactions per block if everyone
wants to recover their funds prior to B being able to steal everything".
Then in that case, they can calculate along the following lines: 1M users
with 2-outputs per internal tx means 2M transactions, divide that by 100
gives 20k blocks, at 144 blocks per day, that's 5 months. Therefore,
I'm going to ensure all my funds are rolled over to a new utxo while
there's at least 5 months left on the timeout.
That lowers B's capital efficiency -- if all the causal users follow
that policy, then B is going to own all the funds in Fx for five whole
months before it can access them. So each utxo here has its total
lifetime (L) actually split into two phases: an active lifetime LA of
some period, and an inactive lifetime of LI=5 months, which would have
been used by everyone to recover their funds if B had attempted to block
normal rollover. The capital efficiency is then reduced by a factor of
1/(1+LA/LI). (LI is dependent on the number of users, their willingness
to pay high fees to recover their funds, and global blockchain capacity,
LA is L-LI, L is your choice)
Note that casual users can't easily reduce their LI timeout just by
having the provider split them into different utxos -- if the provider
cheats/fails, that's almost certainly a correlated across all their
utxos, and all the participants across each of those utxos will need
to drop to the chain to preserve their funds, each competing with each
other for confirmation.
Also, if different providers collude, they can cause problems: if you
expected 2M transactions over five months due to one provider failing,
that's one thing; but if a dozen providers fail simultaneously, then that
balloons up to perhaps 24M txs over the same five months, or perhaps 25%
of every block, which may be quite a different matter.
Ignoring that caveat, what do numbers here look like? If you're a provider
who issues a new utxo every week (so new customers can join without too
much delay), have a million casual users as customers, and target LA=16
weeks (~3.5 months), so users don't need to rollover too frequently,
and each user has a balanced channel with $2000 of their own funds,
and $2000 of your funds, so they can both pay and be paid, then your
utxos might look like:
active_1 through active_16: 62,500 users each; $250M balance each
inactive_17 through inactive_35: $250M balance each, all your funds,
waiting for timeout to be usable
That's:
* $2B of user funds
* $2B of your funds in active channels
* $4.5B of your funds locked up, waiting for timeout
In that case, only 30% of the $6.5B worth of working capital that you've
dedicated to lightning is actually available for routing.
Optimising that formula by making LA as large as possible doesn't
necessarily work -- if a casual user spends all their funds and
disappears prior to the active lifetime running out, then those
funds can't be easily spent by B until the total lifetime runs out,
so depending on how persistent your casual users are, I think that's
another way of ending up with your capital locked up unproductively.
(There are probably ways around this with additional complexity: eg,
you could peer with a dedicated node, and have the timeout path be
"you+them+timeout", so that while you could steal from casual users who
don't rollover, you can't steal from your dedicated peer, so that $4.5B
could be rolled into a channel with them, and used for routing)
You could perhaps also vary the timeout at different layers of the
internal tree -- if you have 500k users with a $10 balance, and give them
a timeout of 16 weeks, and give the remaining 500k with an average $2000
balance a timeout of 26 weeks, then each will calculate LI=10 weeks,
and the $10 folks will rollover at 1.5 months, and the remainder will
rollover at about 4 months; but your idle balance will be $5M for 20
weeks plus $1B for 10 weeks, rather than $1.005B for 20 weeks.
Anyway, I think that's an interesting way of capturing a big concern
with this sort of approach (namely, "what happens if the nice, scalable
path doesn't work, and we have to dump *LOTS* of stuff onchain") in a
measurable way.
Cheers,
aj

2023-07-27 00:22:34

- reply

📅 Original date posted:2023-07-26
🗒️ Summary of this message: Carla thanks everyone for their participation in the meeting and acknowledges Wolf for hosting in NYC and Michael Levin for providing notes.
📝 Original message:
On Wed, Jul 19, 2023 at 09:56:11AM -0400, Carla Kirk-Cohen wrote:
> Thanks to everyone who traveled far, Wolf for hosting us in style in
> NYC and to Michael Levin for helping out with notes <3
Thanks for the notes!
Couple of comments:
> - What is the “top of mempool” assumption?
FWIW, I think this makes much more sense if you think about this as a
few related, but separate goals:
* transactors want their proposed txs to go to miners
* pools/miners want to see the most profitable txs asap
* node operators want to support bitcoin users/businesses
* node operators also want to avoid wasting too much bandwidth/cpu/etc
relaying txs that aren't going to be mined, both their own and that
of other nodes'
* people who care about decentralisation want miners to get near-optimal
tx selection with a default bitcoind setup, so there's no secret
sauce or moats that could encourage a mining monopoly to develop
Special casing lightning unilateral closes [0] probably wouldn't be
horrible. It's obviously good for the first three goals. As far as the
fourth, if it was lightning nodes doing the relaying, they could limit
each unilateral close to one rbf attempt (based on to_local/to_remote
outputs changing). And for the fifth, provided unilateral closes remain
rare, the special config isn't likely to cause much of a profit difference
between big pools and small ones (and maybe that's only a short term
issue, and a more general solution will be found and implemented, where
stuff that would be in the next block gets relayed much more aggressively,
even if it replaces a lot of transactions).
[0] eg, by having lightning nodes relay the txs even when bitcoind
doesn't relay them, and having some miners run special configurations
to pull those txs in.
> - Is there a future where miners don’t care about policy at all?
Thinking about the different goals above seems like it gives a clear
answer to this: as far as mining goes, no there's no need to care
about policy restricitions -- policy is just there to meet other goals:
making it possible to run a node without wasting bandwidth, and to help
decentralisation by letting miners just buy hardware and deploy it,
without needing to do a bunch of protocol level trade secret/black magic
stuff in order to be competitive.
> - It must be zero fee so that it will be evicted.
The point of making a tx with ephemeral outputs be zero fee is to
prevent it from being mined in non-attack scenarios, which in turn avoids
generating a dust utxo. (An attacking miner can just create arbitrary
dust utxos already, of course)
> - Should we add trimmed HTLCs to the ephemeral anchor?
> - You can’t keep things in OP_TRUE because they’ll be taken.
> - You can also just put it in fees as before.
The only way value in an OP_TRUE output can be taken is by confirming
the parent tx that created the OP_TRUE output, exactly the same as if
the value had been spent to fees instead.
Putting the value to fees directly would violate the "tx must be zero
fee if it creates ephemeral outputs" constraint above.
> ### Hybrid Approach to Channel Jamming
> - Generally when we think about jamming, there are three “classes” of
> mitigations:
> - Monetary: unconditional fees, implemented in various ways.
> - The problem is that none of these solutions work in isolation.
> - Monetary: the cost that will deter an attacker is unreasonable for an
> honest user, and the cost that is reasonable for an honest user is too low
> for an attacker.
A different way of thinking about the monetary approach is in terms of
scaling rather than deterrance: that is, try to make the cost that the
attacker pays sufficient to scale up your node/the network so that you
continue to have excess capacity to serve regular users.
In that case, if people are suddenly routing their netflix data and
nostr photo libraries over lightning onion packets, that's fine: you
make them pay amazon ec2 prices plus 50% for the resources they use,
and when they do , you deploy more servers. ie, turn your attackers and
spammers into a profit centre.
I've had an email about this sitting in my drafts for a few years now,
but I think this could work something like:
- message spam (ie, onion traffic costs): when you send a message
to a peer, pay for its bandwidth and compute. Perhaps something
like 20c/GB is reasonable, which is something like 1msat per onion
packet, so perhaps 20msat per onion packet if you're forwarding it
over 20 hops.
- liquidity DoS prevention: if you're in receipt of a HTLC/PTLC and
aren't cancelling or confirming it, you pay your peer a fee for
holding their funds. (if you're forwarding the HTLC, then whoever you
forwarded to pays you a slightly higher fee, while they hold your
funds) Something like 1ppm per hour matches a 1% pa return, so if
you're an LSP holding on to a $20 payment waiting for the recipient to
come online and claim it, then you might be paying out $0.0004 per hour
(1.4sat) in order for 20 intermediate hops to each be making 20%
pa interest on their held up funds.
- actual payment incentives: eg, a $20 payment paying 0.05% fees
(phoenix's minimum) costs $0.01 (33sat). Obviously you want this
number to be a lot higher than all the DoS prevention fees.
If you get too much message spam, you fire up more amazon compute
and take maybe 10c/GB in profit; if all your liquidity gets used up,
congrats you've just gotten 20%+ APY on your bitcoin without third party
risk and you can either reinvest your profits or increase your fees; and
all of those numbers are just noise compared to actual payment traffic,
which is 30x or 1500x more profitable.
> - How do you know that these fees will be small? The market could decide
> otherwise.
If the liquidity or message fees on the network are high it's easy to
spin up new lightning nodes at slightly lower fees and steal all that
traffic while still being hugely profitable.
> - The problem here is that there’s no way to prove time when things go
> wrong, and any solution without a universal clock will fall back on
> cooperation which breaks down in the case of an attack.
The amounts here are all very low, so I don't think you really need much
more precision than "hourly". I think you could even do it "per block"
and convert "1% pa" as actually "0.2 parts per million per block", since
the only thing time is relevant for is turning liquidity DoS into an APY
figure. Presumably that needs some tweaking to deal with the possibility
of reorgs or stale blocks.
> - No honest user will be willing to pay the price for the worst case,
> which gets us back to the pricing issue.
> - There’s also an incentives issue when the “rent” we pay for these two
> weeks worst case is more than the forwarding fee, so a router may be
> incentivized to just hang on to that amount and bank it.
I think the worst case for that scenario is if you have a route
A1 -> A2 -> .. -> A19 -> B -> A20
then B closes the {B,A20} channel and at the end of the timeout A20 claims
the funds. At that point B will have paid liquidity fees to A1..A19 for
the full two week period, but will have only received a fixed payout
from A20 due to the channel close.
At 10% APY, with a $1000 payment, B will have paid ~$73 to A (7.3%). If
the close channel transaction costs, say, $5, then either you end up with
B wanting to close the channel early in non-attack scenarios (they collect
$73 from A20, but only pay perhaps 4c back to A1..A19, and perhaps $6 to
open and close the channel), or you end up with A holding up the funds
and leaching off B (B only collects, say, $20 from A20, but then A20
claims the funds after two weeks so is either up $75 if B didn't claim
the funds from A19, or is up $53 after B paid liquidity fees for 2 weeks).
_But_ I think this is an unreasonable scenario: the only reason for B to
forward a HTLC with a 2 week expiry is if they're early in the route,
but the only reason to accept a large liquidity fee is if they're late
in the route. So I think you can solve that by only forwarding a payment
if the liquidity fee rate multiplied by the expiry is below a cap, eg:
A19 -> B : wants 36ppm per block; cap/ppm = 500/36 = 13.8
B -> A20 : expiry is in 13 blocks; wants 38ppm per block
(2ppm per block ~= 10% APY)
For comparison, at the start of the chain, things look like:
A2 -> A3 : wants 2ppm per block; cap/ppm = 500/2 = 250
A3 -> A4 : expiry is in 250 blocks; wants 4ppm per block
In each case, the commitment tx would look like:
$1000 HTLC paying Y refunding to X
$0.50 liquidity fee bonus to X's balance (500ppm cap)
> - They’re not large enough to be enforceable, so somebody always has
> to give the money back off chain.
If the cap is 500ppm per block, then the liquidity fees for a 2000sat
payment ($0.60) are redeemable onchain.
> - Does everybody feel resolved on the statement that we need to take this
> hybrid approach to clamp down on jamming? Are there any “what about
> solution X” questions left for anyone? Nothing came up.
(Actually implementing the above is obviously a tonne of work --
in particular it requires every node in the route to support paying
liquidity fees eg -- assuming it doesn't turn out to be impossible, so
please don't take any of the above as an objection to using reputation
to reduce DoS vectors)
Cheers,
aj

2023-06-09 13:12:36

- reply

📅 Original date posted:2023-02-06
🗒️ Summary of this message: A potential issue with Lightning Network's asset-aware endpoints is the "free call option" problem, where a node can hold up a payment to profit from price fluctuations. This is more of an issue with assets of high volatility.
📝 Original message:
On Mon, Apr 11, 2022 at 02:59:16PM -0400, Olaoluwa Osuntokun wrote:
Thread necromancy, but hey.
> > anything about Taro or the way you plan to implement support for
> > transferring fungible assets via asset-aware LN endpoints[1] will address
> > the "free call option" problem, which I think was first discussed on this
> > list by Corné Plooy[2] and was later extended by ZmnSCPxj[3], with Tamas
> > Blummer[4] providing the following summary
>
> I agree w/ Tamas' quote there in that the problem doesn't exist for
> transfers using the same asset. Consider a case of Alice sending to Bob,
> with both of them using a hypothetical asset, USD-beef: if the final/last
> hop withholds the HTLC, then they risk Bob not accepting the HTLC either due
> to the payment timing out, or exchange rate fluctuations resulting in an
> insufficient amount delivered to the destination (Bob wanted 10 USD-beef,
> but the bound BTC in the onion route is only now 9 USD-beef), in either case
> the payment would be cancelled.
I don't think this defense actually works. If you have:
Alice -> Bob -> Carol -> Dave -> Elizabeth
with Alice/Bob and Dave/Elizabeth having USD channels, but
Bob/Carol and Carol/Dave being BTC channels, then Dave has
a reasonable opportunity to cheat:
- he can be pretty confident that Elizabeth is the final recipient
(since USD is meant to be at the edges, and this is a BTC to USD
conversion)
- he knows the expected USD value of the payment to Elizabeth
- he knows what the on-chain timeout of the USD payment to Elizabeth
will be, because he shares the channel, so can likely be confident
Elizabeth won't cancel the tx as long as he forwards it to her by then
- he can hold up the outbound USD payment while holding onto the
inbound BTC payment, only forwarding the payment on to Elizabeth if
the price of BTC stays the same or increases.
I'm not an expert, but I tried a Black Scholes calculator with an
estimate for Bitcoin's volatility, and it suggests that the fair price
of an option like that that lasts an hour is about 0.3% of the par value
(ie, for a $1000 payment, the ability to hold up the BTC/USD conversion
for an hour and only do it when it's profitable, is worth about $3). That
seems substantial compared to normal lightning fee rates, which I think
are often in the 0.01% to 0.1% range?
(Note that this way of analysing the free option problem means it's
only an issue when the two assets have high volatility -- if they're
sufficiently correlated, like USDT and USDC, or perhaps even USD and EUR,
then the value of the free option is minimised, perhaps to the point
where it's not worth trying to exploit)
Bob may have a similar ability to interfere with the payment, but is
much more constrained: he probably doesn't know Elizabeth's timeout;
and if he's making a profit because the price of BTC has gone down,
then Dave is likely to cancel the transaction rather than forwarding it
to Elizabeth, since he'd be making a lock when converting the BTC amount
to its pre-drop USD value. However, if there wasn't a followup conversion
back from BTC to USD, and Bill was willing to guess at the final timeout
of the payment, he could still make a profit from delaying payments.
(Though it's also less harmful here: only the Alice/Bob funds are being
held up indefinitely, not the funds from random channels)
I think maybe a better approach might be:
Alice -> Bob -BTC-> Carol -BTC-> Elizabeth -BTC-> Dave -USD-> Elizabeth
That is, Alice sends $100 to Bob who forwards 0.004 BTC (or whatever) to
Carol and then Elizabeth; then, before accepting the payment, Elizabeth
extends the path with a BTC/USD exchange with Dave via a short loop. If
Dave doesn't immediately forward the USD to Elizabeth, she can cancel
the transaction, refunding Carol all the way back to Alice, even while
waiting for Dave. She doesn't need to be concerned that Dave could
claim funds from her, as all the transfers are conditional on a secret
only Elizabeth knows, and that she has not yet revealed. If Dave tries
exploiting the free option, Elizabeth can see he doesn't reliably finish
the loop quickly, and try finding another, better, exchange.
That approach also means Alice doesn't need to know what Elizabeth's
currency preference is; she's just sending BTC, so she only needs to
know about the exchange rate between BTC and her own currency, which
seems like it means there's one less thing that could go wrong.
Cheers,
aj

2023-06-09 13:12:33

- reply

📅 Original date posted:2023-01-30
🗒️ Summary of this message: Alice trying to pay Bob through their respective LSPs, Louise and Larry, using a PTLC preimage and a schnorr signature to ensure payment authenticity.
📝 Original message:
After listening to the optech space on the topic, thought it might be
worth having a second go at explaining the idea...
Alice is trying to pay Bob. Alice has an LSP, Louise. Bob has an LSP
Larry. Louise and Larry are online 24/7 but don't have access to Alice
and Bob's private keys. We want the payment flow to be something like:
1) Larry gets some setup info from Bob, Bob goes offline.
* Alice hears about Bob's address, and decides to pay Bob $50.
2) Alice coordinates a unique invoice id with Larry, which we'll call S.
3) Alice tells Louise that she's trying to pay Bob $50 for invoice S.
* Louise registers with Larry to be told when Bob is online.
* Alice goes offline.
* Bob goes online.
* Larry tells Louise that Bob is online.
4) Louise sends the payment to Bob conditional on S.
5) Bob accepts the payment.
* Louise claims the $50 from Alice and closes out the transaction.
6) Alice receives a receipt from Bob.
The goal of a receipt is that if two people want to pay Bob $50, they'll
be able to guarantee that (a) Bob was paid, rather than someone else; (b)
that the receipts are different (so Bob received $100 total, rather than
$50 going somewhere else and one of them just got a photocopied receipt);
and (c) after the fact they can prove that the receipt was theirs,
not someone else's. (a) and (b) prevent the funds getting misdirected;
(c) potentially allows you to use the receipt as evidence to a third
party if you paid for something in advance, then didn't receive it.
To get all those things, what we want is really more like a signature,
than just a hash/preimage. But PTLC preimages and schnorr signatures
aren't much different: with a PTLC preimage, you pay to point S and then
receive back the preimage s, where s*G = S. Meanwhile schnorr signatures
are made up of a number (s) and a point (R), which satisfy the equation:
s*G = R + H(R,P,m)*P
But, if you're willing to squint a bit, you can just wrap the whole
right side of the equation up as "S", and treat it as a PTLC.
(notation: I use capital letters to represent points, and lower case
letters to represent numbers; so if A is a point, a is it's discrete log,
and a*G = A)
To calculate S, you need to know three things: R, P and m -- P is just
the signer's public key, m is the message being signed, but "R" is the
public "nonce" part of the signature, that has to be chosen by the signer
(otherwise whoever does choose it can probably arrange to discover the
signer's private key after a signature or two).
So in that case, the protocol looks like:
Alice proposes that Bob signs a message, eg
m = "Alice paid me $50 -- Bob"
(perhaps this can be some standard nostr message, eg)
Bob chooses an R for this signature, and tells Alice what R is
Alice calculates "S"
Alice pays Bob $50 via a PTLC conditional on S
If Bob accepts the $50, Alice receives the preimage of S, ie s
Alice combines (R,s) and that is a Bob's signature on her message
Having Bob be offline with Alice only able to talk to his
not-fully-trusted representative Larry complicates things. Bob now can't
just choose a brand new R after already knowing Alice's message m, and
that introduces cryptographic attacks [0], where if Alice can request
nonces for many messages she may be able to find a lucky combination
of messages/nonces where she can combine the signatures Bob ends up
generating to steal Bob's private key.
[0] https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da
I *think* those attacks can be avoided by using the same musig2 approach
to generating nonces:
Bob prepares a nonce *pair* R1, R2
Alice chooses the message m
The nonce for the message m is calculated as H(R1,R2,m)*R1 + R2
Note that this doesn't allow you to safely reuse nonces -- if you have
three messages signed with the same R1/R2 pair, the schnorr signing
equation (s = r + H(R,P,m)*p) over each of the three messages gives you
three equations with just three unknowns (r1, r2, and the secret key
p), which you can use regular maths to solve, no fancy attacks needed.
(Presumably if you just reuse a pair twice you open yourself back up to
a Wagner attack)
So that adds up to:
1) Bob shares with Larry a bunch of (R1,R2) points that will form the
basis of his signature nonces. They can be constructed via a
(hardened) HD scheme so that Bob can easily regenerate them just
from an index, eg.
2) Alice obtains a unique (R1,R2) pair from Larry
Alice determines the message she wants Bob to sign (presumably Bob
provides a standard template, and Alice fills in her name and perhaps
what she's paying for) -- this is "m".
Alice calculates R from R1,R2,m; and S from R,P,m
3) Alice passes "m" and "S" onto Louise and starts the payment, locking
up her funds
4) Louise passes "m", "R1", "R2" onto Bob once he's online and sends
the payment to Bob.
5) Bob checks that R1/R2 were what he generated and haven't already
been used; Bob checks that "m" is something he's willing to sign;
Bob calculates s and S, and accepts the payment for S, provided it's
the correct amount as specified in "m", by revealing s.
6) Alice already calculated R and now receives s from Louise when
Louise claims her funds, and (R,s) is a BIP340 signature of m by
Bob, satisfying s*G = R + H(R,P,m)*P, and that signature serves as
her payment receipt from Bob.
Cheers,
aj
On Thu, Jan 26, 2023 at 11:04:12AM +1000, Anthony Towns wrote:
> On Tue, Jan 10, 2023 at 07:41:09PM +0000, vwallace via Lightning-dev wrote:
> > The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time.
>
> Assuming the overall process is:
>
> * Alice sends a payment to Bob, who has provided a reusable address
> AddrBob
> * Bob is offline at the time the payment is sent, but his semi-trusted
> LSP Larry is online
> * Alice is willing/able to do bidirectional communication with Larry
> * The payment does not complete until Bob is online (at which point
> Alice may be offline)
>
> I think in this case you want to aim for the receipt to be a BIP340
> signature of the message "Alice has paid me $50 -- signed Bob".
>
> Given Bob's public signature nonce, R, Alice (and Larry) can calculate
> S = R + H(R,P,m)*P (m is the receipt message, P is Bob's public key),
> and then Alice can send a PTLC conditional on revealing the log of S, ie
> s where s*G=S; and at that point (s, R) is a valid signature by Bob of a
> message confirming payment to Bob, which then serves as the final receipt.
>
> However for this to work, Alice needs to discover "R" while Bob is
> offline. I think this is only doable if Bob pre-generates a set of
> nonces and shares the public part with Larry, who can then share them
> with potential payers. I think to avoid attacks via Wagner's algorithm,
> you probably need to do a similar setup as musig2 does, ie share (R1,R2)
> pairs, and calculate R = H(P,R1,R2,m)*R1+R2.
>
> So a setup like:
>
> Alice gets AddrBob. Decodes Bob's pubkey, Larry's pubkey, and the
> route to Larry.
>
> Alice -> Larry: "Hi, I want to send Bob $50, and get a receipt"
> Larry -> Alice: "The nonce for that will be R"
> Alice: calculates m = "Hash("Alice paid Bob $50"), S = R+H(R,P,m)*P
> Alice -> Larry(for Bob): PTLC[$50, S]
>
> Larry -> Bob: PTLC[$50, S]
> Alice wants to pay you $50, using nonce pair #12345
> Bob: verifies nonce #12345 has not been previously used, calculates R,
> calculates m, calculates s, and checks that s*G = S, checks
> there's a $50 PTLC conditional on S waiting for confirmation.
> Bob -> Alice: claims $50 from PTLC by revealing s
>
> Alice: receives s; (R,s) serves as Bob's signature confirming payment
>
> seems plausible?
>
> Every "S" here commits to a value chosen by the sender (ie, their
> "identity"), so there's no way for Larry to get two different payers
> to use the same S. Using the same nonce twice will just mean Bob has to
> reject the payment (and find a new LSP).
>
> It may make sense to require Alice to make a micropayment to Larry in
> order to claim a nonce. You'd want a standard template for "m" so that
> it's easy to generate and parse consistently, of course.
>
> I think you could even have separate LSPs if you wanted: one to issue
> nonces while you're offline, and the other to actually hold onto incoming
> PTLCs while you're offline.
>
> FWIW, some previous discussion, which didn't focus on offline recipients:
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001034.html
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001490.html
----- End forwarded message -----

2023-06-09 13:12:30

- reply

📅 Original date posted:2023-01-25
🗒️ Summary of this message: The open research question is how the sender will receive an invoice from the offline receiver. A possible solution is to use BIP340 signature and nonce sharing.
📝 Original message:
On Tue, Jan 10, 2023 at 07:41:09PM +0000, vwallace via Lightning-dev wrote:
> The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time.
Assuming the overall process is:
* Alice sends a payment to Bob, who has provided a reusable address
AddrBob
* Bob is offline at the time the payment is sent, but his semi-trusted
LSP Larry is online
* Alice is willing/able to do bidirectional communication with Larry
* The payment does not complete until Bob is online (at which point
Alice may be offline)
I think in this case you want to aim for the receipt to be a BIP340
signature of the message "Alice has paid me $50 -- signed Bob".
Given Bob's public signature nonce, R, Alice (and Larry) can calculate
S = R + H(R,P,m)*P (m is the receipt message, P is Bob's public key),
and then Alice can send a PTLC conditional on revealing the log of S, ie
s where s*G=S; and at that point (s, R) is a valid signature by Bob of a
message confirming payment to Bob, which then serves as the final receipt.
However for this to work, Alice needs to discover "R" while Bob is
offline. I think this is only doable if Bob pre-generates a set of
nonces and shares the public part with Larry, who can then share them
with potential payers. I think to avoid attacks via Wagner's algorithm,
you probably need to do a similar setup as musig2 does, ie share (R1,R2)
pairs, and calculate R = H(P,R1,R2,m)*R1+R2.
So a setup like:
Alice gets AddrBob. Decodes Bob's pubkey, Larry's pubkey, and the
route to Larry.
Alice -> Larry: "Hi, I want to send Bob $50, and get a receipt"
Larry -> Alice: "The nonce for that will be R"
Alice: calculates m = "Hash("Alice paid Bob $50"), S = R+H(R,P,m)*P
Alice -> Larry(for Bob): PTLC[$50, S]
Larry -> Bob: PTLC[$50, S]
Alice wants to pay you $50, using nonce pair #12345
Bob: verifies nonce #12345 has not been previously used, calculates R,
calculates m, calculates s, and checks that s*G = S, checks
there's a $50 PTLC conditional on S waiting for confirmation.
Bob -> Alice: claims $50 from PTLC by revealing s
Alice: receives s; (R,s) serves as Bob's signature confirming payment
seems plausible?
Every "S" here commits to a value chosen by the sender (ie, their
"identity"), so there's no way for Larry to get two different payers
to use the same S. Using the same nonce twice will just mean Bob has to
reject the payment (and find a new LSP).
It may make sense to require Alice to make a micropayment to Larry in
order to claim a nonce. You'd want a standard template for "m" so that
it's easy to generate and parse consistently, of course.
I think you could even have separate LSPs if you wanted: one to issue
nonces while you're offline, and the other to actually hold onto incoming
PTLCs while you're offline.
FWIW, some previous discussion, which didn't focus on offline recipients:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001034.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001490.html
Cheers,
aj

2023-06-09 13:12:28

- reply

📅 Original date posted:2023-01-06
🗒️ Summary of this message: The proposed lightning network update breaks symmetry to prevent cheating and allow for immediate confirmation of closure, but there are still potential vulnerabilities.
📝 Original message:
On Thu, Jan 05, 2023 at 06:59:42PM -0500, Antoine Riard wrote:
> > A simple advantage to breaking the symmetry is that if A does a unilateral
> > close, then B can immediately confirm that closure releasing all funds
> > for both parties. Without breaking the symmetry, you can't distinguish
> > that case from B attempting to confirm his own unilateral close, which
> > would allow B to cheat.
> Yes, IIUC the proposed flow is UA.n -> CB.n -> money, and in this
> optimistic case, there is only one CLTV delay to respect the spend of the
> UA.
The only delay in the UA.n/CB.n case is if someone's trying to redeem
an HTLC that times out in the future, in which case you might have UA.n,
CB.n, (CB.n -> A's balance), (CB.n -> B's balance), (CB.n -> A claiming
HTLC x with preimage x') all in the same block, but (CB.n -> A claiming
HTLC y at timeout) happening 100 blocks later, when y times out.
> (Note on the gist, the UA state description includes a Pa or tapscript "IF
> CODESEP n OP_CLTV DROP ENDIF 1 CHECKSIG" as spendable paths and the CA.n
> state description nSequence = 0, so I'm not sure how the update/justice
> delay is enforced)
(Note that the CLTV here is just for eltoo state ratcheting, and is
always in the past so doesn't imply an actual delay)
CA.n is only able to spend UB.n, not UA.n. (Or it can spend WA.n, but
WA.n can only spend UB.k or prior WA.k, so it means much the same
thing).
That's achievable by having the CA.n signature use ANYPREVOUT rather than
ANYPREVOUTANYSCRIPT (thus committing to UB.n/WA.n's shared scriptPubKey)
and having different scriptPubKey's between UA.n and UB.n (which breaks
the symmetry).
SA.n spends UA.n or WB.n in the same way, except also sets nSequence to
force a relative timelock.
> > If Alice is dishonest, and posts a very old state (n-x), then Bob could
> > post up to x watchtower txs (WB.(n-x+1) .. WB.n) causing Alice to be
> > unable to access her funds for up to (x+1)*to_self_delay blocks. But
> > that's just a reason for her to not be dishonest in the first place.
> So I think there still is the case of Bob broadcasting a very old state and
> Alice's watchtowers colluding to prevent Alice's honest funds access,
> potentially preventing the HTLC-timeout, IIUC.
Alice was the dishonest one here, so it'd be Alice broadcasting an old
state, preventing Bob from accessing funds.
If you're not online and have no honest watchtowers, then Alice can just
broadcast an old state, wait for the delay, and confirm the old state
(UA.k -> SA.k), and steal as much as she wants.
If you are online, or have honest watchtowers, then your honest CB.n
or WB.n can be confirmed in the same block as 2000 dishonest WB.(k+1),
WA.(k+2) txs. The point of having a watchtower helping you out is that the
watchtower can do fancier things than your lightning node on your phone,
like observe the mempool and potentially have direct relationships with
mining pools to overcome things like the 25 tx ancestor/descendant limit.
> I don't know if we're not
> introducing some changes in the trust assumptions towards watchtowers where
> with vanilla eltoo a single compromised watchtower can be corrected by the
> honest channel holder or another watchtower, iirc.
The same scenario applies in traditional eltoo, except in that case
Alice doesn't need to compromise any of Bob's watchtowers, she can
just broadcast multiple states herself -- since the txs are symmetric,
there's no difference between Alice.1 -> Alice.2 and Alice.1 -> Bob.2;
so you can't allow the latter while preventing the former (and there's
likewise no difference between those and Alice.1 -> Watchtower.2).
> > No -- the RB.n transactions immediately release A's funds after applying
> > the penalty, so if the watchtower colludes with A and has an old RB.y
> > transaction, Alice can steal funds by posting UA.x and RB.y, provided that
> > her balance now is sufficiently less than her balance then (ie bal.n <
> > bal.y - penalty).
> >
> > In this model, Bob shouldn't be signing RB.n or CB.n txs until Alice
> > has already started a unilateral close and posted UA.n/UA.k.
> So the penalty transactions should not be delegated to untrusted
> watchtowers.
Yes.
> In case of RB.n signing key compromise, the whole channel
> funds might be lost.
Compromise of pretty much any of the signing keys allows all the channel
funds to be lost; this is always true of the key used for signing
cooperative closes, for instance.
If you do want to delegate punishment, you could probably have an
alternative setup where every watchtower transaction implies punishment.
(I assume watchtower punishment needs to be all or nothing, otherwise a
compromised watchtower would just rbf any attempts to punish, switching
them over to non-punishment, which then encourages attackers to compromise
watchtowers (and prioritise attacking people who use their compromised
watchtowers), and you'd end up with "nothing" anyway...)
Something like:
no-punishment:
UA.n -> delay -> SA.n (keypath)
UA.k -> CB.n (k <= n)
punishment of Alice:
UA.k -> RB.n (k < n - X)
UA.k -> WB.n (k < n)
WB.k -> WB.n (k < n)
WB.k -> RB.n (k <= n)
WB.n -> delay -> TA.n
where A only signs WB.n when the state has already updated to n+X,
and TA.n/RB.n transfers the punishment amount from A's balance to B's
balance compared to SA.n/CB.n.
That introduces an extra signature per state for TA.n, and probably an
additional one given the different constraints for RB.n when spending
UA.k vs WB.k.
Cheers,
aj

2023-06-09 13:12:26

- reply

📅 Original date posted:2023-01-04
🗒️ Summary of this message: A proposal for using a covenant to establish a channel without an expiry date, allowing it to be a first-class citizen among channels.
📝 Original message:
On Wed, Jan 04, 2023 at 01:06:36PM +1100, Lloyd Fournier wrote:
> The advantage of using a covenant
> is that the channel would not have an expiry date and therefore be a first
> class citizen among channels.
I think the approach here would be:
* receive funds on the in-potentiam address with 8000 block CSV
* LSP tracks immediately
* user's wallet wakes up, LSP reports address to user, user signs
a funding tx to establish the channel, and the state 0 close tx
* LSP considers it immediately active
* LSP broadcasts the tx, targeting confirmation within 3 days
* if the funding tx confirms promptly, you just have an ordinary channel
* after 800 blocks, if the tx hasn't confirmed, LSP fee bumps or
closes the channel (relying on the high-feerate unilateral close
tx to do the fee bumping)
ie:
day 0: someone -> in-potentiam address (payment made on-chain, confirmed)
day 7: in-potentiam -> funding (wallet wakes up, tx signed and broadcast,
not necessarily confirmed, channel active)
day 12: in-potentiam -> funding (confirmed)
day 9999: funding -> unilateral/cooperative close
or:
day 0: someone -> in-potentiam address (payment made on-chain, confirmed)
day 14: LSP forgets about in-potentiam utxo as its expiry is only 1000
blocks away
day 420: in-potentiam -> wherever (payment made on-chain by user)
So while the tx introspection approach you advocate *would* allow the
setup phase to skip the "expiry on day 14" restriction, I think the
*bigger* benefit is that you also wouldn't need the on-chain "in-potentiam
-> funding" transaction, but could instead just leave the in-potentiam
tx on chain indefinitely, until it was time to close the channel (which,
if it was a cooperative close, could just be a musig key path spend).
Either approach probably implies that you either have multiple channels
with your LSP (one for each in-potentiam payment you receive), or
that your single channel with your LSP is backed by multiple UTXOs
(maybe you choose an order for them, so that Alice owns 100% of the
balance in utxos 1..(k-1) and Bob owns 100% of the balance in utxos
(k+1)..n?). Otherwise you'd need an on-chain tx anyway to splice the new
funds into your existing channel; and that seems both annoying of itself,
and probably bad for privacy.
Cheers,
aj

2023-06-09 13:07:43

- reply

📅 Original date posted:2022-12-14
📝 Original message:
On Tue, Dec 13, 2022 at 08:22:55PM -0500, Antoine Riard wrote:
> > prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
> > broadcast one of either CA.n or RA.n, and will then have ~150 blocks
> > to claim the HTLC before its timeout
> From my understanding, with two party eltoo w/punihsment, UA.k has a
> tapscript path with "1 CHECKSIGVERIFY k<n CLTV", where the internal pubkey
> substituted is "musig(A,B)/1. Mallory should receive Bob's signature for
> UA.k, though also UA.k+1, UA.k+2, UAk+3, until k=n.
Yes, Mallory can be assumed to be able to generate signatures for UA.0
through UA.n. They all spend the funding transaction (only) though,
so she can only choose one of them, which I called UA.k above.
More particular, I'm imagining scriptPubKeys something like:
F: taproot(AB)
UA.n: taproot(AB/1, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
WB.n: taproot(AB/1, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
UB.n: taproot(AB/2, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
WA.n: taproot(AB/2, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
where AB=musig(A,B) and AB/1 and AB/2 are unhardened HD subkeys of AB.
(The outputs of SA/RA/CA and SB/RB/CB are the balances and active HTLCs)
Then I think the following setup works to allow each transaction to only
spend from the transactions that it's supposed to:
UA.n have ALL or SINGLE|ANYONECANPAY signatures spending F with key
AB.
CA.n/WA.n have ANYPREVOUTANYSCRIPT signatures with codesep_pos=2
against AB/2, with locktime set to n
RA.n has an ANYPREVOUTANYSCRIPT signature with codesep_pos=2
against AB/2, with locktime set to n-1
SA.n has an ANYPREVOUT signature with codesep_pos=FFFFFFFF
against AB/1, with nSequence enforcing to_self_delay
B's signatures are similar, swapping AB/2 and AB/1.
(In order to do the fast forward stuff via scriptless scripts, you also
need F to have an "A CHECKSIGVERIFY B CHECKSIG" tapscript path as well,
and there's probably other things I've glossed over)
> Or is this a tapscript only existing for the dual-funding case ? I think
> this a bit unclear from the gist construction, how Mallory is restrained to
> use the tapscript path on UA.k, with UA.k+1 as she should be in possession
> of Bob's signature for this state.
You lock Mallory into using a particular signature with a particular
script template by only using the key for that signature within that
script template, and you lock them into using a particular path through
that script via use of OP_CODESEPARATOR.
> While update transaction 1 could spend update transaction 0 immediately,
> there is no reliable knowledge by U*.1 transaction broadcaster of the state
> of the network mempools.
That doesn't need to be true; we can easily have lightning nodes
gossip mempool state for channel closes by pattern matching on the
close transaction, including offering "catchup" info for nodes that
were offline, even if that isn't something we do for regular mempool
transactions.
I don't really think getting into the weeds on that now is very productive
though; it's still an open question whether we can get eltoo working in
a laboratory environment, let alone in the wild.
> While I think this solution of eltoo nodes quickly replacing any state K
> previous to the latest state N, there is no guarantee the latest state K
> doesn't offer a higher feerate than state N, making it more attractive to
> the miners.
I think there's really two situations here: one is where miners are
just running friendly mempool software that tries to do right by the
network, in which case "always update to the newest state, even if the
fee rate goes down" is probably workable; the other is where miners want
to profit maximise on every single block and will run MEV software; in
which case all we need is for the final state to be relayed -- provided
its at a reasonable feerate, the MEV miner will include it on top of the
high-fee paying chain of earlier states, even if that would mean it has
"too many" in-mempool descendants.
Cheers,
aj

2023-06-09 13:07:42

- reply

📅 Original date posted:2022-12-13
📝 Original message:
On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
> The attack purpose is to delay the confirmation of the final settlement
> transaction S, to double-spend a HTLC forwarded by a routing hop.
> The cltv_expiry_delta requested by Ned is equal to N=144.
I believe what you're suggesting here is:
Mallory has two channels with Bob, M1 and M2. Both have a to_self_delay
of 144 blocks. In that case cltv_expiry_delay should include some slack,
I'm going to assume it's 154 blocks in total.
Mallory forwards a large payment, M1->Bob->M2.
Mallory claims the funds on M2 just prior to the timeout, but
goes offline on M1.
Bob chose the timeout for M2 via cltv_expiry_delay, so now has 154
blocks before the CLTV on the M1->Bob payment expires.
In this scenario, under the two-party eltoo scheme, Bob should:
1) immediately broadcast the most recent UB.n state for M1/Bob,
aiming for this to be confirmed within 5 blocks
2) wait 144 blocks for the relative timelock to expire
3) broadcast SB.n to finalise the funds, and immediately claim the
large HTLC. providing this confirms within 5 blocks, it will confirm
before the HTLC timelock expires, and Mallory will have been unable
to claim the funds.
The only transactions Mallory could broadcast are:
prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
broadcast one of either CA.n or RA.n, and will then have ~150 blocks
to claim the HTLC before its timeout
during (2): CA.n -- Again, this allows Bob to claim the HTLC
immediately, prior to its timeout
The only delaying attack with repeated transactions comes if Bob
broadcasts an old state UB.k (k < n), in which case Mallory can broadcast
(n-k) WA.i watchtower transactions prior to finalising the state. However
if Bob *only* has old state, Mallory can simply broadcast WA.n, at which
point Bob can do nothing, as (by assumption) he doesn't have access
to current state and thus doesn't have SB.n to broadcast it.
> The attack scenario works in the following way: Malicia updates the Eltoo
> channel N time, getting the possession of N update transactions. At block
> A, she breaks the channel and confirms the update transaction 0 by
> attaching a feerate equal to or superior to top mempool block space + 1
> sat. At each new block, she iterates by confirming the next update
> transaction, i.e update transaction 1 at block A+1, update transaction
> transaction 2 at block A+2, update transaction 3 at block A+3, ...
I think traditional eltoo envisages being able to spend update transaction
1 immediately, without having to wait for the next block. This might
not be compatible with the version 3 relay rules that are being thought
about, though, and presumably would hit ancestor limits.
I think a simple way to avoid that problem would be for eltoo nodes
to have a priority tx relay network -- if they see a channel close to
state N, always replace any txs closing to an earlier state K<N, and
always quickly relay that close to all other peers. There's no reason
to assume the bad guys have the best access to the network when we can
write code so that the honest participants have it instead.
> From Ned's viewpoint, there is limited rationality of the network mempools,
> as such each punishment transaction R, as it's confirmation could have been
> delay due to "honest" slow propagation on the network is likely to be
> pre-signed with top mempool block space feerate, but not more to save on
> fees. Therefore, transaction RN.0 should fail to punish update transaction
> 0 as it's double-spent by update transaction 1, transaction RN.1 should
> fail to punish update transaction 1 as it's double-spent by update
> transaction 2, transaction RN.2 should fail to punish update transaction 2
> as it's double-spent by update transaction 3...
In the two-party scheme, the only transaction Mallory can broadcast
after sending UA.k and having it confirmed on chain is SA.k, and that
only after a 144 block relative timelock. UA.(k+1) etc only spend the
funding output, but that has already been spent by UA.k.
Cheers,
aj

2023-06-09 13:07:37

- reply

📅 Original date posted:2022-12-07
📝 Original message:
Hi all,
On the eltoo irc channel we discussed optimising eltoo for the 2-party
scenario; figured it was probably worth repeating that here.
This is similar to:
- 2018-07-18, simplified eltoo: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
- 2021-09-17, IID 2Stage, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019470.html
- 2022-09-29, Daric: https://eprint.iacr.org/2022/1295
- 2022-10-21, eltoo/chia: https://twitter.com/bramcohen/status/1583122833932099585
The basic idea is "if it's a two party channel with just Alice and Bob,
then if Alice starts a unilateral close, then she's already had her say,
so it's only Bob's opinion that matters from now on, and he should be
able to act immediately", and once it's only Bob's opinion that matters,
you can simplify a bunch of things.
A "gist" for this idea is https://gist.github.com/ajtowns/53e0f735f4d5c06a681429d937200aa5 (it goes into a little more detail in places, though doesn't cover trustless watchtowers at all).
In particular, there are a few practical constraints that we might like
to consider for 2-party channels with eltoo:
- fast forwards: we might want to allow our channel partner
to immediately rely on a new state we propose without needing a
round-trip delay -- this potentially makes forwarding payments much
faster (though with some risk of locking the funds up, if you do a
fast forward to someone who's gone offline)
- doubled delays: once we publish the latest state we can, we want to
be able to claim the funds immediately after to_self_delay expires;
however if our counterparty has signatures for a newer state than we
do (which will happen if it was fast forwarded), they could post that
state shortly before to_self_delay expires, potentially increasing
the total delay to 2*to_self_delay.
- penalties: when you do a unilateral close, attempting to cheat comes
with no cost to you and a possible benefit if you succeed, but
potentially does cost your channel partner (either in forcing them
to spend on-chain fees to update to the correct state, or in the risk
of loss if their node malfunctions occassionally) -- a penalty could
reduce this incentive to cheat
- trustless watchtowers: we may want to consider the possibility of a
watchtower holding onto obsolete states and colluding with an
attacker to attempt to cheat us
What follows is a rough approach for dealing with all those issues for
two-party channels. It's spelled out in a little more detail in the gist.
(I think for initial eltoo experimentation it doesn't make sense to try to
deal with all (or perhaps any) of those constraints; simple and working
is better than complex and theoretical. But having them written down so
the ideas can be thought about and looked up later still seems useful)
In more detail: unilateral closes are handled by each channel participant
maintaining five transactions, which we'll call:
* UA.n, UB.n : unilaterally propose closing at state n
- this is for Alice or Bob to spend the funding tx for a unilater
close to state n. Spends the funding transaction.
* WA.n, WB.n : watchtower update to state n
- this is for an untrusted watchtower to correct attempted cheating
by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
(or UA.k/WB.k) respectively, provided k < n.
* CA.n, CB.n : cooperatively claim funds according to state n
- this is for Alice to confirm Bob's unilateral close (or vice-versa).
Spends UB.k, WA.k (or UA.k/WB.k respectively), provided k <= n
* SA.n, SB.n : slowly claim funds according to state n
- this is for Alice to claim her funds if Bob is completely offline
(or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
timelock of to_self_delay.
* RA.n, RB.n : claim funds with penalty after unilateral close to
revoked state
- this is for Alice to update the state if Bob attempted to cheat
(or vice-versa). Spends UB.k or WA.k (or UA.k/WB.k respectively)
conditional on k < n - 1; outputs are adjusted to transfer a fixed
penalty of penalty_msat from Bob's balance to Alice's (or vice-versa)
Each of these "transactions" requires a pre-signed signature; however
the actual transaction/txid will vary in cases where a transaction has
the possibility of spending different inputs (eg "Spends UB.k or WA.k").
In particular UA.n/UB.n can be constructed with known txids and non-APO
signatures but WA.n/WB.n/CA.n/CB.n/SA.n/SB.n/RA.n/RB.n all require
APO signatures.
They're named such that Alice can immediately broadcast all the *A.n
transactions (provided a tx that it can spend has been broadcast) and
Bob can likewise immediately broadcast all the *B.n transactions.
Scenarios where Alice decides to unilaterally close the channel might
look like:
* if Alice/Bob can't communicate directly, but both are online:
F -> UA.n -> CB.n -> money
(balances and htlcs claimed, no delay)
* if Bob has gone offline entirely:
F -> UA.n -> (to_self_delay) -> SA.n -> money
* Alice cheats, Bob punishes:
F -> UA.k -> RB.n -> money[Alice pays Bob penalty]
* Bob is offline, Alice cheats, but Bob has a watchtower:
F -> UA.k -> WB.n -> (to_self_delay) -> SA.n -> money
* Alice and Bob's watchtower collude, but Bob's not offline:
F -> UA.k1 -> WB.k2 -> RB.n -> money[Alice pays Bob penalty]
* Alice and Bob's watchtower collude, but Bob has many watchtowers:
F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
For Alice to successfully cheat, she needs Bob to be offline for at least
to_self_delay, and for all Bob's watchtowers to either also be offline,
or colluding.
This can be simplified somewhat, if you don't care about all the features:
* If you don't care about trustless watchtowers you can drop WA.n/WB.n
(and simplify SA.n/SB.n to not require an APO signature)
* If you don't care about penalties you can set penalty_msat to 0 and
allow RA.n/RB.n to spend k<=n. In this case, you can either drop
CA.n/CB.n entirely, or you can have CA.n/CB.n only be used for directly
spending of UB.n/UA.n and thus not require APO signatures
In order to allow fast-forwards, when Alice proposes a new state,
she needs to send her partial signatures to allow Bob to unilaterally
accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
also needs to be able to claim the funds if Bob proposes the new state
and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
achieved with an adaptor signature approach (spelt out a bit more fully
in the gist) or a CTV-like approach, provided that UB.n reveals the
state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md).
Note that in this scenario Alice doesn't provide WB.n to Bob
immediately. This is okay, as if Alice proposes UA.(n-1) (her most
recent state), Bob can still immediately claim via CA.n. If Bob did have
WB.n; then if Alice proposed UA.(n-1) Bob could wait for an initial
to_self_delay period and broadcast WB.n, forcing Alice to wait for an
additional to_self_delay before being able to claim her funds via SA.n.
Note also that this is why RA.n/RB.n require "k < n - 1" -- otherwise
Alice would only be able to broadcast UA.(n-1) and Bob would immediately
be able to penalise by broadcasting RB.n.
Note that if you're using a watchtower and wish to punish your
counterparty if it attempts to cheat, you should only pass WA.(n-2)
to your watchtowers, not WA.(n-1) or WA.n.
This doesn't address any potential issues from:
* how to add fees -- the U/W transactions are 1-in/1-out transactions
that can't be trivially CPFPed by the proposer and need to have
fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
ephemeral output and package relay might be workable); the C/S/R
transactions are 1-in/many-out transactions, but have balance outputs
that can be immediately spent to pay for fees via CPFP if package
relay is available.
* how to pay watchtowers -- when a watchtower broadcasts a W
transaction, it needs to add fees, and it's not clear (to me) how it
could fairly and reliably ensure it's compensated for those costs,
particularly if multiple W transactions are broadcast for a single
unilateral close attempt, due to one or more watchtowers colluding
with an attacker, or simply having out of date information.
* lack of layered transactions -- while this prevents you having to
wait longer than to_self_delay before you can claim channel funds,
it still means that any htlc that is going to timeout sooner than that
may not be claimable on-chain, meaning you need to set
cltv_expiry_delta >= to_self_delay.
* extending to multiparty channels -- penalising is hard if there's
more than two parties, fast forwards are probably impossible since
you need multiple round-trips to coordinate signatures anyway, and if
you're doing channels-within-channels to reduce your n-party channel
to an easier to update 2-party channel you're probably forced to have
to_self_delay for each layer of channels. Also, just figuring out how
to coordinate multiparty state updates and even keeping everyone in
a multiparty channel online consistently to generate new signatures
seems potentially hard?
Cheers,
aj

2023-06-09 13:04:41

- reply

📅 Original date posted:2021-12-21
📝 Original message:
On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote:
> The reason we have "toxic waste" with HTLCs is because we commit to the
> payment_hash directly inside the transaction scripts, so we need to
> remember all the payment_hash we've seen to be able to recreate the
> scripts (and spend the outputs, even if they are revoked).
I think "toxic waste" refers to having old data around that, if used,
could cause you to lose all the funds in your channel -- that's why it's
toxic. This is more just regular landfill :)
> *_anchor: dust, who cares -- might be better if local_anchor used key =
> > revkey
> I don't think we can use revkey,
musig(revkey, remote_key)
--> allows them to spend after you've revealed the secret for revkey
you can never spend because you'll never know the secret for
remote_key
but if you just say:
(revkey)
then you can spend (because you know revkey) immediately (because it's
an anchor output, so intended to be immediately spent) or they can spend
if it's an obsolete commitment and you've revealed the revkey secret.
> this would prevent us from bumping the
> current remote commitment if it appears on-chain (because we don't know
> the private revkey yet if this is the latest commitment). Usually the
> remote peer should bump it, but if they don't, we may want to bump it
> ourselves instead of publishing our own commitment (where our main
> output has a long CSV).
If we're going to bump someone else's commitment, we'll use the
remote_anchor they provided, not the local_anchor, so I think this is
fine (as long as I haven't gotten local/remote confused somewhere along
the way).
Cheers,
aj

2023-06-09 13:04:41

- reply

📅 Original date posted:2021-12-19
📝 Original message:
On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote:
> I updated my article [0], people jumping on the thread now may find it
> helpful to better understand this discussion.
> [0] https://github.com/t-bast/lightning-docs/pull/16
Since merged, so https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md
So imagine that this proposal is finished and widely adopted/deployed
and someone adds an additional feature bit that allows a channel to
forward PTLCs only, no HTLCs.
Then suppose that you forget every old PTLC, because you don't like
having your channel state grow without bound. What happens if your
counterparty broadcasts an old state?
* the musig2 channel funding is irrelevant -- the funding tx has been
spend at this point
* the unspent commitment outputs pay to:
to_local: ipk = musig(revkey, mykey) -- known ; scripts also known
to_remote: claimable in 1 block, would be better if ipk was also musig
*_anchor: dust, who cares -- might be better if local_anchor used
key = revkey
*_htlc: irrelevant by definition
local_ptlc: ipk = musig(revkey, mykey) -- known; scripts also known
* commitment outputs may be immediately spent via layered txs. if so,
their outputs are: ipk = musig(revkey, mykey); with fixed scripts,
that include a relative timelock
So provided you know the revocation key (which you do, because it's an
old transaction and that only requires log(states) data to reconstruct)
and your own private key, you can reconstruct all the scripts and use
key path spends for every output immediately (excepting the local_anchor,
and to_remote is delayed by a block).
So while this doesn't achieve eltoo's goal of "no toxic waste", I believe
it does achieve the goal of "state information is bounded no matter
how long you leave the channel open / how many transactions travel over
the channel".
(Provided you're willing to wait for the other party to attempt to claim
a htlc via their layered transaction, you can use this strategy for
htlcs as well as ptlcs -- however this leaves you the risk that they
never attempt to claim the funds, which may leave you out of pocket,
and may give them the opportunity to do an attack along the lines of
"you don't get access to the $10,000 locked in old HTLCs unless you pay
me $1,000". So I don't think that's really a smart thing to do)
Cheers,
aj

2023-06-09 13:04:40

- reply

📅 Original date posted:2021-12-09
📝 Original message:
On Thu, Dec 09, 2021 at 12:34:00PM +1100, Lloyd Fournier wrote:
> I wanted to add a theoretical note that you might be aware of. The final
> message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
> does not care about Bob revoking a commit tx that gives her strictly more
> coins.
That's true if Alice is only sending new tx's paying Bob; and Rusty's
examples in the `option_simplified_update` proposal do only include new
HTLCs...
But I think it's intended to cover *all* update messages, and if Alice is
also including any `update_fulfill_htlc` or `update_fail_htlc` messages in
the commitment, she's potentially gaining funds, both for the amount of
fees she saves by avoiding extra transactions, but for the fulfill case,
potentially also because she doesn't need to worry about the fulfilled
htlc reaching its timeout.
Actually, as an alternative to the `option_simplified_update` approach,
has anyone considered an approach more like this:
* each node can unilaterally send various messages that always update
the state, eg:
+ new htlc/ptlc paying the other node (update_add_htlc)
+ secret reveal of htlc/ptlc paying self (update_fulfil_htlc)
+ rejection of htlc/ptlc paying self (update_fail_htlc)
+ timeout of htlc/ptlc paying the other node (not currently allowed?)
+ update the channel fee rate (update_fee)
* continue to allow these to occur at any time, asynchronously, but
to make it easier to keep track of them, add a uint64_t counter
to each message, that each peer increments by 1 for each message.
* each channel state (n) then corresponds to the accumulation of
updates from each each peer, up to message (a) for Alice, and message
(b) for Bob.
* so when updating to a new commitment (n+1), the proposal message
should just include both update values (a') and (b')
* nodes can then track the state by having a list of
htlcs/ptlcs/balances, etc for state (n), and a list of unapplied
update messages for themselves and the other party (a+1,...,a') and
(b+1,...,b'), and apply them in order when constructing the new state
(n+1) for a new commitment signing round
I think that retains both the interesting async bits (anyone can queue
state updates immediately) but also makes it fairly simple to maintain
the state?
> Bob's new commit tx can use the same revocation key as the previous
> one
That's a neat idea, but I think the fail/fulfill messages break it.
_But_ I think that means it would still be an interesting technique to
use for fast forwards which get updated for every add message...
> Not sending messages you don't need to is usually
> both more performant and simpler
The extra message from Bob allows Alice to discard the adaptor sigs
associated with the old state, which I think is probably worthwhile
anyway?
Cheers,
aj

2023-06-09 13:04:38

- reply

📅 Original date posted:2021-12-08
📝 Original message:
On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev wrote:
> Alternately, fast-forwards, which avoid this because it does not change commitment transactions on the payment-forwarding path.
> You only change commitment transactions once you have enough changes to justify collapsing them.
I think the problem t-bast describes comes up here as well when you
collapse the fast-forwards (or, anytime you update the commitment
transaction even if you don't collapse them).
That is, if you have two PTLCs, one from A->B conditional on X, one
from B->A conditional on Y. Then if A wants to update the commitment tx,
she needs to
1) produce a signature to give to B to spend the funding tx
2) produce an adaptor signature to authorise B to spend via X from his
commitment tx
3) produce a signature to allow B to recover Y after timeout from his
commitment tx spending to an output she can claim if he cheats
4) *receive* an adaptor signature from B to be able to spend the Y output
if B posts his commitment tx using A's signature in (1)
The problem is, she can't give B the result of (1) until she's received
(4) from B.
It doesn't matter if the B->A PTLC conditional on Y is in the commitment
tx itself or within a fast-forward child-transaction -- any previous
adaptor sig will be invalidated because there's a new commitment
transaction, and if you allowed any way of spending without an adaptor
sig, B wouldn't be able to recover the secret and would lose funds.
It also doesn't matter if the commitment transaction that A and B will
publish is the same or different, only that it's different from the
commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
would fix this if it were available)
So I think this is still a relevant question, even if fast-forwards
make it a rare problem, that perhaps is only applicable to very heavily
used channels.
(I said the following in email to t-bast already)
I think doing a synchronous update of commitments to the channel state,
something like:
Alice -> Bob: propose_new_commitment
channel id
adaptor sigs for PTLCs to Bob
Bob -> Alice: agree_new_commitment
channel id
adaptor sigs for PTLCs to Alice
sigs for Alice to spend HTLCs and PTLCs to Bob from her own
commitment tx
signature for Alice to spend funding tx
Alice -> Bob: finish_new_commitment_1
channel id
sigs for Bob to spend HTLCs and PTLCs to Alice from his own
commitment tx
signature for Bob to spend funding tx
reveal old prior commitment secret
new commitment nonce
Bob -> Alice: finish_new_commitment_2
reveal old prior commitment secret
new commitment nonce
would work pretty well.
This adds half a round-trip compared to now:
Alice -> Bob: commitment_signed
Bob -> Alice: revoke_and_ack, commitment_signed
Alice -> Bob: revoke_and_ack
The timings change like so:
Bob can use the new commitment after 1.5 round-trips (previously 0.5)
Alice can be sure Bob won't use the old commitment after 2 round-trips
(previously 1)
Alice can use the new commitment after 1 round-trip (unchanged)
Bob can be sure Alice won't use the old commitment after 1.5 round-trips
(unchanged -- note: this is what's relevant for forwarding)
Making the funding tx a musig setup would mean also supplying 64B
of musig2 nonces along with the "adaptor sigs" in one direction,
and providing the other side's 64B of musig2 nonces back along with the
(now partial) signature for spending the funding tx (a total of 256B of
nonce data, not 128B).
Because it keeps both peers' commitments synchronised to a single channel
state, I think the same protocol should work fine with the revocable
signatures on a single tx approach too, though I haven't tried working
through the details.
Fast forwards would then be reducing the 2 round-trip protocol to
update the state commitment to a 0.5 round-trip update, to reduce
latency when forwarding by the same amount as before (1.5 round-trips
to 0.5 round-trips).
Cheers,
aj

2023-06-09 13:04:09

- reply

📅 Original date posted:2021-10-12
📝 Original message:
On Mon, Oct 11, 2021 at 09:23:19PM +1100, Lloyd Fournier wrote:
> On Mon, 11 Oct 2021 at 17:30, Anthony Towns <aj at erisian.com.au> wrote:
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
> This problem may not be as bad as it seems.
Maybe you can break it down a little bit further. Consider *three*
delays:
1) refund delay: how long you have before a payment attempt starts
getting refunded
2) channel recovery delay: how long you have to recover from node
failure to prevent an old state being committed to, potentially losing
your entire channel balance
3) payment recovery delay: how long you have to recover from node
failure to prevent losing funds due to a forwarded payment (eg,
Carol claimed the payment, while Alice claimed the refund, leaving
Bob out of pocket)
(Note that if you allow payments up to the total channel balance, there's
not really any meaningful distinction between (2) and (3), at least in
the worst case)
With layered transactions, (2) and (3) are different -- if Bob's node
fails near the timeout, then both Alice and Carol drop to the blockchain,
and Carol knows the preimage, Bob may have as little as the channel
"delay" parameter to extract the preimage from Carol's layered commitment
tx to be able to post a layered commitment on top of Alice's unilateral
close to avoid being out of pocket.
(Note that that's a worst case -- Carol would normally reveal the preimage
onchain earlier than just before the timeout, giving Bob more time to
recover his node and claim the funds from Alice)
If you're willing to accept that "worst case" happening more often, I
think you could then retain the low latency forwarding, by having the
transaction structure be:
commitment tx
input:
funding tx
outputs:
Alice's balance
(others)
low-latency inflight tx:
input:
Alice's balance
output:
(1) or (2)
Alice's remaining balance
Bob claim:
input:
(1) [<payment-recovery-delay> CSV bob CHECKSIG]
output:
[<bob-revoke> checksigverify <alice> checksig
ifdup notif <channel-recovery-delay> csv endif]
Too-slow:
input:
(2) [<payment-timeout> CLTV alice CHECKSIG]
output:
Alice
The idea being:
* Alice sends the low-latency inflight tx which Bob then forwards
immediately.
* Bob then tries to update the base channel state with Alice, so both
sides have a commitment to the new payment, and the low-latency
inflight tx is voided (since it's based on a revoked channel state)
If this succeeds, everything is fine as usual.
* If Alice is unavailable to confirm that update, Bob closes the
channel prior to (payment-timeout - payment-recover-delay), and posts
"Bob claim". After an additional pyment recovery delay (and prior
to payment-timeout) Bob posts Bob claim, ensuring that the only way
Alice can claim the funds is if he had posted a revoked state.
* In this case, Alice has at least one payment-recovery-delay period
prior to the payment-timeout to notice the transaction onchain and
recover the preimage.
* If Bob posted the low-latency inflight tx later than
(payment-timeout - payment-recovery-delay) then Alice will have
payment-recovery-delay time to notice and post the "too-slow" tx and
claim the funds via the timeout path.
* If Bob posted a revoked state, Alice can also claim the funds via
Bob claim, provided she notices within the channel-recovery-delay
That only allows one low-latency payment to be inflight though, which I'm
not sure is that interesting... It's also kinda complicated, and doesn't
cover both the low-latency and offline cases, which is disappointing...
Cheers,
aj

2023-06-09 13:04:09

- reply

📅 Original date posted:2021-10-12
📝 Original message:
On Tue, Oct 12, 2021 at 04:18:37AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > A+P + max(0, B'-B)*0.1 to Alice
> > B-f - max(0, B'-B)*0.1 to Bob
> So, if what you propose is widespread, then a theft attempt is costless:
That's what the "max" part prevents -- if your current balance is B and
you try to claim an old state with B' > B for a profit of B'-B, Alice
will instead take 10% of that value.
(Except maybe all the funds they were trying to steal were in P' rather
than B'; so better might have been "A+P + max(0, min(B'+P'-B)*0.1, B)")
Eltoo would enable costless theft attempts (ignoring fees), particularly
for multiparty channels/factories, of course, so getting the game theory
right in advance of that seems worth the effort anyway.
Cheers,
aj

2023-06-09 13:04:09

- reply

📅 Original date posted:2021-10-11
📝 Original message:
On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> 2. The balance transaction - tracks the funding transaction, contains
> a "balance" output for each of the participants.
> 3. The inflight transactions - spends a balance output from the balance
> transaction and provides outputs for any inflight htlc/ptlc transactions.
> 4. Layered transactions - spends inflight htlc/ptlc outputs by revealing
> the preimage, while still allowing for the penalty path.
I don't think the layering here quite works: if Alice forwarded a payment
to Bob, with timeout T, then the only way she can be sure that she can
either reclaim the funds or know the preimage by time T is to close the
channel on-chain at time T-to_self_delay.
Any time later than that, say T-to_self_delay+x+1, would allow Bob to
post the inflight tx at T+x (prior to Alice being able to claim her
balance directly due to the to_self_delay) and then immediately post the
layered transaction (4, above) revealing the preimage, and preventing
Alice from claiming the refund.
Cheers,
aj

2023-06-09 13:04:08

- reply

📅 Original date posted:2021-10-12
📝 Original message:
On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
> ### Scorched earth punishment
> Another thing that I'd like to mention is that using revocable signatures
> enables scorched earth punishments [2].
I kind-of think it'd be more interesting to simulate eltoo's behaviour.
If Alice's current state has balances (A, B) and P in in-flight
payments, and Bob posts an earlier state with (A', B') and P' (so A+B+P
= A'+B'+P'), then maybe Alice's justice transaction should pay:
A+P + max(0, B'-B)*0.1 to Alice
B-f - max(0, B'-B)*0.1 to Bob
(where "f" is the justice transaction fees)
Idea being that in an ideal world there wouldn't be a hole in your pocket
that lets all your coins fall out, but in the event that there is such
a hole, it's a *nicer* world if the people who find your coins give them
back to you out of the kindness of their heart.
> Note that we number each currently inflight transaction by "k",
> starting at 0. The same htlc/ptlc may have a different value for k
> between different inflight transactions.
> Can you expand on why "k" is needed in addition to "n" and "i". k sounds like
> the same thing as i to me.
"k" is used to distinguish the inflight payments (htlcs/ptlcs), not the
inflight state (which is "i").
> Also what does RP/2/k notation imply given the definition of RP you gave above?
I defined earlier that if P=musig(A,B) then P/x/y = musig(A/x/y,B/x/y);
so RP/2/k = musig(A/2/n/i/2/k,RB2(n,i)/2/k).
> * if the inflight transaction contains a ptlc output, [...]
> What about just doing a scriptless PTLC to avoid this (just CSV input of
> presigned tx)? The cost is pre-sharing more nonces per PTLC message.
Precisely that reason. Means you have to share "k+1" nonce pairs in
advance of every inflight tx update. Not a show stopper, just seemed
like a headache. (It's already a scriptless-script, this would let you
use a key path spend instead of a script path spend)
> This does not support option_static_remotekey, but compensates for that
> by allowing balances to be recovered with only the channel setup data
> even if all revocation data is lost.
> This is rather big drawback but is this really the case? Can't "in-flight"
> transactions send the balance of the remote party to their unencumbered static
> remote key?
They could, but there's no guarantee that there is an inflight
transaction, or that the other party will post it for you. In those case,
you have to be able to redeem your output from the balance tx directly,
and if you can do that, might as well have every possible address be
derived differently to minimise the amount of information any third
parties could glean.
Cheers,
aj

2023-06-09 13:04:07

- reply

📅 Original date posted:2021-10-09
📝 Original message:
On Sat, Oct 09, 2021 at 12:21:03PM +0000, Jonas Nick wrote:
> it seems like parts of this proposal rely on deterministic nonces in MuSig.
The "deterministic" nonces are combined with "recoverable" nonces via
musig2, so I think that part is a red-herring?
They're "deterministic" in the sense that the person who generated the
nonce needs to be able to recover the secret/dlog for the nonce later,
without having to store unique randomness for it. Thinking about it,
I think you could make the "deterministic" nonce secrets be
H( private-key, msg, other-party's-nonce-pair, 1 )
H( private-key, msg, other-party's-nonce-pair, 2 )
because you only need to recover the secret if the other party posts a
sig for a revoked transaction, in which case you can lookup their nonce
directly anyway. And you're choosing your "deterministic" nonce after
knowing what their ("revocable") nonce is, so can include it in the hash.
As far as the revocable nonce goes, you should only be generating a
single signature based on that, since that's used to finish things off
and post the tx on chain.
> Generally, this is insecure unless combined with heavy machinery that proves
> correctness of the nonce derivation in zero knowledge. If one signer uses
> deterministic nonces and another signer uses random nonces, then two signing
> sessions will have different challenge hashes which results in nonce reuse by
> the first signer [0]. Is there a countermeasure against this attack in the
> proposal? What are the inputs to the function that derive DA1, DA2? Is the
> assumption that a signer will not sign the same message more than once?
I had been thinking DA1,DA2 = f(seed,n) where n increases each round, but I
think the above would work and be an improvement. ie:
Bob has a shachain based secret generator, producing secrets s_0 to
s_(2**48). If you've seen s_0 to s_n, you only need to keep O(log(n))
of those values to regenerate all of them.
Bob generates RB1_n and RB2_n as H(s_n, 1)*G and H(s_n, 2)*G and sends
those values to Alice.
Alice determines the message (ie, the transaction), and sets da1_n
and da2_n as H(A_priv, msg, RB1_n, RB2_n, 1) and H(A_priv, msg, RB1_n,
RB2_n, 2). She then calculates k=H(da1_n, da2_n, RB1_n, RB2_n), and
signs for her nonce which da1_n+k*da2_n, and sends da1_n*G and
da2_n*G and the partial signature to Bob.
Bob checks and records Alice's musig2 derivation and partial signature,
but does not sign himself.
_If_ Bob wants to close the channel and publish the tx, he completes
the signature by signing with nonce RB1_n + k*RB2_n.
If you can convince Bob to close the channel repeatedly, using the
same nonce pair, then he'll have problems -- but if you can do that,
you can probably trick him into closing the channel with old state,
which gives him the same problems by design... Or that's my take.
> It may be worth pointing out that an adaptor signature scheme can not treat
> MuSig2 as a black box as indicated in the "Adaptor Signatures" section [1].
Hmm, you had me panicking that I'd been describing how to combine the
two despite having decided it wasn't necessary to combine them... :)
(I figured doing musig for k ptlcs for every update would get old fast --
if you maxed the channel out with ~400 inflight ptlcs you'd be exchanging
~800 nonces for every update. OTOH, I guess that's the only thing you'd
be saving, and the cost is ~176 bytes of extra witness data per ptlc...
Hmm...)
Cheers,
aj

2023-06-09 13:04:06

- reply

📅 Original date posted:2021-10-08
📝 Original message:
On Sat, Oct 09, 2021 at 01:49:38AM +0000, ZmnSCPxj wrote:
> A transaction is required, but I believe it is not necessary to put it *onchain* (at the cost of implementation complexity in the drop-onchain case).
The trick with that is that if you don't put it on chain, you need
to calculate the fees for it in advance so that they'll be sufficient
when you do want to put it on chain, *and* you can't update it without
going onchain, because there's no way to revoke old off-chain funding
transactions.
> This has the advantage of maintaining the historical longevity of the channel.
> Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability,
Maybe that's a good reason for routing nodes to do shadow channels as
a matter of course -- call the currently established channel between
Alice and Bob "C1", and leave it as bolt#3 based, but establish a new
taproot based channel C2 also between Alice and Bob. Don't advertise C2
(making it a shadow channel), just say that C1 now supports PTLCs, but
secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx
is buried enough, start advertising C2 instead taking advantage of its
now sufficiently buried funding transaction, and convert C1 to a shadow
channel instead.
In particular, that setup allows you to splice funds into or out of the
shadow channel while retaining the positive longevity heuristics of the
public channel.
Cheers,
aj

2023-06-09 13:04:05

- reply

📅 Original date posted:2021-10-08
📝 Original message:
Hi all,
Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
taproot and implement PTLCs.
It's particularly inspired by ZmnSCPxj's thoughts from Dec 2019 [0], and
some of his and Lloyd Fournier's posts since then (which are listed in
references) -- in particular, I think those allow us to drop the latency
for forwarding a payment *massively* (though refunding a payment still
requires roundtrips), and also support receiving via a mostly offline
lightning wallet, which seems kinda cool.
I somehow hadn't realised it prior to a conversation with @brian_trollz
via twitter DM, but I think switching to PTLCs, even without eltoo,
means that there's no longer any need to permanently store old payment
info in order to recover the entirety of the channel's funds. (Some brute
force is required to recover the timeout info, but in my testing I think
that's about 0.05 seconds of work per ptlc output via python+libsecp256k1)
This doesn't require any soft-forks, so I think we could start work on
it immediately, and the above benefits actually seem pretty worth it,
even ignoring any privacy/efficiency benefits from doing taproot key
path spends and forwarding PTLCs.
I've sketched up the musig/musig2 parts for the "balance" transactions
in python [1] and tested it a little on signet [2], which I think is
enough to convince me that this is implementable. There'll be a bit of
preliminary work needed in actually defining specs/BIPs for musig and
musig2 and adaptor signatures, I think.
Anyway, details follow. They're also up on github as a gist [3] if that
floats your boat.
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
[1] https://github.com/ajtowns/bitcoin/blob/202109-ptlc-lnpenalty/test/functional/feature_ln_ptlc.py
[2] The balance transaction (spending the funding tx and with outputs
being Alice's and Bob's channel balance is at):
https://explorer.bc-2.jp/tx/ba58d99dfaad83e105a0de1a9becfcf8eaf897aaaada54bd7b08134ff579997c?input:0&expand
[3] https://gist.github.com/ajtowns/12f58fa8a4dc9f136ed04ca2584816a2/
Goals
=====
1. Support HTLCs
2. Support PTLCs
3. Minimise long-term data storage requirements
4. Minimise latency when forwarding payments
5. Minimise latency when refunding payments
6. Support offline receiving
7. Minimise on-chain footprint
8. Minimise ability for third-parties to analyse
Setup
=====
We have two participants in the channel, Alice and Bob. They each have
bip32 private keys, a and b, and share the corresponding xpubs A and B
with each other.
Musig
-----
We will use musig to combine the keys, where P = musig(A,B) = H(A,B,1)*A
+ H(A,B,2)*B. We'll talk about subkeys of P, eg P/4/5/6, which are
calculated by taking subkeys of the input and then applying musig,
eg P/4/5/6 = musig(A/4/5/6, B/4/5/6). (Note that we don't use hardened
paths anywhere)
Musig2
------
We'll use musig2 to sign for these keys, that is both parties will
pre-share two nonce points each, NA1, NA2, NB1, NB2, and the nonce will be
calculated as: R=(NA1+NB1)+k(NA2+NB2), where k=Hash(P,NA1,NA2,NB1,NB2,m),
where P is the pubkey that will be signing and m is the message to be
signed. Note that NA1, NA2, NB1, NB2 can be calculated and shared prior
to knowing what message will be signed.
The partial sig by A for a message m with nonce R as above is calculated as:
sa = (na1+k*na2) + H(R,A+B,m)*a
where na1, na2, and a are the secrets generating NA1, NA2 and A respectively.
Calculating the corresponding partial signature for B,
sb = (nb1+k*nb2) + H(R,A+B,m)*b
gives a valid signature (R,sa+sb) for (A+B):
(sa+sb)G = R + H(R,A+B,m)*(A+B)
Note that BIP340 sepcifies x-only pubkeys, so A+B and R implicitly have
even y, however since those values are caluclated via musig and musig2
respectively, this cannot be ensured in advance. Instead, if we find:
H(A,B,1)*A + H(A,B,2)*B
does not have even y, we calculate:
P = (-H(A,B,1))*A + (-H(A,B,2))*B
instead, which will have even y. Similarly, if (NA1+NB1+k(NA2+NB2)) does
not have even y, when signing, we replace each partial nonce by its negation,
eg: sa = -(na1+k*na2) + H(R,A+B,m).
Adaptor Sigs
------------
An adaptor signature for P for secret X is calculated as:
s = r + H(R+X, P, m)*p
which gives:
(s+x)G = (R+X) + H(R+X, P, m)*P
so that (R+X,s+x) is a valid signature by P of m, and the preimage for
X can be calculated as the difference between the published sig and the
adaptor sig, x=(s+x)-(s).
Note that if R+X does not have even Y, we will need to negate both R and X,
and the recovered secret preimage will be -x instead of x.
Revocable Secrets
-----------------
Alice and Bob have shachain secrets RA(n) and RB(n) respectively,
and second level shachain secrets RA2(n,i) and RB2(n,i), with n and i
counting up from 0 to a maximum.
Summary
=======
We'll introduce four layers of transactions:
1. The funding transaction - used to establish the channel, provides
the utxo backing the channel while the channel is open.
2. The balance transaction - tracks the funding transaction, contains
a "balance" output for each of the participants.
3. The inflight transactions - spends a balance output from the balance
transaction and provides outputs for any inflight htlc/ptlc transactions.
4. Layered transactions - spends inflight htlc/ptlc outputs by revealing
the preimage, while still allowing for the penalty path.
Funding transaction
===================
The funding transaction simply pays to P/0/f via taproot, where f starts
at 0 and increases any time the funding transaction is updated onchain
(eg when splicing funds in or out).
Balance transaction
===================
The balance transaction spends the funding transaction, and has two
outputs, one for Alice's balance and one for Bob's balance (omitting a
zero/dust balance).
We count the number of balance updates, starting at 0, and call it "n".
"n" is encoded in the transaction locktime and the input nsequence, so
if a balance transaction appears on chain, "n" can be decoded from the
nsequence and locktime.
Alice's balance is paid to an address with internal pubkey P/1/n/0
and a script path of "<A/1/n> CHECKSIGVERIFY <D> CSV" where D is
Alice's to_self_delay. Bob's balance is similar, with internal pubkey
P/1/n/1.
In order to update to a new balance transaction, the process is as follows.
First, nonces are exchanged in advance:
Alice:
Generates a nonce pair NA1, NA2 derived from RA(n). Shares this with
Bob.
Bob:
Generates a nonce pair NB1, NB2 derived from RB(n). Shares this with
Alice.
Then, presuming Alice initiates the update:
Alice:
Generates deterministic nonce pair, DA1, DA2. Combines this with
Bob's NB1, NB2 nonce pair. Generates partial signature for nonce
(DA, NB) for the transaction. Sends DA1 and DA2 and the partial
signature to Bob.
Bob:
Checks the partial signature is valid. Updates to the new balance
transaction. Generates a nonce pair, DB1, DB2, and gnerates a partial
signature for the balance transaction for nonce (NA, DB). Sends DB1,
DB2, and the partial signature to Alice. Generates a new revocable
secret RB(n+1). Revokes the previous secret RB(n) and sends the
details of both to Alice.
Alice:
Checks the partial signature is valid. Updates to the new balance
transaction. Checks the secret revocation info is correct and stores
it. Generates a new revocable secret RA(n+1). Revokes the previous
secret RA(n) and sends the details of both to Bob.
Bob:
Checks the secret revocation info is correct an stores it.
This means that both Alice and Bob have the same balance transaction here
(with the same txid) but have different signatures for it (and thus
differing wtxids).
Because updating the balance transaction involves two round trips
before Bob can be sure Alice cannot use the old state, we move all the
transaction information to the inflight transactions, which we will be
able to update immediately, without requiring a round trip at all.
Note that if Bob publishes the signature for an old state, then the
signature is:
s = ((DA1+NB1) + k(DA2+NB2)) + H(R,A+B,m)(a+b)
but Alice can calculate the secrets for both DA1 and DA2 (she generated
those deterministically herself in the first place), and NB1 and NB2 (she
has the secret revocation information, and verified that it correctly
generated the nonces Bob was using), which allows her to calculate Bob's
private key using modular arithmetic:
b = H(R,P,m) / (s - (DA1+NB1) - b(DA2+NB2)) - a
which means she can then directly sign without Bob's assistance, allowing
her to claim any funds.
Inflight and Layered Transactions
=================================
We construct two inflight transactions on top of the current balance
transaction, one spending Alice's balance, and one spending Bob's balance.
We will use "i" to represent the number of times a given inflight
transaction has been updated for the nth update to the balance
transaction.
At any time Alice can update the inflight transaction spending her balance
to transfer funds towards Bob, either by updating the balances directly,
or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And
conversely for Bob)
We will define RP=musig(A/2/n/i, RB2(n,i)).
The inflight transaction spending Alice's balance can have multiple
types of outputs:
* Alice's remaining balance: pays directly to A/2/n/i
* Bob's remaining balances: pays to RP/2 with script path
"<B/2/n/i> CHECKSIGVERIFY <D> CSV"
* An htlc paying to Bob: pays to RP/2/k with script paths:
+ "LENGTH 32 EQUALVERIFY HASH160 <X> EQUALVERIFY <B/2/n/i/k> CHECKSIGVERIFY <A/2/n/i/k> CHECKSIG"
+ "<A/2/n/i/k/1> CHECKSIGVERIFY <T> CLTV"
* A ptlc paying to Bob: pays to RP/2/k with script paths:
+ "<B/2/n/i/k> CHECKSIG NOTIF <T> CLTV DROP ENDIF <A/2/n/i/k> CHECKSIG"
Any outputs that would be zero or dust are not included.
Note that we number each currently inflight transaction by "k",
starting at 0. The same htlc/ptlc may have a different value for k
between different inflight transactions.
The inflight transation's locktime is set to the current block
height. This enables brute force searching for the locktime of any
inflight ptlcs (so that in a penalty scenario when the other party posts
an out of date inflight transaction, you can search through a small
number of possible timeout values simply by not sending any ptlcs with
a timeout more that L blocks in the future).
The balance input's nsequence is used to encode the value of the lower
24 bits of i in the same way the balance transaction's fund input's
nsequence encodes the upper 24 bits of n.
The layered transaction will spend the htlc/ptlc outputs, with an
ANYONECANPAY|SINGLE signature by Alice using the A/2/n/i/k path.
The output committed to is:
* pays to RP/3/k with script path:
+ <B/3/n/i/k> CHECKSIGVERIFY <D> CSV
with no absolute or relative locktime.
To update the inflight transaction spending Alice's balance as well as
any dependent layered transactions, the process is as follows:
Bob:
Generates a second level revocable secret, RB2(n,i) and sends Alice
the corresponding point, PB2. Calculates a nonce pair, NB1, NB2, and
sends that to Alice. This is done in advance.
Alice:
Calculates the new inflight transaction. Calculates new nonces NA1,
NA2, and partially signs the spend of her balance via the key path,
with musig2 nonces NA1, NB1, NA2, NB2. For each inflight htlc,
Alice provides a signature via A/2/n/i/k. For each inflight ptlc,
Alice provides an adaptor signature via the A/2/n/i/k/0 path that
is conditional on the ptlc's point.
Bob:
Bob verifies the new proposed inflight state and each of the
signatures. Bob may now rely on the new state. Bob revokes their
prior secret, RB2(n, i-1), and sends a new point/nonce pair (PB2',
NB1', NB2') to Alice to prepare for the next round.
Note that Bob could stream multiple point/nonce pairs in advance,
allowing Alice to do multiple inflight tx updates within the time taken
for a roundtrip.
Alice can unilaterally do the following safely:
1. transfer from Alice's balance to Bob's balance
2. accept that a htlc/ptlc succeeded, removing the corresponding output
and allocating the funds associated with it directly to Bob's balance
3. introduce a htlc/ptlc, spending funds from Alice's balance
However refunding/cancelling a htlc/ptlc requires a two-phase commit
with 1.5 round trips:
- Bob proposes refunding a htlc/ptlc
- Alice agrees and sends a partial signature for the new transaction
with the htlc/ptlc funds transferred back to her balance,
- Bob records the new transaction, and revokes the earlier second
level secret RB2(n, i-1).
- Alice verifies the revocation, and can safely treat the funds as
refunded (and thus refund back to the original payer, eg).
The advantage of doing this over negotiating a new balance transaction
is that only the second level revocation secrets need to be online,
allowing for operation by semi-offline lightning nodes (ie, having the
channel private key and first level revocation secrets offline). Such
semi-offline nodes risk losing funds in the "inflight" transaction
(either by revealing the second level revocation secrets or by simply
data loss of the current inflight/layered transactions) but do not risk
losing or spending funds in their own output of the balance transaction.
This means the funds locked in Alice's balance can be spent in the
following ways:
* Alice can claim them directly if Bob does not post the inflight
transaction before the delay expires, via the script balance output's
script path. Alice gets the entire balance in this case.
* Bob can post a revoked inflight transaction, for which Alice knows the
secret for RB(n,i). In this case Alice recovers the value of i from
the nsequence (using brute force for the upper bits if she has
provided more than 16M updates of the inflight tx for any given
balance transaction), and then calculates the secret key for PB,
and hence PB/2/k and PB/3/k, at which point she can claim every
output via a key path spend, even if Bob posts some or all of the
layered transactions. Alice gets the entire balance in this case
(though spends more on fees).
* Bob can post a current inflight transaction, along with layered
transactions for any of the inflight htlc/ptlcs for which he knows the
corresponding preimage, allowing Alice to recover the preimages from
the on-chain spends immediately. Alice can claim her balance output and
any timed out funds immediately as well. Bob can finish claiming his
balance and any claimed htlc/ptlc funds after the delay has finished.
Note that Bob never shares his signature to spend Alice's balance prior
to posting the inflight transaction, so Alice can never post an inflight
transaction that spends her own balance.
The cases where Alice may have difficulty claiming funds is Bob posts
a revoked inflight transaction (possibly spending a revoked balance
transaction) are:
* if the inflight transaction contains a htlc output, then if Alice
has not retained the old htlc details (the hash160 and the timeout)
she will not be able to reconstruct the script path, and thus will
not be able to calculate the TapTweak to sign for the key path.
However if Bob attempts to claim the output (via the pre-signed
layered transaction), that will reveal the information she was missing,
and she can immediately claim the funds via the layered transaction
output, prior to Bob being able to spend that output.
* if the inflight transaction contains a ptlc output, then if Alice
has not retained the old ptlc details (the point and the timeout)
she will not trivially be able to reconstruct the script path,
which includes the timeout. However, presuming the timeout was
within 5000 blocks, then the only possible timeouts are the inflight
tx's nlocktime+i with 0<i<=5000, and she will only need to calculate
5000*k cases and match the corresponding scriptPubKeys to exhaustively
enumerate every possible ptlc output, which should take under a minute,
and be easily achievable. In addition, if Bob attempts to claim the
funds, he will reveal the script path, and Alice will be either able
to claim the inflight output directly or the layered output.
Misc
====
In order to transition from BOLT#3 format to this proposal, an onchain
transaction is required, as the "revocable signatures" arrangement cannot
be mimicked via the existing 2-of-2 CHECKMULTISIG output.
To allow splicing in/out, it may be important to maintain multiple
concurrent funding transactions (paying to P/0/f and P/0/f+1 eg),
which then requires maintaining multiple current balance transactions
(paying to P/1/n/* and P/1/n+1/x eg) and likewise multiple current
inflight/layered transactions. This will require ensuring the states
for all those transactions are synchoronised when verifying upates,
and requires sharing multiple nonces for signing (eg RA(n) and RA(n+1)
and RB2(n,i), and RB2(n+1,i)).
Fees for the balance and inflight transactions must be considered upfront,
and paid for from the channel balance (or perhaps via additional anchor
outputs that allocate more than the dust threshold and are immediately
spendable). Fees for the layered transactions however can (and must)
be provided by whoever is attempting to claim the funds.
Bob having a current inflight transaction spending Alice's balance is
advantageous to Alice as Bob posting the inflight transaction allows
her to immediately claim her balance, rather than having to wait for
the delay to complete.
If two nodes agree to only forward ptlcs in future, then updating the
funding transaction (to P/0/f+1 eg) and ignoring any proposed inflight
transactions that include htlc outputs is enough to ensure that all htlc
records can be forgotten without risking any part of the channel balance
being unclaimable.
This does not support option_static_remotekey, but compensates for that
by allowing balances to be recovered with only the channel setup data
even if all revocation data is lost.
References
==========
Hopefully the above includes enough explanation to be understood on its own,
but here's references for a bunch of the concepts.
* musig: https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/
* musig2: https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295
* adaptor sigs: https://github.com/ElementsProject/scriptless-scripts/blob/master/md/atomic-swap.md
* fast forwards [ZmnSCPxj]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003043.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003265.html
* revocable signatures [LLFourn]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002785.html

2023-06-09 13:03:36

- reply

📅 Original date posted:2021-08-31
📝 Original message:
On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev wrote:
> As we thought it was obvious that the function is not linear we only explained
> in the paper how the jump from f(0)=0 to f(1) = ppm+base_fee breaks convexity.
(This would make more sense to me as "f(0)=0 but f(epsilon)->b as
epsilon->0, so it's discontinuous")
> "Do we really want users to solve an NP-hard problem when
> they wish to find a cheap way of paying each other on the Lightning Network?"
FWIW, my answer to this is "sure, if that's the way it turns out".
Another program which solves an NP-hard problem every time it runs is
"apt-get install" -- you can simulate 3SAT using Depends: and Conflicts:
relationships between packages. I worked on a related project in Debian
back in the day that did a slightly more complicated variant of that
problem, namely working out if updating a package in the distro would
render other packages uninstallable (eg due to providing a different
library version) -- as it turned out, that even actually managed to hit
some of the "hard" NP cases every now and then. But it was never really
that big a deal in practice: you just set an iteration limit and consider
it to "fail" if things get too complicated, and if it fails too often,
you re-analyse what's going on manually and add a new heuristic to cope
with it.
I don't see any reason to think you can't do roughly the same for
lightning; at worst just consider yourself as routing on log(N) different
networks: one that routes payments of up to 500msat at (b+0.5ppm), one
that routes payments of up to 1sat at (b+ppm), one that routes payments
of up to 2sat at (b+2ppm), one that routes payments of up to 4sat at
(b+4ppm), etc. Try to choose a route for all the funds; if that fails,
split it; repeat. In some case that will fail despite there being a
possible successful multipath route, and in other cases it will choose a
moderately higher fee path than necessary, but if you're talking a paying
a 0.2% fee vs a 0.1% fee when the current state of the art is a 1% fee,
that's fine.
Cheers,
aj

2023-06-09 13:03:27

- reply

📅 Original date posted:2021-08-16
📝 Original message:
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote:
> On 8/15/21 22:02, Anthony Towns wrote:
> > > In
> > > one particular class of applicable routing algorithms you could use for
> > > lightning routing having a base fee makes the algorithm intractably slow,
> > I don't think of that as the problem, but rather as the base fee having
> > a multiplicative effect as you split payments.
> Yes, matching the real-world costs of forwarding an HTLC.
Actually, no, not at all.
The base+proportional fees paid only on success roughly match the *value*
of forwarding an HTLC, they don't match the costs particularly well
at all.
Why not? Because the costs are incurred on failed HTLCs as well, and
also depend on the time a HTLC lasts, and also vary heavily depending
on how many other simultaneous HTLCs there are.
> Yes. You have to pay the cost of a node. If we're really worried about this,
> we should be talking about upfront fees and/or refunds on HTLC fulfillment,
> not removing the fees entirely.
(I don't believe either of those are the right approach, but based on
previous discussions, I don't think anyone's going to realise I'm right
until I implement it and prove it, so *shrug*)
> > Being denominated in sats, the base fee also changes in value as the
> > bitcoin price changes -- c-lightning dropped the base fee to 1sat (from
> > 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x
> > since then, and it seems unlikely the fixed costs of a successful HTLC
> > payment have likewise increased 4x. Proportional fees deal with this
> > factor automatically, of course.
> This isn't a protocol issue, implementations can automate this without issue.
I don't think anyone's proposing the protocol be changed; just that node
operators set an option to a particular value?
Well, except that Lisa's maybe proposing that 0 not be allowed, and a
value >= 0.001 sat be required? I'm not quite sure.
> > > There's real cost to distorting the fee structures on the network away from
> > > the costs of node operators,
> > That's precisely what the base fee is already doing.
> Huh? For values much smaller than a node's liquidity, the cost for nodes is
> (mostly) a function of HTLCs, not the value.
Yes, the cost for nodes is a function of the requests that come in, not
how many succeed. The fees are proportional to how many succeed, which
is at best a distorted reflection of the number of requests that come in.
> The cost to nodes is largely [...]
The cost to nodes is almost entirely the opportunity cost of not being
able to accept other txs that would come in afterwards and would pay
higher fees.
And all those costs can be captured equally well (or badly) by just
setting a proportional fee and a minimum payment value. I don't know why
you keep ignoring that point.
> so I'd argue for many HTLCs forwarded
> today per-payment costs mirror the cost to a node much, much, much, much
> better than some proportional fees?
You're talking yourself into a *really* broken business model there.
> > Additionally, I don't think HTLC slot usage needs to be kept as a
> > limitation after we switch to eltoo;
> The HTLC slot limit is to keep transactions broadcastable. I don't see why
> this would change, you still get an output for each HTLC on the latest
> commitment in eltoo, AFAIU.
eltoo gives us the ability to have channel factories, where we divide
the overall factory balance amongst different channels, all updated
off-chain. It seems likely we'll want to do factories from day one,
so that we don't implicitly limit either the lifetime of the channel
or its update rate (>1 update/sec ~= <4 year lifetime otherwise if I
did the maths right). Once we're doing factories, if we have more than
however many htlcs for a channel, we can re-divide the factory balance
and add a new channel. If the limit is 500 HTLCs per tx, you'd have to
amortize 0.2% of the new tx across each HTLC, in addition to the cost
of the HTLC itself, but that seems trivial.
> > and in the meantime, I think it can
> > be better managed via adjusting the min_htlc_amount -- at least for the
> > scenario where problems are being caused by legitimate payment attempts,
> > which is also the only place base fee can help.
> Sure, we could also shift towards upfront fees or similar solutions,
Upfront fees seem extremely vulnerable to attacks, and are certainly a
(pretty large) protocol change.
> > > Instead, we should investigate how we can
> > > apply the ideas here with the more complicated fee structures we have.
> > Fee structures should be *simple* not complicated.
> > I mean, it's kind of great that we started off complicated -- if it
> > turns out base fee isn't necessary, it's easy to just set it to zero;
> > if we didn't have it, but needed it, it would be much more annoying to
> > add it in later.
> Fee structures should also match reality, and allow node operators
> sufficient flexibility to capture their costs. I think we have a design that
> does so quite well - its pretty simple, there's only two knobs, but the two
> knobs capture exactly the two broad categories of costs a node operator has.
I don't know how you can think these "exactly" capture node operators'
costs. They're missing the time factor, and don't capture any of the
costs due to failed payments.
> Sure, the great thing about today is because the protocol exposes decent
> knobs operators can tune
Knobs are great for experimenting; but they're also something to work
at reducing once the experiments have come up with some results. I
think #zerobasefee is more in the experiment stage: "hey, this seems
like a great idea, let's set this knob to zero and focus on these other
ones instead".
> > For an experimental plugin that aggressively splits payments up, I think
> > either ignoring channels with >0 base fee entirely, or deciding that
> > you're happy to spend a total of X sats on base fees, and then ignoring
> > channels whose base fee is greater than X/paths/path-length sats is fine.
> Sure, experimental plugins can do whatever they want!
Is there any reason to think any of this would be something other than
node configuration options and experimental plugins any time soon?
(By "any time soon" I mean, I could see software defaults changing if
over 50% of the network deliberately switched to zero base fees and found
it worked fine; and I could see deprecating non-zero fees if that ended
up with 90% of the network on zero base fees, no good reasons for node
operators wanting to stick with running non-zero base fees, and the
experimental algos that relied on zero base fees being significantly
easier to maintain or faster/better)
> > But long term, I also think that the base fee is an entirely unhelpful
> > complication that will eventually just be hardcoded to zero by everyone,
> > and eventually channels that propose non-zero base fees won't even be
> > gossiped. I don't expect that to happen any time soon though.
> I very strongly disagree, as discussed, and am left highly dubious
> that it is a practical complication in any case.
That's okay! Long term predictions would be pretty boring if everyone
agreed with them.
Cheers,
aj

2023-06-09 13:03:24

- reply

📅 Original date posted:2021-08-14
📝 Original message:
Hey *,
There's been discussions on twitter and elsewhere advocating for
setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing
this to summarise my understanding in a place that's able to easily be
referenced later.
Setting the base fee to zero has a couple of benefits:
- it means you only have one value to optimise when trying to collect
the most fees, and one-dimensional optimisation problems are
obviously easier to write code for than two-dimensional optimisation
problems
- when finding a route, if all the fees on all the channels are
proportional only, you'll never have to worry about paying more fees
just as a result of splitting a payment; that makes routing easier
(see [1])
So what's the cost? The cost is that there's no longer a fixed minimum
fee -- so if you try sending a 1sat payment you'll pay 0.1% of the fee
to send a 1000sat payment, and there may be fixed costs that you have
in routing payments that you'd like to be compensated for (eg, the
computational work to update channel state, the bandwith to forward the
tx, or the opportunity cost for not being able to accept another htlc if
you've hit your max htlcs per channel limit).
But there's no need to explicitly separate those costs the way we do
now; instead of charging 1sat base fee and 0.02% proportional fee,
you can instead just set the 0.02% proportional fee and have a minimum
payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%
of that is 1sat. Nobody will be asking you to route without offering a
fee of at least 1sat, but all the optimisation steps are easier.
You could go a step further, and have the node side accept smaller
payments despite the htlc minimum setting: eg, accept a 3000 sat payment
provided it pays the same fee that a 5000 sat payment would have. That is,
treat the setting as minimum_fee=1sat, rather than minimum_amount=5000sat;
so the advertised value is just calculated from the real settings,
and that nodes that want to send very small values despite having to
pay high rates can just invert the calculation.
I think something like this approach also makes sense when your channel
becomes overloaded; eg if you have x HTLC slots available, and y channel
capacity available, setting a minimum payment size of something like
y/2/x**2 allows you to accept small payments (good for the network)
when you're channel is not busy, but reserves the last slots for larger
payments so that you don't end up missing out on profits because you
ran out of capacity due to low value spam.
Two other aspects related to this:
At present, I think all the fixed costs are also incurred even when
a htlc fails, so until we have some way of charging failing txs for
incurring those costs, it seems a bit backwards to penalise successful
txs who at least pay a proportional fee for the same thing. Until we've
got a way of handling that, having zero base fee seems at least fair.
Lower value HTLCs don't need to be included in the commitment transaction
(if they're below the dust level, they definitely shouldn't be included,
and if they're less than 1sat they can't be included), and as such don't
incur all the same fixed costs that HTLCs that are committed too do.
Having different base fees for microtransactions that incur fewer costs
would be annoying; so having that be "amortised" into the proportional
fee might help there too.
I think eltoo can help in two ways by reducing the fixed costs: you no
longer need to keep HTLC information around permanently, and if you do
a multilevel channel factory setup, you can probably remove the ~400
HTLCs per channel at any one time limit. But there's still other fixed
costs, so I think that would just lower the fixed costs, not remove them
altogether and isn't a fundamental change.
I think the fixed costs for forwarding a HTLC are very small; something
like:
0.02sats -- cost of permanently storing the HTLC info
(100 bytes, $500/TB/year, 1% discount rate)
0.04sats -- compute and bandwidth cost for updating an HTLC ($40/month
at linode, 1 second of compute)
The opportunity cost of having HTLC slots or Bitcoin locked up until
the HTLC succeeds/fails could be much more significant, though.
Cheers,
aj
[0] https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message
[1] https://basefee.ln.rene-pickhardt.de/

2023-06-09 13:03:19

- reply

📅 Original date posted:2021-08-12
📝 Original message:
On Tue, Aug 10, 2021 at 06:37:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of
> the HTLC.
Right: but that just means it's not something you should determine once
for the HTLC, but something you should determine each time you update the
channel commitment -- if fee rates are at 1sat/vb, then a 10,000 sat HTLC
that's going to cost 100 sats to create the utxo and eventually claim it
might be worth committing to, but if fee rates suddenly rise to 75sat/vb,
then the combined cost of 7500 sat probably isn't worthwhile (and it
certainly isn't worthwhile if fees rise to above 100sat/vb).
That's independent of dust limits -- those only give you a fixed size
lower limit or about 305sats for p2wsh outputs.
Things become irrational before they become uneconomic as well: ie the
100vb is perhaps 40vb to create then 60vb to spend, so if you create
the utxo anyway then the 40vb is a sunk cost, and redeeming the 10k sats
might still be marginally wortwhile up until about 167sat/vb fee rate.
But note the logic there: it's an uneconomic output if fees rise above
167sat/vb, but it was already economically irrational for the two parties
to create it in the first place when fees were at or above 100sat/vb. If
you're trying to save every sat, dust limits aren't your problem. If
you're not trying to save every sat, then just add 305 sats to your
output so you avoid the dust limit.
(And the dust limit is only preventing you from creating outputs that
would be irrational if they only required a pubkey reveal and signature
to spend -- so a HTLC that requires revealing a script, two hashes,
two pubkeys, a hash preimage and two signatures with the same dust
threshold value for p2wsh of ~305sats would already be irrational at
about 2.1sat/vb and unconomic at 2.75 sat/vb).
> (From a LN viewpoint, I would say we're trying to solve a price discovery
> issue, namely the cost to write on the UTXO set, in a distributed system, where
> any deviation from the "honest" price means you trust more your LN
> counterparty)
At these amounts you're already trusting your LN counterparty to not just
close the channel unilaterally at a high fee rate time and waste your
funds in fees, vs doing a much for efficient mutual/cooperative close.
Cheers,
aj

2023-06-09 13:03:08

- reply

📅 Original date posted:2021-07-12
📝 Original message:
Hello world,
Suppose you have some payments going from Alice to Bob to Carol with
eltoo channels. Bob's lightning node crashes, and he recovers from an
old backup, and Alice and Carol end up dropping newer channel states
onto the blockchain.
Suppose the timeout for the payments is a few hours away, while the
channels have specified a week long CSV delay to rectify any problems
on-chain.
Then I think that that means that:
1) Carol will reveal the point preimages on-chain via adaptor
signatures, but Bob won't be able to decode those adaptor signatures
because those signatures will need to change for each state
2) Even if Bob knows the point preimages, he won't be able to
claim the PTLC payments on-chain, for the same reason: he needs
newer adaptor signatures that he'll have lost with the state update
3) For any payments that timeout, Carol doesn't have any particular
incentive to make it easy for Bob to claim the refund, and Bob won't
have the adaptor signatures for the latest state to do so
4) But Alice will be able to claim refunds easily. This is working how
it's meant to, at least!
I think you could fix (3) by giving Carol (who does have all the adaptor
signatures for the latest state) the ability to steal funds that are
meant to have been refunded, provided she gives Bob the option of claiming
them first.
However fixing (1) and (2) aren't really going against Alice or Carol's
interests, so maybe you can just ask: Carol loses nothing by allowing
Bob to claim funds from Alice; and Alice has already indicated that
knowing P is worth more to her than the PTLC's funds -- otherwise she
wouldn't have forwarded the PTLC to Bob in the first place.
Likewise, everyone's probably incentivised to negotiate cooperative
closes instead of going on-chain -- better privacy, less fees, and less
delay before the funds can be used elsewhere.
FWIW, I think a similar flaw exists even in the original eltoo spec --
Alice could simply decline to publish the settlement transaction until
the timeout has been reached, preventing Bob from revealing the HTLC
preimage before Alice can claim the refund.
So I think that adds up to:
a) Nodes should share state on reconnection; if you find a node that
doesn't do this, close the channel and put the node on your enemies
list. If you disagree on what the current state is, share your most
recent state, and if the other guy's state is more recent, and all
the signatures verify, update your state to match theirs.
b) Always negotiate a mutual/cooperative close if possible, to avoid
actually using the eltoo protocol on-chain.
c) If you want to allow continuing the channel after restoring an old
state from backup, set the channel state index based on the real time,
eg (real_time-start_time)*(max_updates_per_second). That way your
first update after a restore from backup will ensure that any old
states that your channel partner may not have told you about are
invalidated.
d) Accept that if you lose connectivity to a channel partner, you will
have to pay any PTLCs that were going to them, and won't be able
to claim the PTLCs that were funding them. Perhaps limit the total
value of inbound PTLCs for forwarding that you're willing to accept
at any one itme?
Also, layered commitments seem like they make channel factories
complicated too. Nobody came up with a way to avoid layered commitments
while I wasn't watching did they?
Cheers,
aj

2023-06-09 12:58:58

- reply

📅 Original date posted:2020-02-27
📝 Original message:
On Mon, Feb 24, 2020 at 01:29:36PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote:
> >> And if there is a grace period, I can just gum up the network with lots
> >> of slow-but-not-slow-enough HTLCs.
> > Well, it reduces the "gum up the network for <timeout> blocks" to "gum
> > up the network for <grace period> seconds", which seems like a pretty
> > big win. I think if you had 20 hops each with a 1 minute grace period,
> > and each channel had a max_accepted_htlcs of 30, you'd need 25 HTLCs per
> > second to block 1000 channels (so 2.7% of the 36k channels 1ml reports),
> > so at the very least, successfully performing this attack would be
> > demonstrating lightning's solved bitcoin's transactions-per-second
> > limitation?
> But the comparison here is not with the current state, but with the
> "best previous proposal we have", which is:
>
> 1. Charge an up-front fee for accepting any HTLC.
> 2. Will hang-up after grace period unless you either prove a channel
> close, or gain another grace period by decrypting onion.
In general I don't really like comparing ideas that are still in
brainstorming mode; it's never clear whether there are unavoidable
pitfalls in one or the other that won't become clear until they're
actually implemented...
Specifically, I'm not a fan of either channel closes or peeling the onion
-- the former causes problems if you're trying to route across sidechains
or have lightning as a third layer above channel factories or similar,
and I'm not convinced even within Bitcoin "proving a channel close"
is that meaningful, and passing around decrypted onions seems like it
opens up privacy attacks.
Aside from those philosophical complaints, seems to me the simplest
attack would be:
* route 1000s of HTLCs from your node A1 to your node A2 via different,
long paths, using up the total channel capacity of your A1/A2 nodes,
with long timeouts
* have A2 offer up a transaction claiming that was the channel
close to A3; make it a real thing if necessary, but it's probably
fake-able
* then leave the HTLCs open until they time out, using up capacity
from all the nodes in your 1000s of routes. For every satoshi of
yours that's tied up, you should be able to tie up 10-20sat of other
people's funds
That increases the cost of the attack by one on-chain transaction per
timeout period, and limits the attack surface by how many transactions
you can get started/completed within whatever the grace period is, but
it doesn't seem a lot better than what we have today, unless onchain
fees go up a lot.
(If the up-front fee is constant, then A1 paid a fee, and A2 collected a
fee so it's a net wash; if it's not constant then you've got a lot of
hassle making it work with any privacy I think)
> > A->B: here's a HTLC, locked in
> > B->C: HTLC proposal
> > C->B: sure: updated commitment with HTLC locked in
> > B->C: great, corresponding updated commitment, plus revocation
> > C->B: revocation
> Interesting; this adds a trip, but not in latency (since C can still
> count on the HTLC being locked in at step 3).
> I don't see how it helps B though? It still ends up paying A, and C
> doesn't pay anything?
The updated commitment has C paying B onchain; if B doesn't receive that
by the time the grace period's about over, B can cancel the HTLC with A,
and then there's statemachine complexity for B to cancel it with C if
C comes alive again a little later.
> It forces a liveness check of C, but TBH I dread rewriting the state
> machine for this when we can just ping like we do now.
I'd be surprised if making musig work doesn't require a dread rewrite
of the state machine as well, and then there's PTLCs and eltoo...
> >> There's an old proposal to fast-fail HTLCs: Bob sends an new message "I
> >> would fail this HTLC once it's committed, here's the error"
> > Yeah, you could do "B->C: proposal, C->B: no way!" instead of "sure" to
> > fast fail the above too.
> > And I think something like that's necessary (at least with my view of how
> > this "keep the HTLC open" payment would work), otherwise B could send C a
> > "1 microsecond grace period, rate of 3e11 msat/minute, HTLC for 100 sat,
> > timeout of 2016 blocks" and if C couldn't reject it immediately would
> > owe B 50c per millisecond it took to cancel.
> Well, surely grace period (and penalty rate) are either fixed in the
> protocol or negotiated up-front, not per-HTLC.
I think the "keep open rate" should depend on how many nodes have
already been in the route (the more hops it's gone through, the more
funds/channels you're tying up by holding onto the HTLC, so the more
you should pay), while the grace period should depend on how many nodes
there are still to go in the route (it needs to be higher to let each of
those nodes deduct their delta from it). So I think you *should* expect
those to change per HTLC than you're forwarding, as those factors will
be different for different HTLCs.
Cheers,
aj

2023-06-09 12:58:57

- reply

📅 Original date posted:2020-02-23
📝 Original message:
On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote:
> > I think the way it would end up working
> > is that the further the route extends, the greater the payments are, so:
> > A -> B : B sends A 1msat per minute
> > A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to A
> > A -> B -> C -> D : D sends C 3 msat, etc
> > A -> B -> C -> D -> E : E sends D 4 msat, etc
> > so each node is receiving +1 msat/minute, except for the last one, who's
> > paying n msat/minute, where n is the number of hops to have gotten up to
> > the last one. There's the obvious privacy issue there, with fairly
> > obvious ways to fudge around it, I think.
> Yes, it needs to scale with distance to work at all. However, it has
> the same problems with other upfront schemes: how does E know to send
> 4msat per minute?
D tells it "if you want this HTLC, you'll need to pay 4msat/minute after
the grace period of 65 seconds". Which also means A as the originator can
also choose whatever fees they like. The only consequence of choosing too
high a fee is that it's more likely one of the intermediate nodes will
say "screw that!" and abort the HTLC before it gets to the destination.
> > I think it might make sense for the payments to have a grace period --
> > ie, "if you keep this payment open longer than 20 seconds, you have to
> > start paying me x msat/minute, but if it fulfills or cancels before
> > then, it's all good".
> But whatever the grace period, I can just rely on knowing that B is in
> Australia (with a 1 second HTLC commit time) to make that node bleed
> satoshis. I can send A->B->C, and have C fail the htlc after 19
> seconds for free. But B has to send 1msat to A. B can't blame A or C,
> since this attack could come from further away, too.
So A gives B a grace period of 35 seconds, B deducts 5 seconds
processing time and 10 seconds for latency, so gives C a grace period of
20 seconds; C rejects after 19 seconds, and B still has 15 seconds to
notify A before he has to start paying fees. Same setup as decreasing
timelocks when forwarding HTLCs.
> And if there is a grace period, I can just gum up the network with lots
> of slow-but-not-slow-enough HTLCs.
Well, it reduces the "gum up the network for <timeout> blocks" to "gum
up the network for <grace period> seconds", which seems like a pretty
big win. I think if you had 20 hops each with a 1 minute grace period,
and each channel had a max_accepted_htlcs of 30, you'd need 25 HTLCs per
second to block 1000 channels (so 2.7% of the 36k channels 1ml reports),
so at the very least, successfully performing this attack would be
demonstrating lightning's solved bitcoin's transactions-per-second
limitation?
I think you could do better by having the acceptable grace period be
dynamic: both (a) requiring a shorter grace period the more funds a HTLC
locks up, which stops a single HTLC from gumming up the channel, and (b)
requiring a shorter grace period the more active HTLCs you have (or, the
more active HTLCs you have that are in the grace period, perhaps). That
way if the network is loaded, you're prioritising more efficient routes
(or at least ones that are willing to pay their way), and if it's under
attack, you're dynamically increasing the resources needed to maintain
the attack.
Anyway, that's my hot take; not claiming it's a perfect solution or
final answer, rather that this still seems worth brainstorming out.
My feeling is that this might interact nicely with the sender-initiated
upfront fee. Like, you could replace a grace period of 30 seconds at
2msat/minute by always charging 2msat/minute but doing a forward payment
of 1msat. But at this point I can't keep it all in my head at once to
figure out something that really makes sense.
> > Maybe this also implies a different protocol for HTLC forwarding,
> > something like:
> > 1. A sends the HTLC onion packet to B
> > 2. B decrypts it, makes sure it makes sense
> > 3. B sends a half-signed updated channel state back to A
> > 4. A accepts it, and forwards the other half-signed channel update to B
> > so that at any point before (4) Alice can say "this is taking too long,
> > I'll start losing money" and safely abort the HTLC she was forwarding to
> > Bob to avoid paying fees; while only after (4) can she start the time on
> > expecting Bob to start paying fees that she'll forward back. That means
> > 1.5 round-trips before Bob can really forward the HTLC on to Carol;
> > but maybe it's parallelisable, so Bob/Carol could start at (1) as soon
> > as Alice/Bob has finished (2).
> We added a ping-before-commit[1] to avoid the case where B has disconnected
> and we don't know yet; we have to assume an HTLC is stuck once we send
> commitment_signed. This would be a formalization of that, but I don't
> think it's any better?
I don't think it's any better as things stand, but with the "B pays A
holding fees" I think it becomes necessary. If you've got a route
A->B->C then from B's perspective I think it currently looks like:
A->B: here's a HTLC, locked in
B->C: ping
C->B: pong!
B->C: updated commitment with HTLC locked in
C->B: *silence*
at which point the best B can do is unilaterally close the B/C channel
with their pre-HTLC commitment, but they still have to wait for that to
confirm before they can safely cancel the HTLC with A, and that will
likely take more than whatever the grace period is, so B will be losing
money on holding fees.
Whereas:
A->B: here's a HTLC, locked in
B->C: HTLC proposal
C->B: sure: updated commitment with HTLC locked in
B->C: great, corresponding updated commitment, plus revocation
C->B: revocation
means that if C goes silent before B receives a new commitment, B can
cancel the HTLC with A with no risk (B can publish the old commitment
still even if the new arrives later, and C can only publish the pre-HTLC
commitment), and if C goes silent after B receives the new commitment, B
can drop the new commitment to the blockchain and pay A's fees out of it.
> There's an old proposal to fast-fail HTLCs: Bob sends an new message "I
> would fail this HTLC once it's committed, here's the error"
Yeah, you could do "B->C: proposal, C->B: no way!" instead of "sure" to
fast fail the above too.
And I think something like that's necessary (at least with my view of how
this "keep the HTLC open" payment would work), otherwise B could send C a
"1 microsecond grace period, rate of 3e11 msat/minute, HTLC for 100 sat,
timeout of 2016 blocks" and if C couldn't reject it immediately would
owe B 50c per millisecond it took to cancel.
Cheers,
aj

2023-06-09 12:58:57

- reply

📅 Original date posted:2020-02-20
📝 Original message:
On Thu, Feb 20, 2020 at 03:42:39AM +0000, ZmnSCPxj wrote:
> A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me?
>
> Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim it up until the timelock.
> If the peer does not claim it, I cannot claim it in my incoming as well.
> I also cannot safely fail my incoming, as the outgoing peer can still claim it until the timelock expires.
Suppose the channel state looks like:
Bob's balance: $150
Carol's balance: $500
Bob to Carol: $50, hash X, timelock +2016 blocks
The pre-signed close transaction will have already deducted maybe $1 in
fees, say 50c from each balance.
At 5% pa, that's $50*0.05*2/52, so about 10 cents worth of "holding"
fees, so that seems like it's worth just committing to up-front, ie:
Bob's balance: $149.60 (-.50+.10)
Carol's balance: $499.40 (-.50-.10)
Bob to Carol: $50, hash X, timelock +2016 blocks
Fees: $1
And that seems necessary anyway: if the channel does drop to the chain,
then the HTLC can't be cancelled, so if it never confirms, Bob will have
had to pay, say, 9.5c to Alice waiting for the timeout, and can then
immediately cancel the HTLC with Alice allowing it to finish unwinding.
So I think the idea would be not to accept a (rate, amount, timelock)
tuple for an incoming HTLC unless the rate*amount*timelock product
is substantially less than what you're putting towards the blockchain
fees anyway, as otherwise you've got bad incentives for the other guy to
drop to the chain.
Note the rate increases with number of hops, so if it's 1% pa per hop,
the 11th peer will be emitting 10% pa. I think that's probably okay,
because BTC's deflationary nature probably means you don't need to earn
much interest on it, and you can naturally choose the rate dynamically
based on how many HTLCs you currently have open and how much of your
channel funds are being used up by the HTLC?
Also, you'd presumably update your channel state every hundred blocks,
reducing the 10c by half a cent or so each time, so you could have your
risk reduce. Maybe there could be some way of bumping the timelock across
a HTLC path so that the risk is capped, but if the HTLC is still being
paid for it doesn't have to be cancelled?
Cheers,
aj

2023-06-09 12:58:56

- reply

📅 Original date posted:2020-02-20
📝 Original message:
On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote:
> A different way of mitigating this is to reverse the direction in which the
> bond is paid. So instead of paying to offer an htlc, nodes need to pay to
> receive an htlc. This sounds counterintuitive, but for the described jamming
> attack there is also an attacker node at the end of the route. The attacker
> still pays.
I think this makes a lot of sense. I think the way it would end up working
is that the further the route extends, the greater the payments are, so:
A -> B : B sends A 1msat per minute
A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to A
A -> B -> C -> D : D sends C 3 msat, etc
A -> B -> C -> D -> E : E sends D 4 msat, etc
so each node is receiving +1 msat/minute, except for the last one, who's
paying n msat/minute, where n is the number of hops to have gotten up to
the last one. There's the obvious privacy issue there, with fairly
obvious ways to fudge around it, I think.
But that's rational, because that last node can either (a) collect the
payment, covering their cost; or (b) forward the payment, at which point
they'll start collecting funds rather than paying them; or (c) cancel
the payment releasing all the locked up funds all the way back.
I think it might make sense for the payments to have a grace period --
ie, "if you keep this payment open longer than 20 seconds, you have to
start paying me x msat/minute, but if it fulfills or cancels before
then, it's all good".
I'm not sure if there needs to be any enforcement for this beyond "this
peer isn't obeying the protocol, so I'm going to close the channel"; not
even sure it's something that needs to be negotiated as part of payment
routing -- it could just be something each peer does for HTLCs on their
channels? If that can be made to work, it doesn't need much crypto or
bitcoin consensus changes, or even much deployment coordination, all of
which would be awesome.
I think at $10k/BTC then 1msat is about the fair price for locking up $5
worth of BTC (so 50k sat) for 1 minute at a 1% pa interest rate, fwiw.
Maybe this opens up some sort of an attack where a peer lies about the
time to make the "per minute" go faster, but if msats-per-minute is the
units, not sure that really matters.
Maybe this also implies a different protocol for HTLC forwarding,
something like:
1. A sends the HTLC onion packet to B
2. B decrypts it, makes sure it makes sense
3. B sends a half-signed updated channel state back to A
4. A accepts it, and forwards the other half-signed channel update to B
so that at any point before (4) Alice can say "this is taking too long,
I'll start losing money" and safely abort the HTLC she was forwarding to
Bob to avoid paying fees; while only after (4) can she start the time on
expecting Bob to start paying fees that she'll forward back. That means
1.5 round-trips before Bob can really forward the HTLC on to Carol;
but maybe it's parallelisable, so Bob/Carol could start at (1) as soon
as Alice/Bob has finished (2).
Cheers
aj

2023-06-09 12:58:11

- reply

📅 Original date posted:2020-01-21
📝 Original message:
Hi all,
At present, BOLT-3 commitment transactions provide a two-layer
pay-to-self path, so that you can reduce the three options:
1) pay-to-them due to revoked commitment
2) pay-to-me due to timeout (or: preimage known)
3) pay-to-them due to preimage known (or: timeout)
to just the two options:
1) pay-to-them due to revoked commitment
2) pay-to-me due to timeout (or: preimage known)
This allows the `to_self_delay` and the HTLC timeout (and hence the
`cltv_expiry_delta`) to be chosen independently.
As it stands, both the original eltoo proposal [0] and the
ANYPREVOUT-based sketch [1] don't have this property, which means that
either the `cltv_expiry_delta` needs to take the `to_self_delay` into
account, or you risk not being able to claim funds to cover payments
you forward.
[0] https://blockstream.com/eltoo.pdf
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
I think if we drop the commitment to the input value from
ANYPREVOUTANYSCRIPT signatures, it's possible to come up with a scheme
that preserves the other benefits of eltoo while also having the same
benefits BOLT-3 currently achieves. I think for eltoo it needs to be a
channel-wide "shared_delay" rather than a "to_self" delay, so I'll use
that.
Here's the setup. We have four types of transaction:
* funding transaction, posted on-chain as part of channel setup
* update transaction, posted on-chain to close the channel at a
given state
* revocable claim transaction, posted on-chain to reveal a preimage
or establish a timeout has passed
* settlement transaction, to actually claim funds
As with eltoo, if a stale update transaction is posted, it can be spent
via any subsequent update transaction with no penalty. The revocable
claim transactions have roughly the same goal as the second layer BOLT-3
transactions, that is going from:
1) spent by a later update transaction
2) pay-to-me due to timeout (or: preimage known)
3) pay-to-them due to preimage known (or: timeout)
to
1) spent by a later update transaction
2) pay-to-me due to timeout (or: preimage known)
In detail:
* Get a pubkey from each peer (A, B), and calculate P=MuSig(A,B).
* Each state update involves constructing and calculating signatures
for new update transactions, revocable claim transactions and
settlement transactions.
* The update transaction has k+2 outputs, where k is the number of open
PTLCs. Each PTLC output pays to P as the internal key, and:
IF CODESEP [i] ELSE [500e6+n+1] CLTV ENDIF DROP OP_1 CHECKSIG
as the script. i varies from 1..k; n is the state counter, starting
at 1 and counting up.
Each balance output pays to P as the internal key and:
IF CODESEP IF [balance_pubkey_n] [shared_delay] CSV ELSE OP_1 OP_0 ENDIF
ELSE OP_1 [500e6+n+1] CLTV ENDIF
DROP CHECKSIG
as the script.
The signature that allows an update tx to spend a previous update tx
is calculated using ALL|ANYPREVOUTANYSCRIPT, a locktime of 500e6+n,
with the key P, and codesep_pos=0xffff_ffff.
* For each output of the update tx and each party that can spend it,
we also construct a revocable claim transaction. These are designed
to update a single output of each PTLC, and their output pays to P
as the internal key, and the script:
IF [i*P+p] CODESEP ELSE [500e6+n+1] CLTV ENDIF DROP OP_1 CHECKSIG
(swapping the position of the CODESEP opcode, and encoding both i and
p in the script -- P is the number of peers in the channel, so 2
here, and p is an identifier for each peer so either 0 or 1; i=1..k
for HTLCs, i=0 for the balances)
The signature that allows this tx to be applied to the update tx
is calculated as SINGLE|ANYPREVOUT, with the script committed and
codesep_pos=1. This signature should be made conditional for each
PTLC, either by being an adaptor signature requiring the point preimage
to be added, or by having a locktime given.
* For each revocable claim transaction, we also construct a settlement
transaction. The outputs of the settlement transactions are just
an address for whichever peer receives the funds.
These are also done by SINGLE|ANYPREVOUT signatures, with nSequence
set to the shared_delay. There's no locktime or adaptor signatures
needed here, since they were taken care of for the revocable claim
transaction. The signatures commit to the respective scripts, and
set codesep_pos to either 1 or 2 depending on whether a revocable
claim is being spent or not.
* The funding transaction pays to internal key P, with tapscript:
"OP_1 CHECKSIGVERIFY 500e6 CLTV"
Then: to spend from the funding transaction cooperatively, you make a
new SIGHASH_ALL signature based the output key Q for the funding tx.
If you can't do that, you post two transactions: the latest update tx,
and another tx that includes any revocable claim tx's you can already
claim and an input to cover fees, and any change from the fees. You then
wait for the shared_delay to pass, and can then use the settlement txs
to finish claiming the funds, and do whatever you like afterwards.
If someone else posts an update tx, and you have a later one, then
you construct a new update tx, with an input for each unspent output
(whether directly from the update tx, or from a revocable claim tx),
with the witness for each being the update tx's ANYPREVOUTANYSCRIPT
signature (and a "0" to choose the right path of the IF). You then post
that, and another tx that includes your revocable claims txs and pays
the fees, and continue as before.
If someone else posts the latest update tx, you can post any revocable
claims you have to lock those funds in, then need to just wait for the
shared_delay to pass, so that you can claim your balance and post and
settlement txs you have. If you'd had a bad crash and lost the current
channel state, you can work out which output is your balance, and claim
it using just your private key, however you'll lose any PTLCs you may
have otherwise been able to claim.
There's "only" 1+2*(P+2*k) signatures that need to be calculated for
each state -- 1 for the update transaction, and 2 (revocable commit and
settlement) for each of the P balances and both of the ways (preimage
reveal and timeout) each of the k PTLCs can be claimed.
I think you can distinguish each signature so it's only used for the
appropriate transaction,
-> update sig has codesep_pos=0xffff_ffff which forces the CLTV path
to be taken, and nLockTime set so it's only valid for earlier
updates' scripts
-> revocable claim sig has codesep_pos=1 and commits to the script
which encodes by the state n and either the HTLC index i, or the
balance's owner's pubkey
-> settlement sig has codesep_pos=2 and commits to the script, which
encodes the state n, the HTLC index i, and the peer who claimed the
funds
This doesn't work well with HTLCs because you'd need to encode the HTLC
in script, which means you need to keep a record of every HTLC hash in
case it appears in an old published update tx that you want to update
to a new update transaction. I think more generally it's only compatible
with contracts that can be encoded in a scriptless script, as otherwise
you'd need to remember the contract details in perpetuity in case an old
state was published that you needed to update. I think deferring the
contract details to settlement would solve the revocable part of the
problem, but would bring back the delay/locktime conflict so doesn't
seem helpful.
This should work fine with the "A CHECKSIGVERIFY B CHECKSIG" alternate
scripts mentioned in [2] for shortcutting roundtrips, though having more
than one script path would make every uncooperative close more expensive
than only having one script path.
[2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html
I think this construction generalises fine to multiparty channels,
though maybe there are cheaper ones for two-party channels which might
be worth optimising for. I think the obvious optimisations to two-party
channels fail if you bring in untrusted watchtowers -- though that might
be fixable if you make it so watchtowers get signatures that apply
against earlier update tx's but not the funding tx -- I think that'd
just require calculating an extra signature per state.
It's a pretty artificial structure all round, so definitely gives away
that eltoo is in use as soon as an uncooperative close starts, and
also gives away the number of participants in the channel (because the
balance outputs are distinguishable in order to allow balance recovery
after loss of state info).
This all only works if ANYPREVOUTANYSCRIPT doesn't commit to the value of
the input -- otherwise reusing the single "update" signature won't allow
you to collect every revocable claim tx output back to redistribute all
their funds correctly. That's a significant change to NOINPUT/BIP 118 as
it stands.
Cheers,
aj

2023-06-09 12:57:42

- reply

📅 Original date posted:2019-12-17
📝 Original message:
On Sun, Dec 15, 2019 at 03:43:07PM +0000, ZmnSCPxj via Lightning-dev wrote:
> For now, I am assuming the continued use of the existing Poon-Dryja update mechanism.
> Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and its details seem less settled for now than taproot details.
Supporting PTLCs instead of HTLCs is a global upgrade in that you need
all nodes along your payment path to support it; moving from Poon-Dryja
to Decker-Russell-Osuntokun is only relevant to individual peers. So I
think it makes sense to do PTLCs first if the required features aren't
both enabled at the same time.
> Poon-Dryja with Schnorr
> -----------------------
I think MuSig between the two pairs is always superior to a NUMS point
for the taproot internal key; you definitely want to calculate a point
rather than use a constant, or you're giving away that it's lightning,
and if you're calculating you might as well calculate something that can
be used for a cooperative key path spend if you ever want to.
> A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.
I think you can reduce this via an alternative script path. In
particular, if you want a script that the other guy can spend if they
reveal the discrete log of point X, with musig you do:
P = H(H(A,B),1)*A + H(H(A,B),2)*B
[exchange H(RA),H(RB),RA,RB]
[send X]
sb = rb + H(RA+RB+X,P,m)*H(H(A,B),2)*b
[wait for sb]
sa = ra + H(RA+RB+X,P,m)*H(H(A,B),1)*a
[store RA+RB+X, sa+sb, supply sa, watch for sig]
sig = (RA+RB+X, sa+sb+x)
So the 1.5 round trips are "I want to do a PTLC for X", "okay here's
sb", "great, here's sa".
But with taproot you can have a script path as well, so you could have a
script:
A CHECKSIGVERIFY B CHECKSIG
and supply a partial signature:
R+X,s,X where s = r + H(R+X,A,m)*a
to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete
log of X, and of course they can sign with B at any time. This is only
half a round trip, and can be done at the same time as sending the "I
want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig
spend. It's an extra signature on the sender's side and an extra verification
on the receiver's side, but I think it works out fine.
> Pointlocked Timelocked Contracts
> --------------------------------
> First, I will discuss how to create a certain kind of PTLCs, which I call "purely scriptless" PTLCs.
> In particular, I would like to point out that we *actually* use in current Poon-Dryja Lightning Network channels is *revocable* HTLCs, thus we need to have *revocable* PTLCs to replace them.
> * First, we must have a sender A, who is buying a secret scalar, and knows the point equivalent to that scalar.
> * Second, we have a receiver B, who knows this secret scalar (or can somehow learn this secret scalar).
> * A and B agree on the specifications of the PTLC: the point, the future absolute timelock, the value.
> * A creates (but *does not* sign or broadcast) a transaction that pays to a MuSig of A and B and shares the txid and output number with the relevant MuSig output.
> * A and B create a backout transaction.
> * This backout has an `nLockTime` equal to the agreed absolute timelock.
> * It spends the above MuSig output (this input must enable `nLockTime`, e.g. by setting `nSequence` to `0xFFFFFFFE`).
> * It creates an output that is solely controlled by A.
> * A and B perform a MuSig ritual to sign the backout transaction.
> * A now signs and broadcast the first transaction, the one that has an output that represents the PTLC.
> * A and B wait for the above transaction to confirm deeply.
> This completes the setup phase for the PTLC.
> * After this point, if the agreed-upon locktime is reached, A broadcasts the backout transaction and aborts the ritual.
> * A and B create a claim transaction.
> * This has an `nLockTime` of 0, or a present or past blockheight, or disabled `nLockTime`.
> * This spends the above MuSig output.
> * This creates an output that is solely controlled by B.
> * A and B generate an adaptor signature for the claim transaction, which reveals the agreed scalar.
> * This is almost entirely a MuSig ritual, except at `s` exchange, B provides `t + r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` first, then demands `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, A) * a` from A, then reveals `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` (or the completed signature, by publishing onchain), revealing the secret scalar `t` to A.
> * A is able to learn the secret scalar from the above adaptor signature followed by the full signature, completing the ritual.
(I think it makes more sense to provide "r + H(R+T, P, m)*b" instead of
"r+t + H(R,P,m)*b" -- you might not know "t" at the point you need to
start the signature exchange)
I think the setup can be similar to BOLT-3:
Funding TX output: MuSig(A,B)
Commitment Tx Held by A:
- locktime: obscured commitment number
- input: funding tx
- outputs:
balance A
balance B
PTLC paying to A
PTLC paying to B
[etc]
balance B can pay directly to B
balance A pays to MuSig(Rn,B) -- where Rn is the revocation key for the
nth commitment, and A holds a presigned tx by B with relative locktime
set, paying the funds to A.
PTLCs also pay to MuSig(Rn,B) --
for the one paying to A, A holds a tx
partially presigned by B that needs the point's discrete log added to x
with relative timelock; for the one paying to B, A holds a presigned tx
by B that has absolute locktime set and pays to MuSig(Rn,B) for which
A has another presigned tx by B that has relative locktime set.
HTLC's also pay to MuSig(Rn,B) but they're tweaked by a script -- if
they're paying to B, A just holds the same timelocked presigned tx's as
for PTLCs; if they're paying to A, A will use a "HASH160 X EQUALVERIFY
A CHECKSIGVERIFY delay CSV" script path instead.
B has a similar commitment Tx; and A holds pre-signed tx's for the
PTLC's there, except without the relative timelock txs.
This adds up to B needing to provide A with signatures for:
the funding tx
A's balance
each PTLC/HTLC paying/refunding to A from A's commitment and the sub tx for each of those
each PTLC/HTLC paying/refunding to B from B's commitment
and each of those signatures need to be updated every commitment update.
Note that you need to receive all the partial signatures to spend the
commitment tx before you provide your partial signature over the funding
tx to authorise the commitment tx. So yet more rounds of communication.
I think this approach would let you upgrade existing channels to support
PTLCs without closing/reopening, though.
I think you could do something eltoo-ish to simplify watchtowers:
Funding TX output: MuSig(A,B)
Commitment Tx Held by A:
- locktime: obscured commitment number
- inputs: funding tx
- outputs: MuSig(Rn,B)
Settlement Tx Held by A:
- nsequence: to_self_delay
- input: commitment tx held by A
- outputs:
balance A
balance B
PTLC paying to A
PTLC paying to B
Secondary Settlement Tx Held by B:
- no abs/relative locktime
- input: commitment tx held by A
- outputs:
balance A
balance B
PTLC paying to A
PTLC paying to B
in which case once the commitment is revoked, B only needs to do a single
signature of MuSig(Rn,B) to claim all the funds if A publishes the
old commitment, without having to worry about any HTLC/PTLC info? The
settlement tx can be a bit simplified I think too. Maybe the edge case
when the absolute locktime is close to the relative locktime makes this
painful, though I think it would make eltoo painful then too? Not sure
if I'm missing something here.
(Note that this gives symmetric delays: if A unilaterally closes the
channel by publishing the commitment tx, and B wants their funds, B can
either immediately claim all the funds via the revocation secret if A
was cheating, or has to publish the settlement tx first, at which point
A can get all A's funds immediately as well)
> Revocable Outputs and PTLCs
> ---------------------------
> * No wallet uses relative-timelock for ordinary spends, unlike abolute-locktime where Bitcoin Core always uses absolute-locktime `nLockTime` for ordinary spends.
I think the fact lightning relative timelocks will be "round" numbers,
and the timelocked tx will be published as soon as possible will make
it relatively easy to distinguish them from other spends anyway. Doing
it scriptlessly is cheaper on chain though.
Anyway, my picks are:
- [x] Poon-Dryja PTLCs prior to eltoo
- [x] scriptless revocation via MuSig(Rn,B) internal keys
- [x] support HTLCs via taproot
- [x] (optionally) allow use of script paths to minimise round trip
delay
Cheers,
aj

2023-06-09 12:57:34

- reply

📅 Original date posted:2019-12-03
📝 Original message:
On Tue, Nov 26, 2019 at 03:41:14PM -0800, Conner Fromknecht wrote:
> I recently revisited the eltoo paper and noticed some things related
> watchtowers that might affect channel construction.
> In order to spend, however, the tower must also produce a witness
> script which when hashed matches the witness program of the input. To
> ensure settlement txns can only spend from exactly one update txn,
> each update txn uses unique keys for the settlement clause, meaning
> that each state has a _unique_ witness program.
I don't believe that's necessary with the ANYPREVOUT design, see
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
The design I'm thinking of use a common taproot internal key
P=muSig(A,B) for update transactions. The tapscript paths are
(with the chaperone sigs dropped):
Update n: [nLockTime = 500e6+n]
script: OP_1 CHECKSIGVERIFY [500e6+n+1] CLTV
witness: [ANYPREVOUTANYSCRIPT sig]
Settlement n: [nSequence = delay; nLockTime=500e6+n+1]
witness: [ANYPREVOUT sig]
(This relies on having the two variants of ANYPREVOUT, one of which
commits to the state number via commiting to the [500e6+n+1] value in
the update tx's script, so that you don't need unique keys to ensure
settlement tx n can't spend settlement tx n+k)
With this you can tell which update was posted by subtracting 500e6 from
the nLocktime, and use that to calculate the tapscript the update tx used,
and the internal key is constant.
The watchtower only needs to post the update tx -- as long as the latest
update is posted, the only tx that can spend it is the correct settlement,
so you can post that whenever you're back online, even if that's weeks
or months later, and likewise for actually claiming your funds from the
settlement tx's outputs.
Cheers,
aj

2023-06-09 12:57:07

- reply

📅 Original date posted:2019-11-08
📝 Original message:
On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> [ Snip summary, which is correct ]
Huzzah!
This correlates all the hops in a payment when the route reaches its end
(due to the final preimage getting propogated back for everyone to justify
the funds they claim). Maybe solvable by converting from hashes to ECC
as the trapdoor function?
The refund amount propogating back also reveals the path, probably.
Could that be obfusticated by somehow paying each intermediate node
both as the funds go out and come back, so the refund decreases on the
way back?
Oh, can we make the amounts work like the onion, where it stays constant?
So:
Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
Success:
Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)
Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)
Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
Bob refunds 100 msat to Alice (-1400, +700, +400, +300)
Clean routing failure at Carol/Dave:
Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
Carol says Dave's not talking
Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)
Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
I think that breaks the correlation pretty well, so you just need a
decent way of obscuring path length?
In the uncooperative routing failure case, I wonder if using an ECC
trapdoor and perhaps scriptless scripts, you could make it so Carol
doesn't even get an updated state without revealing the preimage...
Cheers,
aj

2023-06-09 12:57:06

- reply

📅 Original date posted:2019-11-07
📝 Original message:
On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
> > field: it says 14, LLLL." but Alice doesn't know anything other than
> > ZZZZ so can't put LLLL in the onion?
> Alice created the onion. Alice knows all the preimages, since she
> created the chain AAAAA....ZZZZZ.
In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating
the chain AAAA...ZZZZ -- so I was lost as to what you were proposing...
Here's what I now think you're saying, which I think mostly hangs
together:
Alice sends a HTLC with hash X and value V to Dave via Bob then Carol
Alice generates a nonce AAAA, and calculates H^25(AAAA) = ZZZZ.
Alice creates an onion, and sends the HTLC to Bob, revealing ZZZZ and
6,TTTT to Bob, along with 2500 msat (25 for the hashing ops between
AAAA and ZZZZ, and *100 for round numbers). Bob calculates "6" is a
fair price.
Bob checks H^6(TTTT)=ZZZZ. If not, Bob refunds the 2500 msat, and fails
the HTLC immediately. Otherwise, Bob passes the onion on to Carol, with
1900 msat and TTTT; Carol unwraps the onion revealing 15,EEEE. Carol
calcualtes "15" is a fair price.
Carol checks H^15(EEEE)=TTTT, and fails the route if not, refunding
1900msat to Bob. Otherwise, Carol passes the onion on to Dave, with 400
msat and EEEE. Dave unwraps the onion, revealing 2,CCCC, so can claim
200 msat as well as the HTLC amount, etc.
After the successful route, Dave passes 2,CCCC and 200msat back to Carol,
who validates and continues passing things back.
If Carol instead passes, say, 3,CCCC back, then she also has to refund
300msat to avoid Bob closing the channel, which would be fine, because
Bob can just pass that back too -- Carol's the only one losing money in
that case.
If Carol wants to close the channel anyway and collect the HTLC on
chain, then Bob's situation is:
channel with Alice: +2500 msat
channel with Carol: -1900 msat , -fees , -HTLC funds
If Carol isn't cooperative, Bob only definitely knows TTTT, so to keep
the channel open with Alice, has to refund 1900msat, so:
channel with Alice: +600 msat , +HTLC funds
channel with Carol: -1900 msat , -fees , -HTLC funds
(or Bob could keep the 2500 msat at the cost of Alice closing the channel
too:
channel with Alice: +2500 msat , -fees , +HTLC funds
channel with Carol: -1900 msat , -fees , -HTLC funds
)
So Bob and either keep the channel open but is out 1300 msat because of
Carol, or can gain 600 msat at the cost of closing the channel with
Alice?
As far as the "fair price" goes, the spitballed formula is "16 - X/4"
where X is number of zero bits in some PoW-y thing. The proposal is
the thing is SHA256(blockhash|revealedonion) which works, and (I think)
means each step is individually grindable.
I think an alternative would be to use the prepayment hashes themselves,
so you generate the nonce AAAA as the value you'll send to Dave then
hash it repeatedly to get BBBB..QQQQ, then check if pow(AAAA,BBBB) has
60 leading zero bits or pow(AAAA,CCCC) has 56 leading zero bits etc.
If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd
preserve privacy, but also mean you can't meaningfully grind unfairly
cheap routing except for very short paths?
If you don't grind and just go by luck, the average number of hashes
per hop is ~15.93 (if I got my maths right), so you should be able to
estimate path length pretty accurate by dividing claimed prepaid funds by
15.93*25msat or whatever. If everyone grinds at each level independently,
I think you'd just subtract maybe 6 hops from that, but the maths would
mostly stay the same?
Though I think you could obfusticate that pretty well by moving
some of the value from the HTLC into the prepayment -- you'd risk losing
that extra value if the payment made it all the way to the recipient but
they declined the HTLC that way though.
> >> Does Alice lose everything on any routing failure?
> > That was my thought yeah; it seems weird to pay upfront but expect a
> > refund on failure -- the HTLC funds are already committed upfront and
> > refunded on failure.
> AFAICT you have to overpay, since anything else is very revealing of
> path length. Which kind of implies a refund, I think.
I guess you'd want to pay for a path length of about 20 whether the
path is actually 17, 2, 10 or 5. But a path length of 20 is just paying
for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of
1 cent, which doesn't seem that worth refunding (except for really tiny
micropayments, where paying for payment bandwidth might not be feasible
at all).
If you're buying a $2 coffee and paying 500ppm in regular fees per hop
with 5 hops, then each routing attempt increases your fees by 4%, which
seems pretty easy to ignore to me.
Cheers,
aj

2023-06-09 12:57:05

- reply

📅 Original date posted:2019-11-05
📝 Original message:
On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote:
> Sure: for simplicity I'm sending a 0-value HTLC.
> ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat
> in the channel with YAIjbOJa.
Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty...
> Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
> ZmnSCPxj prepares the onion, but adds extra fields (see below).
It would have made more sense to me for Alice (Zmn) to generate
the nonce, hash it, and prepare the onion, so that the nonce is
revealed to Dave (Rusty) if/when the message ever actually reaches its
destination. Otherwise Rusty has to send AAAAA to Zmn already so that
Zmn can prepare the onion?
> He then
> sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those
> fields are in the update_add_htlc msg). His balance with Rusty is now
> 8750msat (ie. 25x50 to Rusty).
>
> Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL.
> Rusty checks: the hash of the onion & block (or something) does indeed
> have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He
> then hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it
> should be.
I'm not sure why lucky hashing should result in a discount? You're
giving a linear discount for exponentially more luck in hashing which
also seems odd.
You've only got two nonce choices -- the initial AAAA and the depth
that you tell Bob and Carol to hash to as steps in the route; so the
incentive there seems to be to do a large depth, so you might hash
AAAA 1000 times, and figure that you'll find a leading eight 0's once
in the first 256 entries, then another by the time you get up to 512,
and another by the time you get to 768, which gets you discounts on
three intermediaries. But the cost there is that your intermediaries
collectively have to do the same amount of hashing you did, so it's not
proof-of-work, because it's as hard to verify as it is to generate.
I think you could just make the scheme be:
Alice sends HTLC(k,v) + 1250 msat to Bob
Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol
Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave
Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol
Carol redeems the HTLC and refunds 200 msat to Bob
Bob redeems the HTLC and refunds 200 msat to Alice
If there's a failure, Alice loses the 1250 msat, and someone in the
path steals the funds. You could make the accountable by having Alice
also provide "Hash(AAAA, refund=200)" to everyone, encoding AAAA in the
onion to Dave, and then each hop reveals AAAA and refunds 200msat to
demonstrate their honesty.
Does that miss anything that all the hashing achieves?
I think the idea here is that you're paying tiny amounts for the
bandwidth, which when it's successful does in fact pay for the bandwidth;
and when it's unsuccessful results in a channel closure, which makes it
unprofitable to cheat the system, but doesn't change the economics of
lightning much overall because channel closures can happen anytime anyway.
I think that approach makes sense.
Cheers,
aj

2023-06-09 12:57:05

- reply

📅 Original date posted:2019-11-06
📝 Original message:
On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote:
> >> Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
> >> ZmnSCPxj prepares the onion, but adds extra fields (see below).
> > It would have made more sense to me for Alice (Zmn) to generate
> > the nonce, hash it, and prepare the onion, so that the nonce is
> > revealed to Dave (Rusty) if/when the message ever actually reaches its
> > destination. Otherwise Rusty has to send AAAAA to Zmn already so that
> > Zmn can prepare the onion?
> The entire point is to pay *up-front*, though, to prevent spam.
Hmm, I'm not sure I see the point of paying upfront but not
unconditionally -- you already commit the funds as part of the HTLC,
and if you're refunding some of them, you kind-of have to keep them
reserved or you risk finalising the HTLC causing a failure because you
don't have enough msats spare to do the refund?
If you refund on routing failure, why wouldn't a spammer just add a fake
"Ezekiel" at the end of the route after Dave, so that the HTLCs always
fail and all the fees are returned?
> Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the
> last hash directly: Alice is saying "I'll pay you 50msat for each
> preimage you can give me leading to this hash".
So my example was Alice paying Dave via Bob and Carol (so Alice/Bob,
Bob/Carol, Carol/Dave being the individual channels).
What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
field: it says 14, LLLL." but Alice doesn't know anything other than
ZZZZ so can't put LLLL in the onion?
Are you using Hornet so that every intermediary can communicate a nonce
back to the source of the route? If not, "Rusty" generating the nonce
seems like you're informing Rusty that you're actually the origin of the
HTLC, and not just innocently forwarding it along; if so, it seems like
you have independent nonces at each step, rather than
AAAA/BBBB/LLLL/ZZZZ in a direct chain.
> > I'm not sure why lucky hashing should result in a discount?
> Because the PoW adds noise to the amounts, otherwise the path length is
> trivially exposed, esp in the failure case. It's weak protection
> though.
With a linear/exponential relationship you just get "half the time it's
1 unit, 25% of the time it's 2 units, 12% of the time it's 3 units", so
I don't think that's adding much noise?
> > You've only got two nonce choices -- the initial AAAA and the depth
> > that you tell Bob and Carol to hash to as steps in the route;
> No, the sphinx construction allows for grinding, that was my intent
> here. The prepay hashes are independent.
Oh, because you're also xoring with the onion packet, right, I see.
> > I think you could just make the scheme be:
> > Alice sends HTLC(k,v) + 1250 msat to Bob
> > Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol
> > Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave
> > Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol
The math here doesn't add up. Let's assume I meant:
Bob keeps 500 sat, forwards 750 sat
Carol keeps 250 sat, forwards 500 sat
Dave keeps 300 sat, refunds 200 sat
> > Carol redeems the HTLC and refunds 200 msat to Bob
> > Bob redeems the HTLC and refunds 200 msat to Alice
> >
> > If there's a failure, Alice loses the 1250 msat, and someone in the
> > path steals the funds.
> This example confuses me.
Well, that makes us even at least? :)
> So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol
> now know Dave is the last hop?
No, Alice is choosing to pay 500, 250 and 300 msat to Bob, Carol and
Dave respectively, as part of setting up the onion, and picks those
numbers via some magic algo trading off privacy and cost.
> Does Alice lose everything on any routing failure?
That was my thought yeah; it seems weird to pay upfront but expect a
refund on failure -- the HTLC funds are already committed upfront and
refunded on failure.
> If so, that is strong incentive for Alice to reduce path-length privacy
> by keeping payments minimal, which I was really trying to avoid.
Assuming v is much larger than 1250msat, and 1250 msat is much lower than
the cost to Bob of losing the channel with Alice, I don't think that's
a problem. 1250msat pays for 125kB of bandwdith under your assumptions
I think?
> > Does that miss anything that all the hashing achieves?
> It does nothing if Carol is the one who can't route.
If Carol can't route, then ideally she just refunds all the money and
everyone's happy.
If Carol tries to steal, then she can keep 750 msat instead of 250 msat.
This doesn't give any way for Bob to prove Carol cheated on him though;
but Bob could just refund the 1250 msat and write the 750 msat off as a
loss of dealing with cheaters like Carol.
Cheers,
aj

2023-06-09 12:56:22

- reply

📅 Original date posted:2019-10-02
📝 Original message:
On Wed, Oct 02, 2019 at 02:03:43AM +0000, ZmnSCPxj via Lightning-dev wrote:
> So let me propose the more radical excision, starting with SegWit v1:
> * Remove `SIGHASH` from signatures.
> * Put `SIGHASH` on public keys.
> <sighash> <pubkey> OP_SETPUBKEYSIGHASH
I don't think you could reasonably do this for key path spends -- if
you included the sighash as part of the scriptpubkey explicitly, that
would lose some of the indistinguishability of taproot addresses, and be
more expensive than having the sighash be in witness data. So I think
that means sighashes would still be included in key path signatures,
which would make the behaviour a little confusingly different between
signing for key path and script path spends.
> This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed.
I don't think the problems with NONE and SINGLE are any worse than using
SIGHASH_ALL to pay to "1*G" -- someone may steal the money you send,
but that's as far as it goes. NOINPUT/ANYPREVOUT is worse in that if
you use it, someone may steal funds from other UTXOs too -- similar
to nonce-reuse. So I think having to commit to enabling NOINPUT for an
address may make sense; but I don't really see the need for doing the
same for other sighashes generally.
FWIW, one way of looking at a transaction spending UTXO "U" to address
"A" is something like:
* "script" lets you enforce conditions on the transaction when you
create "A" [0]
* "sighash" lets you enforce conditions on the transaction when
you sign the transaction
* nlocktime, nsequence, taproot annex are ways you express conditions
on the transaction
In that view, "sighash" is actually an *extremely* simple scripting
language itself (with a total of six possible scripts).
That doesn't seem like a bad design to me, fwiw.
Cheers,
aj
[0] "graftroot" lets you update those conditions for address "A" after
the fact

2023-06-09 12:56:21

- reply

📅 Original date posted:2019-10-01
📝 Original message:
On Mon, Sep 30, 2019 at 11:28:43PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`.
I don't think there's any meaningful difference between making a new
opcode and making a new tapscript public key type; the difference is
just one of encoding:
3301<key>AC [CHECKSIG of public key type 0x01]
32<key>B3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key]
> This new opcode ignores any `SIGHASH` flags, if present, on a signature,
(How sighash flags are treated can be redefined by new public key types;
if that's not obvious already)
Cheers,
aj

2023-06-09 12:56:21

- reply

📅 Original date posted:2019-10-01
📝 Original message:
On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev wrote:
> With the recently renewed interest in eltoo, a proof-of-concept implementation
> [1], and the discussions regarding clean abstractions for off-chain protocols
> [2,3], I thought it might be time to revisit the `sighash_noinput` proposal
> (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
Hey Christian, thanks for the write up!
> ## Open questions
> The questions that remain to be addressed are the following:
> 1. General agreement on the usefulness of noinput / anyprevoutanyscript /
> anyprevout[?]
> 2. Is there strong support or opposition to the chaperone signatures[?]
> 3. The same for output tagging / explicit opt-in[?]
> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
> confusion and make for simpler discussions in the end.
I think there's an important open question you missed from this list:
(1.5) do we really understand what the dangers of noinput/anyprevout-style
constructions actually are?
My impression on the first 3.5 q's is: (1) yes, (1.5) not really,
(2) weak opposition for requiring chaperone sigs, (3) mixed (weak)
support/opposition for output tagging.
My thinking at the moment (subject to change!) is:
* anyprevout signatures make the address you're signing for less safe,
which may cause you to lose funds when additional coins are sent to
the same address; this can be avoided if handled with care (or if you
don't care about losing funds in the event of address reuse)
* being able to guarantee that an address can never be signed for with
an anyprevout signature is therefore valuable; so having it be opt-in
at the tapscript level, rather than a sighash flag available for
key-path spends is valuable (I call this "opt-in", but it's hidden
until use via taproot rather than "explicit" as output tagging
would be)
* receiving funds spent via an anyprevout signature does not involve any
qualitatively new double-spending/malleability risks.
(eltoo is unavoidably malleable if there are multiple update
transactions (and chaperone signatures aren't used or are used with
well known keys), but while it is better to avoid this where possible,
it's something that's already easily dealt with simply by waiting
for confirmations, and whether a transaction is malleable is always
under the control of the sender not the receiver)
* as such, output tagging is also unnecessary, and there is also no
need for users to mark anyprevout spends as "tainted" in order to
wait for more confirmations than normal before considering those funds
"safe"
I think it might be good to have a public testnet (based on Richard Myers
et al's signet2 work?) where we have some fake exchanges/merchants/etc
and scheduled reorgs, and demo every weird noinput/anyprevout case anyone
can think of, and just work out if we need any extra code/tagging/whatever
to keep those fake exchanges/merchants from losing money (and write up
the weird cases we've found in a wiki or a paper so people can easily
tell if we missed something obvious).
Cheers,
aj

2023-06-09 12:56:13

- reply

📅 Original date posted:2019-09-25
📝 Original message:
On Wed, Sep 25, 2019 at 01:30:39PM +0000, ZmnSCPxj wrote:
> > Since it's off chain, you could also provide R and C and a zero knowledge
> > proof that you know an r such that:
> > R = SHA256( r )
> > C = SHA256( x || r )
> > in which case you could do it with lightning as it exists today.
> I can insist on paying only if the server reveals an `r` that matches some known `R` such that `R = SHA256(r)`, as currently in Lightning network.
> However, how would I prove, knowing only `R` and `x`, and that there exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`?
If you know x and r, you can generate C and R and a zero knowledge proof
of the relationship between x,C,R that doesn't reveal r (eg, I think
you could do that with bulletproofs). Unfortunately that zkp already
proves that C was generated based on x, so you get your timestamp for
free. Ooops. :(
Cheers,
aj

2023-06-09 12:56:12

- reply

📅 Original date posted:2019-09-25
📝 Original message:
On Wed, Sep 25, 2019 at 11:01:28AM +0200, Konstantin Ketterer wrote:
> Motivation: If I had to timestamp multiple messages I could simply aggregate
> them in a merkle tree and pay relatively low fees per message. However, if I
> only need to timestamp something once in a while I need to rely on free
> services or pay high fees.
Maybe model the timestamping service as having fixed and floating users,
in which case the fixed users pay a subscription fee that covers the costs
and get placed relatively high in the merkle tree, while the floating
users are placed low in the merkle tree and are basically free money?
Your merkle tree might then have 2**N-1 fixed slots, all at height N,
then 2**K floating slots, all at height N+K, but you don't need to charge
the floating slots anything up front, because your fixed costs are all
paid for by subscription income from the fixed slots.
You might still want to charge some up front fee to prevent people
spamming you with things to timestamp that they're never going to pay
for though.
> Solution: buy a place in a merkle tree "risk-free"
> 1. send hash x of my message (or the merkle root of another tree) to the
> timstamping server
> 2. server calculates Pedersen commit: C = x*H + r*G, hashes it, builds merkle
> tree with other commits in it and publishes a valid transaction containing the
> merkle root to the Bitcoin blockchain
> 3. after a certain number of block confirmations and with the given proof I can
> confirm that the commitment C is indeed part of the Bitcoin blockchain
> 4. I now have to send a lightning payment with C - x*H = r*G as the payment
> point to the timestamping server and as a proof of payment the server must
> reveal r to receive the money.
Nice.
Since it's off chain, you could also provide R and C and a zero knowledge
proof that you know an r such that:
R = SHA256( r )
C = SHA256( x || r )
in which case you could do it with lightning as it exists today.
Cheers,
aj

2023-06-09 12:55:01

- reply

📅 Original date posted:2019-05-16
📝 Original message:
On Thu, May 16, 2019 at 09:55:57AM +0200, Bastien TEINTURIER wrote:
> Thanks for your answers and links, the previous discussions probably happened
> before I joined this list so I'll go dig into the archive ;)
The discussion was on a different list anyway, I think, this might be
the middle of the thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016777.html
> > Specifically we can't make make use of the collaborative path where
> > we override an `update_tx` with a newer one in taproot as far as I can
> > see, since the `update_tx` needs to be signed with noinput (for
> > rebindability) but there is no way for us to specify the chaperone key
> > since we're not revealing the committed script.
> Can you expand on that? Why do we need to "make use of the collaborative path"
> (maybe it's unclear to me what you mean by collaborative path here)?
I think Christian means the "key path" per the terminology in the
taproot bip. That's the path that just provides a signature, rather than
providing an internal key, a script, and signatures etc for the script.
> I feel like there will be a few other optimizations that are unlocked by
> taproot/tapscript, it will be interesting to dig into that.
I had a go at drafting up scripts, and passed them around privately to
some of the people on this list already. They're more "thought bubble"
than even "draft" yet, but for the sake of discussion:
---
FWIW, the eltoo scripts I'm imaginging with this spec are roughly:
UPDATE TX n:
nlocktime: 500e6+n
nsequence: 0
output 0:
P = muSig(A,B)
scripts = [
"OP_1 CHECKSIGVERIFY X CHECKSIGVERIFY 500e6+n+1 CLTV"
]
witness:
sig(P,hash_type=SINGLE|ANYPREVOUTANYSCRIPT=0xc3)
sig(X,hash_type=0)
SETTLEMENT TX n:
nlocktime: 500e6+n+1
nsequence: [delay]
output 0: A
output 1: B
output n: (HTLC)
P = muSig(A,B)
scripts = [
"OP_1 CHECKSIGVERIFY X CHECKSIG"
"A CHECKSIGVERIFY <t> CLTV"
]
witness:
sig(P,hash_type=ALL|ANYPREVOUT=0x41)
sig(X,hash_type=0)
HTLC CLAIM (reveal secp256k1 preimage R):
witness:
hash-of-alternative-script
sig(P,hash_type=SINGLE|ANYPREVOUT,reveal R)
sig(X,hash_type=0)
HTLC REFUND (timeout):
witness:
hash-of-alternative-script
sig(A,hash_type=ALL)
Because "n" changes for each UPDATE tx, each ANYPREVOUT signature
(for the SETTLEMENT tx) commits to a specific UPDATE tx via both the
scriptPubKey commitment and the tapleaf_hash commitment.
So the witness data for both txs involve revealing:
33 byte control block
43 byte redeem script
65 byte anyprevout sig
64 byte sighash all sig
Compared to a 65 byte key path spend (if ANYPREVOUT worked for key paths),
that's an extra 143 WU or 35.75 vbytes, so about 217% more expensive. The
update tx script proposed in eltoo.pdf is (roughly):
"IF 2 Asi Bsi ELSE <500e6+n+1> CLTV DROP 2 Au Bu ENDIF 2 OP_CHECKMULTISIG"
148 byte redeem script
65 byte anyprevout sig by them
64 byte sighash all sig by us
"1" or "0" to control the IF
which I think would be about 282 WU total, or an extra 216 WU/54 vbytes
over a 65 byte key path spend, so about 327% more expensive. So at least
we're a lot better than where we were with BIP 118, ECDSA and p2wsh.
Depending on if you can afford generating a bunch more signatures you
could also have a SIGHASH_ALL key path spend for the common unilateral
case where only a single UPDATE TX is published.
UPDATE TX n (alt):
input: FUNDING TX
witness: sig(P,hash_type=0)
output 0:
P = muSig(A,B)
scripts = [
"OP_1 CHECKSIGVERIFY X CHECKSIGVERIFY 500e6+n+1 CLTV"
]
SETTLEMENT TX n (alt):
nsequence: [delay]
input: UPDATE TX n (alt)
witness: sig(P+H(P||scripts)*G,hash_type=0)
outputs: [as above]
(This approach can either use the same ANYPREVOUT sigs for the HTLC
claims, or could include an additional sig for each active HTLC for each
channel update to allow HTLC claims via SIGHASH_ALL scriptless scripts...)
Despite using SIGHASH_SINGLE, I don't think you can combine two UPDATE txs
generally, because the nlocktime won't match (this could possibly be fixed
in a future soft-fork by using the annex to support per-input absolute
locktimes). You can't combine SETTLEMENT tx, because the ANYPREVOUT
signature needs to commit to multiple outputs (one for my balance, one
for yours, one for each active HTLC). Combining HTLC refunds is kind-of
easy, but only possible in the first place if you've got a bunch expiring
at the same time, which might not be that likely. Combining HTLC claims
should be easy enough since they just need scriptless-script signatures.
For fees, because of ALL|ANYPREVOUT, you can add a new input and new
change output to bring-your-own-fees for the UPDATE tx; and while you
can't do that for the SETTLEMENT tx, you can immediately spend your
channel-balance output to add fees via CPFP.
As far as "X" goes, calculating the private key as a HD key using ECDH
between the peers to generate the seed, and including the update id "n"
in the path, to vary it between each update tx might work well. You'd
need to give this key to watchtowers, but you'll probably have to pay
watchtowers to monitor your txs (so that they can add fees to the UPDATE
tx's), so only giving this key to the watchtowers you pay should maintain
the security assumptions.
Cheers,
aj

2023-06-09 12:54:27

- reply

📅 Original date posted:2019-03-14
📝 Original message:
On Thu, Mar 14, 2019 at 05:22:59AM +0000, ZmnSCPxj via Lightning-dev wrote:
> When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case.
I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
so if you used a tagged output, you could do everything normal taproot
address could, but also do noinput sigs for them.
So you might have:
funding tx -> cooperative claim
funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
funding tx -> update 3 [TAGGED] ->
update 4 [TAGGED,NOINPUT] ->
settlement 4 [TAGGED,NOINPUT] ->
claim [NOINPUT]
In the cooperative case, no output tagging needed.
For the unilateral case, you need to tag all the update tx's, because
they *could* be spend by a later update with a NOINPUT sig, and if
that actually happens, then the settlement tx also needs to use a
NOINPUT sig, and if you're using scriptless scripts to resolve HTLCs,
claiming/refunding the HTLCs needs a partially-pre-signed tx which also
needs to be a NOINPUT sig, meaning the settlement tx also needs to be
tagged in that case.
You'd only need the script path for the last case where there actually
are multiple updates, but because you have to have a tagged output in the
second case anyway, maybe you've already lost privacy and always using
NOINPUT and the script path for update and settlement tx's would be fine.
> However, it is probably more likely that I simply misunderstood what you said, so if you can definitively say that it would be possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot then I am fine.
Yeah, that's my thinking.
> Minor pointless reactions:
> > 5. if you're using scriptless scripts to do HTLCs, you'll need to
> > allow for NOINPUT sigs when claiming funds as well (and update
> > the partial signatures for the non-NOINPUT cases if you want to
> > maximise privacy), which is a bit fiddly
> If I remember accurately, we do not allow bilateral/cooperative close when HTLC is in-flight.
> However, I notice that later you point out that a non-cheating unilateral close does not need NOINPUT, so I suppose. the above thought applies to that case.
Yeah, exactly.
Trying to maximise privacy there has the disadvantage that you have to
do a new signature for every in-flight HTLC every time you update the
state, which could be a lot of signatures for very active channels.
Cheers,
aj

2023-06-09 12:52:44

- reply

📅 Original date posted:2018-11-16
📝 Original message:
On Thu, Nov 15, 2018 at 11:54:22PM +0000, ZmnSCPxj via Lightning-dev wrote:
> The improvement is in a reduction in `fee_base_msat` in the C->D path.
I think reliability (and simplicity!) are the biggest things to improve
in lightning atm. Having the flag just be incuded in invoices and not
need to be gossiped seems simpler to me; and I think endpoint-only
merging is better for reliability too. Eg, if you find candidate routes:
A -> B -> M -- actual directed capacity $6
A -> C -> M -- actual directed capacity $5.50
M -> E -> F -- actual directed capacity $6
A -> X -> F -- actual directed capacity $7
and want to send $9 form A to F, you might start by trying to send
$5 via B and $4 via C.
With endpoint-only merging you'd do:
$5 via A,B,M,E,F -- partial success
$4 via A,C,M,E -- failure
$4 via A,X,F -- payment completion
whereas with in-route merging, you'd do:
$5 via A,B,M -- held
$4 via A,C,M -- to be continued
$9 via M,E -- both partial payments fail
which seems a fair bit harder to incrementally recover from.
> Granted, current `fee_base_msat` across the network is very low currently.
> So I do not object to restricting merge points to ultimate payees.
> If fees rise later, we can revisit this.
So, while we already agree on the approach to take, I think the above
provides an additional rationale :)
Cheers,
aj

2023-06-09 12:52:21

- reply

📅 Original date posted:2018-11-08
📝 Original message:
On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote:
> > A node, via their node_announcement,
> Most implementations today will ignore node announcements from nodes that
> don't have any channels, in order to maintain the smallest routing set
> possible (no zombies, etc). It seems for this to work, we would need to undo
> this at a global scale to ensure these announcements propagate?
Having incoming capacity from a random node with no other channels doesn't
seem useful though? (It's not useful for nodes that don't have incoming
capacity of their own, either)
Cheers,
aj

2023-06-09 12:52:19

- reply

📅 Original date posted:2018-11-08
📝 Original message:
On Wed, Nov 07, 2018 at 06:40:13PM -0800, Jim Posen wrote:
> can simply close the channel. So if I'm charging for liquidity, I'd actually
> want to charge for the amount (in mSAT/BTC) times time.
So perhaps you could make a market here by establishing a channel saying
that
"I'll pay 32 msat per 500 satoshi per hour for the first 3 days"
When you open the channel with 500,000 satoshi donated by the other guy,
you're then obliged to transfer 32 satoshi every hour to the other guy
for three days (so a total of 14c or so).
If the channel fails beforehand, they don't get paid; if you stop
paying you can still theoretically do a mutual close.
Maybe a complicated addition to the protocol though?
Cheers,
aj

2023-06-09 12:52:06

- reply

📅 Original date posted:2018-11-05
📝 Original message:
On Mon, Nov 05, 2018 at 01:05:17AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > And it just doesn't work unless you give over uniquely identifying
> > information. AJ posts to r/bitcoin demonstrating payment, demanding his
> > goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes
> > the same proof.
> Technically speaking, all that AJ in Australia needs to show is that he or she knows, the private key behind the public key that is indicated on the invoice.
Interesting. I think what you're saying is that with secp256k1 preimages
(with decorrelation), if you have the payment hash Q, then the payment
preimage q (Q=q*G) is only known to the payee and the payer (and not
any intermediaries thanks to decorrelation), so if you see a statement
m="This invoice has been paid but not delivered as at 2018-11-05"
signed by "Q" (so, some s,R s.t. s*G = R + H(Q,R,m)*Q) then that means
either the payee signed it, in which case there's no dispute, or the
payer signed it... And that's publicly verifiable with only the original
invoice information (ie "Q").
(I don't think there's any need for multiple rounds of signatures)
FWIW, I don't see reddit as a particularly viable "court"; there's
no way for reddit to tell who's actually right in a dispute, eg if I
say blockstream didn't send stickers I paid for, and blockstream says
they did; ie there's no need for a sock puppet in the above scenario,
blockstream can just say "according to our records you signed for
delivery, stop whinging". (And if we both agree that it did or didn't
arrive, there's no need to post cryptographic proofs to reddit afaics)
I think there's maybe four sorts of "proof of payment" people might
desire:
0) no proof: "completely" deniable payments (donations?)
1) shared secret: ability to prove directly to the payee that an
invoice was paid (what we have now)
2) signed payment: ability to prove to a different business unit of
the payee that payment was made, so that you can keep all the
secrets in the payment-handling part, and have the service-delivery
part not be at risk for losing all your money
3) third-party verifiable: so you can associate a payment with real
world identity information, and take them to court (or reddit) as a
contract dispute; needs PKI infrastructure so you can be confident
the pubkey maps to the real world people you think it does, etc
Cheers,
aj

2023-06-09 12:52:04

- reply

📅 Original date posted:2018-11-04
📝 Original message:
On Sun, Nov 04, 2018 at 01:30:48PM +1030, Rusty Russell wrote:
> I'm not sure. Jonas Nick proposed a scheme, which very much assumes
> Schnorr AFAICT:
> Jonas Nick wrote:
> > How I thought it would work is that the invoice would contain a
> > Schnorr nonce R.
(Note this means the "invoice" must be unique for each payment)
> > Then the payer would construct s*G = R +
> > H(payee_pubkey,R,"I've bought 5 shirts shipped to Germany")*G. Then
> > the payer builds the scriptless script payment path such that when the
> > payee claims, the payer learns s and thus has a complete
> > signature. However, that doesn’t work with recurrent payments because
> > the payee can use the nonce only once.
So that's totally fine to do however you receive the "s" value -- the
message that's getting the Schnorr signature isn't a valid bitcoin
transaction, so it's something that only needs to be validated by
BOLT-aware courts.
I also think you can get recurrent payments easily by extending the
verification algorithm. Basically instead of Verify(m,P,sig) have
Verify(m,P,n,sig) to verify you've made n payments of the invoice "m".
Construct "m" to include the postimage X = H(pre,1000) which indicates
"pre" has been hashed 1000 times, so X = H(H(pre,1000-n),n).
Calculate the original signature as:
s = r + H(P,R,m+X)*p
and verify that n payments have been made by checking:
Verify(m,P,n,(s,R,rcpt)) :: s*G = R + H(P,R,m+H(rcpt,n))*P
You'd provide s,R,X when setting up the subscription, then reveal the
preimage to X, the preimage to the preimage of X etc on each payment.
(Maybe shachain would work here?)
I think that approach is independent of using sha256/secp256k1 for
preimages over lightning too.
> I would probably enhance this to include a nonce, which allows for AMP
> (you have to xor the AMP payments to get the nonce):
> R + H(payee_pubkey,R,"I've bought 5 shirts shipped to Germany",NONCE)*G
R is already a unique nonce under the hash here, so I don't think a
second one adds any value fwiw.
> > I think it makes sense to think of proof-of-payment in terms of a
> > verification algorithm (that a third party court could use), that takes:
> >
> > m - the invoice details, eg
> > "aj paid $11 for stickers to be delivered to Australia"
> > P - the pubkey of the vendor
> > sig - some signature
> >
> > With the current SHA256 preimages, you can make sig=(R,s,pre)
> > where the sig is valid if:
> >
> > s*G = R + H(P,R,m+SHA256(pre))*P
> >
> > If you share R,s,SHA256(pre) beforehand, the payer can tell they'll have
> > a valid signature if they pay to SHA256(pre). That's a 96B signature,
> > and it requires "pre" be different for each sale, and needs pre-payment
> > interactivity to agree on m and communicate R,s back to the payer.
> For current-style invoices (no payer-supplied data), the payee knows
> 'm', so no interactivity needed, which is nice.
I'm looking at it as needing interactivity to determine m prior to
the payment going through -- the payer needs to send through "aj" and
"Australia" in the example above, before the payee can generate s,R to
send back, at which point the payer can make the payment knowing they'll
either get a cryptographic proof of payment or a refund.
> In the payer-supplied data case, I think 'm' should include a signature
> for a key only the payer knows: this lets them prove *they* made the
> payment.
I don't object to that, but I think it's unnecessary; as long as there
was a payment for delivery of the widget to "aj" in "Australia" does it
matter if the payment was technically made by "aj" by "Visa on behalf
of aj" or by "Bank of America on behalf of Mastercard on behalf of aj's
friend who owed him some money" ?
> How does this interact with AMP, however?
The way I see it is they're separate: you have a way of getting the
preimage back over lightning (which is affected by AMP), and you have a
way of turning a preimage into a third-party-verifiable PoP (with
Schnorr or whatever).
(That might not be true if there's a clever way of safely feeding the
nonce R back, so that you can go straight from a generic offer to an
accepted payment with proof of payment)
> > With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),
> > and needing to communicate an R to the payer initially, who can then
> > calculate S and send "m" along with the payment.
> OK, I buy that.
Crap, do I need to give you proof of payment for it now? :)
> > Maybe it makes sense to disambiguate the term "invoice" -- when you don't
> > know who you might be giving the goods/service to, call it an "offer",
> > which can be a write-once/accept-by-anyone deal that you just leave on
> > a webpage or your email signature; but an "invoice" should be specific
> > to each individual payment, with a "receipt" provided once an invoice
> > is paid.
> "offer" is a good name, since I landed on the same one while thinking
> about this too :)
Yay!
> > It seems to me like there are three levels that could be implemented:
> >
> > - laolu/conner: ("low AMP" ?)
> > works with sha256
> > some privacy improvement
> > loses proof-of-payment
> > can't claim unless all payments arrive
>
> Yep.
>
> > - just send multiple payments with the same hash:
> > works with sha256
> > privacy not improved much (some intermediary nodes no longer know
> > full invoice value)
> > can claim partial payments as soon as they arrive
> > accepting any partial payment provides proof-of-payment
>
> Interestingly, if vendor takes part payment, rest can be stolen by
> intermediaries.
Or you could just see a $5 bill, send $0.50 through, and wait to see
if the take the partial payment immediately before even trying the
remaining $4.50.
> > - secp256k1: ("high AMP" ?)
> > needs secp256k1 preimages
> > works fine with decorrelation improving privacy at every step
> > can set it up so can only claim once all partial payments arrive
> > accepting partial payment provides proof-of-payment
> Yes. Though I'm not sure exactly how this works with your scheme
> above...
Vendor -> *: "I sell widgets for 0.01 BTC, my pubkey is P"
Customer -> Vendor: "I want to buy a widget"
Vendor -> Customer: "Here's an R value"
Customer: calculates S = R + H(P,R,"send $me a widget at $address")*P
Customer -> Vendor: "here's 0.01 BTC for s corresponding to S, my
details are R, $me, $address"
Vendor: looks up r for R=r*G, calculates s = r + H(P,R,"send $me a
widget at $address")*p, checks S=s*G
Vendor -> Customer: <accepts payment, revealing s>
Customer -> Court: reveals the invoice ("send $me a widget...") and the
signature by Vendor's pubkey P, (s,R)
I think the way to do secp256k1 AMP with that is that when sending
through the payment is for the customer to send three payments to the
Vendor conditional on preimages for A,B,C calculated as:
A = S + H(1,secret)*G
B = S + H(2,secret)*G
C = S + H(3,secret)*G
where "secret" is your xor of info from each of the three message hashes.
> > In theory, both "just send multiple payments" and "secp256k1" could have
> > splitting and joining at any hop, if we could encode the instructions
> > on how to do that in the onion message; joining is probably easy, but
> > splitting seems like it might be hard?
> I don't think so. If you can join two payments, it wasn't private?
Sorry, I mean "source-directed splits and joins", so rather than
your source routing being a linear "me -> A -> B -> C -> D -> you",
you specify a graph: "me -> A -> B,E ; B -> C ; E -> F -> G ; C,G ->
D -> you" so you tell "A" how to split the payment into two new routes,
and tell "D" to join two payments and continue it on. The ECC part works
fine for that, but the onion routed messages seem difficult and probably
not worth considering for spec v1.1.
> Note: if we need an interaction message for BOLT11 features we want in
> future[1], then it has the advantage that it decouples the bolt11
> features from changing preimages to secp256k1. That makes this question
> *critical* for the Summit next week.
>
> Thanks!
> Rusty.
>
> [1] If we're not careful we're going to implement HORNET so we can pass
> arbitrary messages around, which means we want to start charging for
> them to prevent spam, which means we reopen the pre-payment debate, and
> need reliable error messages...
Could leave the interactivity to the "web store" layer, eg have a BOLT
11 v1.1 "offer" include a url for the website where you go an enter your
name and address and whatever other info they need, and get a personalised
BOLT 11 v1.1 "invoice" back with payment-hash/nonce/signature/whatever?
Cheers,
aj

2023-06-09 12:52:02

- reply

📅 Original date posted:2018-11-03
📝 Original message:
On Fri, Nov 02, 2018 at 03:45:58PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:
> >> There's been some discussion of what the lightning payment flow
> >> might look like in the future, and I thought I'd try to look forwards so
> >> we can avoid painting ourselves into a corner now. I haven't spent time
> >> on concrete design and implementation to be sure this is correct,
> >> however.
> > I think I'd like to see v1.1 of the lightning spec include
> > experimental/optional support for using secp256k1 public/private keys
> > for payment hashes/preimages. That assumes using either 2-party ECDSA
> > magic or script magic until it's viable to do it via Schnorr scriptless
> > scripts, but that seems like it's not totally infeasible?
> Not totally infeasible, but since every intermediary needs to support
> it, I think we'd need considerable buy-in before we commit to it in 1.1.
"every intermediary" just means "you have to find a path where every
channel supports it"; nodes/channels that aren't in the route you choose
aren't a problem, and can still pass on the gossiped announcements,
I think?
> > I think the
> > components would need to be:
> > - invoices: will the preimage for the hash be a secp256k1 private key
> > or a sha256 preimage? (or payer's choice?)
> From BOLT11:
> The `p` field supports the current 256-bit payment hash, but future
> specs could add a new variant of different length, in which case
> writers could support both old and new, and old readers would ignore
> the one not the correct length.
> So the plan would be you provide two `p` fields in transition.
Yeah, that sounds workable.
> > - channel announcements: do you support secp256k1 for hashes or just
> > sha256?
> Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support
> secp256k1 with Schnorr". You need a continuous path of channels with
> the same feature.
I don't think that's correct: whether it's 2p-ecdsa, Schnorr or script
magic only matters for the two nodes directly involved in the channel
(who need to be able to understand the commitment transactions they're
signing, and extract the private key from the on-chain tx if the channel
gets unilaterally closed). For everyone else, they just need to know that
they can put in a public key based HTLC, and get back the corresponding
private key when the HTLC goes through.
It's also (theoretically) upgradable afaics: if two nodes have a channel
that supports 2p-ecdsa, and eventually both upgrade to support segwit
v1 scriptless schnorr sigs or whatever, they just need to change the
addresses they use in new commitment txs, even for existing HTLCs.
> > Even if you calculate r differently, I don't think you can do this
> > without Bob and Alice interacting to get the nonce R prior to sending
> > the transaction, which seems effectively the same as having dynamic
> > invoice hashes, though.
> I know Andrew Poelstra thought it was possible, so I'm going to leave a
> response to him :)
AFAICT, in general, if you're going to have n signatures with a public
key P, you need to generate the n R=r*G values from n*32B worth of random data,
that's previously unknown to the signature recipients. If you've got
less than that, then you will have calculated each R by doing something
like based on <n*32B of data you've been given:
R = a*R1 + b*R2 + ..
and the n signatures you eventually receive will give you n simultaneous
linear equations along the lines of:
s = (a*r1 + b*r2 + c*r3 + ..) + H(..)*p
with <= n unknowns (p and less than n r1,r2,.. values). (If you don't
known the values a,b,c you won't be able to calculate the R values for
your signatures in the first place)
Willing to be surprised by a different approach, but I'm pretty
skeptical...
I think it makes sense to think of proof-of-payment in terms of a
verification algorithm (that a third party court could use), that takes:
m - the invoice details, eg
"aj paid $11 for stickers to be delivered to Australia"
P - the pubkey of the vendor
sig - some signature
With the current SHA256 preimages, you can make sig=(R,s,pre)
where the sig is valid if:
s*G = R + H(P,R,m+SHA256(pre))*P
If you share R,s,SHA256(pre) beforehand, the payer can tell they'll have
a valid signature if they pay to SHA256(pre). That's a 96B signature,
and it requires "pre" be different for each sale, and needs pre-payment
interactivity to agree on m and communicate R,s back to the payer.
With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),
and needing to communicate an R to the payer initially, who can then
calculate S and send "m" along with the payment.
Maybe it makes sense to disambiguate the term "invoice" -- when you don't
know who you might be giving the goods/service to, call it an "offer",
which can be a write-once/accept-by-anyone deal that you just leave on
a webpage or your email signature; but an "invoice" should be specific
to each individual payment, with a "receipt" provided once an invoice
is paid.
AMP:
> I think a general scheme is: payer creates a random group-marker, sends
> <group-marker><32-byte-randomness>[encrypted data...] in each payment.
> Receipient collects payments by <group-marker>, xoring the
> <32-byte-randomness>; if that xor successfully decrypts the data, you've
> got all the pieces.
>
> (For low-AMP, you use payment_hash as <group-marker>, and just use
> SHA256(<xor-of-all-randomness><32-byte-randomness>) as the per-payment
> preimage so no [encrypted data] needed).
Hmm, right, I've got decorrelation and AMP combined in my head. I'm also
a bit confused about what exactly you mean by "low-AMP"...
Rereading through the AMP threads, Christian's post makes a lot of sense
to me:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001023.html
I'm not really seeing the benefits in complicated AMP schemes without
decorrelation...
It seems to me like there are three levels that could be implemented:
- laolu/conner: ("low AMP" ?)
works with sha256
some privacy improvement
loses proof-of-payment
can't claim unless all payments arrive
- just send multiple payments with the same hash:
works with sha256
privacy not improved much (some intermediary nodes no longer know
full invoice value)
can claim partial payments as soon as they arrive
accepting any partial payment provides proof-of-payment
- secp256k1: ("high AMP" ?)
needs secp256k1 preimages
works fine with decorrelation improving privacy at every step
can set it up so can only claim once all partial payments arrive
accepting partial payment provides proof-of-payment
In theory, both "just send multiple payments" and "secp256k1" could have
splitting and joining at any hop, if we could encode the instructions
on how to do that in the onion message; joining is probably easy, but
splitting seems like it might be hard?
Cheers,
aj

2023-06-09 12:52:01

- reply

📅 Original date posted:2018-11-02
📝 Original message:
On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:
> There's been some discussion of what the lightning payment flow
> might look like in the future, and I thought I'd try to look forwards so
> we can avoid painting ourselves into a corner now. I haven't spent time
> on concrete design and implementation to be sure this is correct,
> however.
I think I'd like to see v1.1 of the lightning spec include
experimental/optional support for using secp256k1 public/private keys
for payment hashes/preimages. That assumes using either 2-party ECDSA
magic or script magic until it's viable to do it via Schnorr scriptless
scripts, but that seems like it's not totally infeasible? I think the
components would need to be:
- invoices: will the preimage for the hash be a secp256k1 private key
or a sha256 preimage? (or payer's choice?)
- channel announcements: do you support secp256k1 for hashes or just
sha256?
- node features: how do you support secp256k1? not at all (default),
via 2p-ecdsa, via script magic, (eventually) via schnorr, ...?
I think this is (close to) a necessary precondition for payment
decorrelation, AMP, and third-party verifiable proof-of-payment.
> Desired Status
> --------------
> Ideally, you could create one invoice which could be paid arbitrary many
> times, by different individuals. eg. "My donation invoice is on my web
> page", or "I've printed out the invoice for a widget and stuck it to the
> widget", or "Pay this invoice once a month please".
>
> Also, you should be able to prove you've paid, in a way I can't just
> copy the proof and claim I paid, too, even if I'm the merchant, and that
> you agreed to my terms, eg. "I'm paying for 500 widgets to be shipped to
> Rusty in Australia".
So, I think at a high level the logic here goes:
1. Alice: "Buy a t-shirt from me for $5!"
2. Bob: "Alice, I want to buy a t-shirt from you, here's $5"
3. Alice: "Receipt: Bob bought a t-shirt from me"
4. Bob: "Your Honour, here's my receipt from Alice for a t-shirt, please
make her deliver on it!"
Going backwards; for the last step to be useful, the receipt has to be
a signature with the Alice's public key -- if it were anything short of
that, Alice will claim Bob could have just made up all the numbers. For a
Schnorr sig, that means (R,s) with the vendor choosing R and not revealing
R's preimage as that would reveal their private key.
If both vendor and customer know R, then to get the signature, you need
the private key holder to reveal s which is just revealing the secp256k1
private key corresponding to S, calculated as:
S = R + H(P,R,"Bob bought a $5 t-shirt from me")*P
where P is Alice's public key. If R is calculated via the Schnorr BIP's
recommendation, then r = H(p, "Bob bought a $5 t-shirt from me") -- ie,
based on the private key and the message being signed.
Even if you calculate r differently, I don't think you can do this
without Bob and Alice interacting to get the nonce R prior to sending
the transaction, which seems effectively the same as having dynamic
invoice hashes, though.
Maybe querying for a nonce through the lightning network would make
sense though, which would allow the "invoice" to be static, and all the
dynamic things would be via lightning p2p? That step could perhaps be
combined with the 0 satoshi payment probes that Fabrice proposes in
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html
but I think replying with a public nonce value would need a new message
type of some sort?
I think AMP is independent, other than also using secp256k1 preimages
rather than SHA256. I think AMP splits and joins are just:
- if you're joining incoming payments, don't forward until you've
got all the HTLCs, and ensure you can generate the secret for each
incoming payment from the single outgoing payment
- if you're splitting an incoming payment into many outgoing payments,
ensure you can claim the incoming payment from *any* outgoing
payments' secret
Which I think in practice just means knowing x_i for each input, and
y_j for each output other than the first, and verifying:
I_i = O_1 + x_i*G
O_j = O_1 + y_j*G
(this gives I_i = O_j + (x_i-y_j)*G and the corresponding secret being
i_i = o_j + x_i - y_j) allowing you to claim all incoming HTLCs given
the secret from any outgoing HTLC)
Cheers,
aj

2023-06-09 12:51:58

- reply

📅 Original date posted:2018-11-07
📝 Original message:
On Wed, Nov 07, 2018 at 02:26:29AM +0000, Gert-Jaap Glasbergen wrote:
> > Otherwise, if you're happy accepting 652 satoshis, I don't see why you
> > wouldn't be happy accepting an off-chain balance of 652.003 satoshis;
> > you're no worse off, in any event.
> I wouldn’t be worse off when accepting the payment, I agree. I can safely ignore whatever fraction was sent if I don’t care about it anyway. The protocol is however expecting (if not demanding) me to also route payments with fractions, provided they are above the set minimum. In that case I’m also expected to send out fractions. Even though they don’t exist on-chain, if I send a fraction of a satoshi my new balance will be 1 satoshi lower on-chain since everything is rounded down.
But that's fine: suppose you want everything divided up into lots of
1 satoshi, and you see 357.719 satoshis coming in and 355.715 satoshis
going out. Would you have accepted 357 satoshis going in (rounded down)
and 356 satoshis going out (rounded up)? If so, you're set. If not,
reject the HTLC as not having a high enough fee.
Yes, you're still expected to send fractions of a satoshi around, but
that doesn't have to affect your accounting (except occassionally to
your benefit when you end up with a thousand millisatoshis).
I think you can set your fee_base_msat to 2000 msat to make sure every
HTLC you route pays you at least a satoshi, even with losses from
rounding. If you're willing to find yourself having routed payments for
free (after rounding), then setting it to 1000 msat should work too.
> > Everything in open source is configurable by end users: at worst, either
> > by them changing the code, or by choosing which implementation to use…
> Well, yes, in that sense it is. But the argument was made that it’s too complex for average users to understand: I agree there, [...]
Then it's not really a good thing for different implementations to have
as a differentiator...
Cheers,
aj

2023-06-09 12:51:57

- reply

📅 Original date posted:2018-11-06
📝 Original message:
On Tue, Nov 06, 2018 at 10:22:56PM +0000, Gert-Jaap Glasbergen wrote:
> > On 6 Nov 2018, at 14:10, Christian Decker <decker.christian at gmail.com> wrote:
> > It should be pointed out here that the dust rules actually prevent us
> > from creating an output that is smaller than the dust limit (546
> > satoshis on Bitcoin). By the same logic we would be forced to treat the
> > dust limit as our atomic unit, and have transferred values and fees
> > always be multiples of that dust limit.
> I don’t follow the logic behind this.
I don't think it quite makes sense either fwiw.
> > 546 satoshis is by no means a tiny amount anymore, i.e., 546'000 times
> > the current minimum fee and value transferred. I think we will have to
> > deal with values that are not representable / enforceable on-chain
> > anyway, so we might as well make things more flexible by keeping
> > msatoshis.
> I can see how this makes sense. If you deviate from the realms of what is possible to enforce on chain,
What's enforcable on chain will vary though -- as fees rise, even if the
network will still relay your 546 satoshi output, it may no longer be
economical to claim it, so you might as well save fees by not including
it in the first place.
But equally, if you're able to cope with fees rising _at all_ then
you're already okay with losing a few dozen satoshis here and there, so
how much difference does it make if you're losing them because fees
rose, or because there was a small HTLC that you could've claimed in
theory (or off-chain) but just can't claim on-chain?
> Again, I am not advocating mandatory limitations to stay within base layer enforcement, I am advocating _not_ making it mandatory to depart from it.
That seems like it adds a lot of routing complexity for every node
(what is the current dust level? does it vary per node/channel? can I
get a path that accepts my microtransaction HTLC? do I pay enough less
in fees that it's better to bump it up to the dust level?), and routing
is already complex enough...
You could already get something like this behaviour by setting a high
"fee_base_msat" and a low "fee_proportional_millionths" so it's just
not economical to send small transactions via your channel, and a
corresponding "htlc_maximum_msat" to make sure you aren't too cheap at
the top end.
Otherwise, if you're happy accepting 652 satoshis, I don't see why you
wouldn't be happy accepting an off-chain balance of 652.003 satoshis;
you're no worse off, in any event.
> I would not envision this to be even configurable by end users. I am just advocating the options in the protocol so that an implementation can choose what security level it prefers.
Everything in open source is configurable by end users: at worst, either
by them changing the code, or by choosing which implementation to use...
Cheers,
aj

2023-06-09 12:51:48

- reply

📅 Original date posted:2018-10-10
📝 Original message:
On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. [...]
Maybe this is obvious, but in case it's not, re: the locktime-based
sequencing in eltoo:
"any number above 0.500 billion is interpreted as a UNIX timestamp, and
with a current timestamp of ~1.5 billion, that leaves about 1 billion
numbers that are interpreted as being in the past"
I think if you had a more than a 1B updates to your channel (50 updates
per second for 4 months?) I think you could reset the locktime by rolling
over to use new update keys. When unilaterally closing you'd need to
use an extra transaction on-chain to do that roll-over, but you'd save
a transaction if you did a cooperative close.
ie, rather than:
[funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc]
or
[funding] -> [coop close / re-fund] -> [coop close]
you could have:
[funding] -> [update 1B] -> [update 23,310,561 with key2] -> [HTLCs]
or
[funding] -> [coop close]
You could repeat this when you get another 1B updates, making unilateral
closes more painful, but keeping cooperative closes cheap.
Cheers,
aj

2023-06-09 12:50:36

- reply

📅 Original date posted:2018-05-14
📝 Original message:
On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote:
> > The big concern I have with _NOINPUT is that it has a huge failure
> > case: if you use the same key for multiple inputs and sign one of them
> > with _NOINPUT, you've spent all of them. The current proposal kind-of
> > limits the potential damage by still committing to the prevout amount,
> > but it still seems a big risk for all the people that reuse addresses,
> > which seems to be just about everyone.
> If I can convince you to sign with SIGHASH_NONE, it's already a problem
> today.
So, I don't find that very compelling: "there's already a way to lose
your money, so it's fine to add other ways to lose your money". And
again, I think NOINPUT is worse here, because a SIGHASH_NONE signature
only lets others take the coin you're trying to spend, messing up when
using NOINPUT can cause you to lose other coins as well (with caveats).
> [...]
> In a world where SIGHASH_NONE didn't exist, this might be an argument :)
I could see either dropping support for SIGHASH_NONE for segwit
v1 addresses, or possibly limiting SIGHASH_NONE in a similar way to
limiting SIGHASH_NOINPUT. Has anyone dug through the blockchain to see
if SIGHASH_NONE is actually used/useful?
> That was also suggested by Mark Friedenbach, but I think we'll end up
> with more "magic key" a-la Schnorr/taproot/graftroot and less script in
> future.
Taproot and graftroot aren't "less script" at all -- if anything they're
the opposite in that suddenly every address can have a script path.
I think NOINPUT has pretty much the same tradeoffs as taproot/graftroot
scripts: in the normal case for both you just use a SIGHASH_ALL
signature to spend your funds; in the abnormal case for NOINPUT, you use
a SIGHASH_NOINPUT (multi)sig for unilateral eltoo closes or watchtower
penalties, in the abnormal case for taproot/graftroot you use a script.
> That means we'd actually want a different Segwit version for
> "NOINPUT-can-be-used", which seems super ugly.
That's backwards. If you introduce a new opcode, you can use the existing
segwit version, rather than needing segwit v1. You certainly don't need
v1 segwit for regular coins and v2 segwit for NOINPUT coins, if that's
where you were going?
For segwit v0, that would mean your addresses for a key "X", might be:
[pubkey] X
- not usable with NOINPUT
[script] 2 X Y 2 CHECKMULTISIG
- not usable with NOINPUT
[script] 2 X Y 2 CHECKMULTISIG_1USE_VERIFY
- usable with NOINPUT (or SIGHASH_ALL)
CHECKMULTISIG_1USE_VERIFY being soft-forked in by replacing an OP_NOP,
of course. Any output spendable via a NOINPUT signature would then have
had to have been deliberately created as being spendable by NOINPUT.
For a new segwit version with taproot that likewise includes an opcode,
that might be:
[taproot] X
- not usable with NOINPUT
[taproot] X or: X CHECKSIG_1USE
- usable with NOINPUT
If you had two UTXOs (with the same value), then if you construct
a taproot witness script for the latter address it will look like:
X [X CHECKSIG_1USE] [sig_X_NOINPUT]
and that signature can't be used for addresses that were just intending
to pay to X, because the NOINPUT sig/sighash simply isn't supported
without a taproot path that includes the CHECKSIG_1USE opcode.
In essence, with the above construction there's two sorts of addresses
you generate from a public key X: addresses where you spend each coin
individually, and different addresses where you spend the wallet of
coins with that public key (and value) at once; and that remains the
same even if you use a single key for both.
I think it's slightly more reasonable to worry about signing with NOINPUT
compared to signing with SIGHASH_NONE: you could pretty reasonably setup
your (light) bitcoin wallet to not be able to sign (or verify) with
SIGHASH_NONE ever; but if you want to use lightning v2, it seems pretty
likely your wallet will be signing things with SIGHASH_NOINPUT. From
there, it's a matter of having a bug or a mistake cause you to
cross-contaminate keys into your lightning subsystem, and not be
sufficiently protected by other measures (eg, muSig versus checkmultisig).
(For me the Debian ssh key generation bug from a decade ago is sufficient
evidence that people you'd think are smart and competent do make really
stupid mistakes in real life; so defense in depth here makes sense even
though you'd have to do really stupid things to get a benefit from it)
The other benefit of a separate opcode is support can be soft-forked in
independently of a new segwit version (either earlier or later).
I don't think the code has to be much more complicated with a separate
opcode; passing an extra flag to TransactionSignatureChecker::CheckSig()
is probably close to enough. Some sort of flag remains needed anyway
since v0 and pre-segwit signatures won't support NOINPUT.
Cheers,
aj

2023-06-09 12:50:36

- reply

📅 Original date posted:2018-05-08
📝 Original message:
On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote:
> Given the general enthusiasm, and lack of major criticism, for the
> `SIGHASH_NOINPUT` proposal, [...]
So first, I'm not sure if I'm actually criticising or playing devil's
advocate here, but either way I think criticism always helps produce
the best proposal, so....
The big concern I have with _NOINPUT is that it has a huge failure
case: if you use the same key for multiple inputs and sign one of them
with _NOINPUT, you've spent all of them. The current proposal kind-of
limits the potential damage by still committing to the prevout amount,
but it still seems a big risk for all the people that reuse addresses,
which seems to be just about everyone.
I wonder if it wouldn't be ... I'm not sure better is the right word,
but perhaps "more realistic" to have _NOINPUT be a flag to a signature
for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
so that it's fundamentally not possible to trick someone who regularly
reuses keys to sign something for one input that accidently authorises
spends of other inputs as well.
Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
wouldn't be equally effective for the forseeable usecases? That would
ensure that a _NOINPUT signature is only ever valid for keys deliberately
intended to be single use, rather than potentially valid for every key.
It would be ~34 witness bytes worse than being able to spend a Schnorr
aggregate key directly, I guess; but that's not worse than the normal
taproot tradeoff: you spend the aggregate key directly in the normal,
cooperative case; and reserve the more expensive/NOINPUT case for the
unusual, uncooperative cases. I believe that works fine for eltoo: in
the cooperative case you just do a SIGHASH_ALL spend of the original
transaction, and _NOINPUT isn't needed.
Maybe a different opcode maybe makes sense at a "philosophical" level:
normal signatures are signing a spend of a particular "coin" (in the
UTXO sense), while _NOINPUT signatures are in some sense signing a spend
of an entire "wallet" (all the coins spendable by a particular key, or
more accurately for the current proposal, all the coins of a particular
value spendable by a particular key). Those are different intentions,
so maybe it's reasonable to encode them in different addresses, which
in turn could be done by having a new opcode for _NOINPUT.
A new opcode has the theoretical advantage that it could be deployed
into the existing segwit v0 address space, rather than waiting for segwit
v1. Not sure that's really meaningful, though.
Cheers,
aj

2023-06-09 12:49:30

- reply

📅 Original date posted:2018-03-13
📝 Original message:
On Tue, Mar 13, 2018 at 06:07:48PM +0100, René Pickhardt via Lightning-dev wrote:
> Hey Christian,
> I agree with you on almost anything you said. however I disagree that in the
> lightning case it produces just another double spending. I wish to to emphasize
> on my statement that the in the case with lightning such a 51% attack can steal
> way more BTC than double spending my own funds.
I think you can get a simpler example:
* I setup a channel, funding it with 10 BTC (ie, balance is 100% on my side)
* Someone else sets up a channel with me, funding it with 5 BTC
(balance is 100% on their side)
* I route 5 BTC to myself from the first channel through the second:
aj -> X -> ... -> victim -> aj
* I save the state that says I own all 5BTC in the victim <-> aj channel
* I route 5 BTC to myself from the second channel throught the first:
aj -> victim -> ... -> X -> aj
* At this point I'm back to having 10 BTC (minus some small amont
of lightning fees) in the first channel
* I use 51% hashing power to mine a secret chain that uses the saved
state to close the victim<->aj channel. Once that chain is long enough
that I can claim the funds I do so. Once I have claimed the funds on
my secret chain and the secret chain has more work than the public
chain, I publish it, causing a reorg.
* At this point I still have 10 BTC in the original channel, and I have
the victim's 5 BTC.
I can parallelise this attack as well: before doing any private mining or
closing the victim's channel, I can do the same thing with another victim,
allowing me to collect old states worth many multiples of up to 10 BTC, and
mine them at once, leaving with my original 10BTC minus fees, plus n*10BTC
stolen from victims.
This becomes more threatening if you add in conspiracy theories about
there already being a miner with >51% hashpower, who has financial
interests in seeing lightning fail...
The main limitation is that it still only allows a 51% miner to steal
funds from channels they participate in, so creating channels with
identifiable entities with whom you have an existing relationship (as
opposed to picking random anonymous nodes) is a defense against this
attack. Also, if 51% of hashpower is mining in secret for an extended
period, that may be detectable, which may allow countermeasures to
be taken?
You could also look at this the other way around: at the point when
lightning is widely deployed, this attack vector seems like it gives an
immediate, personal, financial justification for large economic actors
to ensure that hash rate is very decentralised.
> In particular I could run for a decade on stable payment channels
> storing old state and at some point realizing it would be a really big
> opportunity secretly cashing in all those old transactions which can't be
> revoked.
(I'd find it surprising if many channels stayed open for a decade; if
nothing else, I'd expect deflation over that time to cause people to
want to close channels)
Cheers,
aj

2023-06-09 12:46:01

- reply

📅 Original date posted:2016-03-16
📝 Original message:
Hello lightning implementors!
(Posted to lightning-dev as well, hopefully that's fine with everyone)
Matsjj set up a repo a while ago for collaborating on documenting the
lightning protocol and gave a bunch of us admin access:
- https://github.com/lightning-core/lightning
"""I think it is a very good idea to carry all the different
implementations to one spot. I think such a repository is best suited
for it."""
- https://github.com/lightning-core/lightning/pull/4#issuecomment-151778273
I think the layout is a bit too nested (which makes sense coming from
the Java implementor, I guess? :) and I think it'd be good to have a
simple way to decide how to move ideas into/through the repo, without
making it a place where there's any point trying to politicise proposals.
(It's kind of telling that something's wrong when even matsjj hasn't
been able to get his pull requests accepted :)
Anyway I've taken Rusty's couple of BOLT proposals as well as the shachain
design txt and rearranged them in a way I think makes sense:
- https://github.com/ajtowns/lightning-core/tree/rusty
What do you guys think?
I hear there's totally going to be released code out by
northern-hemisphere summer, so documenting the protocols/standards is
only going to get more pressing...
My inclination is to add:
- matsjj's pull requests [0]
- the anonymous "R", via private key reveal stuff [1]
- Joseph's 2-of-3 Instant Escrow [2]
as additional "early drafts". Probably things from Rusty's "Deployable
Lightning" paper (like the HTLC scripts), or the "elkrem" scheme, or
Nicholas Dorier's "backward deterministic [revocation] Value" stuff
would be good too...
Cheers,
aj
[0] thunsync: https://github.com/lightning-core/lightning/pull/2/files
thunenc: https://github.com/lightning-core/lightning/pull/3/files
thungoss: https://github.com/lightning-core/lightning/pull/4
[1] rprivkey:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000314.html
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
[2] escrow23: http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html

2023-06-09 12:45:58

- reply

📅 Original date posted:2016-03-09
📝 Original message:
>From IRC:
<rusty> Hmm, what term should I use in documentation for the
failure mode where a node uses too tight a timeout and ends up
paying out an outgoing HTLC but unable to redeem the incoming
HTLC?
<rusty> "one-sided redemption" is what I came up with, but it's not very
punchy for "you screwed up and lost money"
That's too loose a timeout, isn't it? You choose the timeout for your
outgoing payment, so if the incoming timeout runs out, your outgoing
timeout was too long.
I'd just call it "avoiding timeout on incoming HTLC when forwarding"
or similar?
On Wed, Mar 09, 2016 at 11:13:36AM +1030, Rusty Russell wrote:
> Confusingly, we also use "revocation preimage" as the term method to
> invalidate old transactions, a private matter between pairs of nodes,
> but try to avoid abbreviating it to R.
Yeah, the lack of an obvious abbreviation for the revocation preimage
has bugged me a couple of times. What about saying we "void" the old
commitment, and use "V" as the symbol for the hash/signature/whatever?
(R for the HTLC "receipt" seems to work okay so probably good to keep
that)
Cheers,
aj

2023-06-09 12:45:53

- reply

📅 Original date posted:2016-03-18
📝 Original message:
On Mon, Mar 07, 2016 at 02:21:02PM +1030, Rusty Russell wrote:
> ### Derivation of the Shared Secret and Encryption Keys ###
> Once a node has received the initial handshake, it can derive the
> shared secret using the received `sessionpubkey` point and its own
> `sessionsecretkey` scalar using EC Diffie-Hellman.
I think this should be expanded -- I'm assuming the sessionsecretkey is
calculated as per libsecp256k1, as:
(x,y) = y.public*x.secret = x.public*y.secret = g*(x.secret*y.secret)
sha256( (2 + y%2) || x )
This is different to the NIST specification (see 5.7.1.2 in [0]) which
just uses the x coordinate of the point directly, ignoring y and not
(necessarily) hashing it.
I've added some wording for this for your consideration:
https://github.com/rustyrussell/lightning/pull/1
> While multiple choices are possible for public-key cryptography, the
> bitcoin protocol already relies on the secp256k1 elliptic curve, so
> reusing it here avoids additional dependencies.
Hmm, if secp256k1 breaks and gets deprecated, that would be a backwards
incompatible change. You could handle this with the protocol as described
by incrementing the high byte of "length" in the first message; old
clients would see that as an invalid length, >16M, and refuse the
connection; new clients could just treat it as a version byte.
Cheers,
aj
[0] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf

2023-06-09 12:45:46

- reply

📅 Original date posted:2016-02-26
📝 Original message:
On Fri, Feb 26, 2016 at 01:32:34AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I'm interested in input and in the level of receptiveness to this. If
> > there is interest, I'll write up a draft BIP in the next couple days.
> .. I think this should probably be constructed as a new segwit script type,
> and not a base feature.
+1 to both
> The exact construction you're thinking of there isn't clear to me...
I think the idea is that you have three transactions:
anchor:
input: whatever
output:
- single output, spendable by 2-of-2 multisig
- [possibly others as well, whatever]
commitment:
input: anchor
outputs:
1. payment to A
2. payment to B
3. HTLC to A on R1, timeout T1
4. HTLC to A on R2, timeout T2
5. HTLC to B on R3, timeout T3
...
penalty:
inputs:
all the outputs from the commitment tx
outputs:
1. 99% as payment to me
2. 1% as outsourcing fee
As long as the key I use for spending each of commitment transactions
outputs is "single use" -- ie, I don't use it for other channels or
anywhere else on the blockchain, then as long as the signature commits
to the outputs it's safe afaics.
(You still have to send a lot of data to the place you're outsourcing
chain-monitoring to; all the R1,R2,R3 and T1,T2,T3 values are needed in
order to reconstruct the redeem scripts)
> one thing that comes to mind is that I think it is imperative that we
> do not deploy a without-inputs SIGHASH flag without also deploying at
> least a fee-committing sighash-all.
If the fee for commitment transactions changes regularly (eg, a new
commitment transaction is generated every few seconds/minutes, and the fee
is chosen based on whatever estimatefee returns), I think this would cause
problems -- you couldn't use a single signature to cover every revoked
commitment, you'd need one for each different fee level that you'd used
for the lifetime of the channel. Actually, the size of the commitment
transaction will differ anyway depending on how many HTLCs are open,
so even if estimatefee didn't change, the fee would still differ. So I
think commiting to a fee isn't workable for the lightning use case...
> When you do write a BIP for this its imperative that the vulnerability
> to replay is called out in bold blinking flaming text, along with the
> necessary description of how to use it safely. The fact that without
> input commitments transactions are replayable is highly surprising to
> many developers... Personally, I'd even go so far as to name the flag
> SIGHASH_REPLAY_VULNERABLE. :)
+1, though I'm not sure it's so much "vulnerable" to replay as it is
"explicitly designed" to be replayable...
Cheers,
aj

2023-06-09 12:45:46

- reply

📅 Original date posted:2016-03-01
📝 Original message:
bitcoin-dev dropped, just lightning-dev
On Mon, Feb 29, 2016 at 10:55:53AM +1030, Rusty Russell wrote:
> If each HTLC output is a p2sh[1], you need the timeout and rhash for
> each one to build the script to redeem it. In practice, there's not
> much difference between sending a watcher a tx for every commit tx and
> sending it information for every new HTLC (roughly a factor of 2).
There's a bigger saving if you've got a very active channel with
comparatively long lived HTLCs. With pre-signed transactions you have
to send:
tx 1234:
input: anchor
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 2 ; HTLC 3 ; ...
tx 1235: (HTLC 2 cleared)
input: anchor
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 4 ; ...
tx 1235: (HTLC 4 cleared)
input: anchor
outputs: Alice balance ; Bob balance ; HTLC 1 ; HTLC 3 ; HTLC 5 ; ...
...
So if you do, say 30 HTLCs per minute, but each HTLC lasts for 20 seconds,
then each HTLC appears in ~10 transactions, and you've correspondingly
got to supply 10 signatures to your outsourced claimant for each HTLC
you deal with. Comparatively, you only have to supply the R/timeout
values once per HTLC.
With SIGHASH_NOINPUT you'd still have to send all the R/timeout values
for each HTLC, but you'd only need to send a single signature for the
channel.
> So we also need to put more in the scriptPubKey for this to work; either
> the entire redeemscript, or possibly some kind of multiple-choice P2SH
> where any one of the hashes will redeem the payment.
We discussed how to recover the timeout/R values recoverable last
year fwiw, see the thread surrounding:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000058.html
I don't think there's a big problem with sending that info to a third
party who's doing transaction reclaiming; it might hurt privacy a bit.
Note that with segwit, having a visible scriptPubKey so that R is
trivially obvious isn't even possible anymore...
(If by "multiple-choice p2sh" you mean merkelized abstract syntax trees
that would let you exchange 20+4 / 32+4 bytes of R+timeout for 32 bytes
of a merkle path, which would be an improvement, but not huge. Otherwise
I think you'd have to have a new double-length script hash type; which
might not be friendly to UTXO? Though maybe two 160 bit hashes wouldn't
be out of the question, at 40 bytes versus 32 or 64?)
Cheers,
aj

2023-06-09 12:45:43

- reply

📅 Original date posted:2016-02-09
📝 Original message:
On Tue, Feb 09, 2016 at 10:09:12AM +1030, Rusty Russell wrote:
> Otherwise, if you want to do a unilateral close, there's some game
> theory as you'd rather convince the other side to do it so your own
> funds aren't locked up.
I think the options are:
a) keep the channel open
b) they close the channel unilaterally
c) you close the channel unilaterally
d) you both close the channel cooperatively
At any point, I believe the preferences are strictly: d > b > c
(b) is better than (c) because of the OP_CSV delay; and (d) is better
than (b) if you can use a lower transaction fee than you use for your
commitment transactions, or spend directly to a useful output address
(opening up a new channel eg).
If you find yourself trying to convince the other person to do (b)
to avoid doing (c) yourself, I think it's a dominating strategy to
simply do (d) -- you prefer that over (b) anyway, and they will prefer
it over (c).
With the current arrangement, I don't think your counterparty can
realistically make any threats: "you'll close the channel? okay,
that's better than me closing it!" and "you'll close the channel
unilaterally? well, that's a lot worse for you as it is for me,
so whatever".
With an OP_CSV on both sides of HTLCs, you can make a somewhat
realistic threat: "if you don't pay me $x to do a cooperative close,
I'll close unilaterally which will lock your funds up. sure you can
close unilaterally yourself, but your funds will still be locked up that
way too."
So changing seems like it would make things marginally worse, but no
better, to me.
Cheers,
aj

2023-06-09 12:45:35

- reply

📅 Original date posted:2016-01-29
📝 Original message:
On Fri, Jan 29, 2016 at 12:05:35PM +1030, Rusty Russell wrote:
> > Probably doesn't really matter, but I think it leads me to prefer Rusty's
> > construction. Might be good to have an explanation with it diagrammed
> > as an n-way tree structure though, in a similar way to how you visualise
> > the elkrem tree...
> Definitely; a 64-deep binary tree is a 64-dimensional 1x1...x1
> hypercube, but the former is less brainhurty.
Nono, you don't need hypercubes to describe shachain, just a tree.
Voila:
[attached]
(Okay, so technically it's a spanning tree for a hypercube, fine,
whatever. I guess you can kind-of see the outline of the 4d hypercube
in the picture if you look hard enough...)
In the notation I'm using, H(p||x) means "flip the xth bit from the
parent hash/seed then hash" [0]. So to get to the hash for 10 you do:
SHA256( SHA256( seed with bit 3 flipped ) with bit 1 flipped )
The subtrees are all very self-similar, and extending past 2**n just means
adding a new branch off from 0. Because it's so self-similar adding the
branch is just literally copying the existing tree, adding 2**n to all the
node values, and then adding a H(p||n) step from 0 to keep it connected.
Python code for generating the graph also attached, for whatever that's
worth. Layout gets a bit painful when you add an additional dimension to
get up to 32 nodes.
Cheers,
aj
[0] Or, alternatively and IMO preferably, append the number "x" and
hash.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shachain.png
Type: image/png
Size: 48127 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160129/2463d873/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shachain.py
Type: text/x-python
Size: 798 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160129/2463d873/attachment-0001.py>

2023-06-09 12:45:35

- reply

📅 Original date posted:2016-01-27
📝 Original message:
On Wed, Jan 27, 2016 at 01:37:04PM +1030, Rusty Russell wrote:
> 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]
Hmm, I was going to say I like it, but I'm not sure I do...
The comments in the code don't quite make sense to me, for instance,
the given examples:
0b0000: L(L(L(L(seed))))
0b0001: R(L(L(L(seed))))
0b1000: L(L(L(seed)))
should be 0, 1 and 2, I think, not 0, 1 and 8; and with four hash
operations, you've got 31 nodes not 15, and 16 leaves, not 8?
I think the pattern is:
0b0000: LLL (ie L(L(L(seed)))
0b0001: RLL (ie R(L(L(seed)))
0b0010: LL -> (0, 1)
0b0011: LRL
0b0100: RRL
0b0101: RL -> (3, 4)
0b0110: L -> (0, 1, 2, 3, 4, 5)
0b0111: LLR
0b1000: RLR
0b1001: LR -> (7, 8)
0b1010: LRR
0b1011: RRR
0b1100: RR -> (10, 11)
0b1101: R -> (7, 8, 9, 10, 11, 12)
0b1110: seed -> (0,..,13)
(Running the code translated into python gives those results too)
I don't the code is quite right either (though I may have translated
something wrong); eg if I try calling:
descend(6, 13, 2, R(seed))
I get
L(L(R(seed)))
instead of an error (since the right answer would be L(seed), which
can't be derived from R(seed)).
Personally, I think both this and shachain have the indexing backwards;
I think i=0 should match the seed, and the first hash transmitted across
the wire should be i=2^64-1, then counting down from there. This matches
the numbering used in https://en.wikipedia.org/wiki/Hash_chain fwiw.
With shachain, that gives the nice property that the only parameter
you need is the seed, you can work out the hash for any given index
directly from that, up to any arbitrary index, until you run out of
integer precision, or bits of security in your hash function.
With elkrem you can build an arbitrarily deep tree given a seed at the
conceptual level without any further parameters, but when you start
mapping that to indexes you need to know the desired height first.
This is, in essence, because L(seed) (eg) gets sent at different places
depending on the "height"; with a height of 1 it's the first value (or
third from last), with a height of 2 it's the third value (or fifth
from last), with a height of 3 it's the seventh value (or ninth from
last), etc.
Probably doesn't really matter, but I think it leads me to prefer Rusty's
construction. Might be good to have an explanation with it diagrammed
as an n-way tree structure though, in a similar way to how you visualise
the elkrem tree...
> - 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.
FWIW I think this should still be considered an R&D idea rather than
trying to release it in v1.0.
> - 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).
It's "more than one hash" not more than one /signature/, isn't it? (The
proposal was also to support 2-of-3 hashes, slightly more complicated
than just multiple hashes)
Cheers,
aj

2023-06-09 12:45:18

- reply

📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 04:37:04PM +0900, Nicolas Dorier wrote:
> By adapting an idea from gmaxwell (
> https://bitcointalk.org/index.php?topic=303088.0) it is possible to open a
> channel without suffering from malleability attack.
> The process for A to open channel with B is the following:
> * A asks B pubkey
> * A create the first commitment transaction
> * A extract the hash that B needs to sign to be able to broadcast the
> commitment
> * A asks B to sign the hash, but do not disclose the commitment
> * A broadcast the anchor
> * After confirmation, A announce the anchor to B.
A also passes the original unsigned commitment to B, who verifies that
it's in the right format (ie, can be revoked), and hashes to the hash
that he signed.
> B can't identify A's anchor before announcement because he does not know
> the P2SH of the multisig.
> Am I missing something ?
Someone other than B (ie a third party) could malleate the anchor between
broadcast and confirmation just for their own amusement.
B can't reuse pubkeys between different channels with this protocol
either, but that's good practice anyway.
>From the same forum post, using child-pays-for-parent seems plausible.
Doing:
txA: spend 6 BTC to
5 BTC to A&B
1 BTC to A
txB: spend 1 BTC from txA:1 to
0.999 BTC to A
should be pretty safe: either someone malleates txA and mines it for
0 fee; or they mine both txA+txB for 0.001 BTC fee, and txA can't be
malleated. But CPFP doesn't work yet, and segregated witness seems like
it'll happen sooner anyway?
Cheers,
aj

2023-06-09 12:45:18

- reply

📅 Original date posted:2015-11-27
📝 Original message:
On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:
> > A also passes the original unsigned commitment to B, who verifies that
> > it's in the right format (ie, can be revoked), and hashes to the hash
> > that he signed.
> No, if A pass the unsigned commitment to B then B can malleate the anchor.
Sorry, I meant the above needs to happen after the anchor's confirmed
in the blockchain (and A's told B about the anchor).
> > B can't reuse pubkeys between different channels with this protocol
> > either, but that's good practice anyway.
> Right, neither A should. If A reuse a key, then B can guess the redeem
> hash, then would identify the transaction to malleate at broadcast time,
> before A's announcement.
B will be providing a signature for a tx that:
- has the anchor as input
- has a single refund output payable to
(A && OP_CSV) | (B && OP_HASH <revoke> OP_EQUALVERIFY)
But B won't be able to guess what the <revoke> hash is, so won't be
able to correlate with potential anchor transactions at all, afaics,
even if pubkeys <A> and <B> are both known to B?
> I'd prefer seggregated witness to fix the problem cleanly, but I think that
> opening the channel as I said is a good enough workaround until it happen.
Yeah, it's 99% of the way there; I just worry about random vandalism,
personally.
Cheers,
aj

2023-06-09 12:45:17

- reply

📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 07:14:54AM +0100, Mats Jerratsch wrote:
> Another way to deal with it is to add two HTLCs to the commit, basically
> 'I pay you 1.00000001 BTC and you pay me 1 BTC, so effectively I paid
> you 1 satoshi'.
True! Doubles the cost of the HTLC if it gets published to the
blockchain though...
> One issue with this is that it increases the fees by a lot, as the
> locked up capital increases by quite a lot. It might also not
> translate that well over many hops, when fees are different in each
> direction.
I don't think number of hops matters; it only affects each channel
directly (so hop1 pays a+b one way, and b the other way; hop2 pays
a-f+c one way, c the other way; etc), a as the transaction amount,
f as b's fee, b and c arbitrary channel parameters for a/b and b/c
channels respectively.
You only have to lock up a little more than the dust amount, so call that
1c per HTLC, assume a locktime of 20 days, and a time cost of bitcoin
of 20% pa, then that's an extra cost of 0.01 of a cent per transaction.
If you're aiming for a 1% per-hop fee, you can still handle transactions
worth about a cent with that approach. If you've got a time cost of
bitcoin at about 5% pa and a lock time of 10 days, you can do a 2c
transaction with a per-hop fee of about 0.1%.
> We might want to have some special protocol for these
> payments?
I don't think that helps?
> By the way, as far as I know the dust value got increased to 5430? So
> even more of a problem for us now... (wow, that's already 2ct, don't
> think we can just disallow these, given that we promised the holy
> grail of micro payments ;) )
I don't think so? minrelayfee got increased to .05 mBTC, but that's for
1000 bytes while the dust threshold is for 546 bytes, so that's 2730
satoshi (a little under 1c at $351 USD/BTC).
According to Visa, anything less than $20 is a micropayment though, so
there's still plenty of leeway ;)
http://www.techworld.com.au/article/351015/visa_payclick_takes_paypal_micropayments/
> I also don't think just adding these to the change amount is
> sustainable. That's a thing I realized some time ago, as soon as there
> is some loop hole somewhere, there will be one guy who will move
> heaven and earth to make a profit off of it.
Yeah, and with onion routing and so on, I could be that guy!!
If you anonymously setup two channels with another node, and route a whole
bunch of dust payments to yourself, ie me1 -> them -> me2, then:
- if the HTLCs are in both txns, you can't do anything
- if the second channel's commitment unconditionally pays you for a
bunch of transactions, close the channel, and never reveal any of
the secrets. you eventually get all your money back in me1, and made
a profit in me2.
- if the first channel's commitment doesn't debit you for a bunch
of transactions, reveal the corresponding secrets in the second
channel, updating its commitment, but refuse to follow protocol to
update the transactions in the first channel, closing it, but keeping
your money.
- if txns in the second channel are credited to fees, but have HTLCs
in the first channel; close the second channel, and the txns timeout,
refunding your money, but costing the other node the sum of those
HTLCs.
Yay, more problems!
Maybe you could tweak the dual HTLC approach to make attacks unattractive:
42 satoshi from A -> B
10042 satoshi for (B && R || A && 20days CLTV)
10000 satoshi for (A && R && 15 days CLTV || B && 20days CLTV)
If it resolves on channel, fine; but if it hits the blockchain, A has to
wait 15 days even if R gets revealed to get her 3.5c back.
Not actually sure if that does any real good though...
Cheers,
aj
> 2015-11-27 4:58 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> > Anthony Towns <aj at erisian.com.au> writes:
> >> Hey,
> >>
> >> Suppose you have a lightning channel, with balances of exactly 2 BTC
> >> on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
> >> micropayment of 42 satoshi across the channel, resulting in an updated
> >> commitment that looks like:
> >>
> >> in:
> >> anchor (3.001 BTC): [yoursig theirsig redeemscript]
> >>
> >> out:
> >> 1 BTC: [pay2pubkey(theirs)]
> >> 1.99999958 BTC: [pay2pubkey(yours)]
> >> 0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
> >> timeout)]
> >>
> >> But the third output will hit the IsDust() test (less than 546 satoshi
> >> for a min relay fee of 0.01 mBTC) and the entire transaction will be
> >> rejected, so the channel can't be closed at all!
> >>
> >> This is a similar problem to sub 1-satoshi payments, but it's different
> >> in that while you can't represent them as an HTLC output, you can
> >> represent them as soon as they complete -- ie:
> >>
> >> out:
> >> 1.00000042 BTC: [pay2pubkey(theirs)]
> >> 1.99999958 BTC: [pay2pubkey(yours)]
> >>
> >> is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
> >> wouldn't be).
> >>
> >> I assume treating them much the same way is the only real option --
> >> account for them exactly in the lightning state, but just approximate the
> >> results in the actual commitments. So long as you're closing channels
> >> infrequently, losing a few hundred satoshi here and there won't matter
> >> much.
> >
> > Yes, unfortunately we'll have to have a rule to avoid producing those
> > outputs.
> >
> > I've opened https://github.com/ElementsProject/lightning/issues/14
> > so we make sure we track this.
> >
> >> Another option might be to weaken the dust protection in the network --
> >> eg if you made the dust output be
> >>
> >> 0.00000042 BTC: [(them && (R || revoke))
> >> || (you && d CSV && t CLTV)
> >> || (3 months CSV)]
> >>
> >> then anyone could clear the dust after 3 months if it weren't otherwise
> >> claimed; maybe having some dust for a finite time is okay. But it'd also
> >> mean paying to an actual (non-standard) script, rather than a scripthash,
> >> which would be annoying in its own way... And, really, adding that output
> >> to the txn would probably cost more in additional fees that it's going
> >> to pay you in any case.
> >
> > Agreed, we'll just cull those outputs and let them go to fees.

2023-06-09 12:45:16

- reply

📅 Original date posted:2015-11-27
📝 Original message:
Hey,
Suppose you have a lightning channel, with balances of exactly 2 BTC
on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
micropayment of 42 satoshi across the channel, resulting in an updated
commitment that looks like:
in:
anchor (3.001 BTC): [yoursig theirsig redeemscript]
out:
1 BTC: [pay2pubkey(theirs)]
1.99999958 BTC: [pay2pubkey(yours)]
0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
timeout)]
But the third output will hit the IsDust() test (less than 546 satoshi
for a min relay fee of 0.01 mBTC) and the entire transaction will be
rejected, so the channel can't be closed at all!
This is a similar problem to sub 1-satoshi payments, but it's different
in that while you can't represent them as an HTLC output, you can
represent them as soon as they complete -- ie:
out:
1.00000042 BTC: [pay2pubkey(theirs)]
1.99999958 BTC: [pay2pubkey(yours)]
is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
wouldn't be).
I assume treating them much the same way is the only real option --
account for them exactly in the lightning state, but just approximate the
results in the actual commitments. So long as you're closing channels
infrequently, losing a few hundred satoshi here and there won't matter
much.
The important thing is that adding dust to your commitment might mean you
can't access _any_ of your funds if your channel counterparty goes AWOL.
Even though the amount mightn't matter, you can't just treat it like
any other case in the code.
Another option might be to weaken the dust protection in the network --
eg if you made the dust output be
0.00000042 BTC: [(them && (R || revoke))
|| (you && d CSV && t CLTV)
|| (3 months CSV)]
then anyone could clear the dust after 3 months if it weren't otherwise
claimed; maybe having some dust for a finite time is okay. But it'd also
mean paying to an actual (non-standard) script, rather than a scripthash,
which would be annoying in its own way... And, really, adding that output
to the txn would probably cost more in additional fees that it's going
to pay you in any case.
Cheers,
aj

2023-06-09 12:45:14

- reply

📅 Original date posted:2015-11-25
📝 Original message:
On Wed, Nov 25, 2015 at 10:32:54AM +1030, Rusty Russell wrote:
> For A if HTLC times out + revocation relative timeout, OR
> (Aside: can we reduce the HTLC timeout there so that it takes into account
> the relative timeout? I'd have to think harder about all the other
> scripts, too, but it seems reasonable on the surface?).
Definitions:
d -- the OP_CSV delay
T -- top OP_CLTV timeout
C -- the commitment tx is signed by B and given to A at time C
P -- the commitment tx is published at time P
S -- the commitment tx is spent at time S
X -- the timeout at which a refund can be forced
Constraints enforced by bitcoin:
P >= C
S >= T
S >= P+d
When A is paying the HTLC, and wants to claim a refund by unilaterally
closing the channel, We want to enforce S >= P+d and S >= X.
If C+d >= X, then P+d >= C+d >= X, and we can just use OP_CSV <d>.
If C+d < X, then if the commitment is published immediately, P+d < X,
and we still need OP_CSV <d> && OP_CLTV <T=X>.
However if the commitment gets updated while the HTLC remains open, C
will increase over time while d and X remain constant, so eventually the
OP_CLTV could be dropped. But I don't see how that does any good?
_But_ if you're updating a commitment and C+d >= X, then it seems like
your counterparty should already have given up on trying to redeem it,
not keep it open? If so, you're probably being cheated and should have
closed the channel already.
Alice forwards to Bob who forward to Carol creates two HTLCs:
(Bob, x, R, T)
(Carol, x-f, R, T-t)
What we want is to be able to say that "assuming Bob can close the HTLC
with Carol by T-t+k, Alice can close the channel by time T+k", I think...
* At time T-t+k, Alice says "Bob, you haven't given me R. Do you give
up?". If Bob has closed his channel with Carol and is cooperative,
he reveals R (if Carol did) and is happy, or gives up and Alice times
out the HTLC slightly early. (If Bob doesn't answer at this point,
he's violating protocol, and we don't care if he loses money)
* Otherwise, Alice declares Bob uncooperative, and closes the channel,
with an output spending to:
(Alice & OP_CLTV T & OP_CSV d) | (Bob & (R | Revoke_A))
* This enters the blockchain at time T-t+k+x (where x is some delay due
to the time it takes to find a block, and whether the fee Alice's
commitment pays is competitive or not)
* Alice can spend this HTLC at time max(T, T-t+k+x+d), which we'd like to
no later than T. So T-t+k+x+d <= T, which just means d <= t-k-x
If t >> d (ie, inter-hop-delta is much greater than revocation delay),
that's satisfied.
* Depending on the fee Alice pays etc, her transaction then gets
n confirmations by time T+y, or else Bob manages a double spend,
revealing R. If we chose k such that y <= k here, we're done: if Bob
tried at doublespend, then at time T+k Alice knows R, or Alice is
confident she got her refund.
* Induction lets us note that Bob can apply the same argument and
ensure that he complies with protocol, giving us the original
assumption.
* For concreteness, then, assuming you pay fees that get your block
accepted withing the next F blocks or so, k=y=10*(n+F) minutes,
x=10*F minutes, and t >= d+10*(n+2F).
So normally your HTLC will expire at T-t+k = T-d-10*F and the channel
will stay open; otherwise you'll close the channel and not know the
answer for sure until T+k = T+10*(n+F).
For n=4, F=4, t >= d+2 hours, so normal expiry is no later than
T-d-40m, and uncooperative expiry is at T+1h20, so d+2h later.
> > (3)
> > As the absolute CLTV timeout has to increase with each hop, it can
(decrease with each hop; at least if you start counting at whoever's
paying)
> It's not about DoS, really. The revocation time has to be long enough
> so you're certain to spot someone cheating. And we've established that
> the HTLC inter-hop-delta should be >> revocation time.
>
> If your node is online and robust, 3 hours should be sufficient for
> revocation time (remember, you can jack up fees if you need to).
So if d=3h, then t>=5h above assuming 4 confirmations is enough to give
you confidence you won't be reorged and doublespent, and you pay enough
fees to get into one of the next 4 blocks.
> 12
> hours will give you plenty of time to take your claim transactions and
> inject them into the bitcoin network via carrier pidgeon or whatever you
> need to get around any DDoS.
d=3h and t=12h gives (n+2F)=54, so say n=24, F=15; meaning pay enough
fees to get in in the next 15 blocks, and accept spends after 24
confirmations.
> Still, let's assume everyone uses 1 day for revocation time, and 2 days
> for HTLC timeout delta, and we have 20 hops.
>
> The original HTLC (NODE 0 -> NODE 1) times out in 40 days. The last
> HTLC (NODE 19 -> NODE 20) times out in 2 days, and that one falls to the
> blockchain. NODE 19 takes 3 days to get a refund.
By my protocol above, node 19 would demand an answer from node 20
at time T-t+k, but T=2 days, and t=2 days, so that's just time 0+k.
d<=t-k-x, so k<=t-d-x; ie, k<=1 day - x, and x=10*F minutes. So node 19
demands an answer from node 20 after, say, k=21 hours (F=18 blocks). Node
20 doesn't reply, so 19 closes the channel and posts the commitment
to the blockchain, paying enough fee to be visible after 18 blocks,
which happens to be 3h later, ie 1 day total time. After another day,
both OP_CLTV and OP_CSV pass, so node 19 tries spending it, with enough
fee to get in after 18 blocks, or 3h, so that's at about T=51h.
Meanwhile node 18 is wondering what's going on, and follows the same
protocol. At time T'-t+k demanding an answer from node 19. T'=4 days,
t=2 days, and k=21h, so T'-t+k = 69h. So node 19 has 18 hours to be
confident its refund transaction isn't going to be reorged, or to see an
attempt at a doublespend by node 20 revealing R. Either way, node 19 can
respond to node 18's request and keep the channel open. Node 18 can
pre-emptively pass on R or close 17's HTLC at that point and so on.
So by my count, node 19 has a refund within 2 days 21 hours.
> So, worst case is 3 days unless there are multiple hop failures?
A single hop failure at node 3 immediately after the transaction gets
passed on would be worse. Setup:
node 1/node 2 = 38 days
node 2/node 3 = 36 days
node 3/node 4 = 34 days
...
node 19/node 20 = 2 days
t+1 second:
node 1/node 2 = 38 days
node 2/node 3 = 36 days
node 3/node 4 = 34 days
[everyone else resolved]
Node 4 asks node 3 "wtf??". doesn't get an answer, closes the channel,
publishing the commitment to the blockchain.
After a day, node 4 can reclaim uncommitted funds, and reveal R to claim
the HTLC funds. node 3 is out of pocket.
Within the next 33 days, node 3 wakes up, sees R and finishes the
transaction. Node 2, in particular, has funds held up for the 34 days
node 3 was down.
> What do you think about reducing the OP_CHECKLOCKTIMEVERIFY argument if
> it's followed by the revocation delay?
The revocation delay happens simultaneously, so I don't think this can
be made to work usefully.
Don't think it's needed either though, so long as channels have parameters
"t" and "k" as well as "d" to drop to the blockchain well before T
actually comes around.
Cheers,
aj

2023-06-09 12:45:05

- reply

📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 02:25:09PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > The alternative approach, which andytoshi and I came up with
> > independently is a lot more complicated:
> > revealP( Q, R, sigA, sigB, sigC ) {
> > check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();
> > check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();
> > check_multisig_verify(2, P, Q, 2, sigC, sigB);
> > }
> > If sigA, sigB and sigC all share the same r and SIGHASH settings,
> I don't think this works? We can't provide the signatures in the
> scriptPubkey, since that requires them signing themselves.
The scriptPubkey has the pubkey P, and a whole mess of stack operations
to implement the function above; the scriptSig just has Q, R and the
three signatures.
> We can't
> have them provide it in the scriptSig, since theres no "do these have
> the same r value" operator in script.
There's six sig ops, but only three different signatures. Getting the
various combinations to have the same signature forces the same r value
between each of the signatures, without needing a separate op to check
it explicitly.
It's mathematically possible to come up with Q, R, sigA, sigB, sigC where
sigA.r, sigB.r and sigC.r are all different; but it requires being able
to come up with a transaction with a particular hash, or calculating the
discrete log of a weird value to do so, so should be safely intractable.
Cheers,
aj

2023-06-09 12:45:04

- reply

📅 Original date posted:2015-11-24
📝 Original message:
On 24 November 2015 1:30:19 pm AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>Anthony Towns <aj at erisian.com.au> writes:
>> On Fri, Nov 20, 2015 at 12:05:46PM +1030, Rusty Russell wrote:
>>> With the segregated witness proposal, introducing new opcodes is
>easy,
>>> so maybe someone would find a reason to prefer open-coding it like
>this?
>>
>> I don't follow how segregated witness makes new opcodes any easier?
>
>I didn't either, and that's because it's slightly orthogonal.
>
>The proposal I heard is that the first byte of SW script is a version
>byte, and if you don't understand that version, the script succeeds.
Ah, I see - it doesn't make OP_CHECK*VERIFY any easier then, but adding ops that actually change the contents of the stack becomes a soft fork instead of a hard fork. Pretty neat. Don't think that's needed here though.
Cheers,
aj
--
Sent from my phone.

2023-06-09 12:45:04

- reply

📅 Original date posted:2015-11-26
📝 Original message:
On Fri, Nov 20, 2015 at 05:44:15PM +1000, Anthony Towns wrote:
> > After a night of sleep and some reassurance with sipa, I thought about
> > something similar but with EC keys, that will allow us to do the same,
> > but without SNARKS.
> So this is genius! And I swear I would have thought of it myself if
> I could just get past my mental block on adding opcodes to bitcoin.
> Honest, guv!
And wow, it looks like you can do it without adding opcodes to bitcoin.
Two approaches to forcing someone to reveal the private key corresponding
to secp256k1 public key P. Number one, which Greg Maxwell came up with:
OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY <P> OP_CHECKSIGVERIFY
To satisfy this script, you have to generate a signature with P, that
produces <r> and <s> parameters for the signature that have a combined
total of 15 leading zero bytes (or more). There is a known <r> value with
11 leading zero bytes though: g^(1/2), so you need to brute force about
2**32=4B <s> parameters to get a valid signature, and that's just modifing
the transaction, hashing it, and doing modular arithmetic ops. It might
mean paying for a few seconds use of dedicated mining hardware though.
Using that <r> value reveals the secret key p: p = (2s - h)/r (mod O(g)).
If you want to cheat, you can brute force a secret key N with
corresponding public key r with as many leading zero bytes as possible.
Greg Maxwell thinks grinding r values at a rate 0.08 microseconds per
try is practical, so that's ~10e6/second. Doing that on 2000 8-core
machines for abut a week gets you an r-value with 7 leading 0-bytes.
Getting 8 leading 0-bytes might take 20k machines and four months.
With 7 leading zeroes in r, you still need 8 leading zeroes in s, which
would require about 213,000 GH/s worth of mining hardware running for 24
hours to achieve. With 8 leading zeroes in r, you'd only need 7 leading
zeroes in s, which you could get in 1 hour with 20GH/s of mining hardware.
The alternative approach, which andytoshi and I came up with
independently is a lot more complicated:
revealP( Q, R, sigA, sigB, sigC ) {
check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();
check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();
check_multisig_verify(2, P, Q, 2, sigC, sigB);
}
If sigA, sigB and sigC all share the same r and SIGHASH settings, coming
up with secret keys Q' and R' is straightforward (Q'=P'-(h2-h1)/r,
R'=P'-(h2-h3)/r, where h1, h2 and h3 are the transaction hashes for
the various steps), and you have two valid sigs by key P with the same
r value, letting you calculate P'. If you don't use the same r value,
or use different sighash types between the signatures, coming up with
valid keys and sigs seems to require doing discrete logs on the elliptic
curve, so should be intractable. (In particular, I don't think throwing
lots of hashpower at the problem helps at all)
But if you have to drop the transaction to the blockchain, it's six
sigops, which combined with the two other signatures an HTLC needs to
be usable (one for A on timeout, one for B on success), means a total
of 8 sigops per output, which is about equivalent to 400B per output
given the relationship between the bytes-per-block and sigops-per-block
limits. Yikes. Translating from pseudocode into script is a little
hard too.
> > Assume two keypairs, K1(Q, q) and K2(R, r). Further we have a scalar
> > p, such that
> > r = p * q
> > and
> > R = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.
Greg Maxwell also pointed out you can also do this faster while still
being secure; assuming Q was the public key from the incoming HTLC, and P
is the public key you'll use for the outgoing HTLC, and r is your secret:
p = q + r
P = (q+r)*G = q*G + r*G = Q + r*G
Given Q is already known, calculating P just requires multiplying the
base point and an addition, which is quicker than multiplying an arbitrary
point. And once you find out p, calculating q=p-r is obviously easy.
Cheers,
aj

2023-06-09 12:45:03

- reply

📅 Original date posted:2015-11-20
📝 Original message:
On Thu, Nov 19, 2015 at 01:16:57PM +0000, Mats Jerratsch wrote:
> Interesting, thanks for the write-up Anthony!
Glad I went ahead and implemented it as a snark before posting the idea
or you would have spoiled all the fun I had playing with snarkfront!
> I feel like the way ZKPs are constructed, one has to be absolutely
> certain everything is perfectly implemented to actually work out the
> way we want it.
Yeah. I think you could have a "stop-loss" condition, where any node that
gets cheated (ie, they have a proof that R2 gives them and R1 for H1,H2,X;
but they have an R2 that doesn't give them R1) can just publish all that
evidence, and everyone can immediately stop trusting snarks and so only
a small amount of money can actually be stolen from the system. But, yeah.
> ---------------
> After a night of sleep and some reassurance with sipa, I thought about
> something similar but with EC keys, that will allow us to do the same,
> but without SNARKS.
So this is genius! And I swear I would have thought of it myself if
I could just get past my mental block on adding opcodes to bitcoin.
Honest, guv!
> Assume two keypairs, K1(Q, q) and K2(R, r). Further we have a scalar
> p, such that
> r = p * q
> and
> R = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.
> You can therefore give someone Q, R and p and he is able to verify
> that above conditions indeed holds true. For a sufficiently large p it
> is not possible to derive that relationship within reasonable time
> without p. If he ever gets to know q, he is able to directly compute r
> as well.
Even better, given K1(Q,q) (q the public key provided by the merchant,
Q the merchant's secret, used to claim the payment and serving as a
receipt), you (as the consumer) can construct r2, .., rN by generating
random bits, and then generate
q1 = q
q2 = r2*q1
q3 = r3*q2
...
qN = rN*q[N-1]
and route your HTLC payable to qN at the first hop, q[N-1] at the second
all the way to q1 when it gets to the merchant. The merchant reveals
Q=Q1, and nodes calculate:
Q2 = r2*Q1
Q3 = r3*Q2
...
QN = rN*Q[N-1]
to collect their payments. So the extra burden for keeping the payment
private falls entirely on the consumer, rather than the merchant. (Okay,
you had this point in your mail already essentially)
Hmm, I'm not sure if you can divide QN by (r2*..*rN) to get back to Q1,
but I think you can (the lowercase q's are the points on the elliptic
curve where division is hard, but the capital Q's are just numbers
in Z_n where n is the order of G on the curve, I think?). If you can,
you even get the original receipt/proof of payment!
Oh, _and_ you don't even having to reveal q1/Q to any intermediate hops
-- you could just pay to q[N-1] on the final hop and provide rN in the
onion message on the final hop. If you do that, nobody but the merchant
and the end consumer can calculate the proof of payment.
_And_ I think you could just use SHA(ECDH_SEC || 3) as the r values at
each stage rather than needing any additional entropy, or having to add
any significant data to the onion packets.
> There is one caveat. We are currently unable to enforce a payment with
> a priv/pub key pair. We would need a new operator
> OP_CHECKPRIVPUBKEYPAIR or similar that pops two items from the stack
> <Private Key> <Public Key>
> and replaces them with true/false.
There are a few "generic" crypto ops that might be useful to have; two
that come to mind are:
<point> <multiplicand> <resultpoint> OP_CHECK_SECP256K1_MUL_VERIFY
(enough for this, maybe lets you do ECDH on the blockchain,
and allows you to commit to revealing a key on the blockchain)
<signature> <pubkey> <message> OP_CHECK_INLINE_SIGNATURE_VERIFY
(this would let you do atomic cross-chain swaps without knowing in
advance who you're swapping with)
Maybe it'd make sense to combine them into a soft-forkable OP_CRYPTO_OP
that pulls the crypto operation id from the stack, then if the operation
is known, pulls the operands, and fails the script if the operands
don't add up. If the operation is unknown, mark it as non-standard but
acceptable for future soft-forkability...
On Fri, Nov 20, 2015 at 12:05:46PM +1030, Rusty Russell wrote:
> With the segregated witness proposal, introducing new opcodes is easy,
> so maybe someone would find a reason to prefer open-coding it like this?
I don't follow how segregated witness makes new opcodes any easier?
Cheers,
aj

2023-06-09 12:45:03

- reply

📅 Original date posted:2015-11-22
📝 Original message:
On Fri, Nov 20, 2015 at 05:44:15PM +1000, Anthony Towns wrote:
> Hmm, I'm not sure if you can divide QN by (r2*..*rN) to get back to Q1,
> but I think you can [...] If you can,
> you even get the original receipt/proof of payment!
Yep, this works!
> _And_ I think you could just use SHA(ECDH_SEC || 3) as the r values at
> each stage rather than needing any additional entropy, or having to add
> any significant data to the onion packets.
This doesn't quite, though: if a txn routes from Alice through Bob to
Carol, with Alice/Bob's secret being p,P and Bob/Carol's being q,Q,
with p = q*r and P = Q*r; Alice has to pass on both p and q; p as part
of the HTLC contract, and q inside the onion payload because calculating
q=p/r is infeasible unless elliptic curve crypto is broken.
So add an extra 32B of payload to each onion hop if calculating r from
the ECDH secret is fine, or 64B of payload if it's not.
Cheers,
aj

2023-06-09 12:45:02

- reply

📅 Original date posted:2015-11-17
📝 Original message:
Hi all,
An obvious privacy limitation with lightning is that even with onion
routing, differents hops can be associated as being part of the same
transaction due to sharing a common R value. So if you see a HTLC from
Alice to Bob, paying $5 to Bob on receipt of R where SHA(R)=12345..;
and you see another HTLC from Carol to Dave, paying $4.95 to Bob on
receipt of R under the same condition, SHA(R)=12345..., then you know
it's part of the same transaction.
If you could change R at each step in the route, this would go away,
improving payment anonymity and making it harder to attack the system in
general.
That's hard, because as a forwarding node, if you receive a HTLC payable
on R1, then to send a HTLC payable on R2, you need to be able to
calculate R1 from R2 or you'll be out of pocket. But you also can't be
able to calculate R1 *without* R2, or you could just rip off whoever's
making the payment. And, of course you have to know SHA(R2) to forward the
payment at all. And if you only know SHA(R1) and SHA(R2) it's hard to
say anything at all about R1 and R2 because cryptographic hash functions
are designed to make any structural relationships go away.
BUT! I think the magic of SNARKs [0] lets you do this!
With a SNARK, you can "prove" that you have some secrets (ie, R1 and R2)
that satisfy some programmable condition (ie, SHA(R1)=H1 and SHA(R2)=H2
and R1=R2 XOR X), based on public inputs (H1, H2 and X), without revealing
those secrets.
I think that's pretty safe, because if you receive an HTLC asking for a
preimage for H1, along with instructions in the onion saying ask Bob for
a preimage for H2, and here's X and a proof, then either:
- your forwarded HTLC will fail, and everything's fine
- you'll receive R2, calculate R1=R2 XOR X and see SHA(R1)=H1 as
expected, and everything's fine
- you'll receive R2, calculate R1=R2 XOR X and see SHA(R1) != H1,
which is only possible if the cryptography behind SNARKs are broken
- you'll receive RX, such that H2=SHA(RX) but RX being too
long or too short. If SNARKs aren't broken, this means that you know
R2alt and someone else knows R2 that are different but hash to the
same value, meaning SHA has been broken.
It seems like there are research-level tools out there that actually
make this practical to try out. I've had a go at implementing this using
snarkfront [1]. Using it looks like:
1) initial setup of proof/verification keys
$ ./test_lightning -m keygen > keygen.txt # global setup
2) generate a proof, using a 32 byte secret, and XOR key (64 hex digits)
$ SECRET="the quick brown fox jumps lazily"
$ XOR=$(echo "she sells sea shells" | sha256sum | head -c64)
$ cat keygen.txt |
./test_lightning -m proof -s "$SECRET" -x "$XOR" > proof.txt
m: proof.
f: .
b: .
x: 5677d356ccd6ff29b296a697791d109a1703557ecbbcf52b4f38d4b680858912.
F: 74686520717569636b2062726f776e20666f78206a756d7073206c617a696c79
B: 221fb676bda3964ad9b6c4e5166a7eba716c2d5ea1c9985b3c18b8d7faece56b
#F: ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85
#B: 166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245
generate proof
(6) ..................................................
(5) ..................................................
(4) ..................................................
(3) ..................................................
(2) ..................................................
(1) ..................................................
3) Verify the proof:
$ F=ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85
$ B=166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245
$ cat keygen.txt proof.txt |
./test_lightning -m verify -h "$F" -b "$B" -x "$XOR"
m: verify.
f: ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85.
b: 166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245.
x: 5677d356ccd6ff29b296a697791d109a1703557ecbbcf52b4f38d4b680858912.
verify proof (6) (5) (4) (3) (2) (1)
proof is verified
4) Verify it doesn't report a valid proof with different inputs:
$ cat keygen.txt proof.txt |
./test_lightning -m verify -h "$B" -b "$F" -x "$XOR"
m: verify.
f: 166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245.
b: ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85.
x: 5677d356ccd6ff29b296a697791d109a1703557ecbbcf52b4f38d4b680858912.
verify proof (6) (5) (4) (3) (2)
proof is rejected
Some results:
* the proof/verification key data take up about 100MB -- in theory
one set of this data can be used by everyone; the only catch is
that everyone has to trust that nobody has kept the original random
numbers used to generate it.
* proof/verification key data takes about a minute to generate,
and about 650MB of RAM.
* the proof data itself (which would need to be sent to the node that's
going to switch R's) is just 864 bytes; so it'd use up about 5 hops
worth of onion routing at 192B per hop -- in a 4096 byte packet eg,
you could have four hops, changing R each time; or you could have 9
hops, changing R only three times.
* generating the proof data for a given R1,X pair takes about 10
seconds, and 260MB of RAM
* verifying the proof is quick-ish -- it takes 0.5s on my laptop,
and uses about 150MB of RAM.
For comparison, that last point makes a SNARK verification 500+ times
more expensive than an ECDH operation. If I got my maths right, you
can translate 3c for a linode CPU-hour into 2.5 satoshi for a linode
CPU-second (at $338/BTC), so you're probably looking at a minimum fee
of a few satoshi per SNARK verification, but that's still pretty okay
for transactions of 500 satoshi or more, ie anything more than about a
fifth of a US cent.
The 10s proof generation time is probably more of a limitation -- though
you could generate them in advance easily enough and just store them until
you need to use them, which would avoid lag being a problem at least. But
even then it's still essentially adding up to 30c of additional costs to
your transaction (ie 10s cpu time valued at up to 3c/s), which probably
isn't worthwhile for transactions smaller than a dollar or two.
A drawback is that you'd either (a) have to do all this on the merchant's
side (not just sending SHA(R) to whoever wants to pay you, but sending
SHA(R1), SHA(R2), SHA(R3), SHA(R4), X12, X23, X34, and three proofs,
which would be pretty painful; or (b) you'd have to generate all the
R secrets as a consumer, and you wouldn't get to use the fact that you
know R as evidence that you paid the merchant.
Anyway, it's obviously not ready for prime time today: SNARKs are still
pretty new as a concept; I'm definitely not familiar enough with SNARK
theory to be sure I'm not misusing the concept somehow; snarkfront may not
have implemented the theory fully correctly; and I might not have captured
everything I needed to in order for my "proof" to actually say what I
want it to. So not a great idea to use this to protect real money today.
But still, this seems like it's not all /that/ far from being practical,
and if the crypto's not fundamentally broken, seems like it goes a long
way to filling in the biggest privacy hole in lightning today [3]...
Code is at https://github.com/ajtowns/snarkfront/ or more directly at:
https://github.com/ajtowns/snarkfront/blob/lightning-sha/test_lightning.cpp
Cheers,
aj
[0] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SNARKs
[1] https://github.com/jancarlsson/snarkfront
[2] This would also improve privacy/anonymity for other applications of
HTLCs, such as atomic swaps across chains:
1 bitcoin, payable on R1 + Alice's sig or timeout + Bob's sig
100 litecoin, payable on R2 + Robert's sig or timeout + Ally's sig
Alice and Bob communicate privately, agreeing to trade 1 BTC for 100
litecoin and revealing their aliases Robert and Ally; Alice generates
R1, R2, and reveals SHA(R1), SHA(R2), R1^R2 and the SNARK proof and
publishes the litecoin payment. Bob verifies the proof, and publishes
the bitcoin payment. Alice claims the bitcoin payment, revealing R1;
Bob calculates R2 and claims the litecoin payment. The swap can take
place trustlessly because Bob knows the only way Alice can claim his
bitcoin is by revealing enough info so he can claim the corresponding
litecoin. But there isn't any on-chain information linking the two
transactions, because R1 and R2 are independent (and could even be
using different hash functions as well as different preimages).
After the funds have been claimed, the private communication is
also completely deniable, since anyone could generate R1^R2 and a
corresponding SNARK proof just using the info on the blockchain.

2023-06-09 12:45:01

- reply

📅 Original date posted:2015-10-28
📝 Original message:
On Tue, Oct 27, 2015 at 10:34:12PM +0100, CJP wrote:
> > 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?
Trivially, if a majority of hashpower wanted to act as a cartel, they
could just use the soft-fork protocol to make and enforce any decisions
(eg, versionbits to vote on decisions, then orphan any non-compliant
blocks to enforce it).
> So, how do your calculations work out if the miners are not a cartel,
> but instead completely non-organized?
I don't see how to come up with a figure for fees or miner revenue other
than than maximising revenue for miners (ie, the same fees they'd charge
if they were a cartel) or minimising costs for users (ie fees at 0 or 1
satoshi per tx). The supply constraints for transactions per block aren't
really tied to miners' costs, so supply capacity doesn't particularly
increase with costs, and so supply/demand curves don't help much.
If you choose somewhere in between those extremes, that might mean the
blockchain gets used for transactions above $20 or $100 rather than only
above $200; but given we're talking about lightning payments being below
about $10 each, that seems fine.
> 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?
Hmm. Having miners accept txs with different fees introduces a timing
aspect -- ie, it's not just "is it worthwhile to pay Bob $5 if it costs
45c?" it's "is it worth paying Bob $5 in 10 minutes for 45c; or in 60
minutes for 20c?"
Once you add that complication to the analysis I think you have to figure
a cartel would take it into account too. If every 10 minutes you had a
new set of transactions from people with the following willingness to pay:
1000 tx worth 100c in 10 minutes or 20c in 60 minutes
500 tx worth 90c in 10 minutes or 20c in 60 minutes
200 tx worth 30c in 10 minutes or 25c in 60 minutes
100 tx worth 20c in 10 minutes or 20c in 60 minutes
Then I think you'd optimise your revenue by accepting any transactions at
90c or more immediately, along with any transactions that are at least
50 minutes old at 25c or more. Or you could just include 17% of 25c txs
from the mempool in each block for roughly the same effect. That would
make you around $1400 in fees, and does better than:
$1350 in fees if you just accept 90c txs asap
$1000 in fees if you just accept 100c txs asap
$510 in fees if you just accept 30c txs asap
$360 in fees if you accept 20c txs at anytime up to 50m
If a non-cartel miner comes into the picture with 17% hashpower (so gets
one block an hour roughly), they could have a different policy. (If they
had less hashpower, they couldn't affect prices) They'd still get the
1500 90c fees that were set based on assuming a cartel member would
only pick them up immediately at that price. They could pick up all
the 20c fee transactions, without having to let them age 50m as well,
for maybe $1650 in total fees. But if the non-cartel miner accepted 20c
transactions as well, users would notice, realise they can just offer
20c in fees and still be fairly reliably accepted within an hour, and
that miner would only end up collecting $360 in fees, rather than $1650.
(Accepting all the 25c transactions actually means consumers would be
paying 25c to get their transaction accepted in about 55 minutes rather
than 60 minutes which might also affect prices, but the analysis is hard
enough already...)
> 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",
Because you only get blocks in relation to your hashpower, and people care
about timeliness of confirmations, I don't think you can spoil the market
easily just by being a miner with a small percent of hashpower.
*Alternative* payment methods to publishing on the blockchain (like
lightning, altcoins, or fiat payments) can undercut prices and steal
marketshare though. So I think prices will still end up at "free market"
rates rather than anything really extortionate -- ie, lightning fees of
1% and bitcoin txs would cap bitcoin fees at about $2/tx even with an
absolutely effective revenue-maximising bitcoin miner cartel.
(Calling bitcoin miners a cartel is probably unfair; you don't call
"Visa" a cartel just because it sets its own fees at a profit-maximising
level. You'd only really have a cartel if the /industry/ cooperated
like that, so Visa, Amex and Mastercard all coordinating fees. Likewise
you'd only have a blockchain cartel if Bitcoin and litecoin and other
altcoins coordinated fees; switching to an altcoin seems about as easy
as changing credit card providers)
Anyway, this is pretty tangential to lightning at this point. Followups
to bitcoin-discuss or direct mail?
Cheers,
aj

2023-06-09 12:45:01

- reply

📅 Original date posted:2015-10-27
📝 Original message:
On Wed, Oct 28, 2015 at 06:03:25AM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > C. Without lightning, as bitcoin adoption increases, either fees rise,
> > or number of transactions per block increases proportionally. If
> > 1% of people know about bitcoin, and use it whenever it's cheap;
> > then 2% of people knowing about bitcoin gives twice as many
> > transactions at any given price level.
> Metcalf's law? Both sides need to "know about bitcoin".
I think Metcalf's law would be a lower bound -- you're more likely to
adopt bitcoin if the people you transact with use bitcoin, so they're
not independent. ie,
P(tx via bitcoin | bitcoin is cheaper than alternatives)
= P(consumer can use bitcoin) *
P(merchant can use bitcoin | consumer can use bitcoin)
If those are independent and P(consumer)=P(merchant), you get Metcalf's
law. If P(merchant|consumer)=1 you get my assumption above.
I assume reality would be somewhere in between; because I think once
a merchant had a few customers asking for bitcoin they're more likely
(though not certain) to offer it as a payment method. Getting an actual
model would probably depend on what marketing strategy was undertaken
for lightning.
> Say: 1 billion people, each initiating 100 txs per year. But only 1%
> know about bitcoin, so those 10M can only use it for 1 of their annual
> transactions. At 2%, 20M can use it for 2 of their annual transactions...
Yeah, so if Metcalf's law applied directly, you'd just have:
p_tx = p_u^2
or p_u = sqrt(p_tx), where p_u is the proportion of users with access
to bitcoin, and p_tx is the proportion of transactions that could be
done on bitcoin (what I called "adoption").
> Not sure how this alters the rest of your calculations.
I don't think I actually used the proportion of users in any calculations
in the original mail.
It would matter for adoption rates, and I think it matters for comparing
how many bytes are needed for lightning anchor txs on the blockchain
(as per my previous mail) though.
Cheers,
aj

2023-06-09 12:45:00

- reply

📅 Original date posted:2015-10-27
📝 Original message:
On Tue, Oct 27, 2015 at 10:38:52AM +0100, Pierre wrote:
> You seem to be considering that bitcoin tx and lightning tx are completely
> independent, which is not entirely true because of anchor transactions.
> While this is certainly a valid assumption, maybe it would be worth stating
> it explicitely ?
Yep.
I'm not sure what the frequency of anchor transactions is likely to
be. If you consider 10% adoption to be 30M users (10% of US population),
each of whom does an anchor and claim once a month, that would be 720M
transactions, at 500B/tx that's an extra 7MB per block, compared to the
8MB of high value transactions we were taking from Visa at 10% adoption.
If anchor/claim happens once a year on average, instead of every month,
that would be an extra 570kB compared to the same 8MB.
(Using Metcalfe's law, 10% adoption by transaction volume might actually
require 94M users (P(tx via btc) = P(userA has btc) * P(userB has btc)
= 94/300*94/300 = 0.098 ~= 10%; so 21MB or 1.8MB in lightning anchor/tx
txs compared to 8MB of high-value ex-Visa transactions per block)
Cheers,
aj

2023-06-09 12:44:59

- reply

📅 Original date posted:2015-10-27
📝 Original message:
On Tue, Oct 27, 2015 at 03:40:29PM +1000, Anthony Towns wrote:
> 7. The micropayments market is very small by comparison, with only
> $1e10 (10 billion) in volume per year, counting anything under $12
> as a "micropayment".
Ooops. [2]
[2] http://letstalkpayments.com/payment-entrepreneurs-go-micropayments-segment-13-b-opportunity-globally/
Cheers,
aj

2023-06-09 12:44:58

- reply

📅 Original date posted:2015-10-27
📝 Original message:
Hi all,
A question that's been raised a few times in various places [0] is what
the impact of a fully armed and operational lightning network on miners
fees will be -- lightning depends on the security of the blockchain to
be functional, but the blockchain will eventually rely on transaction
fees to be secure, so lightning had better leave sufficient transactions
for the blockchain!
A trivial answer to this is "market forces will work it out" -- too many
lightning transactions reduces security, reduces lightning transactions,
so it will presumably stabilise at something sane, and everyone lives
happily every after.
But I think it's actually a tractable question, so we can probably
actually work out numbers!
Basic assumptions:
1. devs/miners limit the number of transactions per block
2. miners choose the transactions that pay the highest fees to fill
blocks
3. bitcoin watch what miners accept, and all settle on the smallest
per-transaction fee that will get them included in a block
4. some people would like to use bitcoin, but are priced out because
there are cheaper alternatives at the given per-transaction fee.
eg at 8c/tx, it might be cheaper to send 50c by paypal (at 5c+5%)
than the blockchain; whereas at 7c/tx bitcoin would be preferred.
If blocks were unlimited, miners would accept every transaction, no
matter how small the fee (2), which would set the per-tx fee to ~1
satoshi (3). Rational miners will thus limit the number of txs they
accept (1) to ensure fees don't go to zero.
Market assumptions:
5. the only thing preventing bitcoin from replacing credit card
transactions at point of sale is (a) adoption of bitcoin, and (b)
the transaction fees -- ie, if Visa/Mastercard is cheaper, people
will keep using it.
6. Visa does around $7e12 (7 trillion) in volume per year in the US;
and about 60e9 (60 billion) transactions [1]; on average that's 1900
tx/s, and about $117 per transaction.
7. The micropayments market is very small by comparison, with only
$1e10 (10 billion) in volume per year, counting anything under $12
as a "micropayment".
8. Imagine payments are distributed in a log-normal distribution,
then we can use the figures from (6) and (7) to get parameters
median=exp(mu)=77.669, sigma=0.9021.
9. Visa charges about 20c+2% per transaction
10. Lightning will charge 1% for a full transaction (eg, 8 hops,
0.125% per hop)
Basic conclusions:
A. First thing to note is that of the three alternatives, ie, Visa,
lightning and blockchain; that Visa and lightning get more expensive
as the transaction amount increases, but bitcoin doesn't.
Additionally, lightning is (by assumption) always chepaer than Visa.
B. Without lightning, then, the highest value N transactions will go
via the blockchain filling it up, at a fee equal to about 20c+2%
of the smallest transaction. (If the fee were any lower, smaller
transactions would be eligible for the blockchain, and higher value
transactions would bid higher fees to ensure they were included first)
So if the fee turned out to be 40c, transactions above $10 would be
in the blockchain, and smaller than that would be via Visa.
C. Without lightning, as bitcoin adoption increases, either fees rise,
or number of transactions per block increases proportionally. If
1% of people know about bitcoin, and use it whenever it's cheap;
then 2% of people knowing about bitcoin gives twice as many
transactions at any given price level. If blocks accepted 2000 txs,
and there were 1000 $20 tx/block and 1000 $10 tx/block, then
doubling adoption either means having 2000 $20 tx/block and a new
fee of about 60c (versus 40c), or doubling the block size and
keeping the fee.
D. Without lightning, fees increase rapidly with adoption: there are
1900 tx/s on Visa with an average value of $120, so there are probably
around 900 tx/s with a value greater than $100. With a 1MB block
allowing 2000 tx every 10 minutes, 0.4% adoption of bitcoin allows
everyone of those transactions to be worth over $100, which in turn
means the per transaction fee could be up to $2.20 (compared to
about 2c at present)
E. Without lightning, by this analysis, miners fees are mostly subject
to what the competition charges -- if Visa drops their rates from
20c+2% to 5c+1.5%, bitcoin transaction fees will drop
correspondingly.
F. With lightning, the only part of the above that changes is the
comparison to Visa -- instead of the only alternative to putting
your transaction in the blockchain being to pay 20c+2% to Visa; you
can pay 1% to lightning nodes to route your payment; so the outcome
to miners is exactly the same as if Visa dropped its rates to a
flat 1%. If the number of transactions per block stays constant,
the transactions actually selected will also be the same, but fees
paid to miners will reduce by about half (ie $2.20 to $1, 60c to 20c,
40c to 10c)
Numerical conclusions:
G. 60e9 transactions per year is 164M transactions per day or 1.13M
transactions every ten minutes. If each megabyte of block size allows
2000 transactions, then handling 1.13M transactions every 10 minutes
would require 565MB per block. However this would also drive fees down
to zero; so there is a smaller blocksize that induces optimal fees.
H. Given the log-normal distribution in (8), at 100% adoption and 100%
availability of lightning, this turns out to occur with a blocksize
of about 83MB, and a corresponding fee of about $2.02. This implies
a rate of 276 tx/second on the blockchain, and miner revenue of
about $335,000 in fees per block (compared to the inflation reward
of about $7500 per block, at 25 BTC and $300/BTC).
J. In such a scenario, lightning would be cheaper for any
transaction with a value under $202, by far the majority of
transactions. Lightning nodes would thus take the remaining 1624
tx/second, and earn what works out to be about $107M in fees per
day, or, for comparison purposes, about $750,000 in fees per block.
Collectively, lightning nodes would be handling 5.8 times as many
transactions for about 2.2 times as much in fees.
K. In the same scenario as above, but without lightning (and thus Visa
as the only alternative, pushing fees up), the optimal blocksize
works out to be 90MB, with a corresponding fee of about $4 per
transaction. That works out a rate of 300 tx/second, and miner
revenue of $720,000 in fees per block. Visa would handle the
remaining transactions, earning $232M per day, or for comparison
purposes about $1,615,000 per block.
L. If people adopt bitcoin and lightning independently of their
transaction amounts, and the log-normal model above is accurate,
those figures scale fairly simply: with lightning, $2.02 remains the
revenue-maximising per-transaction fee for miners; optimal blocksize
scales proportionally; ie with 10% adoption, an 16000 transactions per
block or about 8MB is optimal, and with 1% adoption, 1600 transactions
per block or about 800kB is optiomal.
M. Varying the fee lightning nodes charge in the scenario above has a
direct effect on the bitcoin fee, but does not change the optimal
block size for a given level of adoption. So halving the lightning
fee to 0.5% would result in the optimal fee also halving, with miners'
revenue halving to about $168,000 per block.
N. If lightning had fees at 0.22%, the optimal bitcoin fee would be
about 45c per transaction (with lightning still cheaper for
transactions below $200 in value); at 10% adoption, optimal blocksize
would be about 8MB or 16000 transactions per block, which would
result in about $7200 per block in fee to miners, which is about
24BTC per block given a price of $300/BTC. This might be a plausible
set of figures to target -- reasonable volume, reasonable profit,
still fairly cheap, and with wide but not completely crazy adoption?
Caveats:
Z. The log-normal distribution might not be reasonable. I've no idea of
anything better though. Also, the numbers from Visa might be
inaccurate or incomplete in the first place. They're also a couple
of years old, don't include Mastercard, Amex, etc.
Y. Visa, bitoin and lightning aren't exact subsititutes:
* Neither Visa nor Lightning can execute "smart contracts" like
bitcoin can; so the blockchain has additional demand on it beyond
Visa's current market.
* Visa is expensive or unsuitable for micropayments while lightning
is designed for them, so the potential demand may be larger than
estimated above (7).
* Unlike Visa, lightning and bitcoin do not naturally support
payments on credit or fraud protection for consumers, so some
proportion of Visa's market is probably not addressable by lightning
or bitcoin.
* Lightning payments are confirmed immediately, unlike bitcoin
transactions which take some time to be confirmed and can be
unconfirmed for a short period afterwards, and unlike Visa where
chargebacks are possible for month.
X. Increased adoption probably has some correlation to transaction
sizes rather than being completely independent; ie early adopters
probably have a different distribution of transaction amounts compared
to late adopters. No idea /how/ that's likely to differ though...
W. Current fees of up to ~2c/tx differs wildly from the above estimates
of $2 to $4 as the revenue maximising fees for miners above, given
alternative methods of payment take 1%-2% in fees. Maybe that just
means miners aren't maximising fee revenue at present (given low
adoption, and high inflation reward that's probably reasonable);
but maybe it means the distribution of payment sizes in bitcoin is
wildly different to the estimated distribution of Visa transactions
above (and skewed much lower). 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...
Cheers,
aj
[0] https://www.reddit.com/r/Bitcoin/comments/3n89cu/lightning_network_onion_routing_proposal/cvlvskx
https://www.reddit.com/r/bitcoinxt/comments/3hf74y/lighting_network_ultimately_takes_fees_away_from/
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011523.html
[1] http://investor.visa.com/files/doc_downloads/annual%20meeting/Visa%20Annual%20Report%202013%20final%20website.pdf

2023-06-09 12:44:54

- reply

📅 Original date posted:2015-10-19
📝 Original message:
On Mon, Oct 19, 2015 at 10:51:52AM +0200, Mats Jerratsch wrote:
> Hm interesting. So far the IP-PubKey-Relationship was public for me
> (furthermore, I even think about adding it to the gossip protocol, see
> other post).
Yeah, it's definitely easier to think about that way.
> I think we can mitigate the risks associated fairly well. Suppose
> lightning nodes run on dedicated machines, firewalled against any
> incoming connections (except ones on the lightning port).
(I don't think lightning wallets can realistically run on dedicated
machines/IPs; so that makes a significant distinction between wallets
for consumers and nodes for routing/merchants I think)
> Against MITM and eavesdropping your pubkey to a stranger connecting to
> your node, we can change the protocol such that the one initiating the
> connection always sends his signed pubkey object first.
I don't thnk that works -- if you can MITM Alice and Bob, then you just do
that while they're in the middle of a connection. When Alice reconnects,
she immediately tells you who she is. If Bob tries reconnecting as well,
you find out who he is too. Sending a shared secret nonce instead,
then just sending signatures avoids that; either one can re-establish
the connection if they can actually talk, and if there's a MITM they
reveal nothing, but do discover they can't talk.
Cheers,
aj

2023-06-09 12:44:54

- reply

📅 Original date posted:2015-10-21
📝 Original message:
On Wed, Oct 21, 2015 at 11:41:45AM +1030, Rusty Russell wrote:
> Having a session nonce does help after first handshake, though it allows
> correlation, so it needs to change (pretty trivial, it could just be
> sha256() of some shared secret plus a number which increments on each
> successful handshake).
Can just be the first 4-8 bytes of that too (leaving the next 4-28 bytes
to be the secret response in the signature). ECDH of the node ids would
be the obvious shared secret to use as a base?
> In practice I think "successful handshake" is a bit vague, so may
> require allowing +/- 1 nonce. I'd have to think harder about this
> though.
> Is this overcomplicating things?
While nodes are publishing their ids (and IPs -- even if only by /whois)
in a public IRC channel, I don't think a nonce does any good -- the info
it's trying to avoid revealing is already being revealed anyway. So I
think table this for now?
Cheers,
aj

2023-06-09 12:44:53

- reply

📅 Original date posted:2015-10-19
📝 Original message:
On Sat, Oct 17, 2015 at 06:53:55AM +1000, Anthony Towns wrote:
> I think treating the relationship between a network address (IPv4/IPv6
> addr and port, tor service) and the lightning network address as sensitive
> is valuable. Revealing a network address helps reveal physical identity,
> makes denial-of-service attacks straightforward, and gives a point of
> entry for targetted hacking to steal your money.
I guess the attacks I'm thinking of are something like:
Exploits leading to theft:
- if you're a merchant, it's easy to find out your lightning id (just
buy something from you!) and during the trading day you'll probably
have a relatively large balance in your lightning channels (up until
you close it out by committing your profits to the blockchain eg). If
I can find your IP address and hack into your system, I can steal
that money.
- if you're making lots of money routing payments, I might be able to
deduce that from public information (like how cheap your fees are,
how rarely your fees change, how many connections you have, ...)
and thus know that you have a lot of money in lightning channels that
I can steal
- if you're just being a consumer, however, I can't think of a reason
your lightning id would matter -- if I can snoop on your IP connection,
I can probably tell you're mostly a consumer by traffic analysis,
and conclude that you've probably got $10-$100 that could be
stolen. failure of imagination on my behalf?
Denial of service:
- I might know the lightning id of someone I don't like; a merchant who
sells something unpopular, or a node that routes payment for people I
don't like. If I can translate that into an IP address, I might be
able to DoS them using botnets etc.
Exploits that help you exploit others:
- if I know X has a channel with you; figuring out X's IP might let
me monitor X's TCP connections (by hacking into their system, or
by subpoena'ing their ISP), which in turn would help me figure out
your IP.
I guess there's three ways you can associate the info:
a) given a lightning id, cheaply work out the IP that provides it
b) given an IP, cheaply work out the lightning id associated with it
c) given an IP and a lightning id, confirm/deny whether that lightning
id is provided by that IP
(a) is what you want if you're planning theft or DoS
(c) is enough if you've got other information about whoever you want to
attack that can narrow down the lightning ids and IP addresses (eg, you
want to attack a local business, so you can find out their lightning id
directly, and narrow down their IP based on local ISPs)
(c) is obviously trivial if you've already got (a) or (b).
You can get to (a) from (b) if (b) is cheap enough and you can build up
a database that you can query in reverse.
If you're not an attacker, then (a) is useful if you want to have new
channels not be totally random (eg, to have people be able to connect
to newly announced beacons). And (c) is presumably necessary if you
want to reconnect to someone you had a channel with, when you lose your
internet connction.
One "clever" way to handle (a) might be via a "fund a new channel by
lightning transaction" operation. ie, if you (Alice) want to open a
channel with Bob, route a payment to Bob with instructions to forward to
Alice, and to do that by connecting to a given IP/port and establishing
a new channel; ie rather than just telling Bob to route to Alice in the
onion payoad, also included Alice's network address. That way Alice
reveals her IP precisely to Bob; and Bob only reveals his IP if he
decides he is interested in opening a channel.
That'd also provide a way of reconnecting with a peer if you lose your
connection and both of you change your IPs. It assumes that you both
have an alternative channel that's still functional though.
Okay... so how about the following. When making a new p2p connection, when
you know who you're talking to, you rely on a shared secret X, and send:
Alice: "Hi. I'm <session key A>. My nonce is X."
Bob: "Good to meet you, I'm <session key B>."
Rest is encrypted to ECDH(A,B).
Alice: SIG_Alice(Alice || Bob || A || ECDH(A,B))
Bob: SIG_Bob(Bob || Alice || B || ECDH(A,B))
Alice: "Hi Bob!"
Bob: "Hi Alice!"
If you don't know who you're talking to, you don't send a nonce and
you do the current protocol. Once you're connected (or once you have a
channel setup) they'll tell you a nonce to use next time:
Alice: "Hi. I'm <session key A>."
Bob: "Good to meet you, I'm <session key B>."
Rest is encrypted to ECDH(A,B).
Alice: I'm Alice, SIG(Alice || A || ECDH(A,B))
Bob: I'm Bob, SIG(Bob || B || ECDH(A,B))
Bob: BTW, next time you connect, use nonce <Y>.
If Bob wants some degree of privacy, while still accepting anonymous
connections, then he generates a new id to hand out to anonymous
connections every so often, linking it up to one of his other ids, or
to one of his neighbours by reusing a pre-existing channel. If you're
asking someone to connect to you and have a bunch of ids, you give them
a nonce to use that will select the correct one. You use nonces as a
hash key to lookup your id, their id, and any channels you have open.
You don't share or reuse nonces.
(If an attacker knows Alice and Bob have a connection, and can MITM
Alice trying to connect to X, the above lets them verify which of Alice's
connections is Bob. If that's a reasonable attack, it'd be avoidable if
the nonce X was replaced by X and Y; X sent in cleartext as above, but
Y simply included in the info being signed. That prevents the attacker
from being able to verify the signature info at all)
Not convinced that's quite right, but maybe something along those lines
might work out.
Until there's a substantial number of lightning nodes (1000s?), it's
probably trivial to link network address and lightning id by traffic
analysis, so I think it's probably sane to leave implementing any of
the above until later.
Cheers,
aj

2023-06-09 12:44:52

- reply

📅 Original date posted:2015-10-19
📝 Original message:
On Mon, Oct 19, 2015 at 11:18:30AM +1030, Rusty Russell wrote:
> > (1) Pubkey-Channel-Relationships (see other post on ML)
> > Very static, relayed every 10 days // 264 Bytes
> > (2) Node addresses/IP
> > ... approx every 12h // 133 Bytes [...]
> > (3) Channel-Status (capacity, fee, ...)
> > ... once an hour? // 176 Bytes [...]
> These estimates seem about the right ballpark to me. But once per hour
> may be extremely optimistic when channels approach exhaustion.
> Yeah, my design point has been 1M nodes. Ideally, on a cell phone :)
> In the very short term, Bitcoin used IRC as the peer protocol. It has
> the advantage of being really easy to debug, and trivial to implement,
> so I'm going to aim at that while we research our more ambitious
> proposals...
I'm totally a fan of being able to log the entire network dynamics too...
So doing the above over IRC means maybe doubling the byte size to encode
keys/sigs into hex, and adding maybe 32B per message for IRC protocol
overhead. So:
560B/channel/10 days
298B/node/12h
384B/channel/1h
Assume ~10 channels per node and converting to bytes/node/day:
560B/node/day
564B/node/day
92,160B/node/day
= 93,284B/node/day total
which is about 1.054 KiB/s per thousand nodes. If it's a single server
relaying that to a thousand nodes, that's 8.2 megabit/s outgoing
already. So that plan probably maxes out somewhere between 500-3000 nodes?
>From what I gather bitcoin only used IRC to get IP addresses to connect
to, which were encoded in the nicks used, rather than anything being
actually said. It seems like that got up to 10000 nodes [0]. Hopefully
lightning's irc usage doesn't get misdetected as botnet C&C :)
[0] https://bitcointalk.org/index.php?topic=9240.0
Cheers,
aj

2023-06-09 12:44:52

- reply

📅 Original date posted:2015-10-16
📝 Original message:
Hey *,
A few thoughts on the daemon/p2p protocol in slightly longer form than
is feasible on IRC...
# protobufs or capnp or flatbuffers or ...
Currently lightning relies on protobuf's with union support, which
requires a newer version of protobuf-c than is in Debian or Ubuntu.
I've filed this as http://bugs.debian.org/801950 -- seems to be an
easy fix.
11:43 * rusty looks at capnproto, is tempted to see what that would
look like compared to protobufs.
capnp's canonical implementation is in C++ rather than C; the C version
is serialisaion-only, which seems like it loses the fancy time-travel
RPC feature? C and Python versions of capnp don't seem to be packaged
for Debian. Not a show-stopper afaics, but I'm not seeing the benefit?
11:44 <rusty> But it still doesn't have fixed-length fields, which is a
PITA.
FWIW, I think that "fixed-length fields" is just a schema/IDL thing? ie
the serialised format should still have a byte or two to specify format
and length (because it's no big deal and slightly safer/saner when
deserialising), but if it's not the correct value from the schema/.proto
file, you get an error when you try to de/serialise.
With protobufs, I think you could do this with custom field options:
https://developers.google.com/protocol-buffers/docs/proto?hl=en#customoptions
Something like:
import "descriptor.proto";
extend google.protobuf.FieldOptions {
optional int32 fixed_size = 59797;
}
// Protobufs don't have fixed-length fields, so these are a hack.
message sha256_hash2 {
required bytes hash = 1 [(fixed_size)=32];
}
seems like it works as documentation. Not obvious how to get it passed
through to C somehow so that you could actually check it automatically.
(Not sure what's with the brackets around fixed_size; it whines if you
don't have them.)
# lightning public keys...
I think there are (at least) three uses for public key crypto in lightning:
1) routing keys -- used for constructing the onion. the routing public
key is essentially the node's identity as far as lightning is
concerned and must be well known and associated with channels
and fees for routing to be possible. *However* a single lightning
instance might play host to multiple routing keys. (This would be
less efficient for the network, but might be a win for privacy or
might be dictated by deployment reasons...)
2) anchor keys -- used for spending the anchor transaction for a
channel and thus signing commitment transactions; only needs to be
known by the counterparty you're constructing a channel with; can
be different for every channel.
3) p2p keys -- used for establishing a shared secret when talking to a
node, to avoid your p2p communications being available to someone
else (either a passive observer or a MITM). could be different for
every connection, or could just have one the lightning instance.
# p2p protocol...
If Alice tries to connect to Bob, I think the current protocol (as of
git commit gc7eaa4f, from daemon/cryptopkt.c) is:
Alice: "Call me <RichGirl57914>."
Bob: "Call me <MoneyBags70623>."
Then, encrypted to key based on ECDH(RichGirl57914, MoneyBag70623):
Alice: "RichGirl57914 is actually Alice, signed <Alice>"
Bob: "MoneyBags70623 is actually Bob, signed <Bob>"
This is secure against passive monitoring; and after the signatures are
verified, it's also secure against MITM attacks.
It seems like it has a couple of downsides though:
- if you're accepting incoming p2p connections, you'll reveal your node
id to anyone who asks
- if the node you're connecting to is MITM'ed, you'll reveal your node
id before realising you're MITM'ed
- you can't run multiple node ids on a single connection
- Bob has to do crypto operations for every connection, leading to
potential DoS attacks
I think treating the relationship between a network address (IPv4/IPv6
addr and port, tor service) and the lightning network address as sensitive
is valuable. Revealing a network address helps reveal physical identity,
makes denial-of-service attacks straightforward, and gives a point of
entry for targetted hacking to steal your money.

2023-06-09 12:44:50

- reply

📅 Original date posted:2015-10-19
📝 Original message:
On Mon, Oct 19, 2015 at 09:45:34AM +0200, Mats Jerratsch wrote:
> All of your assumptions have the premise though, that choosing a
> 'good' vs a 'bad' guy is pure probability, like picking the right ball
> out of a bag. [...]
Three sorts of attack:
- Vandals randomly join the lightning network with dysfunctional nodes.
They don't have special powers to corrupt your network, and aren't
targetting anyone in specific, just trying to damage things because
they think lightning is a bad idea and want to stop it happening.
This is just a denial of service attack. This is the class of attack
that gives the "pure probability" of hitting a bad node.
- Sybil attack, where someone is targetting you personally, and
controlling all the nodes you connect to. This is the "compromised
wifi or ISP" case, and afaics denial-of-service is trivial here,
so all you can reasonably do is detect that you can't send funds to
anyone usefully, and avoid locking up lots of funds while trying.
- Pervasive attack, where everyone in some large group is
simultaenously suffering from a sybil attack; eg the Chinese gov or an
ISP blocks lightning connections unless they're to one of its nodes,
so they always see both ends of payments between their victims. This
seems very expensive to pull off to me (you have to do deep inspection
of a whole bunch of people's internet connections), but I'm not sure
it can be effectively defended against. "Oh i was just forwarding
that to someone else" doesn't work if there wasn't any way you could
make a channel with anyone else (or if secretly forwarding payments
is criminal in itself).
> Think about an attacker who is able to MITM your internet connection,
> like the hotspot you connect to at a Cafe (or your ISP if hijacked).
> They can build locally a gigantic network, all pointing to the same
> node. You can't tell, and they don't have to necessarily just block
> your payments. (see above)
But you can tell, just by seeing whether a well-known third party's
lightning address is routable? If every node on your network is an
attacker's, then you won't see the third party's address.
If you do see a route to the third party (ie, Me -> Attacker -> Attacker
-> Attacker -> Bob -> Carol -> Third party), then you could work backwards
asking Carol and Bob to connect directly to you, which would get you a
non-attacker node with reasonable probability, assuming there are any.
I guess there's two ways in which a node is "on the network" -- one
is if it's reachable by p2p hopping ("Hey, what are your neighbours'
network addresses?" "Okay, connect to them and repeat"), the other if it's
routable over established channels. If you do a Sybil attack against p2p
hopping; my argument is you can still use the payment channels as a way
of connecting to other nodes. And if you do a Sybil attack against both
p2p hopping /and/ the graph of channels, then that's detectable because
well-known nodes simply won't appear in the graph.
> Only nuisance is that it requires either SPV or full node to check the
> anchor, but I kinda like the idea of having all (or a good amount) of
> lightning nodes be full bitcoin nodes as well.
You need to monitor the blockchain for spends of your own anchors
anyway, so that doesn't seem like a big additional limitation to me.
Cheers,
aj

2023-06-09 12:44:49

- reply

📅 Original date posted:2015-10-18
📝 Original message:
On Sun, Oct 18, 2015 at 01:25:29PM +0200, Mats Jerratsch wrote:
> > It only works if you actually setup a channel, though -- so you have to
> > lock some money into the channel for however many confirmations until
> > the channel activates, before you can test, plus the OP_CSV delay if
> > the test fails.
> And there's the catch. If an attacker achieves nodes opening up
> channels with him, he already succeeded in vandalism.
I'm not sure this is true? Supposing there are V vandals on the system,
compared to T total nodes, so V/T is your probability of selecting a
vandal. Then, to join the lightning network, you open up N channels
with randomly chosen nodes at $1 each, committing $N in total, and
(if they're all run by vandals and have to get closed) spending about
2*N*2c (so 4%?) in fees. If there are 1000 nodes (ie, lots), then the
probability of finding at least one good node is about 1-(V/T)^N. If you
want a probability of 99% of getting a good node on your first try, then:
V/T = 10%: N = 2
V/T = 20%: N = 3
V/T = 30%: N = 4
V/T = 40%: N = 6
V/T = 50%: N = 7
V/T = 60%: N = 9
V/T = 70%: N = 13
V/T = 80%: N = 21
V/T = 90%: N = 43
V/T = 95%: N = 86
V/T = 99%: N = 368
So with 90% of nodes being hostile, that'd be getting expensive, but
not completely implausible. If 40%-plus of the network is legit, though,
just trying out 10 random nodes seems like it works fine, and only locks
up $10 for a couple of days and costs about 40c in bitcoin fees...
Also, if you've got to run 2.5 times as many vandal nodes as there are
legitimate nodes for people to even really be bothered, I don't think
you'll see many vandals in the first place...
(Once you've got a node that actually works, you can expand your channel
from $1 to $10 or $100, and/or open additional channels, and at that point
(afaics) you're set.)
That's only necessary if you don't know anyone with a lightning account
already, though. Since anyone can forward for you, you could start with
someone you trust in real life -- eg, a friend, a bank, a government,
etc. If Rusty tells me he'll route my payments (as long as they're made
between 10am and 3pm Adelaide time on a weekday, maybe) then I can open
a $5 channel with him, and use that to send 1 satoshi payments to test
connectivity. So, if I'm wondering whether BOBSBANK is reliable, I work
out a route:
aj -> rusty -> a -> b -> c -> BOBSBANK -> x -> y -> z -> rusty -> aj
apply it as an onion so it can't get short-circuited, and see if it gets
back to me, at a cost of maybe 10% of a satoshi (10 hops at 1% each)...
If it does, BOBSBANK is connected and functional, and I can try opening a
channel. If it doesn't, I can try a different route to BOBSBANK, or try
someone else entirely.
> Furthermore, an
> attacker can always play by the rules and forward all payments up to
> one point where he stops.
(For example, he could happily route payments on $1 channels, but refuse
to do likewise when the channel capacity was upped to $10)
In the general case though, does that even count as an attack? Isn't
that just like a web site going down or being put behind a paywall? ie,
annoying, but completely legitimate? I mean, if someone downloads the
lightning software to try it out, runs it for a while, then decides it's
no fun and stops, they'll be "playing by the rules up to one point where
they stop"; but they're not trying to "attack" the system.
Coping with unreliability is definitely important, but running a node that
works sometimes but is deliberately unreliable is a lot more effort than
running a node that claims to work, but never does. It's also more work
(and less profitable) than just running a node that actually work...
> And even worse, if everyone connect to his
> nodes, he can relay all payments, but he is able to distinctively
> identify payee and payers, even with onion routing.
That's a different attack isn't it? To get everyone to connect to your
nodes, you'd have to be running the majority of nodes -- ie, there's
5000 different organisations running lightning nodes, but 4999 of them
run one or two nodes each, but one of them runs 100,000 nodes.
But if it were cheap enough for one org to run 100k nodes, why wouldn't
the others treat it as an arms race and end up running, say, 20-50
nodes each? They'd have an economic incentive to do so, in that it
increases their odds of collecting fees... At that point the attacker's
already reduced to 28%-50% of nodes. ie, I think that's likely to be
self-correcting?
But! An arms race in nodes-per-person would probably cause a scaling
problem for the network (depending on how routing actually works), and
you'd have to address that by creating some cost to run (or at least
register?) a node/channel. But if they're all legitimate nodes, I think
that's just a scaling problem, rather than vandalism per se.
(An additional but: even if spamming the list of nodes doesn't work as
an effective attack, if you can spam the list of *channels* with valid
looking edges that won't actually route payments successfully, you can
screw over the network pretty well)
Cheers,
aj

2023-06-09 12:44:48

- reply

📅 Original date posted:2015-10-16
📝 Original message:
On Fri, Oct 16, 2015 at 02:22:25PM +0100, Mats Jerratsch wrote:
> [...] an attacker could trick it into a fake network, [...]
How do you tell the difference between the "real" network and a "fake"
one? (ie, what does a Turing test for the lightning network look like?)
I think there's two things:
1) you can figure out a route to people you want to pay (and
vice-versa)
2) payments on those routes actually go through
Even better, you can test this! Get a couple of merchant ids you find
interesting, and pay 1 satoshi to each of them, setting the R value as
the (double) SHA256 of the decrypted onion message. [0]
If you spent 1 satoshi to each of 10 merchants every day for a year to
verify connectivity, that'd still only amount to about $0.01 USD total
at current exchange rates, so it seems pretty affordable. [1]
It only works if you actually setup a channel, though -- so you have to
lock some money into the channel for however many confirmations until
the channel activates, before you can test, plus the OP_CSV delay if
the test fails.
But I think that would let people trustlessly avoid "fake" lightning
networks, even with a sybil-esque attack; no extra infrastructure needed.
Cheers,
aj
[0] If you're already on the lightning network, and you're establishing
a new channel as backup, you can just pay yourself 1 satoshi to verify
connectivity. If you have friends on lightning, you could pay them
1 satoshi to verify connectivity rather than a random merchant too.
[1] Hmm, does forwarding 1 satoshi (2.6 10,000ths of a cent) make
sense, or would the CPU cycles cost more than the fees you'd make?
How much does it cost to forward a transaction? In python on my
laptop, I get about 1000 ECDH operations per second in python, and
290k AES ops over a 3kB onion per second, and about 77k SHA256 ops
per second. So just counting elliptic ops, forwarding a transaction
requires three ops: an ECDH on the onion message, and an ECDSA on
the commitment transaction to add the HTLC, and another sometime
later to remove it. So say 1/350th of a CPU-second. My linode costs
3c/hour and seems to be about half as fast on the SHA256 test, but
gives me two CPUs which evens it out. So so 3/60/60/350 cents is
about the cost of forwarding a single transaction, which is about
2.4e-8 dollars, which is currently about 9.1e-11 bitcoin, which
is 0.0091 satoshi. Conveniently lightning balances are denominated
in millisatoshi, so as long as yours increases by 9 or 10, you're
doing fine. 10 millisatoshi is 1% of 1 satoshi, so that seems like
the right order of magnitude.

2023-06-09 12:44:47

- reply

📅 Original date posted:2015-10-16
📝 Original message:
On Sat, Oct 17, 2015 at 07:20:30AM +1030, Rusty Russell wrote:
> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
AFAICS, to have a lightning channel between NODE-A and NODE-B, you just
have to have a way for those two people to be comfortable writing IOUs
to each other. HTLCs and commitments spending anchor transactions on
the blockchain is one way to do this, but you could also do it on a
pegged sidechain, or, if the two parties trusted each other, you could
do it with literal IOUs written on bits of paper. I'm not sure we want
to block people from doing those things?
Also, if you're only doing dual-signature, not quad-signature, I think
it's open to creating fake edges in the routing graph: ie, I make up to
keys AJ1 and AJ2, and publish a multisig transaction in the blockchain,
then claim there's a route between RUSTY and MATS by publishing
AJ1 AJ2 RUSTY MATS TX <SIG:AJ1 AJ2>
Then when Alice wants to route to Bob, she decides to use that edge, and
her transaction fails because it doesn't exist.
(If you just sign with RUSTY and MATS, obviously you can claim to have
a route just by referencing any multisig transaction that you know the
pubkeys of)
> > For 100k nodes and 10 open channels per node,
> > this adds up to 220MB. [...]
> Also, once a node is live, I'm not sure how much of the map it will need
> to keep. It might be able to prune distant parts of the map randomly,
> and get it back from the rest of the network if needed? Requires more
> thought, though.
Well, we could not worry about it until there are >10k nodes; and then
we'd have actual data as well?
Cheers,
aj

2023-06-09 12:44:45

- reply

📅 Original date posted:2015-10-06
📝 Original message:
> On Tue, Oct 06, 2015 at 12:19:14PM +1030, Rusty Russell wrote:
> > I reworked test_onion and Makefile test to separate generate and
> > decode;
> > we should mix in the python version there too.
Okay, branch updated:
https://github.com/ElementsProject/lightning/pull/9
On Tue, Oct 06, 2015 at 03:22:36PM +1000, Anthony Towns wrote:
> In onion_key.c, I don't see why you're using flip_key() -- that's only
> needed for the single use onion-msg-keys, aiui?
So I disabled that, and made the 02/03 prefix explicit. Maybe saving
a bit/byte somewhere will be worth it; but it seems way premature and
just gave me the heebie-jeebies. :)
I also changed the "Message for blah..." to serialize the pubkey before
turning it into hex -- aiui you were dumping the internal representation
of the point, which would be hard to duplicate compatibly.
I tweaked onion_key to avoid the for loop and cut calls. pyelliptic
doesn't like to generate a pubkey given a privkey, so I'm just passing
both to it directly.
Running decoding through python is slooooow -- unfortunately most of
the time is in loading the interpretor and crypto modules, so only way
to improve it would be to run the decodes in a single python process,
which I'm not sure is actually desirable?
Anyway, fwiw.
Was there any conclusion on the wiki/rfc/whatever ideas about documenting
lightning protocol/technology decisions? That'd be good to try, no?
Cheers,
aj

2023-06-09 12:44:44

- reply

📅 Original date posted:2015-10-06
📝 Original message:
On Tue, Oct 06, 2015 at 12:19:14PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> >> https://github.com/ElementsProject/lightning/pull/8
> > (This is updated correspondingly)
> Thanks, merged.
Nifty.
> I reworked test_onion and Makefile test to separate generate and
> decode;
> we should mix in the python version there too.
In onion_key.c, I don't see why you're using flip_key() -- that's only
needed for the single use onion-msg-keys, aiui?
On Tue, Oct 06, 2015 at 12:18:11PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > - AES128 just uses the first half of the calculated enckey, iv and
> > pad_iv
> True.
> > - since libsecp256k1 already sha256s the ecdh secret; the hmac/enckey/etc
> > end up being sha256'ed twice (with a byte added in between). confused
> > me for a minute.
> I didn't notice that. Perhaps this is somewhere we should optimize?
You could save a sha call by using both halves of a sha for iv and pad_iv,
rather than two separate sha's. Otherwise don't see anything obvious to
do? I assume the ECDH step dominates as far as performance goes anyway?
> PS. Message size of 128 bytes is completely made up, as is 20 hops. We
> might want to reduce to 96 or 64 bytes.
I figured 20=floor(4096/192) which made sense to me. AFAICS the message
*needs* to include fee info and the forwarding address; so that's 4B and
20B-32B respectively (you could use the hash160 here and assume the
forwarding node can figure it out).
But maybe some nodes want to do clever things, like allow you to tell it
to deliberately delay forwarding for an hour or two, or deduct (different)
fees from multiple HTLC's simultaneously. But I guess 64B is probably
plenty for that?
Other thing is if you want to redirect an onion routed payment (which we
talked about as a possibility originally, as compared to only allowing
source-based routing). ie, a HTLC is sent from A to B->C->D->E, but
C actually needs to send it to D via X->Y->Z->D rather than doing it
directly. AFAICS, in that case you need to add and drop hops, ie:
A->B: - - - - - - - E D C B
B->C: b - - - - - - - E D C
C->X: c b - - - - - - - E D Z Y X
X->Y: x c b - - - - - - - E D Z Y
Y->Z: y x c b - - - - - - - E D Z
Z->D: c b - - - - - - - E D
D->E: d c b - - - - - - - E
ie, Z needs to be able to be told "don't add padding, in fact, drop two
blocks worth of padding before forwarding". That presumably just needs a
byte or two of data; but it completely messes up the constant-size
packets. :-/
Cheers,
aj

2023-06-09 12:44:44

- reply

📅 Original date posted:2015-10-04
📝 Original message:
On Sun, Oct 04, 2015 at 02:38:56AM +1000, Anthony Towns wrote:
> Sigh. I've had a go at reimplementing it in python, but ...
But nothing! The decoding/forwarding is successfully working in python
with pyelliptic. (I'm running the HMAC twice rather than actually working
out y)
$ test/test_onion 15 > TEST.OUT
$ python test/test_onion.py < TEST.OUT
Message to 0
Message to 1
Message to 2
Message to 3
Message to 4
Message to 5
Message to 6
Message to 7
Message to 8
Message to 9
Message to 10
Message to 11
Message to 12
Message to 13
Message to 14
done
I changed test_onion.c to output the generated node keypairs (private
key and non-compressed public key) and to dump the first message, like
so:
$ grep -v Decrypting TEST.OUT | tail -n3 | cut -c1-300
* Keypair 13: 3f62802944de7ca5894e5759d351adac869580ec17e485f18c0c66f17cc07cbb 047d1b9ad310727493cf5fab067ec9b7476eac30eca03348ddce13f63f73ccce235dfa2807ab608a81628df72aa29d16c284379e8a48e2ddc1b98cfccf07c12a42
* Keypair 14: 22fce466da610b63af62bc83b4692f3affaf271693ac071fb86d11342d8def4f 045319588ea4788b57452821af386aaf25842c96e680fc3a0f16076bd4bf21f1647144bc5ff1e492fcb6c12c1f893a02dc5d12ba85d96d4eaea0faaeded0f452fa
* Message: 9c9e39281020fe4e4193ba2c1147753038c88e7ca98f4cbc1e074011fc0f85f15dd7576d9e400779eff31b27872b7762e1844447a92772a0bd495f86389a9ae0eae16f0f8dff246d57156a3a5aa36ebae2eaafd50e3bb7e08fc6b97e435b8e62f715980068f23bcf6c177d50b61507efdaf377fd1de20374ca556ec323acd7533e19031c36945e895be7935ec9d6c181
Eh, I made it a pull request; those are fun right?
https://github.com/ElementsProject/lightning/pull/8
Some notes:
- AES128 just uses the first half of the calculated enckey, iv and
pad_iv
- I couldn't get pyCrypto's AES128 to work -- I think because I wasn't
sure exactly how openssl turns an "IV" into a "counter". I couldn't
find docs on what openssl is trying to do here either, but didn't
bother looking at the source
- since libsecp256k1 already sha256s the ecdh secret; the hmac/enckey/etc
end up being sha256'ed twice (with a byte added in between). confused
me for a minute.
Cheers,
aj

2023-06-09 12:44:44

- reply

📅 Original date posted:2015-10-05
📝 Original message:
On Sun, Oct 04, 2015 at 03:57:17PM +1000, Anthony Towns wrote:
> On Sun, Oct 04, 2015 at 02:38:56AM +1000, Anthony Towns wrote:
> > Sigh. I've had a go at reimplementing it in python, but ...
> But nothing! The decoding/forwarding is successfully working in python
> with pyelliptic. (I'm running the HMAC twice rather than actually working
> out y)
> $ test/test_onion 15 > TEST.OUT
> $ python test/test_onion.py < TEST.OUT
> Message to 0
> Message to 1
Okay, and now the python version does creation as well, though I haven't
checked if the C version can decode it:
$ ./test/test_onion 3 | python test/test_onion.py
Message to 0
Message to 1
Message to 2
done
$ python test/test_onion.py generate 3 | python test/test_onion.py
Howzit 0...
Howzit 1...
Howzit 2...
done
$ wc test/test_onion.{c,py} -l
684 test/test_onion.c
329 test/test_onion.py
(though about 1/3 of the python lines are just implementing "determine
y given x" and "ecdh with y as well as x", bleh. It also doesn't have
the "export-friendly encryption" mode implemented ;)
> Eh, I made it a pull request; those are fun right?
> https://github.com/ElementsProject/lightning/pull/8
(This is updated correspondingly)
Cheers,
aj

2023-06-09 12:44:43

- reply

📅 Original date posted:2015-10-03
📝 Original message:
On Fri, Oct 02, 2015 at 03:18:39PM +0930, Rusty Russell wrote:
> So, I've pushed some test onion routing code in an acceptable
> format:
> https://github.com/ElementsProject/lightning/blob/onion/test/test_onion.c
> struct hop {
> unsigned char msg[MESSAGE_SIZE];
> struct pubkey pubkey;
> struct sha256 hmac;
> };
> That's a fixed 3840 bytes;
Is the idea to switch that to non-fixed size using protobufs, or?
> then prepends padding.
(prefixes...)
My understandng is it works as follows:
* random EC key pairs are generated for each hop, known to the
initiator
* the public key for each hop is included in plaintext as hop.pubkey
* ECDH is used to establish a shared secret with each hop
(initiator uses routing node's pubkey (ie, their lightning node id)
and the generated privkey; routing node uses their privkey and the
hop.pubkey value)
* symmetric AES & HMAC keys are derived based on the secret
When you receive a message (say you're hop 5) what you'll get is:
P4 P3 P2 P1 H20 H19 ... H5
where P1 is padding added at node 1, and H19 is the hop structure
intended for node 19, etc; all of those in various stages of
encryption/decryption.
You then grab the pubkey from H5.pubkey; which is already plaintext,
and calculate your shared secret, and generate AES key, HMAC key, IV
and padding IV from those. That then lets you run a hmac of everything
you've received, excluding the final hmac (so, P4 ... P1 H20 .. H6 +
msg + pubkey), and compare that to the hmac.
You then decrypt everything (except maybe the hmac and pubkey, but
whatever) using AES in CTR mode with a nonce of IV, giving you:
P4' P3' P2' P1' H20' H19' .. H4' [M5]
M5 lets you know what to do, and if you need to forward it, you generate
P5 by encrypting 0000's with AES in CTR mode with a nonce of PAD_IV. You
forward:
P5 P4' P3' .. H4'
and you're done.
Question:
- I think this means lightning nodes are identified by the
full 512 bit (or 257 bit?) public key used for routing -- (ie,
knowing the HASH160 of the pubkey isn't enough, unlike in normal
bitcoin pay2pubkey transactions).
- I think you can still use different keys for routing and
anchors/commitments so far. (Using the anchor transaction to turn
your routing id into a beacon would probably change that though)
Sigh. I've had a go at reimplementing it in python, but I'm stuck trying
to reproduce the secret info using pyelliptic (which in turn uses
openssl).
...
Ah, it looks like the problem is that libsec256k1 actually goes a step
further and runs SHA256(y||x), where "x" is the value I'm getting and y
is '\x02' is the y value is even and '\x03' if it's odd. If I try both,
one of them turns out right:
Secret1: d9946724c6bd8d5b58bdd2256a0251816a42f9707c794427a410075e4dbb199c
Secret2: 105e0c04f0a910d72dcf2683c21903ba08cd8b225e4124afc41bb2341dc40f49
Unfortunately openssl throws away y and just gives us x, so I'm not sure
if I can work out the right secret directly. I guess I can run the HMAC
twice and pick the value that worked?
Okay, we'll see if we can get any further tomorrow.
Cheers,
aj

2023-06-09 12:44:43

- reply

📅 Original date posted:2015-10-05
📝 Original message:
On Sat, Oct 03, 2015 at 11:02:39AM -0700, Richard Kiss wrote:
> > Ah, it looks like the problem is that libsec256k1 actually goes a step
> > further and runs SHA256(y||x), where "x" is the value I'm getting and y
> > is '\x02' is the y value is even and '\x03' if it's odd. If I try both,
> > one of them turns out right:
> >
> > Unfortunately openssl throws away y and just gives us x, so I'm not sure
> > if I can work out the right secret directly. I guess I can run the HMAC
> > twice and pick the value that worked?
>
> My open source library pycoin has a function that will give you Y from X,
> so you can use that or just pilfer enough code to reproduce it (it's not
> native, but it's not a very complex operation).
Yep, but I'd still need to know whether to set is_even True or False,
which is what I'm trying to find out.
And if I want to be able to send onion messages not just forward them,
then I need to know. So to this end I've implemented ECDH directly (it's
just a single EC_POINT_mul operation afterall). Aside from a bug where I
was checking eveness by comparing the last byte to 0 rather than the
last bit, all good.
Still, it'd probably be friendlier to alternative implementations for
ECDH to only use the x value when creating secrets. I've added a comment
to an existing secp256k1 pull request to that effect:
https://github.com/bitcoin/secp256k1/pull/262#issuecomment-145473597
Cheers,
aj

2023-06-09 12:44:42

- reply

📅 Original date posted:2015-09-24
📝 Original message:
Hi all,
So as was discussed last month [0] there's a potential incentive problem
if fees are only paid on success: you can lock up someone else's funds for
"TIMEOUT" and pay them nothing, just by routing a payment to someone who
won't either collect it, or redeem it. As an alternative to fines [1]
I think it's possible to offer fees directly for forwarding a transaction.
Suppose you have an onion wrapped routing message, and want to send N
bitcoins to Dave via Alice, Bob and Carol. Alice receives message MA,
Bob receives MB, etc. Alice wants "a" in fees, Bob wants "b" in fees,
etc. Then you setup HTLCs paying A as follows:
"c/2+n" bitcoins payable on receipt of R
"c/2+b/2" bitcoins payable on receipt of #(MD)
"b/2+a/2" bitcoins payable on receipt of #(MC)
"a/2" bitcoins payable on receipt of #(MB)
Alice forwards MB to Bob (encrypted), and asks if Bob is able to determine
what hashes to #(#(MB)). Bob calculates #(MB) and #(#(MB)) and gives an
ack or nak -- if there's a nak, Alice aborts the transaction. If it's
an ack, Bob begins updating the commitments to add (c/2+n), (c/2+b/2),
(b/2) HTLCs with Alice payable to Bob, and provides #(#(MB)) to Alice,
allowing her to collect the first half of her fee.
This then repeats for Bob/Carol and Carol/Dave.
This lets nodes get paid upfront (when they forward the transaction,
rather than when the transaction eventually completes), including for
failing transactions, but requires them to actually do 90% of the work
forwarding the transaction (Alice can abort accepting the HTLCs with
Bob, but Alice will miss out on half her fee, and Bob will know Alice
is cheating him out of "b" bitcoins at that point, and can close the
channel as punishment). It also gives the payer some progress information
on how the transaction is doing (the "a" transaction should be finished
shortly after the transaction has made it to Bob, etc).
Downsides: it's complicated and multiplies the number of HTLCs you have
to deal with, and it (at least somewhat) reveals the length of the route.
(If incremental fines work out, I think they're probably a better way
of dealing with delayed acceptance of transactions. Still, maybe this
turns out to be useful/interesting anyway...)
Cheers,
aj
[0] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
[1]
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000158.html

2023-06-09 12:44:41

- reply

📅 Original date posted:2015-09-30
📝 Original message:
On Wed, Sep 30, 2015 at 11:11:09AM +0930, Rusty Russell wrote:
> > (I'm not following why the state coverage testing doesn't do something
> > more like: [...]
> Sure, but that's not even close to exhaustive testing (drawing diagrams
> was just a side-effect for me).
Absolutely. But... I'm not seeing what the code actually /does/ with the
exhaustive testing? There's a lot of asserts; but I'm not sure that's
actually testing things "make sense" or just "don't crash". Maybe having
some optional output of traces for successful test cases would make it
more obvious?
eg, (and I haven't tried pulling the code apart to really understand
it or anything) I can't tell if you're testing agreeing on two HTLCs then
having the first one time out, versus the second one time out first.
Hmm:
report_trail(&t, "CLOSED with htlc in progress?");
I figured that was expected and normal protocol behaviour? Not ideal,
but if you're still communicating at all, if someone decides the channel
has to be closed, it's still always better to do a mutual close to
avoid the CSV delays and any unnecessarily elevated fees, even with
outstanding HTLCs.
That would mean CLOSE should start tracking HTLCs (and spending when
timeouts hit or R's become known) just like when a commitment is
published; so I guess that's CLOSE_WAIT_HTLCs?
Cheers,
aj

2023-06-09 12:44:41

- reply

📅 Original date posted:2015-09-24
📝 Original message:
On Thu, Sep 24, 2015 at 03:17:41PM +0930, Rusty Russell wrote:
> 4) HTLC precision increase, ceiling drop.
> As a secondary effect, 32 bits places a ceiling of 0.04 satoshi
> (currently about $10USD) on each HTLC.
This means keeping the channel balances in 64 bit counters, right?
I was thinking along the following lines:
- bitcoin txns have absolute fees (currently f = 0.1 mBTC)
- lightning has percentage fees (call it p)
- so breakeven point is a transaction amount A, where
A * p = f; ie A = f/p
- p should be less than 2%, putting a lower limit on A of 5 mBTC,
but 0.04 BTC = 40 mBTC, which is well above that.
- if A = 0.04 BTC, p = f/A = 0.25%, putting a lower limit on lightning
fees (that's for the entire path, individual hops could be lower)
I probably would have preferred capping out at about 0.1 BTC (~$23),
corresponding to lightning fees of 0.1% matching bitcoin fees of 0.1 mBTC,
but that's quibbling.
Anyway, if you want to send more than $10 via lightning you just do
multiple transactions with different R values [0], the same way you
might use two $20 notes to pay someone $40. Even $1000 would just be
100 transactions, which doesn't seem like too big a deal?
Having a small maximum is probably also useful for routing -- if you want
to send two $10 notes, send them along different routes to avoid draining
any particular channel. That also helps obscure how much is being spent.
A maximum seems pretty helpful for planning how to fund a node too --
if you know no individual transaction will be more than 0.04 BTC, you
can setup your fee schedule in 0.04 BTC increments (or greater), and
not have to worry about "if i got 30 mBTC I'd raise my fee before the
next 30 mBTC came in; but here's 60 mBTC in one hop with just 2x the
lower fee! do I accept it or reject it?"
So, hey, turns out I totally endorse this change. +1.
Cheers,
aj
[0] or just rely on the different S values the R/S method for avoiding
onion probing would automatically use

2023-06-09 12:44:40

- reply

📅 Original date posted:2015-09-29
📝 Original message:
On Thu, Sep 24, 2015 at 12:25:11PM +0200, Pierre wrote:
> > 1) Close now has an second ACK stage, which means you know the close ack
> Argh, I already have trouble understanding the rationale behind all
> the existing closing flows and states :-s Would it be possible to
> publish an updated version of the svg ? aj, any chance you could do
> the same with your 'flat' version ?
Yeah. I've updated state.py so the following flow works:
$ test/test_state_coverage --dump-states | tee STATES
$ ./state.py > update.dot
$ dot -Tsvg update.dot > update.svg
state.py is at https://github.com/ajtowns/lightning/blob/state/state.py
Updated svg is viewable at
http://azure.erisian.com.au/~aj/tmp/lightstate/simplified-states-20150929.svg
Note that some transitions are still missing, notably
PKT_UPDATE_DECLINE_HTLC.
(I'm not following why the state coverage testing doesn't do something
more like:
states = []
path_to_state = {}
for s in init_states:
path_to_states[s] = [s]
states.append(s)
i = 0
while i < len(states):
tst_state = states[i]
p = path_to_states[tst_state]
for in_pkt in all_packets:
# enter test state
simulation_init(p[0])
for setup_pkt in p[1:]:
simulation_send_pkt(setup_pkt)
# send packet
new_state, response_pkt = simulation_send_pkt(in_pkt)
# document result
dump_transition(tst_state, in_pkt, new_state, response_pkt)
# if new state, add it to list to test
if new_state not in states:
path_to_state[new_state] = p + [in_pkt]
states.append(new_state)
ie, for every state, throw every packet at it and record what happens;
assuming that any given state behaves the same no matter how you get
into it)
Cheers,
aj