Conner Fromknecht [ARCHIVE]

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

Public Key

npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2a

Profile Code

nprofile1qqspwh7j75jf0wd6yukwhk6rdm5cwmc3rd429te74x7q8e7d7j69y3sja22k7

Author Public Key

npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2a

Show more details

Last Notes

2023-06-09 13:01:23

- reply

📅 Original date posted:2020-10-20
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
Today we are writing to disclose the details of CVE-2020-26895 as a follow up to
the partial disclosure sent to lightning-dev [1].
## Abstract
Prior to v0.10.0-beta, a malicious peer could force an lnd node to accept a
high-S ECDSA signature when updating new off-chain states. Though the signatures
are valid according to consensus rules, the mempool policy would reject
transactions containing high-S values, potentially leading to loss of funds if
time-sensitive transactions cannot be relayed and confirmed. We have no evidence
of the bug being exploited in the wild.
It affects all classes of lnd nodes: routing, merchant, mobile, etc.
The vulnerability was reported privately to the lnd team by Antoine Riard.
## Background
The lightning-rfc specifies a fixed-width, 64-byte encoding used to transmit
ECDSA signatures in the Lightning protocol, which differs from the DER-encoding
used at the consensus layer. For regular, on-chain transactions, signature
serialization is handled by the btcec library's Signature.Serialize() method
[2]. This method always normalizes signatures to their low-S variant before
performing the DER-encoding to ensure that the btcec library can't _produce_
high-S signatures.
Early in lnd's history, however, serialization modeled off btcec was added to
produce DER-encoded signatures directly from the fixed-width representation,
bypassing the conversion into big.Int representation used internally by btcec.
In doing so, retaining the low-S normalization behavior was overlooked, and so
Sig.ToSignatureBytes() [3] would return high-S DER signatures whenever the
fixed-size signature was encoded with a high-S value.
During unilateral closure, this can be exploited by an attacker to cause a
second-level HTLC-success transaction from being accepted to the mempool. If the
victim is unable to patch before the HTLC's CLTV expires, the attacker can then
broadcast their HTLC-timeout transaction and recover the full value of the HTLC
minus fees. On the other hand, lnd’s cooperative close fully verifies the remote
party’s signatures using full policy-aware verification. As a result, the only
exploitation vector occurs during the force close scenario.
## Updates to Lighting RFC
As noted by Riard during the process, the lightning-rfc is lacking in terms of
specifying how nodes should validate signatures accepted off-chain. Notably, the
signatures should be checked for conformation to both consensus _and_ tx-relay
standardness rules, and rejected otherwise. Riard has confirmed that he is
planning to submit an update to the specification incorporating these
recommendations.
## Patch
This vulnerability was fixed in v0.10.0-beta by converting all witness
construction methods in lnd to accept signatures according to the
input.Signature interface introduced in PR 4172 [4], which requires the passed
object to have a Serialize() method. lnwire.Sig does not have a Serialize()
method, and so cannot satisfy the interface. As a result, the relevant call
sites were updated to pass in a btcec.Signature, forcing witness signature
serialization through btcec's Serialize() method which includes low-S
normalization.
Note: A high-S signature can be converted to a low-S one manually w/o software
changes, or by a 3rd party, assuming one is aware of the reason for rejection.
Though the above recommendation to the spec by Riard also mitigates the issue,
this approach was chosen because it could retroactively patch affected nodes if
they are upgraded before the HTLC deadline expires, as well as its covertness.
After upgrading, any outstanding broadcasts would be reattempted, this time
normalizing any previously-persisted high-S signatures into their low-S variant.
Following the disclosure, lnd will also introduce the full tx-relay standardness
checks that are to be added to the lightning-rfc, as this offers a more general
and complete approach to ensuring lnd always adheres to standardness rules.
## Timeline
04/03/2020 - Initial report from Antoine Riard
04/10/2020 - PR 4172 merged into master
04/29/2020 - lnd v0.10.0-beta released
08/20/2020 - lnd v0.11.0-beta released
10/08/2020 - Partial Disclosure sent to lightning-dev and lnd mailing list [1]
10/20/2020 - Full Disclosure sent to lightning-dev and lnd mailing list
## References
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002819.html
[2] https://github.com/btcsuite/btcd/blob/ba530c4abb35ea824a1d3c01d74969b5564c3b08/btcec/signature.go#L47
[3] https://github.com/lightningnetwork/lnd/blob/0f94b8dc624cf0e96ddc8fe1b8e3bf4b3fc4c074/lnwire/signature.go#L92
[4] https://github.com/lightningnetwork/lnd/pull/4172
[5] https://gist.github.com/ariard/fb432a9d2cd3ba24fdc18ccc8c5c6eb4
Huge thanks to Antoine Riard for the responsible disclosure and for helping to
make lnd more safu. More information can be found in Antoine’s disclosure [5].
Regards,
Conner Fromknecht
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl+PWykACgkQ59c3tn+l
ksf7Yg//WqZjtkw4Ol1fsbK+lfAkt6UENAq6Pja4/ZatkFI+U9Of3SwCNA5aAP1p
XSSk4tQptNJi3o8IoUSGLuFZVOzc6SB/vrU3l+MMVcAfgnSj1N5rqW1OLv3Lm/fH
Jz8eSvPtSEdtFt1JOC1VEd4ZEukjB8T6P/d4yudptUTk0tMrkLhLcN7byflxttU/
vG2JTtLl0uO+A2rhHkNvoUYqNLEOQssoAmShEBu+8uK56xGkRJQoBWvWN+yJDWor
MsI9awUzWrvlGU4qCD2WxVWjK7/SXK7cz4PC1XaNr0RqhucXm6lL2wn4r/G1Qqx6
z6ztMG3rHNnLI43Y1DVn2qPiLyhx1cBe/X8U9EUmA1jDv3zCKo9MmRx1gS69DQx+
rWBx3N6AIevs3aU6fF2IrwMfrX/0Xb0HT/fIDq1qhN46UZaxJTUuRkQkpJHNNajI
ze5mmussTg/cdPlSkYTt7/h0CgWN6DAEGVYp6hsPqGoH7jrsEB+wRtsihHRAXevX
dcHZRoB4OG/oKs5vYZk2LIRKr1miNSdas5T0rJA7voGMMJEa5L8nKqGfzMXsudAv
n+gVXCLPx3KjTF8yQrNu277ptGIy4AG71MQoOdxkzLtbzm2vfyDMNd14Qk3KWHVz
NACF4EXcq+oebSIj5kkiNx2jei0hdYVJGPHp8XkewRb0KuB2yDw=
=Sd09
-----END PGP SIGNATURE-----

2023-06-09 13:01:23

- reply

📅 Original date posted:2020-10-20
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
Today we are writing to disclose the details of CVE-2020-26896 as a follow up to
the partial disclosure sent to lightning-dev [1].
## Abstract
Prior to v0.11.0-beta, an lnd node could be coerced into revealing an invoice
preimage for a forwarded HTLC with a colliding payment hash. This can be
exploited to a) weaken the victim's receiver privacy by confirming the
destination of an HTLC, and/or b) under certain circumstances, result in loss of
funds to the victim by believing the invoice was paid when it only received
routing fees. We have no evidence of either case being exploited in the wild.
It affects routing nodes, i.e. any lnd node that permits HTLC forwarding and
operates as any form of merchant node (accepts payment for goods & services);
nodes that use rejecthtlc=1 are not affected.
The vulnerability was reported privately to the lnd team by Antoine Riard.
## Background
When resolving incoming HTLCs on-chain, the forwarding node is expected to
supply a valid preimage via the witness in order to claim the HTLC. Preimages
can be learned in two primary ways: by generating an invoice or receiving a
preimage as the result of a successfully forwarded HTLC. Internally, lnd tracks
these differing preimage classes in two distinct places: an invoice database and
a preimage database.
For proper handling, a node should inspect the off-chain HTLC it received to
determine whether the node was an intermediary or the final hop (indicated by an
all zeros next_hop short channel id). Final hops are intended to consult the
invoice database for preimages, while intermediaries should consult the preimage
database.
Earlier versions of lnd would incorrectly fallback to the invoice database if
the preimage database did not contain the preimage. This resulted in situations
where the node would reveal an invoice preimage, even though the victim was not
the final hop in a route.
In coordination with a triggered channel closure, an attacker can construct a
malicious HTLC through the victim, divulging the target invoice preimage
on-chain when the incoming HTLCis claimed. After disclosing the preimage, an
attacker can claim a concurrent outgoing HTLC whose CLTV has not yet expired.
his results in the HTLC's value being stolen, minus routing fees, since the
victim incorrectly believes they received the payment.
## Attack Scenario
An example of the attack goes as follows:
Assume a _real HTLC_ is routed to a malicious node, Malice, that has a channel
with sufficient outgoing bandwidth to forward to the victim, Bob, the intended
receiver of the payment.
Instead of forwarding the real HTLC, Malice creates a new _malicious HTLC_ which
has the same payment hash. The first hop’s amount should be equal or slightly
larger, the CLTV can be increased as desired up to default implementation
limits.
Malice forwards the malicious HTLC in a circular route through Bob and back to
herself, where she holds the malicious HTLC.
With the malicious HTLC locked in place, Malice triggers a unilateral close of
the Malice-Bob channel. The commitment played (from Bob’s POV) has an incoming
HTLC with the target invoice’s payment hash. The unilateral closure should be
initiated well before any of the malicious HTLC’s CLTVs expire, otherwise the
last channel in the route will also go to chain.
When the unilateral close is confirmed, Bob will promptly broadcast the
HTLC-success transaction for the malicious HTLC. Due to the bug, the preimage
provided to sweep the malicious HTLC is obtained from the invoice database as a
fallback to the (forwarded) preimage database, rather than being ignored.
The victim, Bob, has already marked the invoice settled and published the
preimage on-chain. However, the malicious HTLC is still active on Bob’s
downstream channel (and the rest of the circular route), allowing Malice to
settle the malicious HTLC she holds _after_ the invoice has already been marked
paid. This results in Bob only receiving routing fees, and the Malice
redirecting the payment to herself, while simultaneously convincing Bob of
receiving the full payment.
At this point, the malicious HTLC has been successfully pulled from Malice to
herself in a circular route, making herself whole minus routing fees (in
addition to chain fees if she was the initiator of the Malice-Bob channel).
Malice then settles the real, intercepted HTLC using the same preimage to obtain
a profit.
### Caveats
For the attack to succeed, Malice must intercept a legacy HTLC or a
single-sharded MPP HTLC. If any other concurrent MPP shard has already reached
Bob before attempting to claim on-chain, the attack will fail due to additional
safety checks added to lnd [2], preventing an invoice from being settled by a
downgraded HTLC after it has already accepted an MPP shard with a valid payment
secret.
In order to directly profit from the attack, Malice must be intercepting a
payment from an unsuspecting victim, limiting control of timing and the amount
that can be siphoned. Malice must also somehow infer or guess that Bob has the
corresponding invoice being paid.
If Malice runs the same attack without intercepting a real HTLC, she pays
routing fees, and possibly chain fees, in exchange for the invoice preimage and
identity of the receiver. However, it is possible for her to indirectly profit
from this if the service provider releases tangible goods or services to anyone
with knowledge of the invoice preimage, which is not recommended in practice.
The upstream attacker does not need to be adjacent, they only need to know which
channel to target and watch for closure. Being adjacent increases the
assuredness of pulling off an exploit, but is not strictly required.
Similarly, the downstream attacker (possibly distinct from Malice) does not need
to be adjacent, they can settle the malicious HTLC further downstream to the
same effect at the cost of more routing fees.
## Patch
This vulnerability was patched in lnd v0.11.0-beta, by properly isolating the
preimage database from the invoice database according to the HTLC's next_hop
field in commit cf739f3f [3] of PR 4157 [4]. The isolation ensures that we can
only claim forwarded HTLCs as a result of learning the preimage from an outgoing
HTLC. It also fixes the privacy leak by not revealing invoice preimages unless
the node is the final destination.
Due to the complexities involved in describing vulnerabilities over textual
mediums, the full nature of the issue wasn’t fully understood until after
v0.10.0-beta had been released. Additionally, the covert fix contained in the
v0.11.0-beta release was pushed back due to a concurrent investigation into
network instabilities resulting in unexpected channel closures.
Note, although the above patch fixes the issue, this issue could have also been
avoided by having receivers require payment secrets (BOLT 11 `s` field) since
the attackers would be unable to guess the payment secret. However, left as
optional, the attacker can always downgrade to using malicious HTLCs that omit
the payment secret.
For some time we have debated flipping the switch on requiring payment secrets
across the three major implementations. This vulnerability is further evidence
to the additional safety and privacy benefits. Now almost a year since the
initial deployment of payment secrets in lnd, the upcoming v0.12.0-beta release
of lnd is likely to make payment secrets required by default. We would welcome
other implementations to do the same.
## Timeline
04/19/2020 - Initial report from Antoine Riard
04/29/2020 - lnd v0.10.0-beta released
07/07/2020 - PR 4157 merged into master
08/20/2020 - lnd v0.11.0-beta released
10/08/2020 - Partial Disclosure sent to lightning-dev and lnd mailing list [1]
10/20/2020 - Full Disclosure sent to lightning-dev and lnd mailing list
## References
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002819.html
[2] https://github.com/lightningnetwork/lnd/blob/9f32942a90bcd91cc37a4a9c6c2fb454f534a65d/invoices/update.go#L229
[3] https://github.com/lightningnetwork/lnd/pull/4157/commits/cf739f3f87fdcb28ab45dfd48e3d18adf26e45b3
[4] https://github.com/lightningnetwork/lnd/pull/4157
[5] https://gist.github.com/ariard/6bdeb995565d1cc292753e1ee4ae402d
A big thank you to Antoine for the responsible disclosure and for helping to
make lnd more safu. More information can be found in Antoine’s disclosure [5].
Regards,
Conner Fromknecht
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl+PWzMACgkQ59c3tn+l
kseIJw//UwswUyh6BNgmi4D8NoC6olelW0dRmecqcZF7JBQa619kVFm/D7rixp33
J1YsXvZC2OLTpqmaJcJ3OvBKLVcW7CxheDp3Pm0JjrfVnmOl1NGX4CSymL6Zpou7
nFqh+nqOZ2n6o4OIv+mx0y2YANKjAVtAcr9LakubMn/3LgYzqvKKu39QGqrtz9vZ
lYGAAPU3zlAjIjFNv56xWpF0Pj9VE2mQB27w2QmbSuNtR21feOSJhJimEvmXhk6d
O0Ze78Fea+eaS+d1uyRkB7aaEKBRAA5WCtDKgSOwfEY+mHC7u5+LRasyegjlc8Ie
hYBNOsjEZqVjwIgr+lqMDbQ8B5RtW4LVro/LMYGCbVRnGuF16gHu/lkDnVgz/sY7
sbsPVG11wfVFH0U/TyJoBC8qOmeHMJoVsvGbY9I2XQiFw7yAbWxEdU+7mMhQZA2Z
Zd9pl0ATByLFPyg58gA6G4JV+F45DvYrG3jj6cdkUvL2nQST08IZtTjnDxAnkDTk
HwnJo0fd7vsixEyssTMuSCjbGSaPDMPCkmNQg8PAhhoIK8MeKUlylCKJuM6gMWeW
YypzGBmE6O7OtoMTOYFWysU67edVXgQTV2dD/PE6abTYOfS79gvkNekU4BvW9NDE
af0JBywXovzNVshdqpijPBleOT8/QSyTdLvI78ev+zpJMsKMugU=
=PY6W
-----END PGP SIGNATURE-----

2023-06-09 13:01:06

- reply

📅 Original date posted:2020-10-08
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
We are writing to let the Lightning community know about the existence of
vulnerabilities that affect lnd versions 0.10.x and below. The full details of
these vulnerabilities will be disclosed on October 20, 2020. The circumstances
surrounding the discovery resulted in a compressed disclosure timeline compared
to our usual timeframes. We will be publishing more details about this in the
coming weeks along with a comprehensive bug bounty program.
While we have no reason to believe these vulnerabilities have been exploited in
the wild, we strongly urge the community to upgrade to lnd 0.11.0 or above ASAP.
Please ping us on the #lnd IRC channel, the LND Slack, or at
support at lightning.engineering if you need any assistance in doing so. Upgrade
instructions can be found in our installation docs:
https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md#installing-lnd.
Regards,
Conner Fromknecht
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl9/ozwACgkQ59c3tn+l
kscVvBAAk21z6tlHPkOSwfj1lBE0pqc65A6Qa927WEjN5hdUpjjof4Xo2j+GzbnN
Uoj4HGZu+koakzoVpJ4mzN+vg086zAnv+K668hhl7bbPHsQu6FqA1ALiAyy0nH6H
1yukXxpRflq53RTIVPjrEnFVdt6FCLhkCm9LuOk0a/SUf8D4b/N6OaB1Bxupeceu
QFSCIkb9kvW/Eplwkv7PEnx/IZNGIQP9F11DaKLTAjWY5RnIxmCw/oamvlP8Mxt8
/AqlzWVtPVqvwgJLhbMziraXNVV05naHrIXvbXrOI2Q7FZjdaxF+S4EKT4feuq1w
iW7NYSS/u5N2FP3yK8YIdoX0I/nwYQQcpsfbAv2dS4Ql2Td/dyREId4NcchmaKSV
N3w1jByMPWrgUtinl5WEDDOJdUKS2PHkQ95t3s/1uYDFsPz1kXJR2x37a/1AVz/K
6zQ45wFvHEopFR49hu/CV6MUvsvn4XKzPa46Ii7puaBaNqygx0RwuwlxbxCNxPNQ
v45CaCUEq2Tj3stu7YoYGntFvrXVkxXJocn51eK6D+g0bIEXxaGlPJeTuvifKMTO
3T3ZEEbCe9UhDUT8Ja2boP2IIi8wAyExGS59k0tndQGzMSjkzWZ0fzgYyyf+y4nt
r3nTCGi5WWe4y1i2KpiYZTRrQkbrNkRf+fnVdlnTS4lcgEWFFiY=
=8t9Q
-----END PGP SIGNATURE-----

2023-06-09 13:01:06

- reply

📅 Original date posted:2020-10-09
📝 Original message:
Hi all,
For those looking to verify the gpg signature, please be sure the
support email is formatted
correctly. For example, the archive replaces "@" with " at ", and
apparently google groups
trims "support" to "sup...". If you run into issues, please double
check the plaintext matches
verbatim with what was sent on lightning-dev.
Cheers,
Conner
On Thu, Oct 8, 2020 at 5:19 PM Conner Fromknecht
<conner at lightning.engineering> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> We are writing to let the Lightning community know about the existence of
> vulnerabilities that affect lnd versions 0.10.x and below. The full details of
> these vulnerabilities will be disclosed on October 20, 2020. The circumstances
> surrounding the discovery resulted in a compressed disclosure timeline compared
> to our usual timeframes. We will be publishing more details about this in the
> coming weeks along with a comprehensive bug bounty program.
>
> While we have no reason to believe these vulnerabilities have been exploited in
> the wild, we strongly urge the community to upgrade to lnd 0.11.0 or above ASAP.
> Please ping us on the #lnd IRC channel, the LND Slack, or at
> support at lightning.engineering if you need any assistance in doing so. Upgrade
> instructions can be found in our installation docs:
> https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md#installing-lnd.
>
> Regards,
> Conner Fromknecht
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl9/ozwACgkQ59c3tn+l
> kscVvBAAk21z6tlHPkOSwfj1lBE0pqc65A6Qa927WEjN5hdUpjjof4Xo2j+GzbnN
> Uoj4HGZu+koakzoVpJ4mzN+vg086zAnv+K668hhl7bbPHsQu6FqA1ALiAyy0nH6H
> 1yukXxpRflq53RTIVPjrEnFVdt6FCLhkCm9LuOk0a/SUf8D4b/N6OaB1Bxupeceu
> QFSCIkb9kvW/Eplwkv7PEnx/IZNGIQP9F11DaKLTAjWY5RnIxmCw/oamvlP8Mxt8
> /AqlzWVtPVqvwgJLhbMziraXNVV05naHrIXvbXrOI2Q7FZjdaxF+S4EKT4feuq1w
> iW7NYSS/u5N2FP3yK8YIdoX0I/nwYQQcpsfbAv2dS4Ql2Td/dyREId4NcchmaKSV
> N3w1jByMPWrgUtinl5WEDDOJdUKS2PHkQ95t3s/1uYDFsPz1kXJR2x37a/1AVz/K
> 6zQ45wFvHEopFR49hu/CV6MUvsvn4XKzPa46Ii7puaBaNqygx0RwuwlxbxCNxPNQ
> v45CaCUEq2Tj3stu7YoYGntFvrXVkxXJocn51eK6D+g0bIEXxaGlPJeTuvifKMTO
> 3T3ZEEbCe9UhDUT8Ja2boP2IIi8wAyExGS59k0tndQGzMSjkzWZ0fzgYyyf+y4nt
> r3nTCGi5WWe4y1i2KpiYZTRrQkbrNkRf+fnVdlnTS4lcgEWFFiY=
> =8t9Q
> -----END PGP SIGNATURE-----

2023-06-09 12:57:32

- reply

📅 Original date posted:2019-12-03
📝 Original message:
Good evening,
> I didn't think this was the design. The update transaction can spend any
prior, with a fixed script, due to NOINPUT.
>From my reading of the final construction, each update transaction has a
unique script to bind settlement transactions to exactly one update.
> My understanding is that this is not logically possible?
The update transaction has no fixed txid until it commits to a particular
output-to-be-spent, which is either the funding/kickoff txout, or a
lower-`nLockTime` update transaction output.
> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no
txid it can spend, if it is constrained to spend a particular update
transaction.
This is also my understanding. Any presigned descendants of a NOINPUT txn
must also use NOINPUT as well. This chain must continue until a signer is
online to bind a txn to a confirmed input. The unique settlement keys thus
prevent rebinding of settlement txns since NOINPUT with a shared script
would be too liberal.
Cheers,
Conner
On Mon, Dec 2, 2019 at 18:55 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Rusty,
>
> > > Hi all,
> > > I recently revisited the eltoo paper and noticed some things related
> > > watchtowers that might affect channel construction.
> > > Due to NOINPUT, any update transaction can spend from any other, so
> > > in theory the tower only needs the most recent update txn to resolve
> > > any dispute.
> > > 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 didn't think this was the design. The update transaction can spend
> > any prior, with a fixed script, due to NOINPUT.
> >
> > The settlement transaction does not use NOINPUT, and thus can only
> > spend the matching update.
>
> My understanding is that this is not logically possible?
> The update transaction has no fixed txid until it commits to a particular
> output-to-be-spent, which is either the funding/kickoff txout, or a
> lower-`nLockTime` update transaction output.
> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no
> txid it can spend, if it is constrained to spend a particular update
> transaction.
>
> Unless I misunderstand how update transactions work, or what settlement
> transactions are.
>
> Regards,
> ZmnSCPxj
>
--
—Sent from my Spaceship
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191202/00acdf73/attachment-0001.html>

2023-06-09 12:57:28

- reply

📅 Original date posted:2019-11-26
📝 Original message:
Hi all,
I recently revisited the eltoo paper and noticed some things related
watchtowers that might affect channel construction.
Due to NOINPUT, any update transaction _can_ spend from any other, so
in theory the tower only needs the most recent update txn to resolve
any dispute.
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.
Naively then a tower could store settlement keys for all states,
permitting it to reconstruct arbitrary witness scripts for any given
sequence of confirmed update txns.
So far, the only work around I’ve come up with to avoid this is to
give the tower an extended parent pubkey for each party, and then
derive non-hardened settlement keys on demand given the state numbers
that get confirmed. It's not the most satisfactory solution though,
since leaking one hot settlement key now compromises all sibling
settlement keys.
Spending the unique witness programs is mentioned somewhat in section
4.1.4, which refers to deriving keys via state numbers, but to me it
reads mostly from the PoV of the counterparties and not a third-party
service. Is requiring non-hardened keys a known consequence of the
construction? Are there any alternative approaches folks are aware of?
Cheers,
Conner

2023-06-09 12:55:10

- reply

📅 Original date posted:2019-06-14
📝 Original message:
Hi Paberlance,
As ZmnSCPxj mentioned, it should be possible to so after TLV and related
dependencies are finalized.
However I don’t think embedding an invoice in the onion is the most
efficient way to do this. Once a spontaneous payments protocol is
established, it should be sufficient to embed, minimally, the sender’s
pubkey, and perhaps some hop hints if the node is private.
Obviously this leaks the sender’s identity, but no more than an invoice
would. IMO leaking the sender’s pubkey in every payment (even ones that
might not be refunded) seems like pretty big drawback. That being said, the
same info could probably be provided externally (or out of band) if the
sender really does want to be refunded and offer better privacy for
non-refunded payments.
Cheers,
Conner
On Thu, Jun 13, 2019 at 23:16 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Paberlance,
>
> You may be interested in the current work with "TLV" that is on-going at
> the spec level now.
>
> This will allow a sort of key-value map to be sent on every payment.
>
> It would be possible, *once TLV has been finalized*, to propose the
> addition of such data in a Lightning payment.
>
> As of now, there is no easy way to transmit extra application-level data
> on each payment.
>
> The dependencies, as I understand them, are:
>
> refund invoice on payment -> application-specific data TLV -> TLV spec ->
> variable-length onion packet
>
>
> Variable-length onion packet should finalize "soon" for some definition of
> "soon", if my understanding is correct.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, June 14, 2019 1:53 PM, Paberlance via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Hello Lightning Devs,
> >
> > i was wondering about the following idea: What if you attach a refund
> invoice to any LN payment. With this the recipient then has the possibility
> to refund, fully, partially or eventually tipping even a higher payment
> amount back to the sender.
> >
> > From the user side, the userwallet pays just as normal Lightning
> Invoice, but attached along with the payment of 0 sat invoice back to the
> seller. From a UX perspective, this all happens is controlled by the
> wallet, which must agree on a protocol for embedding the return invoice
> with the LN payment.
> >
> > On the recipee side, a normal LN invoice is recieved and optionally
> store that invoice to be able to perform a spontaneous refund later in time
> if he wants.As the invoice amount is not predefined, the seller is free to
> refund any payment, just bounded to the invoice timeout. Probably the payer
> will be motivated to issue invoices with a high expiry time-out.
> >
> > Possible Usecases:
> >
> > *Promotions, like: Every 100x Purchaser wins a prize, gets the order for
> free.
> >
> > *Refunds: I order something, cancel the transaction, seller refunds the
> transaction partially, charging a service fee that he does not return.
> >
> > *Safety deposits: You rent a car, the company keeps the payment as
> safety deposit, that gets reverted as soon as the car is returned.
> >
> > *Spontanous payouts in games
> >
> > Alternatives:
> >
> > *Hodl invoice, can achieve the same goal to refund the customer, but
> limited as it's an "all or nothing refund" option. Amount can't be more
> than the actual payment.
> > https://github.com/lightningnetwork/lnd/pull/2022
> >
> > *"Spontaneous LN invoice creation " with server that acts as a lookup
> proxy that handles the lightning creation on request. Inspiration:
> @georgevaccaro
> >
> > Requirements:
> >
> > Payer has to generate a invoice and provide it encoded in the payment
> request as payload.
> > Reciver: must be able to settle the actual payment. And optionaly he may
> support the feature After storing the refund invoice, he then has the
> ability to decice if or how he will use it to refunde the client in the
> future.
> >
> > Does this exist yet? What people can help me with this idea?
> >
> > Any ressources or hints to digg deeper, built on top of that idea?
> >
> > Paberlance
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
—Sent from my Spaceship
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190613/3ebd8d8a/attachment-0001.html>

2023-06-09 12:52:54

- reply

📅 Original date posted:2018-11-15
📝 Original message:
Hi ZmnSCPxj,
Precisely, something like that is what I had in mind.
Since the max message size is 65KB, one option could be to only allow
the varint to
be max 2 bytes where:
- if the 8th bit is not set, the lowest 7 bits of the first bytes
translate to 0 - 127
- if the 8th bit is set, this implies that the second byte is also
treated as part of the
length, and the total value is 0x7f & first byte + second byte << 7
This would be fairly straightforward to implement, at the cost of
limiting a particular
field to 2^15 bytes. I wonder, is this too restrictive?
At the same time, we could offer a varint that could extend up to the
three bytes.
The third byte would only come in to play if the length of the field
is greater than
2^14 - 1. The argument could be made that for values of this size, one
extra byte
is irrelevant compared to the size of these larger fields.
Cheers,
Conner
On Thu, Nov 15, 2018 at 1:45 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Conner et al,
>
> > > > 5. `len` - one byte or two? I believe we tend to use two bytes for various
> > > > lengths.
> > > >
> > >
> > > Maybe varint? One byte is not enough for all lengths, but two seems excessive
> > > for uint8 or even uint32.
> >
> > Given that messages are currently only up to 65536 bytes total, is that not a bit much?
>
> Sorry, I misunderstood.
>
> This is varint, correct? http://learnmeabitcoin.com/glossary/varint
>
> If so, I think this is good idea.
> It seems we do not have varint currently in Lightning (at least the parts I am familiar with).
> I suppose the t-l-v being in a different BOLT would let us make some section or part for describing `varint`.
>
> Regards,
> ZmnSCPxj

2023-06-09 12:52:53

- reply

📅 Original date posted:2018-11-15
📝 Original message:
Hi ZmnSCPxj,
Thanks for writing this up! I had started an email, but you beat me to it :)
> 1. For a sequence of `type,len,value`, each `type` must be unique. --
> accepted.
To add to this, it seemed that there was some agreement that repeated fields
should be serialized under a single root key, since a receiver can't know if a
field is allowed to have duplicates if they don't understand the field.
> For a sequence of `type,len,value`, the `type`s must be in ascending order
> -- not explicitly accepted or rejected. It would be easier to check
> uniqueness > (the previous rule we accepted) here for a naive parser (keep
> track of some "minimum allowed type" that initializes at zero, check current
> type >= this, update to current type + 1) if `type`s are in ascending order.
Yep ascending makes sense to me, for the reasons you stated.
> 1, `type` - one byte or two?
I'd lean towards one, if a message has 256 optional fields, it might be time to
consider a new message type altogether.
> 3. `type` - does "it's OK to be odd" apply? i.e. if an even `type` that is
> not known is found, crash and burn. But intent of this system is for future
> expansion for optional fields, so...?
Perhaps this depends on context:
- for gossip messages, I think the primary concern is not breaking signature
validation, and that these would need to remain optional for backwards
compatibility.
- for link-level messages, we have a little more control. I imagined the fields
would be gated by feature bit negotiation, and deviating from
unsupported/required would result in being disconnected.
> 5. `len` - one byte or two? I believe we tend to use two bytes for various
> lengths.
Maybe varint? One byte is not enough for all lengths, but two seems excessive
for uint8 or even uint32.
> 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other
> messages and so on simply refer to.
Indeed, are you thinking we'd use this to add new fields proposed in 1.1?
In addition to the above, do we also want to flesh out what sub-TLV structures
would look like? Or perhaps that isn't necessary, if we can continue adding more
root-level keys.
--Conner
On Wed, Nov 14, 2018 at 8:54 PM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning list,
>
> An item added discussed in the summit was the proposed "type,len,value", which is added to the end of messages and other intercommunication structures (invoices and so on).
> This would allow some transition to future additional fields while maintaining backward compatibility.
>
> I believe these were brought up:
>
> 1. For a sequence of `type,len,value`, each `type` must be unique. -- accepted.
> 2. For a sequence of `type,len,value`, the `type`s must be in ascending order -- not explicitly accepted or rejected. It would be easier to check uniqueness (the previous rule we accepted) here for a naive parser (keep track of some "minimum allowed type" that initializes at zero, check current type >= this, update to current type + 1) if `type`s are in ascending order.
>
> Now for bikeshedding:
>
> 1, `type` - one byte or two?
> 2. `type` - maybe some other name, since we already use `type` for messages? How about, `key` instead?
> 3. `type` - does "it's OK to be odd" apply? i.e. if an even `type` that is not known is found, crash and burn. But intent of this system is for future expansion for optional fields, so...?
> 4. `len` - measures bytes of `value`, obviously since if the receiver does not know the `type` then it cannot know what unit is used for the `value`.
> 5. `len` - one byte or two? I believe we tend to use two bytes for various lengths.
> 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other messages and so on simply refer to.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:52:46

- reply

📅 Original date posted:2018-11-21
📝 Original message:
Hi all,
> But it's unnecessary for the recipient to know the total amount I meant
> to pay; they just need to return the receipt once it exceeds the amount
> they want.
I think it’s true that the recipient doesn’t need to know necessarily, but
sending the intended amount is more robust IMO, since it provides an order
invariant hint for when the receiver can safely settle.
If the sender does amount fuzzing (as CL does) or adds a tip, it’s possible
for the final partial payment to be less than `amount_to_pay` -
`invoice_amount`, causing the sender to settle prematurely. Otherwise, we
might want to specify that no split should be less than the amount
overpaid.
Of course, if that amount never comes through yet the invoice is satisfied,
the receiver can always choose to settle even if the remaining amount never
arrives.
Cheers,
Conner
On Wed, Nov 21, 2018 at 14:55 Rusty Russell <rusty at rustcorp.com.au> wrote:
> Johan Torås Halseth <johanth at gmail.com> writes:
> > Seems like we can restrict the changes to BOLT11 by having the receiver
> > assume NAMP for incoming payments < invoice_amount. (with some timeout of
> > course, but that would need to be the case even when the sender is
> > signalling NAMP).
>
> This would effectively become a probe for Base AMP; if you get a partial
> payment error, it's because the recipient didn't support Base AMP.
>
> Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then
> it's explicitly opt-in for both sides and doesn't affect existing nodes
> in any way.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
—Sent from my Spaceship
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/afe803d2/attachment.html>

2023-06-09 12:52:41

- reply

📅 Original date posted:2018-11-13
📝 Original message:
Good morning all,
> MUST NOT forward (if an intermediate node) or claim (if the final node) unless
> it has received a total greater or equal to `intended_total_payment` in all
> incoming HTLCs for the same `payment_hash`.
I was under the impression that this would not require changes on behalf of the
intermediaries, and only need to be implemented by the sender and receiver?
If not, then nodes would need to advertise that they support this so that the
sender can be sure to route through the subset of nodes that support it.
Either way, it would seem that this constraint can only be accurately enforced
by the receiver. If any partial payments fail, then the `intended_total_payment`
through an intermediary may never arise and the payment would be held. This
would also seem to exclude the possibility of iterative path finding, since the
entire payment flow must be known up front during onion packet construction.
Seems the proposal still works without the intermediaries needing to know this?
We may want to add that the receiver:
* SHOULD fail the payment if `intended_total_payment` is less than the invoice
amount
> I'm wondering, since these payments are no longer atomic, should we name it
> accordingly?
Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more
accurate and may avoid confusion?
Cheers,
Conner
On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth <johanth at gmail.com> wrote:
>
> Good evening Z and list,
>
> I'm wondering, since these payments are no longer atomic, should we name it accordingly?
>
> Cheers,
> Johan
>
> On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Good morning list,
>>
>> I propose the below to support Base AMP.
>>
>> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>>
>> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>>
>> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
>> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>>
>> 1. type: 1 (`termination_per_hop`)
>> 2. data:
>> * [`8` : `short_channel_id`]
>> * [`8` : `amt_to_forward`]
>> * [`4` : `outgoing_cltv_value`]
>> * [`8` : `intended_total_payment`]
>> * [`4` : `zeros`]
>>
>> The contents of this hop will be the same across all paths of the Base AMP.
>> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>>
>> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>>
>> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>>
>> The receiver:
>>
>> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
>> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>>
>> The sender:
>>
>> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:52:32

- reply

📅 Original date posted:2018-11-13
📝 Original message:
Quick correction:
> Thus, the cost to perform the attack would be many orders of
> magnitude greater than the cost to back up one channel.
This was written assuming the attacker was trying to upload multiple encrypted
blobs for the same txid, which seems like an unlikely attack vector if the tower
inherently defends against it. If instead they are just trying to fill
up the tower, the cost
is linear in the amount of blobs they send.
--Conner
On Tue, Nov 13, 2018 at 4:12 PM Conner Fromknecht
<conner at lightning.engineering> wrote:
>
> Hi ZmnSCPxj,
>
> I haven't yet gotten around to writing up everything documenting in the working
> watchtower design. However, I think we are nearing that phase where things seem
> mostly solidified and would welcome feedback before attempting to formalize it.
> Expect some follow up posts on the ML :)
>
> > From my bare knowledge of go, it seems data structures and messages so far,
> > without actual logic, but please inform me if I am incorrect.
>
> Much of the server side has been implemented, which accepts encrypted blobs from
> watchtower clients and stores them. The functionality related to scanning blocks
> and publishing justice txns has also been implemented, but has not been merged
> yet. The big remaining task is to integrate the client such that it properly
> backs up states after receiving revocations from the remote peer.
>
> > Note however that watchtowers would require to keep all encrypted blobs that
> > are keyed to the same partial txid. I.e. watchtowers need to store the pair
> > in a set with the set looking at the entire txid+blob as the identity of the
> > object. Otherwise it would be possible, if your watchtower is identified by
> > your counterparty, for the counterparty to give the commitment transaction's
> > txid with a randomly-generated blob to your watchtower before it gives the
> > revocation key to you.
> >
> > I have described the above problem before here:
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html
> > with an unsatisfactory solution.
>
> Indeed, this was great observation! The tower can't be sure which client is
> uploading the "real" blob either. In light of that, the chosen design uses a
> two level bucketing structure that maps:
>
> <txid[:16]> -> client_pubkey1 : encrypted_blob1
> -> client_pubkey2 : encrypted_blob2
>
> ensuring that different client's can't overwrite each other. Further, the tower
> will only store one blob for a given txid per client. Upon decryption, the tower
> would learn that only one of this a valid update (and possibly delete state for
> the offender).
>
> > However, this remains your counterparty best avenue of attack, is to simply
> > spam your watchtower until it runs out of resources and crashes.
>
> The client pubkeys described above are tied to what we've been referring to as a
> session. In order for a client to facilitate the attack described above, they
> would have to pay the tower for multiple sessions tied to different ephemeral
> session keys.
>
> A session grants the client the ability to store up to N blobs, where N would be
> several thousand. Thus, the cost to perform the attack would be many orders of
> magnitude greater than the cost to back up one channel. In the private tower
> case, there isn't necessarily payment, though it's more or less assumed that one
> wouldn't DOS their own tower.
>
> In practice, the tower should only ever accept sessions if it can be certain it
> has the appropriate disk-space to facilitate them, so I don't think
> there is much
> risk in the node crashing due to this. Someone could still pay to fill
> up my tower,
> but the tower would be compensated appropriately. The tower could also raise
> it's price point if it detects such behavior.
>
> > And if the watchtower identifies the user, then this leaks the privacy of the
> > user to the watchtower, and what would then be the point of encrypted blob?
>
> I believe the same session-based, encrypted-blob approach would work eltoo
> towers as well, if the concern is primarily about the channel partner presuming
> the valid blob. The general design should be readily able to serve
> eltoo clients,
> with some slight modifications to breach detection and justice txn construction.
>
> My greater concern with the update-and-replace model is that it leaks timing
> information about a particular channel to the tower, since the tower must know
> which prior state needs replacing. So even though it is possible to make eltoo
> towers constant-space per channel, IMO we're better off storing all prior
> encrypted blobs to maintain adequate privacy. On private towers, perhaps this
> privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense
> on public towers.
>
> Cheers,
> Conner
>
> On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > Good morning list,
> >
> > We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already. From my bare knowledge of go, it seems data structures and messages so far, without actual logic, but please inform me if I am incorrect.
> >
> > I assume much of the watchtowers code and design in lnd is by Conner, simply because, he discussed this on this list earlier this year.
> >
> > I have seen recently, some paper about paying watchtowers by actually simulating breaches. You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it. If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.
> >
> > Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid. I.e. watchtowers need to store the pair in a set with the set looking at the entire txid+blob as the identity of the object. Otherwise it would be possible, if your watchtower is identified by your counterparty, for the counterparty to give the commitment transaction's txid with a randomly-generated blob to your watchtower before it gives the revocation key to you. However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.
> >
> > I have described the above problem before here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html with an unsatisfactory solution.
> >
> > --
> >
> > I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.
> >
> > As I understand, in a separate thread, laolu is promoting that Decker-Russell-Osuntokun channels can simply "update" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. As I point out, unless the watchtower identifies the user somehow, this is unsafe; if I can identify your watchtower, then after you update it but before I attack, I can "update" the blob side with a randomly-generated, invalid blob. And if the watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html
> >
> > I am curious what Conner and the other lnd developers are planning for these issues? You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:52:32

- reply

📅 Original date posted:2018-11-13
📝 Original message:
Hi ZmnSCPxj,
I haven't yet gotten around to writing up everything documenting in the working
watchtower design. However, I think we are nearing that phase where things seem
mostly solidified and would welcome feedback before attempting to formalize it.
Expect some follow up posts on the ML :)
> From my bare knowledge of go, it seems data structures and messages so far,
> without actual logic, but please inform me if I am incorrect.
Much of the server side has been implemented, which accepts encrypted blobs from
watchtower clients and stores them. The functionality related to scanning blocks
and publishing justice txns has also been implemented, but has not been merged
yet. The big remaining task is to integrate the client such that it properly
backs up states after receiving revocations from the remote peer.
> Note however that watchtowers would require to keep all encrypted blobs that
> are keyed to the same partial txid. I.e. watchtowers need to store the pair
> in a set with the set looking at the entire txid+blob as the identity of the
> object. Otherwise it would be possible, if your watchtower is identified by
> your counterparty, for the counterparty to give the commitment transaction's
> txid with a randomly-generated blob to your watchtower before it gives the
> revocation key to you.
>
> I have described the above problem before here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html
> with an unsatisfactory solution.
Indeed, this was great observation! The tower can't be sure which client is
uploading the "real" blob either. In light of that, the chosen design uses a
two level bucketing structure that maps:
<txid[:16]> -> client_pubkey1 : encrypted_blob1
-> client_pubkey2 : encrypted_blob2
ensuring that different client's can't overwrite each other. Further, the tower
will only store one blob for a given txid per client. Upon decryption, the tower
would learn that only one of this a valid update (and possibly delete state for
the offender).
> However, this remains your counterparty best avenue of attack, is to simply
> spam your watchtower until it runs out of resources and crashes.
The client pubkeys described above are tied to what we've been referring to as a
session. In order for a client to facilitate the attack described above, they
would have to pay the tower for multiple sessions tied to different ephemeral
session keys.
A session grants the client the ability to store up to N blobs, where N would be
several thousand. Thus, the cost to perform the attack would be many orders of
magnitude greater than the cost to back up one channel. In the private tower
case, there isn't necessarily payment, though it's more or less assumed that one
wouldn't DOS their own tower.
In practice, the tower should only ever accept sessions if it can be certain it
has the appropriate disk-space to facilitate them, so I don't think
there is much
risk in the node crashing due to this. Someone could still pay to fill
up my tower,
but the tower would be compensated appropriately. The tower could also raise
it's price point if it detects such behavior.
> And if the watchtower identifies the user, then this leaks the privacy of the
> user to the watchtower, and what would then be the point of encrypted blob?
I believe the same session-based, encrypted-blob approach would work eltoo
towers as well, if the concern is primarily about the channel partner presuming
the valid blob. The general design should be readily able to serve
eltoo clients,
with some slight modifications to breach detection and justice txn construction.
My greater concern with the update-and-replace model is that it leaks timing
information about a particular channel to the tower, since the tower must know
which prior state needs replacing. So even though it is possible to make eltoo
towers constant-space per channel, IMO we're better off storing all prior
encrypted blobs to maintain adequate privacy. On private towers, perhaps this
privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense
on public towers.
Cheers,
Conner
On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning list,
>
> We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already. From my bare knowledge of go, it seems data structures and messages so far, without actual logic, but please inform me if I am incorrect.
>
> I assume much of the watchtowers code and design in lnd is by Conner, simply because, he discussed this on this list earlier this year.
>
> I have seen recently, some paper about paying watchtowers by actually simulating breaches. You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it. If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.
>
> Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid. I.e. watchtowers need to store the pair in a set with the set looking at the entire txid+blob as the identity of the object. Otherwise it would be possible, if your watchtower is identified by your counterparty, for the counterparty to give the commitment transaction's txid with a randomly-generated blob to your watchtower before it gives the revocation key to you. However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.
>
> I have described the above problem before here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html with an unsatisfactory solution.
>
> --
>
> I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.
>
> As I understand, in a separate thread, laolu is promoting that Decker-Russell-Osuntokun channels can simply "update" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. As I point out, unless the watchtower identifies the user somehow, this is unsafe; if I can identify your watchtower, then after you update it but before I attack, I can "update" the blob side with a randomly-generated, invalid blob. And if the watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html
>
> I am curious what Conner and the other lnd developers are planning for these issues? You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.
>
> Regards,
> ZmnSCPxj
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:52:25

- reply

📅 Original date posted:2018-11-13
📝 Original message:
Good morning all,
Taking a step back—even if key switching can be done mathematically, it seems
dubious that we would want to introduce re-routing or rendezvous routing in this
manner. If the example provided _could_ be done, it would directly violate the
wrap-resistance property of the ideal onion routing scheme defined in [1]. This
property is proven for Sphinx in section 4.3 of [2]. Schemes like HORNET [3]
support rendezvous routing and are formally proven in this model. Seems this
would be the obvious path forward, given that we've already done a considerable
amount of work towards implementing HORNET via Sphinx.
Cheers,
Conner
[1] A Formal Treatment of Onion Routing:
https://www.iacr.org/cryptodb/archive/2005/CRYPTO/1091/1091.pdf
[2] Sphinx: https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
[3] HORNET: https://arxiv.org/pdf/1507.05724.pdf
On Mon, Nov 12, 2018 at 8:47 PM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Christian,
>
> I am nowhere near a mathematician, thus, cannot countercheck your expertise here (and cannot give a counterproposal thusly).
>
> But I want to point out the below scenarios:
>
> 1. C is the payer. He is in contact with an unknown payee (who in reality is E). E provides the onion-wrapped route D->E with ephemeral key and other data necessary, as well as informing C that D is the rendez-vous point. Then C creates a route from itself to D (via channel C->D or via C->A->D).
>
> 2. B is the payer. He knows the entire route B->C->D->E and knows that payee is C. Unfortunately the C<->D channel is low capacity or down or etc etc. At C, B has provided the onion-wrapped route D->E with ephemeral key and other data necessary, as well as informing to C that D is the next node. Then C either pays via C->D or via C->A->D.
>
> Even if there is an off-by-one error in our thinking about rendez-vous nodes, could it not be compensated also by an off-by-one in the link-level payment splitting via intermediary rendez-vous node?
> In short, D is the one that switches keys instead of A.
>
> The operation of processing a hop would be:
>
> 1. Unwrap the onion with current ephemeral key.
> 2. Dispatch based on realm byte.
> 2.1. If realm byte 0:
> 2.1.1. Normal routing behavior, extract HMAC, etc etc
> 2.2. If realm byte 2 "switch ephemeral keys":
> 2.2.1. Set current ephemeral key to bytes 1 -> 32 of packet.
> 2.2.2. Shift onion by one hop packet.
> 2.2.3. Goto 1.
>
> Would that not work?
> (I am being naive here, as I am not a mathist and I did not understand half what you wrote, sorry)
>
> Then at C, we have the onion from D->E, we also know the next ephemeral key to use (we can derive it since we would pass it to D anyway).
> It rightshifts the onion by one, storing the next ephemeral key to the new hop it just allocated.
> Then it encrypts the onion using a new ephemeral key that it will use to generate the D<-A<-C part of the onion.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, November 13, 2018 11:45 AM, Christian Decker <decker.christian at gmail.com> wrote:
>
> > Great proposal ZmnSCPxj, but I think I need to raise a small issue with
> > it. While writing up the proposal for rendez-vous I came across a
> > problem with the mechanism I described during the spec meeting: the
> > padding at the rendez-vous point would usually zero-padded and then
> > encrypted in one go with the shared secret that was generated from the
> > previous ephemeral key (i.e., the one before the switch). That ephemeral
> > key is not known to the recipient (barring additional rounds of
> > communication) so the recipient would be unable to compute the correct
> > MACs. There are a number of solutions to this, basically setting the
> > padding to something that the recipient could know when generating its
> > half onion.
> >
> > My current favorite goes like this:
> >
> > 1. Rendez-vous RV receives an onion, performs ECDH like normal to get
> > the shared secret, decrypts its payload, simultaneously encrypts
> > the padding.
> >
> > 2. It extracts its per-hop payload and shifts the entire packet over
> > (shift its payload out and the newly generated padding in)
> >
> > 3. It then notices that it should perform an ephemeral key switch, now
> > deviating from the normal protocol (which would just be to generate
> > the new ephemeral key, serialize and forward)
> > 3.1. It zero-fills the padding that it just added (so we are in a
> > state that the recipient knew when generating its partial onion
> > 3.2 It performs ECDH with the switched in ephemeral key to get a new
> > shared secret that which is then used to unwrap one additional
> > layer of encryption, and most importantly encrypt the padding so
> > the next hop doesn't see the zero-filled padding.
> > 3.3 Only then will it generate the new ephemeral key for the next
> > hop, based on the switched in ephemeral key and the newly
> > generated shared secret, serialize the packet and forward it.
> >
> > This has the advantage of reusing all the existing machinery but
> > assembling it a bit differently, by adding a little detour when
> > generating the next onion. It involves one additional ECDH at the
> > rendez-vous, one ChaCha20 encryption and one scalar multiplication to
> > generate the next ephemeral keys. It does not need more space than the
> > single ephemeral key in the per-hop payload.
> >
> > And now for the reason that I write this as a reply to your post: with
> > this scheme it is not possible for C to find an ephemeral key that would
> > end up identical to the one that D would require to decrypt the onion
> > correctly. This would not be an issue if D is informed about this split
> > and would basically accept whatever it gets, but that kind of defeats
> > the transparency that you were going for with your proposal.
> >
> > I'm open for other proposals but I currently can't think of a way to
> > make sure that a) the recipient can deterministically generate the same
> > padding that RV will generate, and b) hide the fact that RV was indeed a
> > rendez-vous point (e.g., by leaving the padding be a well known
> > constant).
> >
> > Sorry for this problem, I had a mental off-by-one at the meeting that I
> > hadn't considered, the solution should work, but it makes this kind of
> > things a bit harder.
> >
> > Cheers,
> > Christian
> >
> > ZmnSCPxj via Lightning-dev lightning-dev at lists.linuxfoundation.org
> >
> >
> > writes:
> >
> > > Good morning list,
> > > As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.
> > > It strikes me, that even if your node has only a single channel to the next node (c-lightning), it is possible, to still perform link-level payment splitting/re-routing.
> > > For instance, consider this below graph:
> > >
> > > E<---D--->C<---B
> > > ^ /
> > > | /
> > > |L
> > > A
> > >
> > >
> > > In the above, B requests a route from B->C->D->E.
> > > However, C cannot send to D, since the channel direction is saturated in favor of D.
> > > Alternately, C can route to D via A instead. It holds the (encrypted) route from D to E. It can take that sub-route and treat it as a partial route-to-payee under rendez-vous routing, as long as node A supports rendez-vous routing.
> > > This can allow re-routing or payment splitting over multiple hops.
> > > Even though C does not know the number of remaining hops between D and the destination, its alternative is to earn nothing anyway as its only alternative is to fail the routing. At least with this, there is a chance it can succeed to send the payment to the final destination.
> > > Regards,
> > > ZmnSCPxj
> > >
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:51:58

- reply

📅 Original date posted:2018-11-09
📝 Original message:
> How do i unsubscribe from this email list? Could someone help me please.
There’s a link in the footer to the linux list, there you can enter your
email to unsubscribe
Cheers,
Conner
-- Sent from my Spaceship
On Fri, Nov 9, 2018 at 17:19 alexis petropoulos <akexis823 at hotmail.com>
wrote:
> How do i unsubscribe from this email list? Could someone help me please.
>
> Kindly,
>
> Alex
> ------------------------------
> *From:* lightning-dev-bounces at lists.linuxfoundation.org <
> lightning-dev-bounces at lists.linuxfoundation.org> on behalf of Gert-Jaap
> Glasbergen <gertjaap at gertjaap.nl>
> *Sent:* Monday, November 5, 2018 3:48:56 PM
> *To:* lightning-dev at lists.linuxfoundation.org; Rusty Russell
> *Subject:* Re: [Lightning-dev] RFC: simplifications and suggestions on
> open/accept limits.
>
>
> Op 1 nov. 2018 om 03:38 heeft Rusty Russell <rusty at rustcorp.com.au> het
> volgende geschreven:
>
>
> I believe this would render you inoperable in practice; fees are
> frequently sub-satoshi, so you would fail everything. The entire
> network would have to drop millisatoshis, and the bitcoin maximalist in
> me thinks that's unwise :)
>
>
> I can see how not wanting to use millisatoshis makes you less compatible
> with other people that do prefer using that unit of account. But in this
> case I think it's important to allow the freedom to choose.
>
> I essentially feel we should be allowed to respect the confines of the layer
> we're building upon. There's already a lot of benefits to achieve from second
> layer scaling whilst still respecting the limits of the base layer. Staying
> within those limits means optimally benefit form the security it offers.
>
> Essentially by allowing to keep satoshi as the smallest fraction, you ensure
> that everything you do off-chain is also valid and enforced by the chain when
> you need it to. It comes at trade offs though: it would mean that if someone
> routes your payment, you can only pay fees in whole satoshis - essentially
> meaning if someone wants to charge a (small) fee, you will be overpaying to
> stay within your chosen security parameters. Which is a consequence of your
> choice.
>
> I would be happy to make a further analysis on what consequences allowing this
> choice would have for the specification, and come up with a proposal on how to
> add support for this. But I guess this discussion is meant to "test the waters"
> to see how much potential such a proposal would have to eventually be included.
>
> I guess what I'm searching for is a way to achieve the freedom of choice,
> without negatively impacting other clients or users that decide to accept some
> level of trust. In my view, this would be possible - but I think working it out
> in a concrete proposal/RFC to the spec would be a logical next step.
>
> Gert-Jaap
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/c820dd77/attachment-0001.html>

2023-06-09 12:51:51

- reply

📅 Original date posted:2018-10-20
📝 Original message:
Good morning everyone,
> We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE
> for HTLC txs, without adding the "OP_TRUE"
> output to the commitment transaction
Doesn’t this require a non-zero number of HTLCs on the commitment txn? We
would still require the OP_TRUE if there are no HTLCs, right?
>From my recollection, HTLC txns with an absolute timeout won’t be accepted
in the mempool until the expiry has matured. So the commitment would have
to be held until that time before it’s descendants can bump the fee rate I
think.
I agree that we should probably modify the HTLC sighashes regardless,
though I wonder if it is a standalone replacement for OP_TRUE.
> 3. The CLTV timeout should be symmetrical to avoid
> trying to game the peer into closing. (Connor IIRC?).
I believe Jimpo proposed this :)
Best,
Conner
On Fri, Oct 19, 2018 at 03:43 Rusty Russell <rusty at rustcorp.com.au> wrote:
> Fabrice Drouin <fabrice.drouin at acinq.fr> writes:
> > Hello,
> >
> >> 1. Rather than trying to agree on what fees will be in the future, we
> > > should use an OP_TRUE-style output to allow CPFP (Roasbeef)
> >
> > We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs,
> without
> > adding the "OP_TRUE" output to the commitment transaction. We would still
> > need the update_fee message to manage onchain fees for the commit tx (but
> > not the HTLC txs) but there would be no reason anymore to refuse fee
> rates
> > that are too high and channels would not get closed anymore when there's
> a
> > spike in onchain fees.
>
> Agreed, that was in the details below:
>
> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
>
> The only problem with these proposals is that it requires you have an
> available UTXO to make the CPFP etc.
>
> Cheers,
> Rusty.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181020/a6c610be/attachment.html>

2023-06-09 12:51:40

- reply

📅 Original date posted:2018-10-19
📝 Original message:
Good evening all,
Thank you Rusty for starting us down this path :) and to ZmnSCPxj and Lisa
for
your thoughts. I think this narrows down the design space considerably!
In light of this, and if I'm following along, it seems our hand is forced in
splicing via a single on-chain transaction. In my book, this is preferable
anyway. I'd much rather push complexity off-chain than having to do a
mutli-stage splicing pipeline.
> To add some context to this, if you start accepting HTLC's for the new
balance
> after the parallel commitment is made, but before the re-anchor is buried,
> there's the potential for a race condition between a unilateral close (or
any
> revoked commitment transaction) and the re-anchoring commitment
transaction,
> that spends the 'pre-committed' UTXO of splicing in funds and the original
> funding transaction
Indeed, I'm not aware of any splicing mechanism that enables off-chain use
of
spliced-in funds before the new funding output confirms. Even in the async,
single-txn case, the new funds cannot be spent until the new funding output
confirms sufficiently.
>From my POV, the desired properties of a splice are:
1. non-blocking (asynchronous) usage of the channel
2. single on-chain txn
3. ability to RBF (have multiple pending splices)
Of these, it seems we've solidified 1 and 2. I understand the desire to not
tackle RBF on the first attempt given the additional complexity. However, I
do believe there are ways we can proceed in which our first attempt largely
coincides with supporting it in the future.
With that in mind, here are some thoughts on the proposals above.
## RBF and Multiple Splices
> 1. type: 132 (`commitment_signed`)
> 2. data:
> * [`32`:`channel_id`]
> * [`64`:`signature`]
> * [`2`:`num_htlcs`]
> * [`num_htlcs*64`:`htlc_signature`]
> * [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)
This will overflow the maximum message size of 65535 bytes for num_htlcs >
511.
I would propose sending a distinct message, which references the
`active_channel_id` and a `splice_channel_id` for the pending splice:
1. type: XXX (`commitment_splice_signed`) (`option_splice`)
2. data:
* [`32`:`active_channel_id`]
* [`32`:`splice_channel_id`]
* [`64`:`signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
This more directly addresses handling multiple pending splices, as well as
preventing us from running into any size constraints. The purpose of
including the `active_channel_id` would be to remote node locate the
spliced channel, since it may not be populated indexes containing
active channels. If we don't want to include this, the existing message
can be used without modification.
> We shouldn't allow more than one pending splice operation anyway, as
> stated in your proposal initially. We are already critically reliant on
our
> transaction being confirmed on-chain, so I don't see this as much of an
> added issue.
IMO there's no reason to limit ourselves to one pending splice at the
message
level. I think it'd be an oversight to not to plan ahead with RBF in mind,
given that funding transactions have gone unconfirmed precisely because of
improperly chosen fee rates. Arguably, funding flow should be extended to
support this as well.
CPFP works, though it's more wasteful than resigning and I'd prefer only to
do
so out of necessity, rather than relying on it. CPFP is nice because it
doesn't
require interaction, though we are already assuming the other party to be
online during the splice (unlike unilateral closes).
Adding a splice-reject message/error code should be sufficient to allow
implementations to signal that their local tolerance for number of pending
splices has been reached. It's likely we'd all start with getting one splice
working, but then the messages won't need to modified if we want to
implement
additional pending splices via RBF.
A node that wants to RBF but receives a reject can then proceed with CPFP
as a
last resort.
Are there any downsides I'm overlooking with this approach?
> | Bit Position | Name | Field
|
> | ------------- | ------------------------- |
-------------------------------- |
> | 0 | `option_channel_htlc_max` | `htlc_maximum_msat`
|
> | 1 | `option_channel_moving` | `moving_txid
|
>
> The `channel_update` gains the following field:
> * [`32`: moving_txid`] (option_channel_moving)
Do we actually need to send the `moving_txid` via a channel update? I think
it's
enough for both parties to send `channel_update`s with the
`option_channel_moving` bit set, and continue to keep the channel in our
routing
table.
If we receive later receive two `channel_update`s whose `short_channel_id`s
reference the spending transaction (and the node pubkeys are the same), we
assume the splice was successful and that this channel has been subsumed. I
think this works so long as the spending transaction doesn't contain
multiple
funding outputs, though I think the current proposal is fallible to this as
well.
To me, this proposal has the benefit of not bloating gossip bandwidth with
an
extra field that would need to parsed indefinitely, and gracefully
supporting
RBF down the road. Otherwise we'd need to gossip and store each potential
txid.
With regards to forwarding, both `short_channel_id`s would be accepted by
the
splicers for up to 100 blocks (after splice confirm?), at which point they
can
both forget the prior `short_channel_id`.
## Shachain
> I thought about restarting the revocation sequence, but it seems like
> that only saves a tiny amount since we only store log(N) entries. We
> can drop old HTLC info post-splice though, and (after some delay for
> obscurity) tell watchtowers to drop old entries I think.
I agree the additional state isn't too burdensome, and that we would still
be
able to drop watchtower state after some delay as you mentioned.
On one hand, it does seem like the opportune time to remove such state if
desired.
OTOH, it is _really_ nice from an atomicity perspective that the current
channel and (potentially) N pending channels can be revoked using a single
commitment secret and message. Doing so would mean we don't have to
modify the `revoke_and_ack` or `channel_reestablish` messages. The receiver
would just apply the commitment secrets/points to the current channel and
any
pending splices.
## Misc
> Any reason to now make the splicing_add_* messages allow one to add
several
> inputs in a single message? Given "acceptable" constraints for how large
the
> witness and pkScripts can be, we can easily enforce an upper limit on the
> number of inputs/outputs to add.
Yes, I prefer this simplification.
> Additionally, as the size of the channel is either expanding or
contracting,
> both sides should be allowed to modify things like the CSV param, reserve,
> max accepted htlc's, max htlc size, etc. Many of these parameters like the
> CSV value should scale with the size of the channel, not allowing these
> parameters to be re-negotiated could result in odd scenarios like still
> maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
> satoshis.
Agreed!
> These all seem marginal to me. I think if we start hitting max values,
> we should discuss increasing them.
Doesn't this defeat the goal of firewalling funds against individual channel
failures?
>>> One thing that I think we should lift from the multiple funding output
>>> approach is the "pre seating of inputs". This is cool as it would allow
>>> clients to generate addresses, that others could deposit to, and then
have
>>> be spliced directly into the channel. Public derivation can be used,
along
>>> with a script template to do it non-interactively, with the clients
picking
>>> up these deposits, and initiating a splice in as needed.
>>
>> How about this restatement?
>>
>> 1. Each channel has two public-key-derivation paths (BIP32) to create
onchain
>> addresses. One for each side of the channel.
>> 2. The base of the above is actually a combined private-public keypair
of both
>> sides (e.g. created via MuSig or some other protocol). Thus the
addresses
>> require cooperation of both parties to spend.
>> 3. When somebody sends to one of the onchain addresses in the path,
their
>> client detects this.
>> 4. The client updates the current transaction state, such that the new
commit
>> transaction has two inputs ( the original channel transaction and the
new UTXO).
>>
>> The above seems unsafe without trust in the other peer, as, the other
peer can
>> simply refuse to create the new commit transaction. Since the address
requires
>> both parties to spend, the money cannot be spent and there is no backoff
>> transaction that can be used. But maybe you can describe some mechanism
to
>> ensure this, if this is what is meant instead?
>
> This could easily be solved by making the destination address a Taproot
> address, which by default is just a 2-of-2, but in the uncooperative
> case it can reveal the script it commits to, which is just a timelocked
> refund that requires a single-sig. The only problem with this is that
> the refund would be non-interactive, and so the entirety of the funds,
> that may be from a third-party, need to be claimed by one endpoint,
> i.e., there is no splitting the funds in case of an uncollaborative
> refund. Not sure how important that is though, since I don't think
> third-party funds will come from unrelated parties, e.g., most of these
> funds will come from an on-chain wallet that is under the control of
> either parties so the refund should go back to that party anyway.
This can be accomplished similarly by having either (or both) party
publishing a
static address or publicly derivable address specific to the channel,
derived
from their HD seed.
Arguably, the address should perhaps be global, so that it can outlive the
lifetime of the channel, i.e. as soon as the first person deposits and a
splice
is initiated, is the address still valid for the new channel if new keys are
used? Similarly, the channel could be closed and the funds locked until
the timeout if the peer disappears.
Regardless, both approaches can be made to have equivalent amounts of
[non-]interactivity. However, the recipient isn't burdened in spending by
1) interaction with the channel peer, or 2) an absolute timeout if 1 fails,
giving the receiver more flexibility if they wish to not commit the received
funds to a splice. It also benefits from smaller witness sizes, a larger
anonymity set, etc.
In general, using a 2-of-2+timeout to stage funds for splicing doesn't offer
that much IMO. It seems the primary purpose is to prevent the funds from
being
double spent during the splice, but observe that this is still possible if
the
timeout matures, perhaps because the splice doesn't confirm in a timely
manner.
Acknowledging this, detecting double-spent inputs is still required for full
correctness. By implementing it, either party is free to propose arbitrary
inputs for a splice, which I believe reduces complexity in the long run.
Splice out,
Conner
On Tue, Oct 16, 2018 at 10:00 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning lisa,
>
> This is a good observation.
>
> Before, I'd already considered the rationale, for why channels have a
> single 2-of-2 UTXO as funding output. And it seems I should have
> considered this, prior to accepting the "parallel" construction as feasible.
>
> For sake of posterity, I leave the below writeup as a tangential to the
> design of splice (and to the design of Lightning having a single 2-of-2
> UTXOs):
>
> # 0-conf is Unsafe, Yet Lightning is Safe; Why?
>
> To accept a 0-conf transaction output, is known to be unsafe.
> Replace-by-fee is always a possibility, regardless of whether the
> transaction opts in to RBF or not: a rational miner will always accept the
> higher feerate, disregarding any "opt-in" flag that is set or not set on
> the transaction. Thus we reject any advice that claims that 0-conf is
> tenable, even for tiny amounts.
>
> Yet when viewed solely in terms of transactions, Lightning protocol uses
> transactions that are not on any block (are kept offchain). Since they are
> not in a block, they are indistinguishable from 0-conf transactions, which
> are accepted by the receiver, yet are also not on any block. One might
> argue the distinction, that a "real" 0-conf transaction exists on some
> mempool somewhere, and thus has a chance to be on a block in the future,
> but mempools have no consensus, and the existence of a transaction on some
> mempool is not a safe assurance of it existing in the mempool of the next
> winning miner.
>
> So why is Lightning safe, when 0-conf transactions are in general not safe?
>
> Again, we should focus on why 0-conf transactions in general are not safe:
> transaction replacement. Thus, 0-conf transactions can be made safe, if
> you are somehow able to ensure that replacement transactions cannot be made.
>
> For example, if you are part of an n-of-n federation that signs the
> transaction, you can always safely accept a 0-conf transaction from that
> federation paying only to you, because you can always veto any replacement
> (by simply refusing to sign) that is not in your interests.
>
> This is in fact how Lightning works: a 2-of-2 federation (the channel
> counterparties) are the signatories of the 0-conf transactions that are the
> commitment transactions of the Lightning protocol. Replacement of the
> commitment transactions is strictly guided by the protocol; both sides have
> veto rights, since the source transaction output is 2-of-2.
>
> Thus, Lightning, though it uses 0-conf transactions, is safe, because it
> prevents the replacement of a 0-conf transaction without the receiver
> allowing it, by the simple expedient of including the receiver in the
> 2-of-2 multisig guarding its single funding TXO.
>
> ## The Implications for Splice Proposals
>
> Some splice proposals involve creating the equivalent of multiple funding
> TXOs for a single channel. Such constructions are unsafe-by-default on
> Poon-Dryja.
>
> In reality, every commitment transaction (or update transaction in
> Decker-Osuntokun-Russell) is replaceable by any other commitment (or
> update) transaction for that channel. Under Poon-Dryja older transactions
> are revoked (and hence one side risks loss of their collateral) while under
> Decker-Osuntokun-Russell older transactions may be "gainsaid" (i.e. newer
> update transactions may be reanchored to consume the TXO of the older
> update transaction, thus preventing that update from truly being committed
> to).
>
> This is relevant since before a splice, the channel has a single funding
> TXO, while after the splice, the channel has multiple.
>
> In particular, a commitment (or update) transaction, that has multiple
> inputs (to consume the multiple funding TXOs), can be replaced with a
> commitment (or update) transaction that was created before the splice.
> Under Poon-Dryja, such a commitment transaction may be revoked, but this
> leaves the other funding TXOs unuseable. Under Decker-Osuntokun-Russell,
> as long as the sequence number is preserved across the splice, it is
> possible for a later update transaction with multiple inputs to simply
> gainsay the old single-input update with the new multiple-input update
> transaction. (I suppose, that this is another advantage that
> Decker-Osuntokun-Russell has).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, October 17, 2018 9:09 AM, lisa neigut <niftynei at gmail.com>
> wrote:
>
> To add some context to this, if you start accepting HTLC's for the new
> balance after the parallel commitment is made, but before the re-anchor is
> buried, there's the potential for a race condition between a unilateral
> close (or any revoked commitment transaction) and the re-anchoring
> commitment transaction, that spends the 'pre-committed' UTXO of splicing in
> funds and the original funding transaction.
>
> You can get around this by waiting until both the pre-commitment UTXO and
> the re-anchor have cleared a minimum depth before accepting HTLC's for the
> new balance totals, but that's twice as long of a wait as the first,
> synchronized re-commitment scheme that Rusty originally proposed.
>
> It also makes leaving the original funding transaction 'exposed' (ie
> Rene's version of parallel splice) untenable, as there's always the risk of
> an old state being published to consume that input. This foobars your
> current HTLC commitments.
>
> On Tue, Oct 16, 2018 at 3:31 PM Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>
>> Rusty Russell <rusty at rustcorp.com.au> writes:
>> > If we're going to do side splice-in like this, I would use a very
>> > different protocol: the reason for this protocol was to treat splice-in
>> > and splice-out the same, and inline splice-in requires wait time. Since
>> > splice-out doesn't, we don't need this at all.
>> >
>> > It would look much more like:
>> >
>> > 1. Prepare any output with script of specific form. eg:
>> > OP_DEPTH 3 OP_EQUAL OP_IF
>> > <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
>> > OP_ELSE
>> > <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> > <myrescue_pubkey> OP_CHECKSIG
>> > OP_ENDIF
>> >
>> > 1. type: 40 (`splice_in`) (`option_splice`)
>> > 2. data:
>> > * [`32`:`channel_id`]
>> > * [`8`: `satoshis`]
>> > * [`32`: `txid`]
>> > * [`4`: `txoutnum`]
>> > * [`4`: `blockheight`]
>> > * [`33`: `myrescue_pubkey`]
>> >
>> > 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
>> > data:
>> > * [`32`:`channel_id`]
>> > * [`32`: `txid`]
>> > * [`4`: `txoutnum`]
>> >
>> > 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
>> > data:
>> > * [`32`:`channel_id`]
>> > * [`32`: `txid`]
>> > * [`2`:`len`]
>> > * [`len`:`errorstr`]
>> >
>> > The recipient of `splice_in` checks that it's happy with the
>> > `blockheight` (far enough in future). Once it sees the tx referred to
>> > buried to its own `minimum_depth`, it checks output is what they
>> > claimed, then sends `update_splice_in_accept`; it's followed up
>> > `commitment_signed` like normal, but from this point onwards, all
>> > commitment txs signatures have one extra sig.
>>
>> Lisa started asking pointed questions, and so I noticed that parallel
>> splice doesn't work with Poon-Dryja channels.
>>
>> The counterparty can spend the old funding txout with a revoked spend.
>> Sure, I can take all the money from that, but what about the spliced
>> input?
>>
>> I came up with increasingly elaborate workarounds, but nothing stuck.
>>
>> Back to Plan A...
>> Rusty.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181018/d57ce11c/attachment-0001.html>

2023-06-09 12:51:40

- reply

📅 Original date posted:2018-10-23
📝 Original message:
Good evening lightning-dev,
> If we receive later receive two `channel_update`s whose
`short_channel_id`s
> reference the spending transaction (and the node pubkeys are the same), we
> assume the splice was successful and that this channel has been subsumed.
I
> think this works so long as the spending transaction doesn't contain
multiple
> funding outputs, though I think the current proposal is fallible to this
as
> well.
Thought about this some more. The main difference seems to be whether the
gossiped data is forward or backward looking. By forward looking, I mean
that we
gossip where the splice will move to, and backward looking gossips where the
splice moved from.
If we want to make the original proposal work w/ multiple funding outputs on
one splice, I think it can be accomplished by sending the funding outpoint
as
opposed to just the txid. For the backward looking proposal, the
`channel_update`
could be modified to include the `short_channel_id` of the prior funding
output.
IMO we probably want to include the extra specificity even if we don't plan
to
have multiple funding outputs on a commitment implemented tomorrow, since
outputs are what we truly care about.
Of the two, it still seems like the backward looking approach results in
less
gossiped data since are able to reference a single confirmed output by
location
(8 bytes), instead of N unconfirmed outputs by outpoint (N*34 bytes).
Another advantage I see with the backward looking splice announcments is
that
they can be properly verified before forwarding to the network by examining
the
channel lineage. In contrast, one can't be sure if the outpoint in a
forward looking
announcement will ever confirm, or even if it spends from the original
channel point
unless one also has the transaction. Until a splice does confirm, a node has
to store multiple potential splice outpoints. Seeing this, it seems to me
that
backward looking announcements are less susceptible to abuse and DOS in
this regard.
Thoughts?
Cheers,
Conner
On Thu, Oct 18, 2018 at 8:04 PM Conner Fromknecht
<conner at lightning.engineering> wrote:
> Good evening all,
>
> Thank you Rusty for starting us down this path :) and to ZmnSCPxj and Lisa
> for
> your thoughts. I think this narrows down the design space considerably!
>
> In light of this, and if I'm following along, it seems our hand is forced
> in
> splicing via a single on-chain transaction. In my book, this is preferable
> anyway. I'd much rather push complexity off-chain than having to do a
> mutli-stage splicing pipeline.
>
> > To add some context to this, if you start accepting HTLC's for the new
> balance
> > after the parallel commitment is made, but before the re-anchor is
> buried,
> > there's the potential for a race condition between a unilateral close
> (or any
> > revoked commitment transaction) and the re-anchoring commitment
> transaction,
> > that spends the 'pre-committed' UTXO of splicing in funds and the
> original
> > funding transaction
>
> Indeed, I'm not aware of any splicing mechanism that enables off-chain use
> of
> spliced-in funds before the new funding output confirms. Even in the async,
> single-txn case, the new funds cannot be spent until the new funding output
> confirms sufficiently.
>
> From my POV, the desired properties of a splice are:
> 1. non-blocking (asynchronous) usage of the channel
> 2. single on-chain txn
> 3. ability to RBF (have multiple pending splices)
>
> Of these, it seems we've solidified 1 and 2. I understand the desire to not
> tackle RBF on the first attempt given the additional complexity. However,
> I
> do believe there are ways we can proceed in which our first attempt largely
> coincides with supporting it in the future.
>
> With that in mind, here are some thoughts on the proposals above.
>
> ## RBF and Multiple Splices
>
> > 1. type: 132 (`commitment_signed`)
> > 2. data:
> > * [`32`:`channel_id`]
> > * [`64`:`signature`]
> > * [`2`:`num_htlcs`]
> > * [`num_htlcs*64`:`htlc_signature`]
> > * [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)
>
> This will overflow the maximum message size of 65535 bytes for num_htlcs >
> 511.
>
> I would propose sending a distinct message, which references the
> `active_channel_id` and a `splice_channel_id` for the pending splice:
>
> 1. type: XXX (`commitment_splice_signed`) (`option_splice`)
> 2. data:
> * [`32`:`active_channel_id`]
> * [`32`:`splice_channel_id`]
> * [`64`:`signature`]
> * [`2`:`num_htlcs`]
> * [`num_htlcs*64`:`htlc_signature`]
>
> This more directly addresses handling multiple pending splices, as well as
> preventing us from running into any size constraints. The purpose of
> including the `active_channel_id` would be to remote node locate the
> spliced channel, since it may not be populated indexes containing
> active channels. If we don't want to include this, the existing message
> can be used without modification.
>
> > We shouldn't allow more than one pending splice operation anyway, as
> > stated in your proposal initially. We are already critically reliant on
> our
> > transaction being confirmed on-chain, so I don't see this as much of an
> > added issue.
>
> IMO there's no reason to limit ourselves to one pending splice at the
> message
> level. I think it'd be an oversight to not to plan ahead with RBF in mind,
> given that funding transactions have gone unconfirmed precisely because of
> improperly chosen fee rates. Arguably, funding flow should be extended to
> support this as well.
>
> CPFP works, though it's more wasteful than resigning and I'd prefer only
> to do
> so out of necessity, rather than relying on it. CPFP is nice because it
> doesn't
> require interaction, though we are already assuming the other party to be
> online during the splice (unlike unilateral closes).
>
> Adding a splice-reject message/error code should be sufficient to allow
> implementations to signal that their local tolerance for number of pending
> splices has been reached. It's likely we'd all start with getting one
> splice
> working, but then the messages won't need to modified if we want to
> implement
> additional pending splices via RBF.
>
> A node that wants to RBF but receives a reject can then proceed with CPFP
> as a
> last resort.
>
> Are there any downsides I'm overlooking with this approach?
>
> > | Bit Position | Name | Field
> |
> > | ------------- | ------------------------- |
> -------------------------------- |
> > | 0 | `option_channel_htlc_max` | `htlc_maximum_msat`
> |
> > | 1 | `option_channel_moving` | `moving_txid
> |
> >
> > The `channel_update` gains the following field:
> > * [`32`: moving_txid`] (option_channel_moving)
>
> Do we actually need to send the `moving_txid` via a channel update? I
> think it's
> enough for both parties to send `channel_update`s with the
> `option_channel_moving` bit set, and continue to keep the channel in our
> routing
> table.
>
> If we receive later receive two `channel_update`s whose `short_channel_id`s
> reference the spending transaction (and the node pubkeys are the same), we
> assume the splice was successful and that this channel has been subsumed. I
> think this works so long as the spending transaction doesn't contain
> multiple
> funding outputs, though I think the current proposal is fallible to this as
> well.
>
> To me, this proposal has the benefit of not bloating gossip bandwidth with
> an
> extra field that would need to parsed indefinitely, and gracefully
> supporting
> RBF down the road. Otherwise we'd need to gossip and store each potential
> txid.
>
> With regards to forwarding, both `short_channel_id`s would be accepted by
> the
> splicers for up to 100 blocks (after splice confirm?), at which point they
> can
> both forget the prior `short_channel_id`.
>
> ## Shachain
>
> > I thought about restarting the revocation sequence, but it seems like
> > that only saves a tiny amount since we only store log(N) entries. We
> > can drop old HTLC info post-splice though, and (after some delay for
> > obscurity) tell watchtowers to drop old entries I think.
>
> I agree the additional state isn't too burdensome, and that we would still
> be
> able to drop watchtower state after some delay as you mentioned.
>
> On one hand, it does seem like the opportune time to remove such state if
> desired.
>
> OTOH, it is _really_ nice from an atomicity perspective that the current
> channel and (potentially) N pending channels can be revoked using a single
> commitment secret and message. Doing so would mean we don't have to
> modify the `revoke_and_ack` or `channel_reestablish` messages. The receiver
> would just apply the commitment secrets/points to the current channel and
> any
> pending splices.
>
> ## Misc
>
> > Any reason to now make the splicing_add_* messages allow one to add
> several
> > inputs in a single message? Given "acceptable" constraints for how large
> the
> > witness and pkScripts can be, we can easily enforce an upper limit on the
> > number of inputs/outputs to add.
>
> Yes, I prefer this simplification.
>
> > Additionally, as the size of the channel is either expanding or
> contracting,
> > both sides should be allowed to modify things like the CSV param,
> reserve,
> > max accepted htlc's, max htlc size, etc. Many of these parameters like
> the
> > CSV value should scale with the size of the channel, not allowing these
> > parameters to be re-negotiated could result in odd scenarios like still
> > maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
> > satoshis.
>
> Agreed!
>
> > These all seem marginal to me. I think if we start hitting max values,
> > we should discuss increasing them.
>
> Doesn't this defeat the goal of firewalling funds against individual
> channel
> failures?
>
> >>> One thing that I think we should lift from the multiple funding output
> >>> approach is the "pre seating of inputs". This is cool as it would allow
> >>> clients to generate addresses, that others could deposit to, and then
> have
> >>> be spliced directly into the channel. Public derivation can be used,
> along
> >>> with a script template to do it non-interactively, with the clients
> picking
> >>> up these deposits, and initiating a splice in as needed.
> >>
> >> How about this restatement?
> >>
> >> 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain
> >> addresses. One for each side of the channel.
> >> 2. The base of the above is actually a combined private-public keypair
> of both
> >> sides (e.g. created via MuSig or some other protocol). Thus the
> addresses
> >> require cooperation of both parties to spend.
> >> 3. When somebody sends to one of the onchain addresses in the path,
> their
> >> client detects this.
> >> 4. The client updates the current transaction state, such that the new
> commit
> >> transaction has two inputs ( the original channel transaction and the
> new UTXO).
> >>
> >> The above seems unsafe without trust in the other peer, as, the other
> peer can
> >> simply refuse to create the new commit transaction. Since the address
> requires
> >> both parties to spend, the money cannot be spent and there is no backoff
> >> transaction that can be used. But maybe you can describe some
> mechanism to
> >> ensure this, if this is what is meant instead?
> >
> > This could easily be solved by making the destination address a Taproot
> > address, which by default is just a 2-of-2, but in the uncooperative
> > case it can reveal the script it commits to, which is just a timelocked
> > refund that requires a single-sig. The only problem with this is that
> > the refund would be non-interactive, and so the entirety of the funds,
> > that may be from a third-party, need to be claimed by one endpoint,
> > i.e., there is no splitting the funds in case of an uncollaborative
> > refund. Not sure how important that is though, since I don't think
> > third-party funds will come from unrelated parties, e.g., most of these
> > funds will come from an on-chain wallet that is under the control of
> > either parties so the refund should go back to that party anyway.
>
> This can be accomplished similarly by having either (or both) party
> publishing a
> static address or publicly derivable address specific to the channel,
> derived
> from their HD seed.
>
> Arguably, the address should perhaps be global, so that it can outlive the
> lifetime of the channel, i.e. as soon as the first person deposits and a
> splice
> is initiated, is the address still valid for the new channel if new keys
> are
> used? Similarly, the channel could be closed and the funds locked until
> the timeout if the peer disappears.
>
> Regardless, both approaches can be made to have equivalent amounts of
> [non-]interactivity. However, the recipient isn't burdened in spending by
> 1) interaction with the channel peer, or 2) an absolute timeout if 1 fails,
> giving the receiver more flexibility if they wish to not commit the
> received
> funds to a splice. It also benefits from smaller witness sizes, a larger
> anonymity set, etc.
>
> In general, using a 2-of-2+timeout to stage funds for splicing doesn't
> offer
> that much IMO. It seems the primary purpose is to prevent the funds from
> being
> double spent during the splice, but observe that this is still possible if
> the
> timeout matures, perhaps because the splice doesn't confirm in a timely
> manner.
>
> Acknowledging this, detecting double-spent inputs is still required for
> full
> correctness. By implementing it, either party is free to propose arbitrary
> inputs for a splice, which I believe reduces complexity in the long run.
>
> Splice out,
> Conner
>
> On Tue, Oct 16, 2018 at 10:00 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning lisa,
>>
>> This is a good observation.
>>
>> Before, I'd already considered the rationale, for why channels have a
>> single 2-of-2 UTXO as funding output. And it seems I should have
>> considered this, prior to accepting the "parallel" construction as feasible.
>>
>> For sake of posterity, I leave the below writeup as a tangential to the
>> design of splice (and to the design of Lightning having a single 2-of-2
>> UTXOs):
>>
>> # 0-conf is Unsafe, Yet Lightning is Safe; Why?
>>
>> To accept a 0-conf transaction output, is known to be unsafe.
>> Replace-by-fee is always a possibility, regardless of whether the
>> transaction opts in to RBF or not: a rational miner will always accept the
>> higher feerate, disregarding any "opt-in" flag that is set or not set on
>> the transaction. Thus we reject any advice that claims that 0-conf is
>> tenable, even for tiny amounts.
>>
>> Yet when viewed solely in terms of transactions, Lightning protocol uses
>> transactions that are not on any block (are kept offchain). Since they are
>> not in a block, they are indistinguishable from 0-conf transactions, which
>> are accepted by the receiver, yet are also not on any block. One might
>> argue the distinction, that a "real" 0-conf transaction exists on some
>> mempool somewhere, and thus has a chance to be on a block in the future,
>> but mempools have no consensus, and the existence of a transaction on some
>> mempool is not a safe assurance of it existing in the mempool of the next
>> winning miner.
>>
>> So why is Lightning safe, when 0-conf transactions are in general not
>> safe?
>>
>> Again, we should focus on why 0-conf transactions in general are not
>> safe: transaction replacement. Thus, 0-conf transactions can be made safe,
>> if you are somehow able to ensure that replacement transactions cannot be
>> made.
>>
>> For example, if you are part of an n-of-n federation that signs the
>> transaction, you can always safely accept a 0-conf transaction from that
>> federation paying only to you, because you can always veto any replacement
>> (by simply refusing to sign) that is not in your interests.
>>
>> This is in fact how Lightning works: a 2-of-2 federation (the channel
>> counterparties) are the signatories of the 0-conf transactions that are the
>> commitment transactions of the Lightning protocol. Replacement of the
>> commitment transactions is strictly guided by the protocol; both sides have
>> veto rights, since the source transaction output is 2-of-2.
>>
>> Thus, Lightning, though it uses 0-conf transactions, is safe, because it
>> prevents the replacement of a 0-conf transaction without the receiver
>> allowing it, by the simple expedient of including the receiver in the
>> 2-of-2 multisig guarding its single funding TXO.
>>
>> ## The Implications for Splice Proposals
>>
>> Some splice proposals involve creating the equivalent of multiple funding
>> TXOs for a single channel. Such constructions are unsafe-by-default on
>> Poon-Dryja.
>>
>> In reality, every commitment transaction (or update transaction in
>> Decker-Osuntokun-Russell) is replaceable by any other commitment (or
>> update) transaction for that channel. Under Poon-Dryja older transactions
>> are revoked (and hence one side risks loss of their collateral) while under
>> Decker-Osuntokun-Russell older transactions may be "gainsaid" (i.e. newer
>> update transactions may be reanchored to consume the TXO of the older
>> update transaction, thus preventing that update from truly being committed
>> to).
>>
>> This is relevant since before a splice, the channel has a single funding
>> TXO, while after the splice, the channel has multiple.
>>
>> In particular, a commitment (or update) transaction, that has multiple
>> inputs (to consume the multiple funding TXOs), can be replaced with a
>> commitment (or update) transaction that was created before the splice.
>> Under Poon-Dryja, such a commitment transaction may be revoked, but this
>> leaves the other funding TXOs unuseable. Under Decker-Osuntokun-Russell,
>> as long as the sequence number is preserved across the splice, it is
>> possible for a later update transaction with multiple inputs to simply
>> gainsay the old single-input update with the new multiple-input update
>> transaction. (I suppose, that this is another advantage that
>> Decker-Osuntokun-Russell has).
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Wednesday, October 17, 2018 9:09 AM, lisa neigut <niftynei at gmail.com>
>> wrote:
>>
>> To add some context to this, if you start accepting HTLC's for the new
>> balance after the parallel commitment is made, but before the re-anchor is
>> buried, there's the potential for a race condition between a unilateral
>> close (or any revoked commitment transaction) and the re-anchoring
>> commitment transaction, that spends the 'pre-committed' UTXO of splicing in
>> funds and the original funding transaction.
>>
>> You can get around this by waiting until both the pre-commitment UTXO and
>> the re-anchor have cleared a minimum depth before accepting HTLC's for the
>> new balance totals, but that's twice as long of a wait as the first,
>> synchronized re-commitment scheme that Rusty originally proposed.
>>
>> It also makes leaving the original funding transaction 'exposed' (ie
>> Rene's version of parallel splice) untenable, as there's always the risk of
>> an old state being published to consume that input. This foobars your
>> current HTLC commitments.
>>
>> On Tue, Oct 16, 2018 at 3:31 PM Rusty Russell <rusty at rustcorp.com.au>
>> wrote:
>>
>>> Rusty Russell <rusty at rustcorp.com.au> writes:
>>> > If we're going to do side splice-in like this, I would use a very
>>> > different protocol: the reason for this protocol was to treat splice-in
>>> > and splice-out the same, and inline splice-in requires wait time.
>>> Since
>>> > splice-out doesn't, we don't need this at all.
>>> >
>>> > It would look much more like:
>>> >
>>> > 1. Prepare any output with script of specific form. eg:
>>> > OP_DEPTH 3 OP_EQUAL OP_IF
>>> > <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
>>> > OP_ELSE
>>> > <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
>>> > <myrescue_pubkey> OP_CHECKSIG
>>> > OP_ENDIF
>>> >
>>> > 1. type: 40 (`splice_in`) (`option_splice`)
>>> > 2. data:
>>> > * [`32`:`channel_id`]
>>> > * [`8`: `satoshis`]
>>> > * [`32`: `txid`]
>>> > * [`4`: `txoutnum`]
>>> > * [`4`: `blockheight`]
>>> > * [`33`: `myrescue_pubkey`]
>>> >
>>> > 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
>>> > data:
>>> > * [`32`:`channel_id`]
>>> > * [`32`: `txid`]
>>> > * [`4`: `txoutnum`]
>>> >
>>> > 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
>>> > data:
>>> > * [`32`:`channel_id`]
>>> > * [`32`: `txid`]
>>> > * [`2`:`len`]
>>> > * [`len`:`errorstr`]
>>> >
>>> > The recipient of `splice_in` checks that it's happy with the
>>> > `blockheight` (far enough in future). Once it sees the tx referred to
>>> > buried to its own `minimum_depth`, it checks output is what they
>>> > claimed, then sends `update_splice_in_accept`; it's followed up
>>> > `commitment_signed` like normal, but from this point onwards, all
>>> > commitment txs signatures have one extra sig.
>>>
>>> Lisa started asking pointed questions, and so I noticed that parallel
>>> splice doesn't work with Poon-Dryja channels.
>>>
>>> The counterparty can spend the old funding txout with a revoked spend.
>>> Sure, I can take all the money from that, but what about the spliced
>>> input?
>>>
>>> I came up with increasingly elaborate workarounds, but nothing stuck.
>>>
>>> Back to Plan A...
>>> Rusty.
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181022/337246c7/attachment-0001.html>

2023-06-09 12:50:11

- reply

📅 Original date posted:2018-04-17
📝 Original message:
Hi ZmnSCPxj,
> I understand. For myself, I will also wait for comment from other
c-lightning
> developers: this seems to require a bit of surgery on our code I think
> (currently construction of justice transactions is done in a separate
process,
> and we always generate a justice transaction that claims all claimable
outputs
> of the revoked commitment transaction), and we might decide to defer this
> feature for later (leaking revocation basepoint secret is easy and
requires
> maybe a few dozen sloc, but that requires a trusted WatchTower).
Certainly, it will require changes to ours as well. Would also love to hear
what the
other implementations think of such a proposal. As of now, we detect if the
commitment outputs have been spent, and if so, attempt to spend an
aggregate of
the commitment outputs and second-level outputs conditioned on which are
reported as spent. To realize this fully, we would need to also detect the
case
in which the second-level txns have already been spent, and then forgo
sweeping
them entirely (on the assumption that it has already been done by a
watchtower).
> Ah, I thought you wanted to impose some kind of contract on
> HTLC-timeout/HTLC-success to enforce this behavior, you are referring to a
> technique that the attacker might attempt to use if we use only a single
> justice transaction that claims all HTLC outputs.
Precisely, if the attacker knows that we can only sweep a particular sets of
outputs when batched, they can choose other sets that the watchtower can't
act
on. Spending them independently seems to resolve this.
-Conner
On Tue, Apr 17, 2018 at 8:02 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Conner,
>
> > I understand. It would be good to know what you have, and perhaps
> consider
> > planning a new BOLT document for such.
> Yes, that is the ultimate goal. I think it might be a little to soon to
> have a
> full-on BOLT spec. There are still some implementation details that we
> would
> like to address before formalizing everything. I am working to have
> something
> written up in the short-term documenting the approach[es] that ends up
> being
> solidified. Hopefully that can get some eyes during development, and
> perhaps
> serve as working document/rough draft.
>
>
> I understand. For myself, I will also wait for comment from other
> c-lightning developers: this seems to require a bit of surgery on our code
> I think (currently construction of justice transactions is done in a
> separate process, and we always generate a justice transaction that claims
> all claimable outputs of the revoked commitment transaction), and we might
> decide to defer this feature for later (leaking revocation basepoint secret
> is easy and requires maybe a few dozen sloc, but that requires a trusted
> WatchTower).
>
> > Sorry, I seem confused this idea. Can you give example for commitment
> with 2x
> > HTLC?
>
> Sure thing! The confirmation of second level HTLC txns can be separated by
> arbitrary delays. This is particularly true if the CLTVs have already
> expired,
> offering an attacker total control over when the txns appear on the
> network. One
> way this can happen is if the attacker iteratively broadcasts a single
> second-level txn, waits for confirmation and CSV to expire, then repeat
> with
> another second-level txn.
>
> Since the CSVs begin ticking as soon as they are included in the chain,
> the
> attacker could try to sweep each one immediately after its CSV expires.
> If the
> watchtower doesn't have the ability to sweep outputs independently, it
> would
> have no way to intercept this behavior, and prevent the breacher from
> sweeping
> individual HTLCs sequentially.
>
> Ah, I thought you wanted to impose some kind of contract on
> HTLC-timeout/HTLC-success to enforce this behavior, you are referring to a
> technique that the attacker might attempt to use if we use only a single
> justice transaction that claims all HTLC outputs.
>
>
> > 5. 0 or 1 or 2 signatures for the main outputs. These sign a single
> > transaction that claims only the main outputs.
>
> Yes, it seems necessary to separate the commitment outpoints from the HTLC
> outpoints in case the commitment txn is broadcasted before the CLTVs
> expire.
> You could try to batch these with the HTLCs, but then we get back into
> exponential territory.
>
> Agreed.
>
> > Is that approximately what is needed? Have I missed anything?
>
> Nope, I think your understanding is on point. IMO this seems to be a
> reasonable
> compromise of the tradeoffs at hand, and definitely something that could
> serve
> as an initial iteration due to its simplicity. In the future, there are definitely
> ways
> to improve on this on make it even more efficient! Though having a
> solid/workable v0 is important if it is to be deployed. I enjoy hearing
> your
> thoughts on this, thank you for your responses!
>
> Thank you for this confirmation.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/466f490f/attachment-0001.html>

2023-06-09 12:50:11

- reply

📅 Original date posted:2018-04-17
📝 Original message:
The ability for a watchtower to spend them independently seems to resolve
this*
On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht
<conner at lightning.engineering> wrote:
> Hi ZmnSCPxj,
>
>
> > I understand. For myself, I will also wait for comment from other
> c-lightning
> > developers: this seems to require a bit of surgery on our code I think
> > (currently construction of justice transactions is done in a separate
> process,
> > and we always generate a justice transaction that claims all claimable
> outputs
> > of the revoked commitment transaction), and we might decide to defer this
> > feature for later (leaking revocation basepoint secret is easy and
> requires
> > maybe a few dozen sloc, but that requires a trusted WatchTower).
>
> Certainly, it will require changes to ours as well. Would also love to
> hear what the
> other implementations think of such a proposal. As of now, we detect if the
>
> commitment outputs have been spent, and if so, attempt to spend an
> aggregate of
> the commitment outputs and second-level outputs conditioned on which are
> reported as spent. To realize this fully, we would need to also detect the
> case
> in which the second-level txns have already been spent, and then forgo
> sweeping
> them entirely (on the assumption that it has already been done by a
> watchtower).
>
>
>
> > Ah, I thought you wanted to impose some kind of contract on
> > HTLC-timeout/HTLC-success to enforce this behavior, you are referring
> to a
> > technique that the attacker might attempt to use if we use only a single
> > justice transaction that claims all HTLC outputs.
>
> Precisely, if the attacker knows that we can only sweep a particular sets
> of
> outputs when batched, they can choose other sets that the watchtower can't
> act
> on. Spending them independently seems to resolve this.
>
>
>
> -Conner
>
> On Tue, Apr 17, 2018 at 8:02 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Conner,
>>
>> > I understand. It would be good to know what you have, and perhaps
>> consider
>> > planning a new BOLT document for such.
>> Yes, that is the ultimate goal. I think it might be a little to soon to
>> have a
>> full-on BOLT spec. There are still some implementation details that we
>> would
>> like to address before formalizing everything. I am working to have
>> something
>> written up in the short-term documenting the approach[es] that ends up
>> being
>> solidified. Hopefully that can get some eyes during development, and
>> perhaps
>> serve as working document/rough draft.
>>
>>
>> I understand. For myself, I will also wait for comment from other
>> c-lightning developers: this seems to require a bit of surgery on our code
>> I think (currently construction of justice transactions is done in a
>> separate process, and we always generate a justice transaction that claims
>> all claimable outputs of the revoked commitment transaction), and we might
>> decide to defer this feature for later (leaking revocation basepoint secret
>> is easy and requires maybe a few dozen sloc, but that requires a trusted
>> WatchTower).
>>
>> > Sorry, I seem confused this idea. Can you give example for commitment
>> with 2x
>> > HTLC?
>>
>> Sure thing! The confirmation of second level HTLC txns can be separated
>> by
>> arbitrary delays. This is particularly true if the CLTVs have already
>> expired,
>> offering an attacker total control over when the txns appear on the
>> network. One
>> way this can happen is if the attacker iteratively broadcasts a single
>> second-level txn, waits for confirmation and CSV to expire, then repeat
>> with
>> another second-level txn.
>>
>> Since the CSVs begin ticking as soon as they are included in the chain,
>> the
>> attacker could try to sweep each one immediately after its CSV expires.
>> If the
>> watchtower doesn't have the ability to sweep outputs independently, it
>> would
>> have no way to intercept this behavior, and prevent the breacher from
>> sweeping
>> individual HTLCs sequentially.
>>
>> Ah, I thought you wanted to impose some kind of contract on
>> HTLC-timeout/HTLC-success to enforce this behavior, you are referring to a
>> technique that the attacker might attempt to use if we use only a single
>> justice transaction that claims all HTLC outputs.
>>
>>
>> > 5. 0 or 1 or 2 signatures for the main outputs. These sign a single
>> > transaction that claims only the main outputs.
>>
>> Yes, it seems necessary to separate the commitment outpoints from the
>> HTLC
>> outpoints in case the commitment txn is broadcasted before the CLTVs
>> expire.
>> You could try to batch these with the HTLCs, but then we get back into
>> exponential territory.
>>
>> Agreed.
>>
>> > Is that approximately what is needed? Have I missed anything?
>>
>> Nope, I think your understanding is on point. IMO this seems to be a
>> reasonable
>> compromise of the tradeoffs at hand, and definitely something that could
>> serve
>> as an initial iteration due to its simplicity. In the future, there are definitely
>> ways
>> to improve on this on make it even more efficient! Though having a
>> solid/workable v0 is important if it is to be deployed. I enjoy hearing
>> your
>> thoughts on this, thank you for your responses!
>>
>> Thank you for this confirmation.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/ba5d4ec3/attachment.html>

2023-06-09 12:50:10

- reply

📅 Original date posted:2018-04-17
📝 Original message:
Good evening ZmnSCPxj,
> Also, thank you for the link.
Definitely! I had to do some digging myself to recover these hidden gems.
> I understand. It would be good to know what you have, and perhaps consider
> planning a new BOLT document for such.
Yes, that is the ultimate goal. I think it might be a little to soon to
have a
full-on BOLT spec. There are still some implementation details that we would
like to address before formalizing everything. I am working to have
something
written up in the short-term documenting the approach[es] that ends up being
solidified. Hopefully that can get some eyes during development, and perhaps
serve as working document/rough draft.
> Sorry, I seem confused this idea. Can you give example for commitment
with 2x
> HTLC?
Sure thing! The confirmation of second level HTLC txns can be separated by
arbitrary delays. This is particularly true if the CLTVs have already
expired,
offering an attacker total control over when the txns appear on the
network. One
way this can happen is if the attacker iteratively broadcasts a single
second-level txn, waits for confirmation and CSV to expire, then repeat with
another second-level txn.
Since the CSVs begin ticking as soon as they are included in the chain, the
attacker could try to sweep each one immediately after its CSV expires. If
the
watchtower doesn't have the ability to sweep outputs independently, it would
have no way to intercept this behavior, and prevent the breacher from
sweeping
individual HTLCs sequentially.
> When the commitment txid is found onchain, the WatchTower creates a single
> main output claim transaction using the 1 or 2 signatures for the main
> outputs. And for each HTLC outpoint on the commitment transaction, if it
gets
> spent, the WatchTower creates one HTLC justice transaction from the
> second-stage HTLC transaction.
Yes, this is how it would work in context of what I was suggesting.
Certainly,
there are other ways to accomplish the same thing. I don't wish to claim
that
this is the best solution available, there are a lot of tradeoffs that need
to be evaluated. I'm hoping that you and others can bring any shortcomings
to
light and help us sift through them.
> 5. 0 or 1 or 2 signatures for the main outputs. These sign a single
> transaction that claims only the main outputs.
Yes, it seems necessary to separate the commitment outpoints from the HTLC
outpoints in case the commitment txn is broadcasted before the CLTVs expire.
You could try to batch these with the HTLCs, but then we get back into
exponential territory.
> Is that approximately what is needed? Have I missed anything?
Nope, I think your understanding is on point. IMO this seems to be a
reasonable
compromise of the tradeoffs at hand, and definitely something that could
serve
as an initial iteration due to its simplicity. In the future, there
are definitely
ways
to improve on this on make it even more efficient! Though having a
solid/workable v0 is important if it is to be deployed. I enjoy hearing your
thoughts on this, thank you for your responses!
Best,
Conner
On Tue, Apr 17, 2018 at 6:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Conner,
>
>
>
>
> Hi ZmnSCPxj,
> > Can you describe the "encrypted blob" approach to me? Or point me to
> > materials?
>
> There's an awesome watchtower thread on the mailing list from 2016 that
> starts
> here [1]. It covers a broader range of possibilities than just the
> encrypted
> blob approach, and also considers other revocation schemes, e.g. elkrem.
>
> Similar to what you described, one encrypted blob approached discussed in
> that thread is:
> 1. hint = tixd[:16]
> 2. blob = Enc(data, txid[16:])
> 3. Send (hint, blob) to watchtower.
>
> Whenever a new block is mined, the watchtower checks if it has an entry
> for each
> txid[:16]. If so, it decrypts using txid[16:], assembles the justice txn,
> and
> broadcasts (assuming the reward output matches what was negotiated).
>
>
> Thank you, that is indeed similar to what I was thinking given the name
> "encrypted blob".
>
> Also, thank you for the link. I have not had much time to back-read
> anything older than 2017 in the archives. I observe that neither Poon nor
> Dryja seem to strongly participate in this list from 2017 onwards.
>
>
>
> > Do you have a description of the WatchTower protocol used in lnd? It
> may be
> > useful to be intercompatible.
> We don't have anything written up formally, though what we have currently
> operates on the design above.
>
>
> I understand. It would be good to know what you have, and perhaps consider
> planning a new BOLT document for such.
>
> Nicolas Dorier mentioned plans for BTCPay to somehow host "merchant
> support networks" where merchants may expose WatchTower endpoints, which
> other merchants may post revocation information for their channels to.
>
>
>
> I'll also take this time to brain dump some recent investigations I've
> been doing on
>
>
>
> watchtowers. TL;DR @ fin.
>
>
>
> FWIW, I've been thinking about this in the context of the simple encrypted
> blob approach, though the observations can generalize to other schemes.
>
>
>
> As Laolu mentioned, the storage requirement for the watchtower is
> dominated by
> the number of HTLC signatures included in the encrypted blob. Due to
> independence of the second stage transactions, there is a combinatoric
> blowup in
> the number of signatures that would need to be pre-signed under the
> revocation
> private key _if sweeping of HTLC outputs is batched_.
>
> If we want to batch sweep without more liberal sighash flags, I think we'd
> need to
> pre-sign n*2^n signatures. There are 2^n possible ways that n HTLCs can
> straddle
> the first and second stages, and each permutation would require n distinct
> signatures
> since the set of inputs is unique to each permutation. Needless to say,
> this isn't feasible
> with the maximum number of HTLCs allowed in the protocol.
>
>
> Yes, I thought this too.
>
>
>
> However, I have some observations that might inform an efficient set of
> signatures we can choose to include in the encrypted blobs.
>
>
>
> The first is that the HTLC timeout or HTLC success transaction _must_ be
> broadcast before the attacker can move funds back into their wallet. If
> these transactions are never mined, it is actually fine to do nothing and
> leave
> those outputs in the breached state.
>
> If/when the victim comes back online, they themselves can sign and
> broadcast
> a justice transaction that executes the revocation clause of either the
> offered or
> received HTLC scripts, based on the observed spentness of the various
> commitment
> HLTC outputs at that time. So, we can save on signature data by only
> requiring the
> watchtower to act if second stage transactions are confirmed.
>
>
> This is a good observation! I initially thought that we would have to
> provide both the first-stage and second-stage revocation signatures.
>
>
> One reallyyy nice thing about not having the watchtower sweep the HTLC
> outputs
> on the commitment txn directly is that it doesn't need to know how to
> reconstruct the more complex HTLC redeem scripts. It only needs to
> reconstruct
> commitment to-local and second-stage to-local scripts and witnesses. This
> means
> the blob primarily contains:
> - 1 revocation pubkey
> - 1 local delay pubkey
> - 1 CSV delay
> - 2 commitment signatures
> - n HTLC signatures
> and we don't have to bother sending CLTVs, local/remote htlc pubkeys, or
> payment hashes at all.
>
> The storage for this ends up being something like ~100 + 64*(2+nhtlcs)
> when you
> include other things like the sweep address.
>
>
> Thank you, that seems like a start at something that can be implemented.
>
>
> The second observation is that the second stage transactions could be
> broadcast
> sequentially such that the CSV delays don't overlap at all. In this
> event, the
> watchtower needs to sweep the HTLCs iteratively to prevent the attacker
> from
> sweeping any of the outputs as the relative timelocks expire.
>
>
> Sorry, I seem confused this idea. Can you give example for commitment
> with 2x HTLC?
>
>
> One minimal solution could be to send signatures for independent sweep
> transactions, allowing the watchtower to sweep each HTLC output
> individually.
> This is nice because it permits the watchtower to sweep exactly the
> subset of
> HTLCs that ever transition into the second stage, and under any
> permutation
> wrt. ordering of confirmed second stage transactions.
>
>
> Yes, this seems like a good general idea.
>
>
> With the single transaction per HTLC approach, the total number of
> signatures that
> are sent to the watchtower remains linear in the number HTLCs on the
> commitment
> transaction. This approach does have the downside of consuming slightly
> more
> fees, since each output is swept with a distinct transaction.
>
>
>
> However, this approach is fairly efficient in preventing the attacker
> entirely from
> moving funds from the channel into their wallet wrt. to the amount of data
> stored.
> Considering that the majority of the channel balance is expected to be in
> the commitment outputs and that hypothetically on-chains fees are offset
> by the
> remote balance, this could be an acceptable tradeoff.
>
>
>
> I suspect that in practice, most second stage transactions will be valid
> by the
> time an attacker would drop to chain. Because of this, it's possible that
> they
> could be mined in the same block as the breach transaction.
>
> If everything is mined in the same block or in quick succession, it might
> be
> worthwhile to also pre-sign a justice txn that batch sweeps all HTLCs
> directly
> from the second layer, requiring one additional signature/HTLC.
> This could be a plausible scenario if the offender breached
> unintentionally, and
> their implementation tries to proceed normally. However it does require
> all of the
> CSV delays to conincide. If that doesn't happen, the watchtower can always
> resort to sweeping the outputs individually.
>
> All in all, I think the ability to sweep each HTLC independently is
> more-or-less
> a requirement just given the complexity of how the on-chain state-space can
>
> manifest, especially if CLTVs have already expired. Other scenarios may
> be worth including on a case by case basis or if we feel they are
> justified. This
> could be handled dynamically by including some bitvector or some compact
> representation of how to reconstruct the transactions for any additional,
> included
> signatures.
>
>
> Okay. So it seems, the blob contains:
>
> 1. Revocation pubkey (from our revocation basepoint and per-commitment
> basepoint)
> 2. Their delayed payment pubkey (needed in scripts)
> 3. Our imposed to_self_delay (the setting we indicate, that we impose on
> the remote side)
> 4. Our payment pubkey
> 5. 0 or 1 or 2 signatures for the main outputs. These sign a single
> transaction that claims only the main outputs.
> 6. 0 or more second-stage HTLC revocation signatures. These sign
> individual transactions (one per HTLC) that claims only the second-stage
> HTLC output.
> 7. scriptpubkey to put all the funds in.
>
> When the commitment txid is found onchain, the WatchTower creates a single
> main output claim transaction using the 1 or 2 signatures for the main
> outputs. And for each HTLC outpoint on the commitment transaction, if it
> gets spent, the WatchTower creates one HTLC justice transaction from the
> second-stage HTLC transaction.
>
> Is that approximately what is needed? Have I missed anything?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/873b48e1/attachment-0001.html>

2023-06-09 12:50:08

- reply

📅 Original date posted:2018-04-17
📝 Original message:
Hi ZmnSCPxj,
> Can you describe the "encrypted blob" approach to me? Or point me to
> materials?
There's an awesome watchtower thread on the mailing list from 2016 that
starts
here [1]. It covers a broader range of possibilities than just the encrypted
blob approach, and also considers other revocation schemes, e.g. elkrem.
Similar to what you described, one encrypted blob approached discussed in
that thread is:
1. hint = tixd[:16]
2. blob = Enc(data, txid[16:])
3. Send (hint, blob) to watchtower.
Whenever a new block is mined, the watchtower checks if it has an entry for
each
txid[:16]. If so, it decrypts using txid[16:], assembles the justice txn,
and
broadcasts (assuming the reward output matches what was negotiated).
> Do you have a description of the WatchTower protocol used in lnd? It may
be
> useful to be intercompatible.
We don't have anything written up formally, though what we have currently
operates on the design above.
There are more complex proposals discussed allowing an encrypted blob to
reference data stored in a prior encrypted blob. Primary advantage would be
reducing the storage costs of HTLCs present on multiple successive
commitment transactions; primary disadvantage is that it's significantly
more
complex, in addition to the other points brought up by Laolu.
I'm not positive as to the extent this approach was implemented/fleshed
out, or
if any other pros/cons may have been realized in the process. I haven't done
nearly as much research as Tadge on that front, he's probably got some
extensive thoughts on the tradeoffs.
=======
I'll also take this time to brain dump some recent investigations I've been
doing on
watchtowers. TL;DR @ fin.
FWIW, I've been thinking about this in the context of the simple encrypted
blob approach, though the observations can generalize to other schemes.
As Laolu mentioned, the storage requirement for the watchtower is dominated
by
the number of HTLC signatures included in the encrypted blob. Due to
independence of the second stage transactions, there is a combinatoric
blowup in
the number of signatures that would need to be pre-signed under the
revocation
private key _if sweeping of HTLC outputs is batched_.
If we want to batch sweep without more liberal sighash flags, I think we'd
need to
pre-sign n*2^n signatures. There are 2^n possible ways that n HTLCs can
straddle
the first and second stages, and each permutation would require n distinct
signatures
since the set of inputs is unique to each permutation. Needless to say,
this isn't feasible
with the maximum number of HTLCs allowed in the protocol.
However, I have some observations that might inform an efficient set of
signatures we can choose to include in the encrypted blobs.
The first is that the HTLC timeout or HTLC success transaction _must_ be
broadcast before the attacker can move funds back into their wallet. If
these transactions are never mined, it is actually fine to do nothing and
leave
those outputs in the breached state.
If/when the victim comes back online, they themselves can sign and broadcast
a justice transaction that executes the revocation clause of either the
offered or
received HTLC scripts, based on the observed spentness of the various
commitment
HLTC outputs at that time. So, we can save on signature data by only
requiring the
watchtower to act if second stage transactions are confirmed.
One reallyyy nice thing about not having the watchtower sweep the HTLC
outputs
on the commitment txn directly is that it doesn't need to know how to
reconstruct the more complex HTLC redeem scripts. It only needs to
reconstruct
commitment to-local and second-stage to-local scripts and witnesses. This
means
the blob primarily contains:
- 1 revocation pubkey
- 1 local delay pubkey
- 1 CSV delay
- 2 commitment signatures
- n HTLC signatures
and we don't have to bother sending CLTVs, local/remote htlc pubkeys, or
payment hashes at all.
The storage for this ends up being something like ~100 + 64*(2+nhtlcs) when
you
include other things like the sweep address.
The second observation is that the second stage transactions could be
broadcast
sequentially such that the CSV delays don't overlap at all. In this event,
the
watchtower needs to sweep the HTLCs iteratively to prevent the attacker from
sweeping any of the outputs as the relative timelocks expire.
One minimal solution could be to send signatures for independent sweep
transactions, allowing the watchtower to sweep each HTLC output
individually.
This is nice because it permits the watchtower to sweep exactly the subset
of
HTLCs that ever transition into the second stage, and under any permutation
wrt. ordering of confirmed second stage transactions.
With the single transaction per HTLC approach, the total number of
signatures that
are sent to the watchtower remains linear in the number HTLCs on the
commitment
transaction. This approach does have the downside of consuming slightly more
fees, since each output is swept with a distinct transaction.
However, this approach is fairly efficient in preventing the attacker
entirely from
moving funds from the channel into their wallet wrt. to the amount of data
stored.
Considering that the majority of the channel balance is expected to be in
the commitment outputs and that hypothetically on-chains fees are offset by
the
remote balance, this could be an acceptable tradeoff.
I suspect that in practice, most second stage transactions will be valid by
the
time an attacker would drop to chain. Because of this, it's possible that
they
could be mined in the same block as the breach transaction.
If everything is mined in the same block or in quick succession, it might be
worthwhile to also pre-sign a justice txn that batch sweeps all HTLCs
directly
from the second layer, requiring one additional signature/HTLC.
This could be a plausible scenario if the offender breached
unintentionally, and
their implementation tries to proceed normally. However it does require all
of the
CSV delays to conincide. If that doesn't happen, the watchtower can always
resort to sweeping the outputs individually.
All in all, I think the ability to sweep each HTLC independently is
more-or-less
a requirement just given the complexity of how the on-chain state-space can
manifest, especially if CLTVs have already expired. Other scenarios may
be worth including on a case by case basis or if we feel they are
justified. This
could be handled dynamically by including some bitvector or some compact
representation of how to reconstruct the transactions for any additional,
included
signatures.
TL;DR: We can get away with just sweeping the second stage outputs. Sweeping
each in a distinct txn avoids combinatoric blowup of trying to batch the
sweeps. The
storage is linear in the number of HTLC outputs, and also reduces the data
required
to reconstruct the individual redeem scripts.
Any feedback or additional insights would be greatly appreciated! Let me
know if
I've overlooked anything critical :)
Cheers,
Conner
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev
/2016-August/000565.html
On Mon, Apr 16, 2018 at 11:30 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Laolu,
>
>
> Hi ZmnSCPxj,
>
> > It seems to me, that the only safe way to implement a trustless
> WatchTower,
> > is for the node to generate a fully-signed justice transaction,
> IMMEDIATELY
> > after every commitment transaction is revoked, and transmit it to the
> > WatchTower.
>
> No, one doesn't need to transmit the entire justice transaction. Instead,
> the client simply sends out the latest items in the script template, and a
> series of _signatures_ for the various breach outputs. The pre-generated
> signature means that the server is *forced* to reproduce the justice
> transaction that satisfies the latest template and signature. Upfront, free
> parameters such as breach bonus (or w/e else) can be negotiated.
>
>
> Thank you, I understand.
>
> As a result of these downside, our current implementation goes back to the
> ol' "encrypted blob" approach. One immediate benefit with this approach is
> that the outsourcing protocol isn't so coupled with the current _commitment
> protocol_. Instead, the internal payload can be typed, allowing the server
> to dispatch the proper breach protocol based on the commitment type. The
> blob approach can also support a "swap" protocol which is required for
> commitment designs that allow for O(1) outsourcer state per-client, like
> the
> scheme I presented at the last Scaling Bitcoin.
>
>
> Can you describe the "encrypted blob" approach to me? Or point me to
> materials?
>
> I imagine that in this case, the protected node hands a (txid, blob) pair
> to the WatchTower. If the WatchTower sees a transaction that matches the
> given txid, it gets some information from the actual transaction to decrypt
> the blob (e.g. use the encrypted commitment index in `nLockTime` and
> `nSequence` as a decryption key); the blob is the justice transaction (or
> just a template type and its signatures as you describe above).
>
> Do you have a description of the WatchTower protocol used in lnd? It may
> be useful to be intercompatible.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/0da51a71/attachment-0001.html>

2023-06-09 12:49:05

- reply

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

2023-06-09 12:48:58

- reply

📅 Original date posted:2018-02-07
📝 Original message:
Hi ZmnSCPxj and Laolu,
> Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting
the
> payment over multiple flows will be, very likely, more expensive,
compared to
> using a single flow.
As Laolu pointed out, we have yet to see how fees evolve on mainnet or what
will
emerge as a sane, default fee schedules. I agree that if the same
proportional
fee is used across all partial payments, then it could certainly be more
expensive.
However, it could also be the case that you were paying a needlessly high
proportional fee to begin with, because paths of sufficient capacity to the
destination were scarce. In an AMP world, there will be an abundance of
channels
that can route small, partial payments, which may itself drive down the
competitive fee rate for smaller payments. Just a hypothesis, we shall see
where
supply meets demand!
At the end of the day, the user can always fall back to regular payment if
they
expect to end up paying more fees using an AMP.
> (If we want to support multiple routes converging to an intermediate node,
> then continue routing to a different final node after routes have merged
(i.e.
> A->B->C->D, and A->E->C->D, with the payment being merged by C, who
forwards
> the combination to D), then we need to follow the current hop data
format, but
> I think supporting AMP at final payees is actually enough...
I think this is an interesting idea, sounds maybe like a
recursive/hierarchical
AMP? The ability to merge the payments seems like it would result in a
decent privacy
leak, as I believe an intermediary would have enough evidence to prove that
two
payments were merged/correlated. Simple traffic analysis would also reveal a
discrepancy in the number of incoming and outgoing packets, and possibly
other
observable differences in routing (some) AMPs vs regular payments.
FWIW the current proposal allows the paths of partial payments to overlap,
in such a scenario C would just forward the HTLCs independently. One could
send
them all along the same path if they desired! I'm assuming the intent here
is to
try and reduce total fees?
Minor correction^2:
> This should actually be (H(s_0 || s_1 || ...), s_i).
This assumes the receiver knows the indexes of each share. Without this
knowledge they would have to brute force all orderings to check the
fingerprint.
To maintain order invariance on the receiving end, I would propose sending
(0, s_i) for the first n-1 partial payments, and then (n, s_i) on the final
one.
As in the description of the basic AMP scheme, the receiver maintains a
persistent count of how many partial payments have been received for ID. If
the
receiver does not get the last payment last, the receiver just waits until
all n
have been received before deciding that its reconstructed value is BP.
The receiver can verify they've received the correct BP and n by rederiving
the
partial preimages r_i = H(BP || i) and checking that there are n outstanding
payments, one for each h_i = H(r_i). This also saves the receiving node n
additional hash invocations.
-Conner
On Tue, Feb 6, 2018 at 4:04 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Hi ZmnSCPxj,
>
> > This is excellent work!
>
> Thanks!
>
> > I think, a `globalfeatures` odd bit could be used for this. As it is
> > end-ot-end, `localfeatures` is not appropriate.
>
> Yep, it would need to be a global feature bit. In the case that we're
> sending to a destination which isn't publicly advertised, then perhaps an
> extension to BOLT-11 could be made to signal receiver support.
>
> > I believe, currently, fees have not this super-linear component
>
> Yep they don't. Arguably, we should also have a component that scales
> according to the proposed CLTV value of the outgoing HTLC. At Scaling
> Bitcoin Stanford, Aviv Zohar gave a talked titled "How to Charge Lightning"
> where the authors analyzed the possible evolution of fees on the network
> (and also suggested adding this super-linear component to extend the
> lifetime of channels). However, the talk itself focused on a very simple
> "mega super duper hub" topology. Towards the end he alluded to a
> forthcoming
> paper that had more comprehensive analysis of more complex topologies. I
> look forward to the publication of their finalized work.
>
> > Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting
> > the payment over multiple flows will be, very likely, more expensive,
> > compared to using a single flow.
>
> Well it's still to be seen how the fee structure on mainnet emerges once
> the
> network is still fully bootstrapped. AFAIK, most running on mainnet atm are
> using the default fee schedules for their respective implementations. For
> example, the default fee_base_msat for lnd is 1000 msat (1 satoshi).
>
> > I believe the `realm` byte is intended for this.
>
> The realm byte is meant to signal "forward this to the dogecoin channel".
> ATM, we just default to 0 as "Bitcoin". However, the byte itself only
> really
> need significance between the sender and the intermediate node. So there
> isn't necessarily pressure to have a globally synchronized set of realm
> bytes.
>
> > Thus, you can route over nodes that are unaware of AMP, and only provide
> > an AMP realm byte to the destination node, who, is able to reconstruct
> this
> > your AMP data as per your algorithm.
>
> Yes, the intermediate nodes don't need to be aware of the end-to-end
> protocol. For the final hop, there are actually 53 free bytes (before one
> needs to signal the existence of EOBs):
>
> * 1 byte realm
> * 8 bytes next addr (all zeroes to signal final dest)
> * 32 bytes hmac (also all zeroes for the final dest)
> * 12 bytes padding
>
> So any combo of these bytes can be used to signal more advanced protocols
> to
> the final destination.
>
>
> A correction from the prior email description:
>
> > We can further modify our usage of the per-hop payloads to send
> > (H(BP), s_i) to consume most of the EOB sent from sender to receiver.
>
> This should actually be (H(s_0 || s_1 || ...), s_i). So we still allow them
> to check this finger print to see if they have all the final shares, but
> don't allow them to preemptively pull all the payments.
>
>
> -- Laolu
>
>
> On Mon, Feb 5, 2018 at 11:12 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Laolu,
>>
>> This is excellent work!
>>
>> Some minor comments...
>>
>>
>> (Atomic Multi-path Payments). It can be experimented with on Lightning
>> *today* with the addition of a new feature bit to gate this new
>> feature. The beauty of the scheme is that it requires no fundamental
>> changes
>> to the protocol as is now, as the negotiation is strictly *end-to-end*
>> between sender and receiver.
>>
>>
>> I think, a `globalfeatures` odd bit could be used for this. As it is
>> end-ot-end, `localfeatures` is not appropriate.
>>
>> - Potential fee savings for larger payments, contingent on there being a
>> super-linear component to routed fees. It's possible that with
>> modifications to the fee schedule, it's actually *cheaper* to send
>> payments over multiple flows rather than one giant flow.
>>
>>
>> I believe, currently, fees have not this super-linear component. Indeed,
>> the existence of per-hop fees (`fee_base_msat`) means, splitting the
>> payment over multiple flows will be, very likely, more expensive, compared
>> to using a single flow. Tiny roundoffs in computing the proportional fees
>> (`fee_proportional_millionths`) may make smaller flows give a slight fee
>> advantage, but I think the multiplication of per-hop fees will dominate.
>>
>>
>> - Using smaller payments increases the set of possible paths a partial
>> payment could have taken, which reduces the effectiveness of static
>> analysis techniques involving channel capacities and the plaintext
>> values being forwarded.
>>
>>
>> Strongly agree!
>>
>>
>> In order to include the three tuple within the per-hop payload for the
>> final
>> destination, we repurpose the _first_ byte of the un-used padding bytes in
>> the payload to signal version 0x01 of the AMP protocol (note this is a PoC
>> outline, we would need to standardize signalling of these 12 bytes to
>> support other protocols).
>>
>>
>> I believe the `realm` byte is intended for this. Intermediate nodes do
>> not need to understand realm bytes that are understood by other nodes in
>> the route, including the realm bytes understood by the final destination,
>> as intermediate nodes cannot, indeed, read the hop data of other nodes.
>> Thus, you can route over nodes that are unaware of AMP, and only provide an
>> AMP realm byte to the destination node, who, is able to reconstruct this
>> your AMP data as per your algorithm.
>>
>> Indeed, the `realm` byte controls the interpretation of the rest of the
>> 65-byte packet. If you define, instead, a separate `realm` that is
>> understood by the destination node, you can redefine the entire 64 bytes of
>> the final hop data as you wish.
>>
>> If we support AMP only at final payees, we can completely redefine the 64
>> bytes in the final hop data for the new AMP `realm`, and not consume the
>> next hop (which would reduce route length by 1).
>>
>> (If we want to support multiple routes converging to an intermediate
>> node, then continue routing to a different final node after routes have
>> merged (i.e. A->B->C->D, and A->E->C->D, with the payment being merged by
>> C, who forwards the combination to D), then we need to follow the current
>> hop data format, but I think supporting AMP at final payees is actually
>> enough... AMP at intermediate nodes might not be used often enough by
>> senders for it to matter, as taking advantage of that seems more complex
>> than just asking your routing algo to provide you multiple routes to a
>> destination, which you are probably already doing)
>>
>> ----
>>
>> Overall, good work I think.
>>
>> Regards,
>> ZmnSCPxj
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180207/686a561b/attachment.html>

2023-06-09 12:48:47

- reply

📅 Original date posted:2018-02-03
📝 Original message:
Hello everyone,
While working on some upgrades to our lightning-onion repo [1],
roasbeef pointed
out that all of our implementations use a quadratic algorithm to
iteratively apply the intermediate blinding factors.
I spent some time working on a linear algorithm that reduces the total
number of scalar multiplications. Overall, our packet construction
benchmarks showed an 8x speedup, from 37ms to 4.5ms, and now uses ~70% less
memory. The diff is only ~15 LOC, and thought this would be a
useful optimization for our implementations to have. I can make a PR that
updates the example source in lightning-rfc if there is interest.
A description, along with the modified source, can be found in my PR to
lightning-onion [2]. The correctness of the output has been verified
against the (updated) BOLT 4 test vector [3].
[1] https://github.com/lightningnetwork/lightning-onion
[2] https://github.com/lightningnetwork/lightning-onion/pull/18
[3] https://github.com/lightningnetwork/lightning-rfc/pull/372
Cheers,
Conner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180203/e0a57a15/attachment.html>

2023-06-07 18:12:15

- reply

📅 Original date posted:2018-05-23
📝 Original message:Hi all,
Jimpo, thanks for looking into those stats! I had always imagined that there
would be a more significant savings in having all filters in one bundle, as
opposed to separate. These results are interesting, to say the least, and
definitely offer us some flexibility in options for filter sharding.
So far, the bulk of this discussion has centered around bandwidth. I am
concerned, however, that splitting up the filters is at odds with the other
goal of the proposal in offering improved privacy.
Allowing clients to choose individual filter sets trivially exposes the
type of
data that client is interested in. This alone might be enough to
fingerprint the
function of a peer and reduce anonymity set justifying their potential
behavior.
Furthermore, if a match is encountered, and block requested, full nodes have
more targeted insight into what caused a particular match. They could infer
that
the client received funds in a particular block, e.g., if they are only
requesting
output scripts.
This is above and beyond the additional complexity of now syncing,
validating,
and managing five or six distinct header/filter-header/filter/block chains.
I agree that saving on bandwidth is an important goal, but bandwidth and
privacy
are always seemingly at odds. Strictly comparing the bandwidth requirements
of
a system that heavily weighs privacy to existing ones, e.g. BIP39, that
don't is a
losing battle IMO.
I'm not fundamentally opposed to splitting the filters, I certainly see the
arguments for flexibility. However, I also want to ensure we are
considering the
second order effects that fall out of optimizing for one metric when others
exist.
Cheers,
Conner
On Wed, May 23, 2018 at 10:29 Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Any chance you could add a graph of input-scripts (instead of input
> outpoints)?
>
> On Wed, May 23, 2018 at 7:38 AM, Jim Posen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > So I checked filter sizes (as a proportion of block size) for each of the
> > sub-filters. The graph is attached.
> >
> > As interpretation, the first ~120,000 blocks are so small that the
> > Golomb-Rice coding can't compress the filters that well, which is why the
> > filter sizes are so high proportional to the block size. Except for the
> > input filter, because the coinbase input is skipped, so many of them
> have 0
> > elements. But after block 120,000 or so, the filter compression converges
> > pretty quickly to near the optimal value. The encouraging thing here is
> that
> > if you look at the ratio of the combined size of the separated filters vs
> > the size of a filter containing all of them (currently known as the basic
> > filter), they are pretty much the same size. The mean of the ratio
> between
> > them after block 150,000 is 99.4%. So basically, not much compression
> > efficiently is lost by separating the basic filter into sub-filters.
> >
> > On Tue, May 22, 2018 at 5:42 PM, Jim Posen <jim.posen at gmail.com> wrote:
> >>>
> >>> My suggestion was to advertise a bitfield for each filter type the node
> >>> serves,
> >>> where the bitfield indicates what elements are part of the filters.
> This
> >>> essentially
> >>> removes the notion of decided filter types and instead leaves the
> >>> decision to
> >>> full-nodes.
> >>
> >>
> >> I think it makes more sense to construct entirely separate filters for
> the
> >> different types of elements and allow clients to download only the ones
> they
> >> care about. If there are enough elements per filter, the compression
> ratio
> >> shouldn't be much worse by splitting them up. This prevents the
> exponential
> >> blowup in the number of filters that you mention, Johan, and it works
> nicely
> >> with service bits for advertising different filter types independently.
> >>
> >> So if we created three separate filter types, one for output scripts,
> one
> >> for input outpoints, and one for TXIDs, each signaled with a separate
> >> service bit, are people good with that? Or do you think there shouldn't
> be a
> >> TXID filter at all, Matt? I didn't include the option of a prev output
> >> script filter or rolling that into the block output script filter
> because it
> >> changes the security model (cannot be proven to be correct/incorrect
> >> succinctly).
> >>
> >> Then there's the question of whether to separate or combine the headers.
> >> I'd lean towards keeping them separate because it's simpler that way.
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180523/b7412db9/attachment.html>

2023-06-07 18:02:25

- reply

📅 Original date posted:2017-06-08
📝 Original message:I don't normally post here, but I'm sorry, if you don't see those two as
equal, then I think you have misunderstood the *entire* value proposition
of cryptocurrencies.
The state of any cryptocurrency should entirely (and only) be defined by
its ledger. If the state of the system can be altered outside of the rules
governing its ledger, then the system isn't secure. It doesn't matter
whether the people making those changes are the ones that are leading the
project or not. An "irregular state change" is a fancy term for a bailout.
I'm sure I speak for more than myself in saying that an "irregular state
change" is equivalent to modifying the underlying ledger. Let's not let
semantics keep us from recognizing what actually took place.
-Conner
On Wed, Jun 7, 2017 at 14:14 Nick Johnson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Jun 7, 2017 at 5:27 PM Tao Effect <contact at taoeffect.com> wrote:
>
>> Nick,
>>
>> Please don't spread misinformation. Whatever you think of the DAO hard
>> fork, it's a simple fact that the Ethereum ledger was not edited.
>>
>>
>> This sort of email is unhelpful to this conversation, and it certainly
>> doesn't help with the perception that Ethereum is nothing but a bunch of
>> hypocritical Bankers 2.0.
>>
>
>
>>
>> Everyone knows you didn't edit Ethereum Classic, but the the hard fork,
>> which was re-branded as Ethereum, was edited.
>>
>
> That's not what I was suggesting. My point is that the ledger was never
> edited. An 'irregular state change' was added at a specific block height,
> but the ledger remains inviolate.
>
> I'm sure I don't have to explain the difference between the ledger and the
> state to you, or why it's significant that the ledger wasn't (and can't be,
> practically) modified.
>
> -Nick
>
>
>> - Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with
>> the NSA.
>>
>> On Jun 7, 2017, at 6:25 AM, Nick Johnson <nick at ethereum.org> wrote:
>>
>> On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > I believe the severity of replay attacks is going unvoiced and is not
>>> > understood within the bitcoin community because of their lack of
>>> experience
>>> > with them.
>>>
>>> Please don't insult our community-- the issues with replay were
>>> pointed out by us to Ethereum in advance and were cited specifically
>>> in prior hardfork discussions long before Ethereum started editing
>>> their ledger for the economic benefit of its centralized
>>> administrators.
>>
>>
>> Please don't spread misinformation. Whatever you think of the DAO hard
>> fork, it's a simple fact that the Ethereum ledger was not edited.
>>
>> -Nick Johnson
>>
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170608/4a1844b0/attachment-0001.html>