Olaoluwa Osuntokun [ARCHIVE]

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

Public Key

npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4

Profile Code

nprofile1qqszmuluyesyt9fphpfvn9w5lsdf8yur3xj7ppt8058tkvl0jtx9gaselhetw

Author Public Key

npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4

Show more details

Last Notes

2023-10-18 13:02:09

- reply

📅 Original date posted:2023-10-16
🗒️ Summary of this message: The email acknowledges the recipient's efforts in reporting an issue and discusses the implementation of mitigations in the lnd software. It also mentions the discovery of a transaction-relay jamming attack affecting lightning channels and the deployment of mitigations by major lightning implementations. The email concludes by mentioning the need to determine the robustness of the deployed mitigations against advanced attackers.
📝 Original message:
Hi Antoine,
Thanks for this great write up, and also your diligence in reporting this
issue to the various implementations, and game planning with us re
mitigations and attack scenarios.
One small clarification: all of lnd's relevant mitigations were in place by
lnd v0.16.1-beta [1], which was released on April 24th 2023. Since then
we've fixed some performance regressions introduced due to some of the
mitigations (mempool watching), and in 0.17.1 we'll start to use the new
`gettxspendingprevout` RPC call with bitcoind to further reduce load.
[1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta
-- Laolu
On Mon, Oct 16, 2023 at 10:04 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> (cross-posting mempool issues identified are exposing lightning chan to
> loss of funds risks, other multi-party bitcoin apps might be affected)
>
> Hi,
>
> End of last year (December 2022), amid technical discussions on eltoo
> payment channels and incentives compatibility of the mempool anti-DoS
> rules, a new transaction-relay jamming attack affecting lightning channels
> was discovered.
>
> After careful analysis, it turns out this attack is practical and
> immediately exposed lightning routing hops carrying HTLC traffic to loss of
> funds security risks, both legacy and anchor output channels. A potential
> exploitation plausibly happening even without network mempools congestion.
>
> Mitigations have been designed, implemented and deployed by all major
> lightning implementations during the last months.
>
> Please find attached the release numbers, where the mitigations should be
> present:
> - LDK: v0.0.118 - CVE-2023 -40231
> - Eclair: v0.9.0 - CVE-2023-40232
> - LND: v.0.17.0-beta - CVE-2023-40233
> - Core-Lightning: v.23.08.01 - CVE-2023-40234
>
> While neither replacement cycling attacks have been observed or reported
> in the wild since the last ~10 months or experimented in real-world
> conditions on bitcoin mainet, functional test is available exercising the
> affected lightning channel against bitcoin core mempool (26.0 release
> cycle).
>
> It is understood that a simple replacement cycling attack does not demand
> privileged capabilities from an attacker (e.g no low-hashrate power) and
> only access to basic bitcoin and lightning software. Yet I still think
> executing such an attack successfully requests a fair amount of bitcoin
> technical know-how and decent preparation.
>
> From my understanding of those issues, it is yet to be determined if the
> mitigations deployed are robust enough in face of advanced replacement
> cycling attackers, especially ones able to combine different classes of
> transaction-relay jamming such as pinnings or vetted with more privileged
> capabilities.
>
> Please find a list of potential affected bitcoin applications in this full
> disclosure report using bitcoin script timelocks or multi-party
> transactions, albeit no immediate security risk exposure as severe as the
> ones affecting lightning has been identified. Only cursory review of
> non-lightning applications has been conducted so far.
>
> There is a paper published summarizing replacement cycling attacks on the
> lightning network:
>
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
>
> ## Problem
>
> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted
> HTLC on incoming link and offered HTLC on outgoing link) should settle the
> outgoing state with either a success or timeout before the incoming state
> timelock becomes final and an asymmetric defavorable settlement might
> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"
> section 2.3 for a classical exposition of this lightning security property).
>
> Failure to satisfy this settlement requirement exposes a forwarding hop to
> a loss of fund risk where the offered HTLC is spent by the outgoing link
> counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming
> link counterparty's HTLC-timeout.
>
> The specification mandates the incoming HTLC expiration timelock to be
> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC
> expiration timelock, this exact interval value being an implementation and
> node policy setting. As a minimal value, the specification recommends 34
> blocks of interval. If the timelock expiration I of the inbound HTLC is
> equal to 100 from chain tip, the timelock expiration O of the outbound HTLC
> must be equal to 66 blocks from chain tip, giving a reasonable buffer of
> reaction to the lightning forwarding node.
>
> In the lack of cooperative off-chain settlement of the HTLC on the
> outgoing link negotiated with the counterparty (either
> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the
> lightning node should broadcast its commitment transaction. Once the
> commitment is confirmed (if anchor and the 1 CSV encumbrance is present),
> the lightning node broadcasts and confirms its HTLC-timeout before I height
> is reached.
>
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee and
> higher feerate than the honest HTLC-timeout of the victim lightning node
> and triggers a replacement. Both for legacy and anchor output channels, a
> HTLC-preimage on a counterparty commitment transaction is malleable, i.e
> additional inputs or outputs can be added. The HTLC-preimage spends an
> unconfirmed and unrelated to the channel parent transaction M and conflicts
> its child.
>
> As the HTLC-preimage spends an unconfirmed input that was already included
> in the unconfirmed and unrelated child transaction (rule 2), pays an
> absolute higher fee of at least the sum paid by the HTLC-timeout and child
> transaction (rule 3) and the HTLC-preimage feerate is greater than all
> directly conflicting transactions (rule 6), the replacement is accepted.
> The honest HTLC-timeout is evicted out of the mempool.
>
> In an ulterior move, the malicious counterparty can replace the parent
> transaction itself with another candidate N satisfying the replacement
> rules, triggering the eviction of the malicious HTLC-preimage from the
> mempool as it was a child of the parent T.
>
> There is no spending candidate of the offered HTLC output for the current
> block laying in network mempools.
>
> This replacement cycling tricks can be repeated for each rebroadcast
> attempt of the HTLC-timeout by the honest lightning node until expiration
> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout
> is broadcast by the counterparty's on the incoming link in collusion with
> the one on the outgoing link broadcasting its own HTLC-preimage.
>
> The honest Lightning node has been "double-spent" in its HTLC forwarding.
>
> As a notable factor impacting the success of the attack, a lightning
> node's honest HTLC-timeout might be included in the block template of the
> miner winning the block race and therefore realizes a spent of the offered
> output. In practice, a replacement cycling attack might over-connect to
> miners' mempools and public reachable nodes to succeed in a fast eviction
> of the HTLC-timeout by its HTLC-preimage. As this latter transaction can
> come with a better ancestor-score, it should be picked up on the flight by
> economically competitive miners.
>
> A functional test exercising a simple replacement cycling of a HTLC
> transaction on bitcoin core mempool is available:
> https://github.com/ariard/bitcoin/commits/2023-test-mempool
>
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the replacement cycling malicious transactions paid
> only equal the sum of the absolute fees paid by the HTLC, adjusted with the
> replacement penalty. Rebroadcasting randomly and multiple times before the
> next block increases the absolute fee cost for the attacker.
>
> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
>
> Local-mempool preimage monitoring: As the replacement cycling attacker in
> a simple setup broadcast the HTLC-preimage to all the network mempools, the
> honest lightning node is able to catch on the flight the unconfirmed
> HTLC-preimage, before its subsequent mempool replacement. The preimage can
> be extracted from the second-stage HTLC-preimage and used to fetch the
> off-chain inbound HTLC with a cooperative message or go on-chain with it to
> claim the accepted HTLC output.
>
> Implemented and deployed by Eclair and LND.
>
> CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid
> by the attacker, a risk of the HTLC-preimage being detected or discovered
> by the honest lightning node, or the HTLC-timeout to slip in a winning
> block template. Bumping the default CLTV delta hardens the odds of success
> of a simple replacement cycling attack.
>
> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.
>
> ## Affected Bitcoin Protocols and Applications
>
> From my understanding the following list of Bitcoin protocols and
> applications could be affected by new denial-of-service vectors under some
> level of network mempools congestion. Neither tests or advanced review of
> specifications (when available) has been conducted for each of them:
> - on-chain DLCs
> - coinjoins
> - payjoins
> - wallets with time-sensitive paths
> - peerswap and submarine swaps
> - batch payouts
> - transaction "accelerators"
>
> Inviting their developers, maintainers and operators to investigate how
> replacement cycling attacks might disrupt their in-mempool chain of
> transactions, or fee-bumping flows at the shortest delay. Simple flows and
> non-multi-party transactions should not be affected to the best of my
> understanding.
>
> ## Open Problems: Package Malleability
>
> Pinning attacks have been known for years as a practical vector to
> compromise lightning channels funds safety, under different scenarios (cf.
> current bip331's motivation section). Mitigations at the mempool level have
> been designed, discussed and are under implementation by the community
> (ancestor package relay + nverrsion=3 policy). Ideally, they should
> constraint a pinning attacker to always attach a high feerate package
> (commitment + CPFP) to replace the honest package, or allow a honest
> lightning node to overbid a malicious pinning package and get its
> time-sensitive transaction optimistically included in the chain.
>
> Replacement cycling attack seem to offer a new way to neutralize the
> design goals of package relay and its companion nversion=3 policy, where an
> attacker package RBF a honest package out of the mempool to subsequently
> double-spend its own high-fee child with a transaction unrelated to the
> channel. As the remaining commitment transaction is pre-signed with a
> minimal relay fee, it can be evicted out of the mempool.
>
> A functional test exercising a simple replacement cycling of a lightning
> channel commitment transaction on top of the nversion=3 code branch is
> available:
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>
> ## Discovery
>
> In 2018, the issue of static fees for pre-signed lightning transactions is
> made more widely known, the carve-out exemption in mempool rules to
> mitigate in-mempool package limits pinning and the anchor output pattern
> are proposed.
>
> In 2019, bitcoin core 0.19 is released with carve-out support. Continued
> discussion of the anchor output pattern as a dynamic fee-bumping method.
>
> In 2020, draft of anchor output submitted to the bolts. Initial finding of
> economic pinning against lightning commitment and second-stage HTLC
> transactions. Subsequent discussions of a preimage-overlay network or
> package-relay as mitigations. Public call made to inquiry more on potential
> other transaction-relay jamming attacks affecting lightning.
>
> In 2021, initial work in bitcoin core 22.0 of package acceptance.
> Continued discussion of the pinning attacks and shortcomings of current
> mempool rules during community-wide online workshops. Later the year, in
> light of all issues for bitcoin second-layers, a proposal is made about
> killing the mempool.
>
> In 2022, bip proposed for package relay and new proposed v3 policy design
> proposed for a review and implementation. Mempoolfullrbf is supported in
> bitcoin core 24.0 and conceptual questions about alignment of mempool rules
> w.r.t miners incentives are investigated.
>
> Along this year 2022, eltoo lightning channels design are discussed,
> implemented and reviewed. In this context and after discussions on mempool
> anti-DoS rules, I discovered this new replacement cycling attack was
> affecting deployed lightning channels and immediately reported the finding
> to some bitcoin core developers and lightning maintainers.
>
> ## Timeline
>
> - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg
> Sanders and Gloria Zhao
> - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier,
> Matt Corallo and Olaoluwa Osuntunkun
> - 2022-12-23: Sharing to Eugene Siegel (LND)
> - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning
> potential affected projects)
> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers
> issuers) and initial proposal of an early public disclosure
> - 2022-01-19: Collection of analysis if other second-layers and
> multi-party applications affected. LN mitigations development starts.
> - 2023-05-04: Sharing to Wilmer Paulino (LDK)
> - 2023-06-20: LN mitigations implemented and progressively released. Week
> of the 16 october proposed for full disclosure.
> - 2023-08-10: CVEs assigned by MITRE
> - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling
> attack existence to security at bitcoincore.org.
> - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /
> CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks
>
> ## Conclusion
>
> Despite the line of mitigations adopted and deployed by current major
> lightning implementations, I believe replacement cycling attacks are still
> practical for advanced attackers. Beyond this new attack might come as a
> way to partially or completely defeat some of the pinning mitigations which
> have been working for years as a community.
>
> As of today, it is uncertain to me if lightning is not affected by a more
> severe long-term package malleability critical security issue under current
> consensus rules, and if any other time-sensitive multi-party protocol,
> designed or deployed isn't de facto affected too (loss of funds or denial
> of service).
>
> Assuming analysis on package malleability is correct, it is unclear to me
> if it can be corrected by changes in replacement / eviction rules or
> mempool chain of transactions processing strategy. Inviting my technical
> peers and the bitcoin community to look more on this issue, including to
> dissent. I'll be the first one pleased if I'm fundamentally wrong on those
> issues, or if any element has not been weighted with the adequate technical
> accuracy it deserves.
>
> Do not trust, verify. All mistakes and opinions are my own.
>
> Antoine
>
> "meet with Triumph and Disaster. And treat those two impostors just the
> same" - K.
> _______________________________________________
> 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/lightning-dev/attachments/20231016/cef364c3/attachment-0001.html>

2023-09-07 11:52:37

- reply

📅 Original date posted:2023-09-06
🗒️ Summary of this message: The Taproot Assets Protocol has been officially published, with various BIPs describing the data structure, validation rules, address format, and more. Highlights include test vectors, the Universe construct, and asset group keys. Versioning and re-org protection have also been implemented.
📝 Original message:
After more than a year of tinkering, iterating, simplifying, and
implementing, I'm excited to officially publish (and request BIP numbers
for) the Taproot Assets Protocol. Since the initial publishing we've
retained the same spec/document structure, with the addition of a new BIP
that describes the vPSBT format (which are PSBTs for the TAP layer). Each
BIP now also contains a set of comprehensive test vectors (to be further
expanded over time.
https://github.com/bitcoin/bips/pull/1489
As the complete set of documents is large, we omit them from this email.
The breakdown of the BIPs are as follows:
* `bip-tap-mssmt`: describes the MS-SMT (Merkle-Sum Sparse Merkle Tree)
data structure used to store assets and various proofs.
* `bip-tap`: describes the Taproot Assets Protocol validation and state
transition rules.
* `bip-tap-addr`: describes the address format used to send and receive
assets.
* `bip-tap-vm`: describes the initial version of the off-chain TAP VM used
to lock and unlock assets.
* `bip-tap-vpsbt`: describes a vPSBT (virtual PSBT) which is a series
custom types on top of the existing PSBT protocol to facilitate more
elaborate asset related transactions.
* `bip-tap-proof-file`: describes the flat file format which is used to
prove and verify the provenance of an asset
* `bip-tap-universe`: describes the Universe server construct, which is an
off-chain index into TAP data on-chain, used for: proof distribution,
asset boostraping, and asset transaction archiving.
Some highlights of the additions/modifications of the BIPs since the initial
drafts were published last year:
* Test JSON vectors for each BIP document now included.
* The Universe construct for initial verification of assets, distributing
asset proofs, and transaction archiving is now further specified. A
naive and tree based syncing algorithm, along with a standardized
REST/gRPC interface are now in place.
* The asset group key structure (formerly known as asset key families) has
been further developed. Group keys allow for the creation of assets that
support ongoing issuance. A valid witness of a group key during the
minting process allows otherwise disparate assets to be considered
fungible, and nested under the same sub-tree. A group key is itself just
a taproot output key. This enables complex issuance conditions such as:
multi-sig threshold, hash chain reveal, and any other conditions
expressible by script (and eventually beyond!).
* New versioning bytes across the protocol to ensure extensibility and
upgradability in a backwards compatible manner where possible. The asset
metadata format now has been re-worked to only commit to a hash of the
serialized meta data. Asset metadata can now also have structured data,
key-value or otherwise.
* Observance of re-org protection for asset proofs. The file format now
also uses an incremental hash function to reduce memory requirements
when added a new transition to the end of the file.
* Specification of the vPSBT protocol [1] which is the analogue of normal
PSBTs for the TAP layer. The packet format specifies custom key/value
pairs for the protocol describes an aggregate TAP transaction. After the
packet is signed by all participants, it's "anchored" into a normal
Bitcoin transaction by committing to the resulting output commitments
and witnesses.
We've also made significant advancements in our initial implementation [2],
with many wallets, explorers, services, and businesses working with us to
test and iterate on both the protocol and the implementation. We're actively
working on our next major release, which will be a major milestone towards
the eventual mainnet deployment of the protocol!
-- Laolu
[1]: https://lightning.engineering/posts/2023-06-14-virtual-psbt/
[2]: https://github.com/lightninglabs/taproot-assets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230906/f3a90b1f/attachment.html>

2023-07-17 13:04:44

- reply

📅 Original date posted:2023-07-16
🗒️ Summary of this message: Lnd supports paying invoices it generates by setting the `allow_self_payment` field. This can be done through the API provided.
📝 Original message:
lnd supports paying invoices it generates, you just need to set the
`allow_self_payment` field using this
API: https://lightning.engineering/api-docs/api/lnd/router/send-payment-v2.
This _does_ end up actually finding a circular route through the network
though, it's most commonly used to implement circular rebalancing.
However if you set up another node, and then fund bi-lateral "trusted
channels" (so zero conf channel that will never actually confirm as the
funding point will never exist on chain), then you gain the ability to pay
invoices without doing the actual network route. This doesn't need any other
external software, and also gives you all the normal payment/invoice records
you'd expect for normal payments.
Another way to accomplish the same thing would be to use the
`"allow-circular-route` flag, which'll let you double back on the same
channel (incoming+outgoing channel is the same for the route).
-- Laolu
On Sat, Jul 15, 2023 at 8:22 PM fiatjaf <fiatjaf at gmail.com> wrote:
> On Thu, Jul 13, 2023 at 3:47 AM David A. Harding <dave at dtrt.org> wrote:
> > My question is whether you think it would be worthwhile to ask
> > developers of the underlying LN node implementations you use to support
> > self-payment of their own invoices (if they don't already).
>
> As far as I know no Lightning node has this ability, which is very
> unfortunate.
> If possible this should definitely be implemented. It would be the
> biggest feature for custodial Lightning service providers of all kinds
> since always.
> _______________________________________________
> 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/20230716/7adc6798/attachment.html>

2023-06-14 14:16:41

- reply

📅 Original date posted:2023-06-13
🗒️ Summary of this message: An extension to BOLT-11 is proposed for invoices to contain two bundled payments with distinct preimages and amounts for non-custodial exchanges. This is useful for services that require prepayment of mining fees, such as submarine swaps and JIT channels. However, dedicated logic is still required for full verification of swap parameters and on-chain sweep/timeout, which is necessary for a trust-minimized swap.
📝 Original message:
> Their website shows an invoice to the user, whose wallet that is agnostic
> about the swap, and it would be unpractical for them to show two invoices
> to be paid simultaneously
In order to be properly non-custodial, a submarine swap client needs to be
able to unilaterally sweep or timeout an on chain HTLC and also validate all
the swap parameters.
Assuming I understand this web based flow correctly, it still requires
"dedicated logic" on the client side to sweep (reveal the preimage) or
timeout the on chain HTLC. If one wishes to avoid the awareness of the
subswap itself, then a user would need to manually go to the website in
order to obtain a signed sweep transaction (for a Loop Out like sub-swap, so
off-chain to on-chain). However, that would still require the wallet to
sign
the HTLC sweep path, once again requiring dedicated logic. A website could
have an option to give a user a signed sweep or refund transaction, but that
can't be created until user goes on chain as something like no_input doesn't
exist today on mainnet. Even then, a website can let the user act first,
then just never give them the necessary signed transaction.
In other words: one always requires dedicated logic in order to fully verify
the swap parameters and also perform an on-chain sweep/timeout, which is a
requirement for a trust minified swap. A user can trust the service to just
send to the given address or pay an invoice for them, but that's not a trust
minimized swap.
-- Laolu
On Tue, Jun 13, 2023 at 6:52 AM Thomas Voegtlin <thomasv at electrum.org>
wrote:
> Good morning list,
>
> I would like to propose an extension to BOLT-11, where an invoice can
> contain two bundled payments, with distinct preimages and amounts.
>
> The use case is for services that require the prepayment of a mining fee
> in order for a non-custodian exchange to take place:
> - Submarine swaps
> - JIT channels
>
> In both cases, the service provider receives a HTLC for which they do not
> have the preimage, have to send funds on-chain (to the channel or submarine
> swap funding address), and wait for the client to reveal the preimage when
> they claim the payment. Because there is no guarantee that the client will
> actually claim the payment, the service providers need to ask prepayment of
> mining fees.
>
> In the case of submarine swaps, services that use dedicated client
> software, such as Loop by Lightning Labs, can ask for a prepayment, because
> their software can handle it (this is called "no show penalty" on the Loop
> website). However, competitors who do require a dedicated wallet, not such
> as the Boltz exchange, cannot do that. Their website shows an invoice to
> the user, whose wallet that is agnostic about the swap, and it would be
> unpractical for them to show two invoices to be paid simultaneously. This
> creates a situation where Boltz is vulnerable to DoS attacks, where the
> attacker forces them to pay on-chain fees.
>
> In the case of JIT channels, providers who want to protect themselves
> against this mining fee attack need to ask the preimage of the main payment
> before they open the channel. I believe this is what Phoenix does (although
> their pay-to-open service is not open-source, so I cannot really check).
> The issue is that a service that asks for the preimage first becomes
> custodian. From a legal perspective, it does not matter whether they open
> the channel immediately after receiving the preimage, the ordering of
> events makes their service custodian. In Europe, such a service will fall
> within the European MICA regulation. Competitors who refuse to offer
> custodian services, such as Electrum, are excluded from that game.
>
> In order to solve that, it would be beneficial to bundle the prepayment
> and the main payment in the same BOLT-11 invoice.
>
> The semantics of bundled payments is as follows:
> - 1. the BOLT-11 invoice contains two preimages and two amounts:
> prepayment and main payment.
> - 2. the receiver should wait until all the HTLCs of both payments have
> arrived, before they fulfill the HTLCs of the pre-payment. If the main
> payment does not arrive, they should fail the pre-payment with a MPP
> timeout.
> - 3. once the HTLCs of both payments have arrived, the receiver fulfills
> the HTLCs of the prepayment, and they broadcast their on-chain transaction.
> Note that the main payment can still fail if the sender never reveal the
> preimage of the main payment.
>
> Of course, nothing in my proposal prevents the service provider from
> stealing the pre-payment, but that is already the case today.
>
> I believe this proposal would level the field in terms of competition
> between lightning service providers. Currently, you need to use a dedicated
> client in order to use Loop, and competitors who do not have an established
> user base running a dedicated client are exposed to the mining fee attack.
> I also believe that ACINQ would benefit from this, because it would make it
> possible for them to make their pay-to-open service fully non-custodian. My
> understanding is that in its current form, the 'pay-to-open' service used
> by Phoenix will fall into the scope of the European MICA regulation, which
> they should consider as a serious issue.
>
> Finally, I believe that such a change should be implemented in BOLT-11,
> and not using BOLT-12 or onion messages. Indeed, my proposal does not
> require the exchange of new messages. Some of the initial feedback I
> received was that this is a use case for BOLT-12 or OM, but I think that
> this is making things unnecessarily complicated. We should not add new
> messages when things can be done in a non-interactive way.
>
> Cheers,
> ThomasV
> _______________________________________________
> 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/20230613/f69bf61e/attachment.html>

2023-06-09 13:12:29

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: The open research question is how the sender will get an invoice from the receiver, given that they are offline at sending-time. One existing protocol extension that solves this is AMP.
📝 Original message:
Hi Val,
Happy to see ppl continue to work on the problem space after discussions and
brainstorming we had at the past LN Summit in Oakland.
> The open research question relates to how the sender will get an invoice
> from the receiver, given that they are offline at sending-time
One existing protocol extension that solves this is AMP [1][2]. The AMP
invoice is fully reusable (tho it can expire), and can be posted anywhere on
the internet, enabling a sender to at least _attempt_ the payment without
the receiver being online. As the sender is the one that generates the
pre-image, it's easy to prevent payment hash re-use (generate a new root
hash, just like you do a shared secret when making an onion). The LSP (or
anyone else) can't steal the funds, as the pre-image shares are in the final
hop of the onion payload, which can only be decrypted by the receiver.
Each payment can use the payment_addr/payment_secret field in the
invoice, but then also generate a new set_id for each logical payment. The
set_id is included in the final hop payload, which lets the receiver
aggregate the HTLCs until they can finally settle it after recovering the
root payment pre-image.
Invoice negotiation protocols such as BOLT 12, LN-URL, and Lightning Address
can also be used to fetch a self-contained AMP invoice.
Here's a testnet AMP invoice that can be paid w/ any amt:
```
lntb1p3murampp56m9m254s7xduktrm7g6j5r7qrpw9kvzc2tpqul7eskhyqfh95lnqdqqcqzpgxq9z0rgqsp5eyam7wajd3mmwk9qmfthzk3t96s0rklv05tc49ak68p8wvks0cmq9q8pqqqssq3jvnkdqn289fd7l3w2weqps89p9zaan4xlqenj3tmclwwkjgudrzn9jvvmkzgemehrdc7dlg4z7sxu0hmeul55keewqk0kdulc6058qpu644f8
```
> such that senders have proof-of-payment? This may ideally be built on top
> of PTLCs
I can't find the original slides (the old LN Conf URL seems to just redirect
to the Fulmo website now), but back in the day, Conner gave a talk about an
AMP extension he called "invoice tunneling". The idea is that you force the
receiver to reveal a unique secret bound to the invoice or payment attempt.
Rather than having the set_id be a 32-byte value, it would instead be a
point and mixed in along all the transmitted partial HTLC shares. In order
to settle the HTLC, both the secret of the point in the original invoice, as
well as the sender provided root payment pre-image would be required.
As usual though, I'm pretty dubious of any sort of "proof of payment"
schemes. Particularly given that virtual no wallets today (UI-wise) give you
direct access to a pre-image, there's no standard that has emerged yet
(seemingly due to a lack of an actual need) to encode such information, and
also most schemes would let any 3rd party that learned the pre-image (an
intermediate node) to claim that they sent the payment (w/o any other
asymmetric crypto).
Circling back to the discussion in Oakland, one of my key takeaways was
that: Trampoline payments are a critical part of any sort of async payment
scheme. Otherwise, you'll require the sender to be online in a synchronous
manner as _they're_ the ones that need to retry the payment continually.
With Trampoline payments, the sender's "LSP" can retry the payment at will
w/o needing to fetch a fresh onion each time. With that the entire flow can
be async:
1. user tries initial payment
2. LSP gets it, can delay the initial try to "phone home" to the receiver
3. HTLC eventually gets the penultimate (second to last hop before the
receiver)
4. Receiver comes online eventually to reveal pre-image
5. pre-image propagates backwards thru the route
6. sender eventually comes back online again to acknowledge receipt
With the way LN works, once step 4 is reached, then the payment has
effectively been completed from the PoV of the receiver (UI can update,
etc). With AMP usage, the receiver also doesn't need to be online for the
sender to even _attempt_ to make a payment.
-- Laolu
[1]: https://github.com/lightning/bolts/pull/658
[2]: https://docs.lightning.engineering/lightning-network-tools/lnd/amp
On Tue, Jan 10, 2023 at 11:41 AM vwallace via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hi list!
>
> This email is a belated Christmas wishlist for interested researchers to
> solve an open question in lightning.
>
> For context, recently there’s been some discussion about supporting “async
> payments”[1]. Supporting this feature would mean that e.g. a mobile
> noncustodial user would be able to receive payments even if they’re
> regularly offline. See the linked email and preliminary spec PR[2] for
> details on this scheme.
>
> The open research question relates to how the sender will get an invoice
> from the receiver, given that they are offline at sending-time. If the
> receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of
> invoices ahead of time, and trust the LSP to never provide the same one
> twice, since doing this would allow the LSP (or some intermediate node on
> the path) to steal the funds, due to already knowing the preimage.
>
> This trust isn’t ideal, obviously. In the original ML email[1], the
> solution presented to this problem is PTLCs. However, upon further
> investigation, it turns out that the current PTLCs design wouldn’t solve
> this problem: the LSP would be able to steal funds the same as before, see
> [3].
>
> Note that even if we don’t want to trust LSPs, this problem doesn’t halt
> async payment progress entirely: the working solution for now is for the
> receiver’s LSP to provide a reusable keysend[4] invoice to senders. The
> current thinking is that BOLT12 invoices will add a feature bit to support
> keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to
> retrieve the keysend invoice. This isn’t ideal because it loses the
> proof-of-payment property, but it seems OK as a stopgap.
>
> So more specifically, the research question is: what is a scheme that
> allows a regularly-offline receiver to create a reusable invoice for their
> LSP to provide to senders, such that senders have proof-of-payment? This
> may ideally be built on top of PTLCs. **Note that while the recipient may
> be offline when the sender initiates the payment, the recipient will come
> back online some time later to fulfill the incoming payment.**
>
> A possible direction suggested by BlueMatt could be to stick with keysend,
> but have the sender encode a nonce + the time they sent the payment + the
> payment amount as a tweak to the keysend PTLC point (as well as in the
> onion), and make the receiver tweak their point with the same data when
> fulfilling the payment. Such a scheme may force the receiver to commit to
> the sender-encoded data[5], which wouldn’t exactly provide
> proof-of-payment, but would allow the sender to prove “I sent X amount at Y
> time.” Handwave handwave.
>
> Thoughts welcome!
>
> Cheers,
>
> Val
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
>
>
> [2]: https://github.com/lightning/bolts/pull/989
>
> [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
>
> [4]: https://github.com/lightning/blips/blob/master/blip-0003.md
> [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
> _______________________________________________
> 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/20230110/f1b1ffe6/attachment-0001.html>

2023-06-09 13:12:27

- reply

📅 Original date posted:2023-01-05
🗒️ Summary of this message: The address generated by the Loop In command is not safe for reuse as it contains a swap hash in the script. The Potentiam swap is a deferred two-stage swap that is less efficient but gives Alice more optionality. The Swap-in-potentiam is safe for address reuse.
📝 Original message:
Hi Z,
> Quick question: is the address given by the `loop in --external` command
safe
> for reuse?
Thx for this question, I think this is the key difference I was looking for
(not the aspect about confirmations, since that's no different). Since that
address contains a swap hash in the script, it's not safe to reuse (just
like a
vanilla invoice on LN today: ppl will learn the pre-image).
The potentiam swap is effectively a sort of deferred two stage swap. The
Loop
In swap I described earlier it complete after two transactions: initial
swap tx
confirmation, and the swap by the user. This swap can only be complete after
three transactions: initial deferred "no-premium swaption" (Alice can swap,
or
just leave it for a while), swap transaction confirmation (Alice initiates
w/
the HTLC added), and final sweep.
So this swap is less efficient from an on-chain perspective (2 vs 3 txns),
but
it gives Alice more optionality. Both variants however enable the final step
(sweeping on chain) to be batched with other related or distinct swaps.
I think one can make the Loop In swap addr pseudo-reusable by adding a
"cancel"
leaf in the rooted tapscript. It would slow down the process though, as
you'd
need another level of relative timeout for Alice to get the funds back. Ofc,
all this is muuuch nicer w/ proper covenants ;).
> The fact that `loop in` requires a specific `--amt=X` flag suggests to me
> that the address generated is not safe for address reuse
The amt field can in theory be left out of the flow, with the swap server
just
assuming w/e was sent to the address is the sending amt.
> Swap-in-potentiam is safe for address reuse, because each UTXO for the
same
> address backs a new, separate swap (if Alice wanted it). The advantage is
> that:
Indeed, if I were to re-write your initial post, I'd lead with this as (to
myself at least) it makes the contribution of this scheme much clearer.
-- Laolu
On Wed, Jan 4, 2023 at 7:11 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Laolu,
>
>
> > Hi Z,
> >
> > > * Submarine swap/peerswap: Requires confirmation before the swap
> service
> > > will send out the HTLC on Lightning.
> >
> > I might be missing something, but I don't see how this is different from
> a
> > normal on-chain to off-chain swap (calling this Loop In for short in the
> > remainder of the email).
> >
> > Given some static swap server params (server key, user key, preimage), a
> > user can derive a tapscript tree and use that to make addresses that any
> 3rd
> > party can send to. Services like Loop return a few addrs (including
> P2TR!)
> > the client can use depending on their wallet sophistication [1] (in this
> > case the command is: `loop in --amt=X --external\, external means a 3rd
> > party will send to the addr). After a 3rd party sends to the script, the
> > swap can be completed at anytime as soon as the client is online
> (assuming
> > swap server is always there).
> >
> > In the scenario above, the newly created outputs to our swap addr need
> to be
> > confirmed before the swap server will initiate the swap. As you mention,
> > this could even be zero conf assuming all sides take w/e precautions
> they're
> > comfortable with. If the swap server goes away for w/e reason, a long
> > timeout in the swap can let the user sweep the funds via some other
> > means eventually. This doesn't need to be a direct swap either, and it
> can
> > flow multi-hop like any other swap.
> >
> > In your scheme you say that:
> >
> > > If so, then the "timer for confirmation" starts as soon as the wallet
> > > receives on the blockchain, not as soon as the wallet decides to move
> > > funds from blockchain to Lightning.
> >
> > Which seems to be the exact same as the flow I described above. For our
> > newer musig2-enabled swaps, the top level keyspend can be spent by both
> > parties, so you also emulate the ability for Alice to move the funds on
> > chain anywhere else w/ the server's cooperation.
> >
> > Using regular swaps also simplified the "Bob Security" section a lot, as
> Bob
> > sends out an HTLC w/ the corresponding swap hash (he watches the chain
> for
> > the scripts, then initiates the swap once they're seen).
> >
> > [1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in
>
> Quick question: is the address given by the `loop in --external` command
> safe for reuse?
>
> In many common onchain-only wallets **available today**, you can do
> something like get a receive address and add it to your forum sig or on a
> static webpage or forum post or whatever, and then anyone can send to it,
> possibly multiple times with different amounts coming from different people.
>
> The fact that `loop in` requires a specific `--amt=X` flag suggests to me
> that the address generated is not safe for address reuse (in particular,
> once *one* swap has completed, I am almost sure that any future funds to
> the same address can be stolen by the swap server without handing it over
> to the purported owner of the funds).
>
> Swap-in-potentiam is safe for address reuse, because each UTXO for the
> same address backs a new, separate swap (if Alice wanted it).
> The advantage is that:
>
> * You get stable addresses that are safe for reuse (which is already
> possible today on non-Lightning wallets, so people already do this today).
> * Those stable addresses can still be spent from quickly on the Lightning
> Network as soon as they are reasonably confirmed.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230104/75286083/attachment.html>

2023-06-09 13:12:26

- reply

📅 Original date posted:2023-01-04
🗒️ Summary of this message: A proposal for a faster way to move funds from an on-chain address to the Lightning Network using regular swaps, which simplifies the process and reduces trust requirements.
📝 Original message:
Hi Z,
> * Submarine swap/peerswap: Requires confirmation before the swap service
> will send out the HTLC on Lightning.
I might be missing something, but I don't see how this is different from a
normal on-chain to off-chain swap (calling this Loop In for short in the
remainder of the email).
Given some static swap server params (server key, user key, preimage), a
user can derive a tapscript tree and use that to make addresses that any 3rd
party can send to. Services like Loop return a few addrs (including P2TR!)
the client can use depending on their wallet sophistication [1] (in this
case the command is: `loop in --amt=X --external\, external means a 3rd
party will send to the addr). After a 3rd party sends to the script, the
swap can be completed at anytime as soon as the client is online (assuming
swap server is always there).
In the scenario above, the newly created outputs to our swap addr need to be
confirmed before the swap server will initiate the swap. As you mention,
this could even be zero conf assuming all sides take w/e precautions they're
comfortable with. If the swap server goes away for w/e reason, a long
timeout in the swap can let the user sweep the funds via some other
means eventually. This doesn't need to be a direct swap either, and it can
flow multi-hop like any other swap.
In your scheme you say that:
> If so, then the "timer for confirmation" starts as soon as the wallet
> receives on the blockchain, not as soon as the wallet decides to move
> funds from blockchain to Lightning.
Which seems to be the exact same as the flow I described above. For our
newer musig2-enabled swaps, the top level keyspend can be spent by both
parties, so you also emulate the ability for Alice to move the funds on
chain anywhere else w/ the server's cooperation.
Using regular swaps also simplified the "Bob Security" section a lot, as Bob
sends out an HTLC w/ the corresponding swap hash (he watches the chain for
the scripts, then initiates the swap once they're seen).
[1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in
-- Laolu
On Tue, Jan 3, 2023 at 5:58 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning
>
> by Jesse Posner, ZmnSCPxj
>
> Introduction
> ============
>
> Moving funds from an onchain-only address to Lightning Network is slow,
> especially if you desire trust-minimization (which removes solutions
> relying on 0-conf).
>
> Basically, to reduce trust requirements in all onchain transactions,
> onchain receivers *MUST* ensure confirmation of the onchain transaction
> that creates their UTXO.
> In practice, the minimum should be at least 3 blocks, since reorgs of
> up to 2 blocks are common occurences, but even 1 confirmation can
> take an inordinately long time in the real world due to the random
> nature of mining.
>
> This is particularly acute for mobile phone use-cases.
> As mobile phones run on a battery, mobile phone OSs often greatly
> restrict CPU and other resource consumption when an app is not
> currently open by the user.
>
> Now consider this user story, for a wallet app that supports both
> Bitcoin blockchain and Lightning Network operations:
>
> * The user wants to be paid over the Bitcoin blockchain.
> * The user gets an address from their wallet and provides it to
> some other party to receive their payment.
> * The user closes their wallet app, which causes the mobile phone
> OS to kill all its threads.
> * The other party sends their payment over blockchain while the
> user is asleep.
> * The blockchain transaction confirms and time passes.
> * The user wakes up and checks their favorite blockchain explorer,
> and sees they received funds on their wallet address.
> * The user opens their wallet app and decides they need a coffee,
> so they buy coffee over Lightning.
>
> For current solutions to move funds from the blockchain layer to
> Lightning, however, the above user story would need to complete
> over a long time, possibly measurable in dozens of minutes or
> even hours in the worst case, due to the need for confirmation:
>
> * Channel open: Requires confirmation, many nodes require 6 or
> more confirmations.
> * Submarine swap/peerswap: Requires confirmation before the swap
> service will send out the HTLC on Lightning.
> * Splice-in: Channel remains operational, but until the splice
> transaction confirms, the channel operates in "dual mode"
> where both pre-splice and post-splice state is valid, and
> that means only the lower amount of the pre-splice and
> post-splice can be used in the mean time.
> For splice-in, the pre-splice amount will be lower, thus
> the amount being spliced in will not be credited until
> the splice transaction is confirmed.
>
> In this writeup, we present a novel protocol, swap-in-potentiam,
> that can be used for immediate transfer from the blockchain
> layer to the Lightning layer, in the above user story.
>
> Advantages And Limitations
> --------------------------
>
> To whet your appetite, here are the advantages:
>
> * Immediate transfer of already-confirmed-received onchain
> funds to Lightning.
> * Onchain funds can also be transferred to another onchain
> address (subject to normal onchain confirmation rules).
> * This can be "immediate" if sending to a receiver that
> accepts the risk of 0-conf onchain transactions.
> * Minimized trust requirement.
>
> The disadvantages, to help convince you that yes, this is
> technology and not magic beans (and to not oversell this
> tech, Bitcoin media reporting often tend to oversell
> new technologies because the disadvantages are often
> hidden away behind technical minutae):
>
> * Requires a cooperating LSP.
> If LSP is down or refuses to cooperate, onchain funds
> are locked for some time.
> This has a timeout (so if the LSP never comes online
> again, you just wait out the timeout) and the timeout
> starts from when the receiving UTXO is confirmed in a
> blocks, so it will not cause loss of funds, only loss
> of opportunity (i.e. "involuntary HODLing").
> * If you have multiple LSPs, when you generate an address
> you *have to* select one of them at that point, you
> *cannot* commit to multiple LSPs and select one of them
> later when your phone wakes up again.
> This exacerbates the above disadvantage, since you have
> to select one of your LSPs and hope that when your
> phone wakes up the LSP you selected is also up and
> cooperative.
> * The onchain-received funds have to be confirmed first,
> otherwise we still need to wait for confirmation of the
> onchain-received funds.
> This is generally true for many blockchain-only wallets
> anyway and is thus not a worsening, but is also not an
> improvement.
> * If the timeout is too near, actions must be performed
> onchain that require confirmation.
>
> Swap-in-Potentiam
> =================
>
> All onchain fund movements, as noted, require confirmation.
> These include onchain fund movements to the Lightning network.
>
> If the onchain address that the wallet provides was controlled
> solely by that wallet, then any action that requires cooperation
> with a Lightning Network participant --- channel open, swap, or
> splice --- would require an onchain transaction that commits to
> that specific Lightning Network participant.
> Only when the new onchain transaction is confirmed, can that
> Lightning participant rely on the transaction output without
> having to trust the initiator.
>
> From there, we can consider: what if the wallet provides an
> address that *already* commits to that specific Lightning Network
> participant?
>
> If so, then the "timer for confirmation" starts as soon as
> the wallet receives on the blockchain, not as soon as the wallet
> decides to move funds from blockchain to Lightning.
>
> This is a significant difference for a mobile wallet: the mobile
> environment does not support the mobile wallet being online for
> long.
> Thus, the mobile wallet may not have any CPU to make the decision
> to move funds from blockchain to Lightning, until the actual user
> explicitly opens the mobile wallet app.
>
> It has already been generally accepted that due to the limitations
> of the mobile phone environment, a mobile phone wallet with
> Lightning support would need some LSP anyway.
> Thus, a mobile wallet that can receive on the blockchain layer
> and then send on the Lightning layer can commit to a specific,
> different, Lightning participant: the LSP it has channels with.
>
> Thus, the mobile wallet can provide an address that commits to
> one particular Lightning Network participant: its LSP.
>
> The mobile wallet can then initiate a single-hop swap with the
> LSP when the mobile wallet app is in the foreground and has CPU
> to think with.
> If it received funds into the address that have already been
> confirmed, then it can do this single-hop swap immediately with
> its LSP.
> The LSP can immediately resolve this swap, crediting funds to
> channel, while atomically ensuring it has sole claim to the
> onchain UTXO.
>
> The Contract
> ------------
>
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
>
> Once *any* funds have been confirmed received into an address
> committing to this contract, Alice owns the funds and can
> dispose of them as it likes (with cooperation from Bob).
> The source of the funds need not be Alice, it could be a third
> party that has an obligation to pay Alice onchain.
>
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
>
> Astute readers will realize that the above is really a variant
> of [CLTV-style unidirectional time-limited channels][1],
> themselves a variant of Spilman-style channels:
>
> * Uses an explicit opcode to simplify channel setup (no need
> to pre-sign a timeout transaction between Alice and Bob,
> can just send funds directly to the address).
> * Uses a relative locktime instead of an absolute one to
> allow funding of the channel address (= receive onchain
> funds ready to spend over Lightning) at any time.
>
> The use-cases this enables are:
>
> * If Alice wants to pay to another onchain address, and Bob
> is also online and cooperative, Alice can ask Bob to help
> sign the Onchain/channel branch to move the funds in any
> arbitrary onchain manner.
> * If Alice wants to pay to a Lightning invoice / keysend, and
> has insufficient Lightning outgoing capacity (but has
> sufficient *total* capacity), it can swap with Bob, by
> offerring a transaction that spends via the Onchain/channel
> branch and instantiates a fresh onchain HTLC that Bob can
> then forward over Lightning.
> As soon as Alice offers its signature of that transaction,
> Bob can immediately offer an in-Lightning HTLC to Alice on
> their channel, and then Alice can immediately resolve it
> (thus immediately getting its funds into Lightning).
> * If Bob is offline or uncooperative, Alice can unilterally
> recover its funds after the timeout in the Timelock
> branch.
>
> Trust is required only to the extent that Alice trusts Bob to
> be cooperative so that Alice can dispose of its funds immediately.
> In case Bob turns out to be non-trustworthy, Alice can recover
> its funds via the timelock branch after the timeout period.
> There is no scope for Bob to steal funds (indeed, it is easier
> for Bob to steal Lightning funds than to steal swap-in-potentiam
> funds).
>
> The intent here is that the mobile wallet is Alice, while the
> LSP is Bob.
>
> ### Bob Security
>
> Bob *MUST* ensure that, for each UTXO, it is either asked to
> sign an arbitrary onchain transaction (i.e the first use-case
> above) *OR* it gets offered an onchain HTLC from that UTXO.
> Once Alice has asked Bob to cooperate in either case for a
> particular UTXO, Bob *MUST* ensure that it does not sign the other
> case (and Bob *MUST* refuse to cooperate in the other case once
> one case has been requested).
>
> In addition, Bob *MUST* ensure that, if it is used in the
> "channel" case (i.e. the second use-case above), the timeout of
> the Timelock branch is far enough in the future that it is likely
> that spends using the Onchain/channel branch have confirmed by
> then.
>
> With both invariants enforced by Bob, Bob can ensure that, if
> Alice requests a swap using the Onchain/channel branch, only Bob
> can spend the UTXO (at least before the timeout), and thus can
> safely offer a Lightning HTLC to Alice immediately without any
> additional waiting for onchain confirmations.
>
> As Bob needs to know the UTXO in the first use-case above, this
> requirement prevents the use of blind signing techniques when
> implementing the first use-case.
> Basically, when being asked to sign, Bob must generate the entire
> `SIGHASH` from data that Alice provides, so that Bob is able to
> keep track of UTXOs it is signing for.
>
> ### Remote Swap
>
> While Bob is generally considered "the" LSP of the mobile wallet
> Alice, nothing in the Lightning protocol actually requires that
> Bob be a direct peer of Alice.
> The only real requirement is that Bob is able to send funds to
> Alice over Lightning in exchange for possession of the equivalent
> onchain funds.
>
> Against this, we should note that the mobile wallet is already
> dependent on one or more LSPs anyway, so it may as well just use
> its direct peer LSPs instead of a remote node.
>
> ### Address Derivation
>
> Swap-in-potentiam addresses can be derived from a root public or
> private key.
>
> We only need one keypair each from Alice and Bob.
> Alice can use standard derivation paths for its keypair.
>
> As Bob is intended to be an LSP, we can just use its Lightning
> node ID as the public key.
> Bob needs to be in possession of the corresponding private key
> anyway in order to set up BOLT 8 encrypted transports.
>
> As LSPs are part of the public network, Alice can simply try to
> scan for all published nodes that advertise support for
> swap-in-potentiam.
> Alternately if the wallet has a short list of fixed LSPs it
> will use, it can simply refer to that list.
>
> Thus:
>
> * Alice uses a derived keypair.
> * Bob uses a fixed keypair (its Lightning node ID).
>
> The above is sufficient to derive swap-in-potentiam addresses
> from an `xprv` or `xpub` root key.
>
> Swap-in-potentiam For LSPs
> ==========================
>
> While the original design of swap-in-potentiam has the mobile
> wallet in the "Alice" role and its LSP in the "Bob" role, it
> turns out that LSPs can provide special service to improve
> receiving mobile wallets.
>
> Suppose that the LSP keeps track of statistics, and thus has
> an idea of which of its mobile wallet clients are likely to
> be net receivers.
>
> Net receivers will often have low inbound capacity (since the
> inbound capacity has been used up during previous LN receives).
>
> During times of low onchain fees, an LSP can check which of its
> offline mobile wallet clients have low inbound capacity, and are
> likely to come online in the future to receive.
> In those cases, the LSP can commit funds to a swap-in-potentiam
> with the mobile client, with the LSP as "Alice" and the mobile
> client as "Bob".
> This at least lets the LSP set up half of a swap during a time of
> low fees.
>
> If the transfer to swap-in-potentiam addresses is confirmed by
> the time the mobile wallet client comes online, the LSP can
> immediately initiate a swap, giving inbound capacity towards the
> mobile client.
> This swap can be immediately resolved, and allows the mobile
> wallet client to immediately receive funds over Lightning.
>
> In particular, if "offline receive" as designed by TheBlueMatt
> is implemented, then the LSP already has indication of a pending
> payment towards an offline mobile wallet client.
> The LSP can check if the offline mobile wallet client has
> insufficient incoming capacity to receive the funds, and if so,
> arrange to fund a swap-in-potentiam with that client.
> Then, when the mobile wallet client comes online, the LSP can
> initiate the swap with them, and once the swap completes (and
> thus the mobile wallet client has sufficient incoming capacity)
> the LSP can contact the sender LSP to complete the payment.
>
> In particular, this use-case allows for *immediate* receives as
> soon as the mobile wallet client gets foregrounded and has CPU
> time, **without** requiring 0-conf trusted transactions and
> thus without requiring any kind of semi-custodial trust, even
> if the mobile wallet client had insufficient incoming capacity.
> A channel still has to be set up beforehand (without 0-conf, if
> trusting funds to the LSP is undesirable).
>
> Implementation Sketch
> =====================
>
> The intent is to use Taproot with Schnorr signatures, but
> **without** using the keyspend path (at least initially).
>
> The plan currently is to use a `MuSig(A, B)` as the internal
> pubkey, but with the branches still explicitly laid out as
> tapleaves.
> That is, there are two tapleaf SCRIPTs corresponding to the
> two branches described above:
>
> * `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG`
> * `<timelock> OP_CHECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`
>
> Using an explicit 2-of-2 branch rather than a MuSig allows
> for a simple protocol at least for initial deployment:
> we can have Alice send the signature using `A` in a single
> half-round without having to engage in a 2-round MuSig2 signing
> ritual.
>
> We intend to use Taproot since the mobile wallet client
> may need to use a 2-of-3 or 2-of-2 signing scheme, similar
> to Blockstream Green.
> This allows either Alice or Bob in the contract to secretly
> be a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or
> MuSig n-of-n).
> This is also another reason for avoiding a 2-of-2 MuSig
> keyspend path between Alice and Bob, as there is (to our
> knowledge) no publicly-reviewed security proof that
> FROST-in-MuSig and MuSig-in-MuSig are safe (or the
> corresponding variants using MuSig2 for the signing
> ritual).
>
> Later, when we are more confident of the use of MuSig2 and
> FROST inside a MuSig2, and with using MuSig2 with possibly
> untrusted outsiders (who might exploit any mis-implementation
> of the MuSig2 signing protocol if we are not careful with
> designing it), we can seamlessly upgrade the protocol
> to use the keyspend path later, to save witness bytes.
>
> For the Onchain use-case (i.e. Alice wants to spend the UTXO
> to an onchain address), the protocol betweeen Alice and Bob
> would be:
>
> * `request_arbitrary_signature` Alice->Bob: Requests Bob
> to sign a PSBT spending a swap-in-potentiam address
> using the Onchain branch.
> * `response_arbitrary_signature` Bob->Alice: Response to
> the above, returning the requested signature.
> * `reject_arbitrary_signature` Bob->Alice: Sent in
> response to `request_arbitary_signature` if Bob refuses
> to cooperate (e.g. the UTXO being spent has already
> been accepted by Bob in a Channel use-case below).
>
> For the Channel use-case (i.e. Alice wants to spend the UTXO
> to a Lightning receiver), we operate the swap-in-potentiam
> UTXO(s) as a Spilman-like channel over two states:
>
> * HTLC-offering: Offering an amount `N` HTLC from Alice to
> Bob, with any remaining amount to a change address to
> Alice.
> * Resolved: Giving the amount `N` outright to Bob, with any
> remaining amount to a change address to Alice.
>
> The intention is that the channel is initially put into
> the HTLC-offerring state.
> Then Bob offers a corresponding in-Lightning HTLC to Alice
> over their channel.
> When Alice resolves the in-Lightning HTLC, it can then
> send a new signature for the Resolved state.
> Once the channel is in a Resolved state, Bob *SHOULD* sign
> the last state and broadcast it on the blockchain, thereby
> closing the Spilman-like channel.
>
> The protocol messages for the Channel use-case are:
>
> * `request_swap_in` Alice->Bob: Tell Bob the UTXOs with
> the same swap-in-potentiam address to spend, how
> much to put into the Alice->Bob channel direction,
> what channel to move into, and (optionally) a change
> address for Alice.
> * `reject_swap_in` Bob->Alice: Sent in response to
> `request_swap_in` if Bob refuses to cooperate (e.g.
> one of the UTXOs on offer was already signed with
> `response_arbitrary_signature`, or Bob cannot legally
> accept control of funds from one or more of the UTXOs
> offerred).
> * `accept_swap_in` Bob->Alice: Sent in response to
> `request_swap_in`, containing the Bob-side address to
> send funds to later once the state is Resolved.
> * `swap_in_signed` Alice->Bob: Response to
> `accept_swap_in`, containing the Alice-side signature
> for the HTLC-offering state transaction.
> Once Bob receives this, Bob can safely construct a
> new on-Lightning HTLC using BOLT1
> `update_offer_htlc`.
> * `swap_in_resolved` Alice->Bob: Sent after Alice has
> acquired the funds via `update_fulfill_htlc` of the
> corresponding on-Lightning HTLC, containing the
> Alice-side signature for the Resolved state
> transaction.
> The Resolved state transaction spends to the Bob-side
> address given in `accept_swap_in`, and any change to
> the Alice-side change address in `request_swap_in`.
>
> The plan is to reserve only one odd BOLT1 message ID,
> and to embed the actual swap-in-potentiam message ID
> as the first 2 bytes of the BOLT1 message, to reduce
> pollution of the limited BOLT1 message ID space and to
> allow more flexibility for swap-in-potentiam to expand
> to new messages inside its own message ID space.
>
> For a richer future protocol, we will want to consider
> how a swap-in can be combined with a splice-in.
> This is useful if the current total capacity of the
> channel is lower than the available onchain funds.
> The swap-in can be credited immediately (and is limited
> to the current total capacity) while additional funds
> can be added to the channel via splice-in (which is
> credited only once the splice-in is confirmed).
>
> As-is, a similar result can be obtained using openv1,
> wherein a swap-in is combined with a channel open,
> with the swap-in immediately credited while the channel
> open is awaiting confirmation:
>
> * Alice and Bob currently have one or more existing
> channels, and Alice has a UTXO in a swap-in-potentiam
> address whose value exceeds the incoming capacity of
> the existing channel(s).
> * Alice->Bob `open_channel`.
> * Bob->Alice `accept_channel`.
> * Alice->Bob `request_swap_in` with the "change address"
> being the funding address of the channel.
> * Bob->Alice `accept_swap_in` provides the TXID of the
> funding transaction (Alice now knows the "change
> address" and the Bob final Resolved address, letting it
> know the final Resolved state transaction TXID).
> * Alice->Bob `funding_created` with the TXID.
> * Bob->Alice `funding_signed`.
> * Alice->Bob `swap_in_signed` to provide the signature
> spending the swap-in-potentiam address to Bob.
> * Bob then constructs an HTLC over the existing channel,
> which Alice claims, revealing the preimage.
> * Alice->Bob `swap_in_resolved`.
> * Bob then broadcasts the Resolved state transaction,
> which is also the funding transaction of the new channel.
> * Both Alice and Bob await confirmation of the transaction
> in order to use the new channel.
> Alice can still use the existing channel, which has been
> topped-up with fresh outgoing capacity by the swap-in.
>
> (The above is not safe, as Bob can complete the protocol
> by using the HTLC-offerring state transaction; this can
> be fixed by having Alice open *2* channels with the same
> amount, one with the HTLC-offering state transaction as
> the funding tx, the other with the Resolved state
> transaction as the funding tx, and later `error`ing the
> channel corresponding to the transaction that is not
> confirmed; this is left as an exercise to the reader,
> though note that it requires two different change addresses
> for Alice for both HTLC-offerring and Resolved states,
> which can be arranged for the protocol)
>
> --
>
> [1]:
> https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels
>
> _______________________________________________
> 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/20230103/5b5b2cad/attachment-0001.html>

2023-06-09 13:07:21

- reply

📅 Original date posted:2022-11-04
📝 Original message:
Hi tbast,
FWIW, we haven't had _too_ many issues with the additional constraints
anchor channels bring. Initially users had to deal w/ the UTXO reserve, but
then sort of accepted the trade-off for the safety that actually being able
to dynamically bump the fee on your commitment transaction and HTLCs. We're
also able to re-target the fee level of second level spends on the fly, and
even aggregate them into distinct fee buckets.
However, I can imagine that if an implementation doesn't have its own
wallet, then things can be a bit more difficult, as stuff like the bitcoind
wallet may not expose the APIs one needs to do things like CPFP properly.
lnd has its own wallet (btcwallet), which is what has allowed us to adopt
default P2TR addresses everywhere so quickly (tho ofc we inherit additional
maintenance costs).
> Correctly managing this fee-bumping reserve involves a lot of complex
> decisions and dynamic risk assessment, because in worst-case scenarios, a
> node may need to fee-bump thousands of HTLC transactions in a short period
> of time.
IMO these new considerations aren't any worse than needing to predict the
future fee schedule of the chain to ensure that you can force close in a
timely manner when you need to. Re fee bumping thousands of HTLCs: anchor
lets them all be batched in the same transaction, which reduces fees and
also the worst-case on-chain force close footprint.
> each node can simply sign multiple versions of the HTLC transactions at
> various feerates
I'm not sure this can be mapped super cleanly to taproot channels that use
musig2. Today in the spec draft/impl, both sides maintain a pair of nonces
(one for each commitment transaction). If they need to sign N different
versions, then they also need to exchange N nonces, both during the initial
funding process, and also each time a new commitment transaction is created.
Mo signatures means mo transaction latency. Also how would retransmitting be
handled? By sending distinct valid signatures for a given fee rate, you're
effectively creating _even more_ commitments one needs to watch to be able
to play once they potentially hit the chain.
Ultimately, I'm not sure why implementations that have already rolled out
anchors by default, and have a satisfactory policy for ensuring fee bumping
UTXOs are available at all times would implement this. It's just yet another
option defined in the spec, and prescribes a more restrictive solution to
what's already possible: being able to dynamically fee bump commitment
transactions, and aggregate second level spends.
-- Laolu
On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Good morning list,
>
> The lightning network transaction format was updated to leverage CPFP
> carve-out and allow nodes to set fees at broadcast time, using a feature
> called anchor outputs [1].
>
> While desirable, this change brought a whole new set of challenges, by
> requiring nodes to maintain a reserve of available utxos for fee-bumping.
> Correctly managing this fee-bumping reserve involves a lot of complex
> decisions and dynamic risk assessment, because in worst-case scenarios,
> a node may need to fee-bump thousands of HTLC transactions in a short
> period of time.
>
> This is especially frustrating because HTLC transactions should not need
> external inputs, as the whole value of the HTLC is already provided in
> its input, which means we could in theory "simply" decrease the amount of
> the corresponding output to set the fees to any desired value. However,
> we can't do this safely because it doesn't work well with the revocation
> mechanism, unless we find fancy new sighash flags to add to bitcoin.
> See [2] for a longer rant on this issue.
>
> A very low tech and unsatisfying solution exists, which is what I'm
> proposing today: each node can simply sign multiple versions of the
> HTLC transactions at various feerates, and at broadcast time if you're
> lucky you'll have a pre-signed transaction that approximately matches
> the feerate you want, so you don't need to add inputs from your fee
> bumping reserve. This reduces the requirements on your on-chain wallet
> and simplifies transaction management logic. I believe that it's a
> pragmatic approach, even though not very elegant, to increase funds
> safety for existing node operators and wallets. I opened a spec PR
> that is currently chasing concept ACKs before I refine it [3].
>
> Please let me know what you think, and if this is something that you
> would like your implementation to provide.
>
> Thanks,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/688
> [2] https://github.com/lightning/bolts/issues/845
> [3] https://github.com/lightning/bolts/pull/1036
> _______________________________________________
> 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/20221104/9a1cfeb2/attachment.html>

2023-06-09 13:07:15

- reply

📅 Original date posted:2022-11-04
📝 Original message:
Hi Johan,
I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However, by the time
that transaction hits the chain, the UTXO may no longer exist. At that
point, what happens to the asset? Is it burned? Can you retry it again? Does
it go back to the sender?
As a concrete example, imagine I have a channel open, and give you an
address to "teleport" some additional assets to it. You take that addr, then
make a transaction to commit to the transfer. However, the block before you
commit to the transfer, my channel closes for w/e reason. As a result, when
the transaction committing to the UTXO (blinded or not), hits the chain, the
UTXO no longer exists. Alternatively, imagine the things happen in the
expected order, but then a re-org occurs, and my channel close is mined in a
block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
used as a serialization point, the scheme seems to lack a necessary total
ordering to ensure safety.
If we look at Taro's state transition model in contrast, everything is fully
bound to a single synchronization point: a normal Bitcoin transaction with
inputs consumed and outputs created. All transfers, just like Bitcoin
transactions, end up consuming assets from the set of inputs, and
re-creating them with a different distribution with the set of outputs. As a
result, Taro transfers inherit the same re-org safety traits as regular
Bitcoin transactions. It also isn't possible to send to something that won't
ultimately exist, as sends create new outputs just like Bitcoin
transactions.
Taro's state transition model also means anything you can do today with
Bitcoin/LN also apply. As an example, it would be possible for you to
withdrawn from your exchange into a Loop In address (on chain to off chain
swap), and have everything work as expected, with you topping off your
channel. Stuff like splicing, and other interactive transaction construction
schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.
Ignoring the ordering issue I mentioned above, I don't think this is a great
model for anchoring assets in channels either. With Taro, when you make the
channel, you know how many assets are committed since they're all committed
to in the funding output when the channel is created. However, let's say we
do teleporting instead: at which point would we recognize the new asset
"deposits"? What if we close before a pending deposits confirms, how can one
regain those funds? Once again you lose the serialization of events/actions
the blockchain provides. I think you'd also run into similar issues when you
start to think about how these would even be advertised on a hypothetical
gossip network.
I think one other drawback of the teleport model iiuc is that: it either
requires an OP_RETURN, or additional out of band synchronization to complete
the transfer. Since it needs to commit to w/e hash description of the
teleport, it either needs to use an OP_RETURN (so the receiver can see the
on chain action), or the sender needs to contact the receiver to initiate
the resolution of the transfer (details committed to in a change addr or
w/e).
With Taro, sending to an address creates an on-chain taproot output just
like sending to a P2TR address. The creation of the output directly creates
the new asset anchor/output as well, which allows the receiver to look for
that address on chain just like a normal on chain transaction. To 3rd party
observers, it just looks like a normal P2TR transfer. In order to finalize
the receipt of the asset, the receiver needs to obtain the relevant
provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
service keyed by the input outpoint and output index. In short, the send
process is fully async, with the sender and receiver using the blockchain
itself as a synchronization point like a normal Bitcoin wallet.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221104/354c256b/attachment.html>

2023-06-09 13:06:45

- reply

📅 Original date posted:2022-09-01
📝 Original message:
Hi Alex,
This is a super cool project! I've shared some thoughts here in a comment on
the draft PR:
PR:
https://github.com/lightningnetwork/lnd/pull/6843#issuecomment-1234933319
Also I cc'd the lnd mailing list on this reply, perhaps we can move the
discussion over there (or in the issue) since this is more of an lnd
specific thing. In the future, the lnd mailing list is also probably a
better place for lnd architecture specific proposals/discussions.
-- Laolu
On Thu, Sep 1, 2022 at 10:56 AM Alex Akselrod via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> At NYDIG, we're considering ways to harden large LND deployments. Joost
> and I discussed that currently, when external untrusted peers make inbound
> connections, LND must verify the identity of the peer during the noise
> handshake, and it must do this before enforcing any potential key-based
> allow lists. This is done in the same process as the node's other critical
> tasks, such as monitoring the chain.
>
> To reduce the attack area of the main node process, we'd like to propose a
> means to optionally separate the peer communication into a separate
> process: something like CLN's connectd, running separately, and the
> connections would be multiplexed over a single network connection initiated
> from the node to the proxy. The core of our current idea is demonstrated in
> a draft PR: https://github.com/lightningnetwork/lnd/pull/6843
>
> I'd love some early feedback on the general direction of this. If this
> would be interesting, I'll build it out into a fully working feature.
>
> Thanks,
>
> Alex Akselrod
> _______________________________________________
> 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/20220901/a7c7cf81/attachment.html>

2023-06-09 13:06:35

- reply

📅 Original date posted:2022-07-01
📝 Original message:
Hi Val,
> Another huge win of backpressure is that it only needs to happen in DoS
> situations, meaning it doesn’t have to impact users in the normal case.
I agree, I think the same would apply to prepayments as well (0 or 1 msat in
calm times). My main concern with relying _only_ on backpressure rate
limiting is that we'd end up w/ your first scenario more often than not,
which means routine (and more important to the network) things like fetching
invoices becomes unreliable.
I'm not saying we should 100% compare onion messages to Tor, but that we
might
be able to learn from what works and what isn't working for them. The
systems
aren't identical, but have some similarities.
On the topic of parameters across the network: could we end up in a scenario
where someone is doing like streaming payments for a live stream (or w/e),
ends up fetching a ton of invoices (actual traffic leading to payments), but
then ends up being erroneously rate limited by their peers? Assuming they
have 1 or 2 channels that have now all been clamped down, is waiting N
minutes (or w/e) their only option? If so then this might lead to their
livestream (data being transmitted elsewhere) being shut off. Oops, they
just
missed the greatest World Cup goal in history! You had to be there, you
had to
be there, you had to *be* there...
Another question on my mind is: if this works really well for rate limiting
of
onion messages, then why can't we use it for HTLCs as well?
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/bb864893/attachment.html>

2023-06-09 13:06:35

- reply

📅 Original date posted:2022-07-01
📝 Original message:
Hi Matt,
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable cost that an attacker cares about without
> impacting the system's usability due to said cost.
Applying this statement to related a area, would you also agree that
proposals
to introduce pre-payments for HTLCs to mitigate jamming attacks is similarly
a dead end? Personally, this has been my opinion for some time now. Which
is why I advocate for the forwarding pass approach (gracefully degrade to
stratified topology), which in theory would allow the major flows of the
network to continue in the face of disruption.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/06c96445/attachment.html>

2023-06-09 13:06:21

- reply

📅 Original date posted:2022-06-29
📝 Original message:
Hi Rusty,
Thanks for the feedback!
> This is over-design: if you fail to get reliable gossip, your routing will
> suffer anyway. Nothing new here.
Idk, it's pretty simple: you're already watching for closes, so if a close
looks a certain way, it's a splice. When you see that, you can even take
note of the _new_ channel size (funds added/removed) and update your
pathfinding/blindedpaths/hophints accordingly.
If this is an over-designed solution, that I'd categorize _only_ waiting N
blocks as wishful thinking, given we have effectively no guarantees w.r.t
how long it'll take a message to propagate.
If by routing you mean a routing node then: no, a routing node doesn't even
really need the graph at all to do their job.
If by routing you mean a sender, then imo still no: you don't necessarily
need _all_ gossip, just the latest policies of the nodes you route most
frequently to. On top of that, since you can get the latest policy each time
you incur a routing failure, as you make payments, you'll get the latest
policies of the nodes you care about over time. Also consider that you might
fail to get "reliable" gossip, simply just due to your peer neighborhood
aggressively rate limiting gossip (they only allow 1 update a day for a
node, you updated your fee, oops, no splice msg for you).
So it appears you don't agree that the "wait N blocks before you close your
channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144?
>From my PoV, the whole point of even signalling that a splice is on going,
is for the sender's/receivers: they can continue to send/recv payments over
the channel while the splice is in process. It isn't that a node isn't
getting any gossip, it's that if the node fails to obtain the gossip message
within the N block period of time, then the channel has effectively closed
from their PoV, and it may be an hour+ until it's seen as a usable (new)
channel again.
If there isn't a 100% reliable way to signal that a splice is in progress,
then this disincentives its usage, as routers can lose out on potential fee
revenue, and sends/receivers may grow to favor only very long lived
channels. IMO _only_ having a gossip message simply isn't enough: there're
no real guarantees w.r.t _when_ all relevant parties will get your gossip
message. So why not give them a 100% reliable on chain signal that:
something is in progress here, stay tuned for the gossip message, whenever
you receive that.
-- Laolu
On Tue, Jun 28, 2022 at 6:40 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi Roasbeef,
>
> This is over-design: if you fail to get reliable gossip, your routing
> will suffer anyway. Nothing new here.
>
> And if you *know* you're missing gossip, you can simply delay onchain
> closures for longer: since nodes should respect the old channel ids for
> a while anyway.
>
> Matt's proposal to simply defer treating onchain closes is elegant and
> minimal. We could go further and relax requirements to detect onchain
> closes at all, and optionally add a perm close message.
>
> Cheers,
> Rusty.
>
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> > Hi y'all,
> >
> > This mail was inspired by this [1] spec PR from Lisa. At a high level, it
> > proposes the nodes add a delay between the time they see a channel
> closed on
> > chain, to when they remove it from their local channel graph. The motive
> > here is to give the gossip message that indicates a splice is in process,
> > "enough" time to propagate through the network. If a node can see this
> > message before/during the splicing operation, then they'll be able relate
> > the old and the new channels, meaning it's usable again by
> senders/receiver
> > _before_ the entire chain of transactions confirms on chain.
> >
> > IMO, this sort of arbitrary delay (expressed in blocks) won't actually
> > address the issue in practice. The proposal suffers from the following
> > issues:
> >
> > 1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement
> > takes longer than 2 hours to reach the "economic majority" of
> > senders/receivers, then the channel won't be able to mask the splicing
> > downtime.
> >
> > 2. Gossip propagation delay and offline peers. These days most nodes
> > throttle gossip pretty aggressively. As a result, a pair of nodes doing
> > several in-flight splices (inputs become double spent or something, so
> > they need to try a bunch) might end up being rate limited within the
> > network, causing the splice update msg to be lost or delayed
> significantly
> > (IIRC CLN resets these values after 24 hours). On top of that, if a
> peer
> > is offline for too long (think mobile senders), then they may miss the
> > update all together as most nodes don't do a full historical
> > _channel_update_ dump anymore.
> >
> > In order to resolve these issues, I think instead we need to rely on the
> > primary splicing signal being sourced from the chain itself. In other
> words,
> > if I see a channel close, and a closing transaction "looks" a certain
> way,
> > then I know it's a splice. This would be used in concert w/ any new
> gossip
> > messages, as the chain signal is a 100% foolproof way of letting an aware
> > peer know that a splice is actually happening (not a normal close). A
> chain
> > signal doesn't suffer from any of the gossip/time related issues above,
> as
> > the signal is revealed at the same time a peer learns of a channel
> > close/splice.
> >
> > Assuming, we agree that a chain signal has some sort of role in the
> ultimate
> > plans for splicing, we'd need to decide on exactly _what_ such a signal
> > looks like. Off the top, a few options are:
> >
> > 1. Stuff something in the annex. Works in theory, but not in practice,
> as
> > bitcoind (being the dominant full node implementation on the p2p
> network,
> > as well as what all the miners use) treats annexes as non-standard.
> Also
> > the annex itself might have some fundamental issues that get in the
> way of
> > its use all together [2].
> >
> > 2. Re-use the anchors for this purpose. Anchor are nice as they allow
> for
> > 1st/2nd/3rd party CPFP. As a splice might have several inputs and
> outputs,
> > both sides will want to make sure it gets confirmed in a timely manner.
> > Ofc, RBF can be used here, but that requires both sides to be online to
> > make adjustments. Pre-signing can work too, but the effectiveness
> > (minimizing chain cost while expediting confirmation) would be
> dependent
> > on the fee step size.
> >
> > In this case, we'd use a different multi-sig output (both sides can
> rotate
> > keys if they want to), and then roll the anchors into this splicing
> > transaction. Given that all nodes on the network know what the anchor
> size
> > is (assuming feature bit understanding), they're able to realize that
> it's
> > actually a splice, and they don't need to remove it from the channel
> graph
> > (yet).
> >
> > 3. Related to the above: just re-use the same multi-sig output. If
> nodes
> > don't care all that much about rotating these keys, then they can just
> use
> > the same output. This is trivially recognizable by nodes, as they
> already
> > know the funding keys used, as they're in the channel_announcement.
> >
> > 4. OP_RETURN (yeh, I had to list it). Self explanatory, push some
> bytes in
> > an OP_RETURN and use that as the marker.
> >
> > 5. Fiddle w/ the locktime+sequence somehow to make it identifiable to
> > verifiers. This might run into some unintended interactions if the
> inputs
> > provided have either relative or absolute lock times. There might also
> be
> > some interaction w/ the main constructing for eltoo (uses the
> locktime).
> >
> > Of all the options, I think #2 makes the most sense: we already use
> anchors
> > to be able to do fee bumping after-the-fact for closing transactions, so
> why
> > not inherit them here. They make the splicing transaction slightly
> larger,
> > so maybe #3 (or something else) is a better choice.
> >
> > The design space for spicing is preeetty large, so I figure the most
> > productive route might be discussing isolated aspects of it at a time.
> > Personally, I'm not suuuper caught up w/ what the latest design drafts
> are
> > (aside from convos at the recent LN Dev Summit), but from my PoV, how to
> > communicate the splice to other peers has been an outstanding design
> > question.
> >
> > [1]: https://github.com/lightning/bolts/pull/1004
> > [2]:
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html
> >
> > -- Laolu
> > _______________________________________________
> > 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/20220629/0823b5a9/attachment.html>

2023-06-09 13:06:20

- reply

📅 Original date posted:2022-06-27
📝 Original message:
Hi y'all,
This mail was inspired by this [1] spec PR from Lisa. At a high level, it
proposes the nodes add a delay between the time they see a channel closed on
chain, to when they remove it from their local channel graph. The motive
here is to give the gossip message that indicates a splice is in process,
"enough" time to propagate through the network. If a node can see this
message before/during the splicing operation, then they'll be able relate
the old and the new channels, meaning it's usable again by senders/receiver
_before_ the entire chain of transactions confirms on chain.
IMO, this sort of arbitrary delay (expressed in blocks) won't actually
address the issue in practice. The proposal suffers from the following
issues:
1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement
takes longer than 2 hours to reach the "economic majority" of
senders/receivers, then the channel won't be able to mask the splicing
downtime.
2. Gossip propagation delay and offline peers. These days most nodes
throttle gossip pretty aggressively. As a result, a pair of nodes doing
several in-flight splices (inputs become double spent or something, so
they need to try a bunch) might end up being rate limited within the
network, causing the splice update msg to be lost or delayed significantly
(IIRC CLN resets these values after 24 hours). On top of that, if a peer
is offline for too long (think mobile senders), then they may miss the
update all together as most nodes don't do a full historical
_channel_update_ dump anymore.
In order to resolve these issues, I think instead we need to rely on the
primary splicing signal being sourced from the chain itself. In other words,
if I see a channel close, and a closing transaction "looks" a certain way,
then I know it's a splice. This would be used in concert w/ any new gossip
messages, as the chain signal is a 100% foolproof way of letting an aware
peer know that a splice is actually happening (not a normal close). A chain
signal doesn't suffer from any of the gossip/time related issues above, as
the signal is revealed at the same time a peer learns of a channel
close/splice.
Assuming, we agree that a chain signal has some sort of role in the ultimate
plans for splicing, we'd need to decide on exactly _what_ such a signal
looks like. Off the top, a few options are:
1. Stuff something in the annex. Works in theory, but not in practice, as
bitcoind (being the dominant full node implementation on the p2p network,
as well as what all the miners use) treats annexes as non-standard. Also
the annex itself might have some fundamental issues that get in the way of
its use all together [2].
2. Re-use the anchors for this purpose. Anchor are nice as they allow for
1st/2nd/3rd party CPFP. As a splice might have several inputs and outputs,
both sides will want to make sure it gets confirmed in a timely manner.
Ofc, RBF can be used here, but that requires both sides to be online to
make adjustments. Pre-signing can work too, but the effectiveness
(minimizing chain cost while expediting confirmation) would be dependent
on the fee step size.
In this case, we'd use a different multi-sig output (both sides can rotate
keys if they want to), and then roll the anchors into this splicing
transaction. Given that all nodes on the network know what the anchor size
is (assuming feature bit understanding), they're able to realize that it's
actually a splice, and they don't need to remove it from the channel graph
(yet).
3. Related to the above: just re-use the same multi-sig output. If nodes
don't care all that much about rotating these keys, then they can just use
the same output. This is trivially recognizable by nodes, as they already
know the funding keys used, as they're in the channel_announcement.
4. OP_RETURN (yeh, I had to list it). Self explanatory, push some bytes in
an OP_RETURN and use that as the marker.
5. Fiddle w/ the locktime+sequence somehow to make it identifiable to
verifiers. This might run into some unintended interactions if the inputs
provided have either relative or absolute lock times. There might also be
some interaction w/ the main constructing for eltoo (uses the locktime).
Of all the options, I think #2 makes the most sense: we already use anchors
to be able to do fee bumping after-the-fact for closing transactions, so why
not inherit them here. They make the splicing transaction slightly larger,
so maybe #3 (or something else) is a better choice.
The design space for spicing is preeetty large, so I figure the most
productive route might be discussing isolated aspects of it at a time.
Personally, I'm not suuuper caught up w/ what the latest design drafts are
(aside from convos at the recent LN Dev Summit), but from my PoV, how to
communicate the splice to other peers has been an outstanding design
question.
[1]: https://github.com/lightning/bolts/pull/1004
[2]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220627/1544d48a/attachment.html>

2023-06-09 13:06:15

- reply

📅 Original date posted:2022-06-23
📝 Original message:
Hi Michael,
> A minor point but terminology can get frustratingly sticky if it isn't
> agreed on early. Can we refer to it as nested MuSig2 going
> forward rather than recursive MuSig2?
No strong feelings on my end, the modifier _nested_ is certainly a bit less
loaded and conceptually simpler, so I'm fine w/ using that going forward if
others are as well.
> Rene Pickhardt brought up the issue of latency with regards to
> nested/recursive MuSig2 (or nested FROST for threshold) on Bitcoin
> StackExchange
Not explicitly, but that strikes me as more of an implementation level
concern. As an example, today more nodes are starting to use replicated
database backends instead of a local ed embedded database. Using such a
database means that _network latency_ is now also a factor, as committing
new states requires round trips between the DBMS that'll increase the
perceived latency of payments in practice. The benefit ofc is better support
for backups/replication.
I think in the multi-signature setting for LN, system designers will also
need to factor in the added latency due to adding more signers into the mix.
Also any system that starts to break up the logical portions of a node
(signing, hosting, etc -- like Blockstream's Greenlight project), will need
to wrangle with this as well (such is the nature of distributed systems).
> MuSig2 obviously generates an aggregated Schnorr signature and so even
> nested MuSig2 require the Lightning protocol to recognize and verify
> Schnorr signatures which it currently doesn't right?
Correct.
> So is the current thinking that Schnorr signatures will be supported first
> with a Schnorr 2-of-2 on the funding output (using OP_CHECKSIGADD and
> enabling the nested schemes) before potentially supporting non-nested
> MuSig2 between the channel counterparties on the funding output later? Or
> is this still in the process of being discussed?
The current plan is to jump straight to using musig2 in the funding output,
so: a single aggregated 2-of-2 key, with a single multi-signature being used
to close the channel (co-op or force close).
Re nested vs non-nested: to my knowledge, if Alice uses the new protocol
extensions to open a taproot channel w/ Bob, then she wouldn't necessarily
be aware that Bob is actually Barol (Bob+Carol). She sees Bob's key (which
might actually be an aggregated key) and his public nonce (which might
actually also be composed of two nonces), and just runs the protocol as
normal. Sure there might be some added latency depending on Barol's system
architecture, but from Alice's PoV that might just be normal network latency
(eg: Barol is connecting over Tor which already adds some additional
latency).
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220623/e1eb0263/attachment.html>

2023-06-09 13:06:13

- reply

📅 Original date posted:2022-06-07
📝 Original message:
Hi y'all,
Last week nearly 30 (!) Lightning developers and researchers gathered in
Oakland, California for three day to discuss a number of matters related to
the current state and evolution of the protocol. This time around, we had
much better representation for all the major Lightning Node implementations
compared to the last LN Dev Summit (Zurich, Oct 2021).
Similar to the prior LN Dev Summit, notes were kept throughout the day that
attempted on a best effort basis to capture the relevant discussions,
decisions, and new relevant research or follow up areas to circle back on.
Last time around, I sent out an email that summarized some key takeaways
(from my PoV) of the last multi-day dev summit [1]. What follows in this
email is a similar summary/recap of the three day summit. Just like last
time: if you attended and felt I missed out on a key point, or inadvertently
misrepresented a statement/idea, please feel free to reply, correcting or
adding additional detail.
The meeting notes in full can be found here:
https://docs.google.com/document/d/1KHocBjlvg-XOFH5oG_HwWdvNBIvQgxwAok3ZQ6bnCW0/edit?usp=sharing
# Simple Taproot Channels
During the last summit, Taproot was a major discussion topic as though the
soft fork had been deployed, we we're all still watching the 🟩 's stack up
on the road to ultimately activation. Fast forward several months later and
Taproot has now been fully activated, with ecosystem starting to
progressively deploy more and more advanced systems/applications that take
advantage of the new features.
One key deployment model that came out of the last LN Dev summit was the
concept of an iterative roadmap that progressively revamped the system to
use more taprooty features, instead of a "big bang" approach that would
attempt to package up as many things as possible into one larger update. At
a high level the iterative roadmap proposed that we unroll an existing
larger proposal [2] into more bite sized pieces that can be incrementally
reviewed, implemented, and ultimately deployed (see my post on the LN Dev
Summit 2021 for more details).
## Extension BOLTs
Riiight before we started on the first day, I wrote up a minimal proposal
that attempted to tackle the first two items of the Taproot iterative
deployment schedule (musig2 funding outputs and simple tapscript mapping)
[3]. I called the proposal "Simple Taproot Channels" as it set out to do a
mechanical mapping of the current commitment and script structure to a more
taprooty domain. Rather than edit 4 or 5 different BOLTs with a series of
"if this feature bit applies" nested clauses, I instead opted to create a
new standalone "extension bolt" that defines _new_ behavior on top of the
existing BOLTs, referring to the BOLTs when necessary. The style of the
document was inspired by the "proposals" proposal (very meta), which was
popularized by cdecker and adopted by t-bast with his documents on
Trampoline and Blinded Paths.
If the concept catches on, extension BOLTs provide us with a new way to
extend the spec: rather than insert everything in-line, we could instead
create new standalone documents for larger features. Having a single self
contained document makes the proposal easier to review, and also gives the
author more room to provide any background knowledge, primaries, and also
rationale. Overtime, as the new extensions become widespread (eg: taproot is
the default channel type), we can fold in the extensions back to the main
set of "core" BOLTs (or make new ones as relevant).
Smaller changes to the spec like deprecating an old field or tightening up
some language will likely still follow the old approach of mutating the
existing BOLTs, but larger overhauls like the planned PTLC update may find
the extension BOLTs to be a better tool.
## Tapscript, Musig2, and Lightning
As mentioned above the Simple Taproot Channels proposal does two main
things:
1. Move the existing 2-of-2 p2wsh segwit v0 funding output to a _single
key_ p2tr output, with the single key actually being an aggregated musig2
key.
2. Map all our existing scripts to the tapscript domain, using the
internal key (keyspend path) for things like revocations, which an
potentially allow nodes to store less state for HTLCs.
Of the two components #1 is by far the trickiest. Musig2 is a very elegant
protocol (not to mention the spec which y'all should totally check out) but
as the signatures aren't deterministic (like RFC 6979 [5]), both signers
need to "protect themselves at all times" to ensure they don't ever re-use
nonces, which can lead to a private key leak (!!).
Rather than try to create some sort of psuedo-deterministic nonces scheme
(which maaybe works until the Blockstream Research team squints vaguely in
its direction), I opted to just make all nonces 100% ephemeral and tied to
the lifetime of a connection. Musig2 defines something called a public
nonces, which is actually two individual 33-byte nonces. This value needs to
be exchanged before signing can begin (but can be sent before sides know
they're aggregated keys). One important thing to note is that given that the
channels today have _asymmetric_ state, we actually need a _pair_ of public
nonces: one that I'll use to sign my commitment, and one I'll use to sign
yours. Lightning channels w/ symmetric state like eltoo can get by w/ only
exchange a single set of nonces, as there's only one message per state.
Nonce exchange takes place in a few places:
* During initial funding: I send my public nonce in the open_channel
message, you send yours in the accept_channel message. After this
exchange we can both generate signatures for the refund commitment
transactions.
* After the channel is "ready" we send another set of nonces, so we can
sign the next state. This is similar to the existing revocation key
exchange: I need your next nonce/key before I can sign a new state.
* Upon channel re-establishment a _new_ set of nonces is sent, as they're
100% ephemeral. The current draft also requires that if you were
re-transmitting a sig, then you use the _new_ nonces to sign again, as
it's possible you went to retransmit but left off an expired/trimmed
HLTC (could lead to nonce re-use and also needing to remember nonces).
* Each time I revoke my channel, I send to you a single nonce, my "local
nonce" (naming needs some work here), which lets you sign for a new
state.
* Each time I send a new sig, I also send you another nonce, my "remote"
nonce", which
* When I send a shutdown (co-op close) I send a single public nonce so we
can sign the next co-opc close offer.
* When I send a closing_signed I send another nonce so once you send your
offer, we sign another set.
The final flows aren't 100% yet finalized, as we'll need some
implementations drafted to make sure the nonce handling and script mapping
works out properly.
### Lightning Channels & Recursive Musig2
One other cool topic that came up is the concept of leveraging recursive
musig2 (so musig2 within musig2) to make channels even _more_ multi-sigy.
The benefit here is that Bob & Carol can each have their individual keys
(which might actually be aggregated keys themselves) and make a channel w/
Alice, who only knows of them as Barol, and doesn't know there're actually
another pair of keys at play. This is _really_ cool as it allows node
operators, wallets, and lightning platforms to experiment with various
key/signing trees that may add more security, redundancy, or flexibility.
When this first came up, someone brought up the fact that while the scheme
is "known" the initial paper as they weren't sure how to actually write a
proof for it. During the session, someone emailed one of the musig2 authors
asking for more details, and if it's safe to implement and roll out.
Thankfully they quickly replied and explained that the proof recursive musig
(pls someone correct me again here if I'm wrong) wasn't left out due to
impossibility, but that a proof in the existing Random Oracle Model (which
was used to derive a bound for the number of nonces needed) would lead to a
blow up in the number of nonces required. Attempting to write the proof in
some other model would likely lead to better results (proved w/ two nonces
as base musig2), but would end up being pretty complicated, so hard to read
and even review for correctness.
Assuming everything checks out, then a useful mental model explained by the
musig2 BIP author is a sort of tree structure. Assuming I'm a signer, and we
assemble the other signer as a sibling leaf in a binary tree, then I just
need to wait for the sibling nonce/key, before I can aggregate that into
the final value. So if there're 3 signers, I wait for the regular public
nonce, but the other signers sum their respective nonces into a single
nonce, then send that to me. A similar operation is carried out for key
aggregation, with the rest of the protocol being mostly the same.
Ultimately, even if wallets/nodes aren't ready to roll something like this
out today, we at least want to make sure the proposed flow is compatible
with Simple Taproot Channels, and ideally we'd have a toy implementation to
verify out understanding and show it's possible/sound. I volunteered to hack
up a simple recursive musig2 demo, as there doesn't seem to be any code in
the wild that implements it.
## Lightning Gossip
# Gossip V2: Now Or Later?
Another big topic related to Taproot was the question of how we should
update the gossip network: the gossip protocol today has all channels
validated by node, which requires that the nodes understand how to
reconstruct the funding output based on the set of advertised keys. The
protocol today assumes a segwit v0 p2wsh multi-sig is used. Assuming we had
everything implemented today, a node wouldn't be able to advertise its new
taproot channels to the rest of the public graph as they wouldn't understand
how to validate it.
This presents a new opportunity: we already need to rework gossip for
taproot, so should we go ahead and re-design the entire thing with an eye
for better privacy and future extensibility?
A proposal for the "re-design the entire thing" was floated in the past by
Rusty [6]. It does away with the strict coupling of channels to channel
announcements, and instead moves them to the _node_ level. Each node would
then advertise the set of "outputs" they have control of, which would then
be mapped to the total capacity of a node, without requiring that these
outputs self identify themselves on-chain as Lightning Channels. This also
opens up the door to different, potentially more privacy preserving
proofs-of-channel-ownership (something something zkp).
On the other hand, we could just follow the path of Simple Taproot Channels
and map musig2+schnorr onto the existing gossip network. This is less
changes in total, with the main benefit being the ability to only send 1 sig
(aggregated musig2 sig of keys) instead of 4 individual sigs. I made a very
lofty proposal in this direction here [7].
Ultimately we decided to take the "just musig2 aspects" from gossip v1.5
(not the real name), and the "let's refresh all the messages w/ TLV
goodness" from the gossip v2 proposal. This gives us a smaller package to
implement, and lets us potentially rejigger the messages to be more
extensible and remove cruft like the node color that almost nothing uses,
but we all validate/store.
The follow up work in this area is a more concrete proposal that updates the
relevant gossip messages to be taproot aware and TLV'd and also update the
set of requirements w.r.t _how_ to validate the channels in the first place
(so given two keys verify that applying the keyagg method of musig2 lead to
what' in the funding output).
Gossip v2 will likely happen "eventually", but the rather large design space
needs to be explored a bit more so we can properly analyze exactly what
privacy and extensibility properties we'll get out of it.
# Applying Mini Sketch to LN Gossip
One issue we have today, is that other than the initial scid query mechanism
added to the protocol, there isn't a great way to ensure you have all the
latest updates your peer has. These days, many nodes pretty aggressively
rate limit other nodes, so you might even have trouble sending out your
update in the first place. A recent paper (that I haven't actually fully
read yet) [8] analyzes the gossip network today to work out things like:
exactly how long it takes things to propagate, total bandwidth usage, etc.
Minisketch [9] (the grandchild of IBLTs ;)), is an efficient set
reconciliation protocol that was designed for Bitcoin p2p mempool syncing,
but can be applied to other protocols. An attendee has been working on
brushing off some older work to try to see how we could apply it to the LN
protocol to give nodes a more bandwidth efficient way to sync channel
updates, and also achieve better update propagation. This supplements some
existing investigative work done by Alex Meyers [10], with more concrete
designs w.r.t: what goes into the sketch, and the various size parameters
that need to be chosen.
# Channel Jamming
An attendee gave a talk on the various proposed solutions to channel
jamming, evaluating them on several axis including: punishment/monetary,
local vs global reputation, feasibility of mechanism design, UX
implications, and implementation complexity. The presenter didn't present a
new concrete proposal, but instead went through the various trade-offs,
ultimately concluding that they factor monetary penalties wherein the funds
are distributed across the route, rather than being provably burnt to
miners. However they alluded to some future upcoming work that attempts a
more rigorous analysis of the proposed solutions, their tradeoffs, and
potential ways we can parametrize solutions to be more effective (how much
should they pay, etc).
For those looking to brush up on the latest state of research/mitigations in
this area, I recommend this blog post by Bitmex research [11].
# Onion Messages & DoS
The topic of DoS concerns related to onion messages (in isolation, so not
necessarily related to things like bolt12 that take advantage of them came
up. During a white boarding session some argued that DoS isn't actually
much of an issue, as nodes can leverage "back propagation congestion
control" to inform the source (who may not actually be the sender) that
they'll start to drop or limit their packets, with each node doing this
iteratively until the actual source of the spam has been clamped. A few
lofty designs were thrown around, but more work needs to be done to
concretely specify something so it can be properly analyzed.
On the other side of the spectrum, rather than attempt to rate limit at the
node level (which each node having their own policy), nodes could opt
instead to forward _anything_ as long as the sender pays them enough. I
proposed a lofty approach that combined AMP and Onion Messages earlier this
year [12]. At a high level I make an AMP payment, which pushes extra coins
to all nodes on a route, and also drops off a special identifier to them.
When I send an onion message I include this identifier, with each node
performing their own account w.r.t the amount of bandwidth an ID has
remaining.
Ultimately a few implementations are pretty close to deploying their
implementation of onion messages, so no matter the intended use case, it
would be good to have code deployed along side to either rate limit or price
resource consumption accordingly. Otherwise, we might end up in a scenario
where DoS concerns were brushed aside, but end up being a huge issue later.
# Blinded Paths, QR Codes & Invoices
Blinded paths [13] is a new-er proposal to solve the "last mile" privacy
issue when receiving payments on LN. Today invoices to unadvertised channels
contain a set of hop hints, which are anchored at public nodes in the graph,
and also leak the scid of the unadvertised channel (points on-chain to the
channel receiving payments). A solution for the on-chain leak, SCID channel
aliases [15] are in the process of being widely rolled out. Channel aliases
instead use a random value in the invoice, allowing receiving nodes to break
that on-chain link and even rotate out the value periodically. With the
on-chain leak addressed, it's still the case that you give away your
"position" in the network, since as a sender I know that you're connected to
node N with a private channel.
Blinded paths address this node-level last mile privacy leak by replacing
hop hints with a new cryptographically blinded path. At a high level, the
receiver can construct a "hop hint" of length greater than 1, gather the
public keys of each of the nodes, then blinded them such that: the sender
can use them for path finding, but doesn't actually now exactly _which_
nodes they actually are.
There're two type of blinded paths: those in onion messages and those used
for actual payments. The latter variant was only formalized earlier this
year, as before people were mainly interested in using them to fetch BOLT 12
invoice via onion messages. One issue that pops up when attempting to use
blinded paths for normal payments is: the size of the resulting invoice. As
blinded paths are actually fragments of publicly known paths, as a receiver,
you want to stuff as many of them into the invoice as possible, since they
MUST be taken in order to route towards you. Invoices are typically
communicated via QR codes, which have a hard limit w.r.t the amount of
information that can be packed in. On the other hand for invoice fetching,
all that matters is that a path exists, so you can get by with stuffing less
of then in a QR code.
As a result, blinded paths aren't necessarily compatible with the widely
deployed BOLT 11 based QR codes. Instead a way to fetch invoice on demand is
required. Both BOLT-12 and LN-URL provide standardized ways for nodes to
fetch invoices, though their transport/signalling medium of choice differs.
Blinded routes are technically compatible with BOLT 11 invoices, but may be
hampered by the fact that you can only include so many routes.
Another consideration is that unlike hop hints, blinded paths require more
maintain once, as since they traverse public route, policy changes like a
fee update may invalidate an entire set set of routes. One proposed solution
is that forwarding nodes should observe their older policy for a period of
time (so a grace period), and also that blinded paths should have an
explicit expiry (similar to the existing invoice expiry).
One other implication is that the set of routes the receiver includes
matters
more: if they don't send enough or select them poorly, the sender may never
be
able to reach them even though a path exists in theory. More hands on
experience is needed so the spec authors can better guide implementations
and
wallets w.r.t best practices.
# Friend-of-a-friend Balance Sharing & Probing
A presentation was given on friend-of-a-friend balance sharing [16]. The
high level idea is that if we share _some_ information within a local
radius, then this gives the sender more information to choose a path that's
potentially more reliable. The tradeoff here ofc is that nodes will be
giving away more information that can potentially be used to ascertain
payment flows. In an attempt to minimize the amount of information shared,
the presenter proposed that just 2 bits of information be shared. Some
initial simulations showed that sharing local information actually performed
better than sharing global information (?). Some were puzzled w.r.t how
that's possible, but assuming the slides+methods are published others can
dig further into the model/parameter used to signal the inclusion.
Arguably, information like this is already available via probing, so one
line of thinking is something like: "why not just share _some_ of it" that
may actually lead to less internal failures? This is related to a sort of
tension between probing as a tool to increase payment reliability and also
as a tool to degrade privacy in the network. On the other hand, others
argued that probing provides natural cover traffic, since they actually
_are_ payments, though they may not be intended to succeed.
On the topic of channel probing, a sort of makeshift protocol was devised to
make it harder in practice, sacrificing too much on the axis of payment
reliability. At a high level it proposes that:
* nodes more diligently set both their max_htlc amount, as well as the
max_htlc_value_in_flight amount
* a 50ms (or select other value) timer should be used when sending out
commitment signatures, independent of HTLC arrival
* nodes leverage the max_htlc value to set a false ceiling on the max in
flight parameter
* for each HTLC sent/forwarded, select 2 other channels at random and
reduce the "fake" in-flight ceiling for a period of time
Some more details still need to be worked out, but some felt that this would
kick start more research into this area, and also make balance mapping
_slightly_ more difficult. From afar, it may be the case that achieving
balance privacy while also achieving acceptable levels of payment
reliability might be at odds with each other.
# Eltoo & ANYPREVOUT
One of the attendees is currently working on both fully implementing eltoo,
as well as specifying the exact channel funding+update interaction were it
to be rolled out align side the existing penalty based channels in the
protocol. As this version of eltoo is based on Taproot, we were able to
compare notes a bit to find the overlapping set of changes (nonce handling,
etc), which permits cross review of the proposals. This type of work is
cool, as only by fully implementing something end to end can you reaaally
work out all the edge cases and nuances.
ANYPREVOUT as hasn't changed significantly as of late. An attendee shared
plans to create a sort of mega all-future-feasible-soft-forks fork of
bitcoind, that would package up various unmerged (from bitcoind's) proposal
soft fork packages into an easy to run+install binary/project attached to a
signet. The hop is that by giving developers an easy way to interact with
proposed soft fork proposals (vs debasing some ancient pull request), wider
participation in testing/implementation/review can be facilitated.
# Trampoline Routing
There was a presentation on Trampoline routing explaining the motivation,
history, and current state of the proposal. The two main cases we've
narrowed down on are:
1. A mobile user doesn't necessarily want to sync the _entire_ graph, so
they can use trampoline to maintain a subset and still be able to send
payments.
2. A mobile user wants to be able to instate a payment, go offline, and
return at a later time to learn about the final state of the payment.
Use case #2 seems to be the most promising when combined with other
proposals for holding HTLCs at an origin node (call it an "LSP") [13].
Combined together, this would allow a mobile node to send a payment, then go
offline, with the LSP being able to retry the payment either continuously or
only when it knows the receiver is online to accept the payment. This may
potentially dramatically improve the UX for LN on mobile, as things suddenly
become a lot more asynchronous: I do something go offline, and the LSP node
can fulfil the payment in the background, then wait for me to come online to
settle the final. hop.
Trampoline can also be composed well with blinded routes (blinded route from
last trampoline to receiver) and also MPP (internal nodes can split
themselves with local information).
One added trade-off is that since the sender doesn't know the entire route,
they need to sort of overshoot w.r.t fees and CTLVs. This is something
we've known for a while, but until Trampoline is more widely rolled out, we
won't have a very good feel w.r.t how much extra senders will need to
allocate.
# Node Fee Optimization & Fee Rate Cards
Over the past few years, a common thread we've seen across successful
routing nodes is dynamic fee setting as a way to encourage/discourage
traffic. A routing nodes can utilize the set of fees of a channel to either
make it too expensive for other nodes to route through (it's already
depleted don't try unless you'll give be 10 mil sats, which no one would) or
very cheap, which'll incentivize flows in the other direction. If all nodes
are constantly sending out updates of this nature, then it can generate a
lot of traffic, and also sort of leak more balance information overtime
(which some nodes are already doing: using fees/max_htlc to communicate
available balances).
One attendee proposed allowing nodes to express a sort of fee gradient via a
static curve/bucket/function, instead of dynamically communicating what the
latest state of the fee+liquidity distribution looks like. A possible
manifestation could be a series of buckets, each of which with varying fee
rates. If your payment consumes 50% of channel balance, then you pay this
rate, otherwise if it's 5% you pay this rate, etc, etc. This might allow for
nodes to capture the same dynamics as they do with more dynamic fee updates,
but in a way that leaks less information and also consumes less gossip
bandwidth.
# The Return of Splicing
Splicing is one of those things that was discussed a long time ago, but was
never really fully implemented and rolled out. A few attendees have started
to take a closer look at the problem, building off of the interactive-tx
scheme that the dual-funding protocol extension uses. The main intricacy
discussed was if concurrent splices should be allowed or not, and if so, how
we would handle the various edge cases. As an example, if I propose a splice
to add more funds via my input, but that turns out to already be spent, then
the splicing transaction we created is invalid and can never be confirmed.
However if we allow _another_ splice to take place, and another one, and
another one, then ideally _one_ of them will confirm and serve as the new
anchor for the channel.
In a world of concurrent splices, the question of "what is my Lightning
balance" becomes even more murky. Wallet and implementations will likely
want to show the most pessimistic value, while also ensuring that the user
is able to effectively account for where all their funds and what they can
spend on/off chain.
# LN-URL + BOLT 12
LN-URL and BOLT 12 are both standardized ways that answer the question of:
how can I fetch an invoice from Bob? LN-URL differs from BOLT 12 in that it
uses the existing BOLT 11 invoice format, and uses an HTTP based protocol
for the negotiation process. BOLT 12 on the other hand is a suite of
protocol additions that includes (amongst other things) a new invoice format
(yay TLV!) and also a way to use onion messages to fetch an invoice _via_
the network.
Assuming blinded paths is widely rolled out, then the question of how
invoices are obtained becomes more important as blinded paths means that you
can't fit much in the traditional QR encoding. As a result, fetching
invoices on demand may become a more common place flow, with all its
trade-offs. There was a group discussion on how we could sort of unifying
everything either by allowing BOLT 12 to be used over LN-URL or the other
way around.
One proposal was to add a new query parameter to the normal LN-URL QR code
contents. This would mean that when a wallet goes to scan an LN-URL QR code,
if they know of the extra param, and what BOLT 12, they can just use the
enclosed offer to fetch the invoice.
An alternative proposal was to instead extract the BOLT 12 _invoice_ format
from the greater BOLT 12 "Offers" proposal. Assuming blinded paths is only
specified w.r.t BOLT 12 _invoices_, then this would mean an LN-URL extension
could be rolled out that allowed returning BOLT 12 invoice rather than BOLT
11 invoices. This would allow the ecosystem to slowly transition to a shared
invoice format, even if there may be fundamental disagreements w.r.t _how_
the invoices should be fetched in the first place.
It's worth noting that both of these proposals can be combined:
* If a wallet knows how to BOLT 12 Offers, they can take the enclosed
offer and run w/ it.
* If they don't know about Offers, but can send w/ the BOLT _invoice_
format, then they can fetch that and complete the payment.
This might be a nice middle ground as it would tend all
wallets/implementations to being able to decode and send w/ a BOLT 12
_invoice_, and leave the question of _how_ it should be fetched up to the
application/wallet/service. In the end, if paths never quite intersect, then
it's still possible to add route blinding to BOLT 11, with LN-URL sticking
with that invoice format to take advantage of the new privacy enhancements
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-November/003336.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
[3]: https://github.com/lightning/bolts/pull/995
[4]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
[5]: https://datatracker.ietf.org/doc/html/rfc6979
[6]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
[7]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html
[8]: https://arxiv.org/abs/2205.12737
[9]: https://bitcoinops.org/en/topics/minisketch/
[10]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html
[11]: https://blog.bitmex.com/preventing-channel-jamming/
[12]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html
[13]: https://github.com/lightning/bolts/pull/765
[14]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
[15]: https://github.com/lightning/bolts/pull/910
[16]: https://github.com/lightning/bolts/pull/780
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220607/eb9e8d17/attachment-0001.html>

2023-06-09 13:05:58

- reply

📅 Original date posted:2022-05-02
📝 Original message:
Hi John,
> That said, I believe that the correct approach to supporting "tokens on
> Lightning" is to make it a separate concern from Taro, and that LL should
> create a separate BOLT proposal from the current Taro BIPs to ensure it LN
> standards have a genericized protocol that all LN implementations would be
> interested in supporting.
The current Taro BIPs describe just about everything needed in order to
create, validate, and interact with assets on chain. Naturally, the system
needs to exist on-chain before any off-chain constructs can be built on top
of it.
On the topic of a BOLT, I don't think something like Taro (particularly our
vision for the deployment path) should exist at the _BOLT level_. Instead,
we aim to create a bLIP that fully specifies the _optional_ series of TLV
extensions needed to open channels using Taro assets, and send them
off-chain. IMO this isn't something that needs to be a BOLT as: it isn't
intended to be 100% universal (most LN routing nodes and users will only
know of the core bitcoin backbone), isn't critical to the operation of the
core LN network, and it's something that will only initial be deployed at
the edges (sender+receiver).
On the BOLT side, there're a number of important upgrades/extensions being
proposed, and imo it doesn't make sense to attempt to soak up the already
scarce review bandwidth into something like Taro that will live purely at
the edges of the network. I also don't want to speak for the other LN devs,
but I think most would prefer to just focus on the core LN protocol and
ignore anything non-bitcoin on the sides. The implementations/developers
that think this is something worth implementing will be able to contribute
to and review the bLIPs as they wish.
A few implementations support LTC today, but that was mainly an exercise in
helping to build consensus for segwit so we could ultimately deploy LN on
Bitcoin's mainnet (iirc some implementations are in the process of even
removing support). A prior version of the onion payload (now called the
legacy payload) had a "realm" field that was intended to be used for
multi-chain stuff. The newer modern TLV payload dropped that field as it
wasn't being used anywhere. IMO that was the right move as it allows us to
keep the core protocol simple and let other ppl be concerned w/ building
multi-asset stuff on top of the base protocol.
> but instead the requirement to add several feature concepts to LN that
> would allow tokens to interact with LN nodes and LN routing:
>From this list of items, I gather that your vision is actually pretty
different from ours. Rather than update the core network to understand the
existence of the various Taro assets, instead we plan on leaving the core
protocol essentially unchanged, with the addition of new TLV extensions to
allow the edges to be aware of and interact w/ the Taro assets. As an
example, we wouldn't need to do anything like advertise exchange rates in
the core network over the existing gossip protocol (which doesn't seem like
the best idea in any case given how quickly they can change and the existing
challenges we have today in ensuring speedy update propagation).
> So, I ask that Lightning Labs coordinate with the LN community to ensure
> such support for other networks and other assets not be dedicated only to
> Taro, and instead genericized enough so that other networks may compete
> fairly in the market,
If you're eager to create a generalized series of extensions to enable your
vision, then of course you're welcome to pursue that. However, I don't think
the other LN developers will really care much about building some
generalized multi-chain/multi-asset system given all the existing work we
still need to do to make sure the bitcoin backbone works properly and can
scale up sufficiently. I'd also caution you against making the same mistakes
that Interledger did: they set out to build a generalized off-chain system
which abstracts over the assets/chains entirely, but years later, and
several hundred wc3 mailing list posts later, virtually nothing uses it.
Why? IMO, because it was overly generalized and they assumed that if they
built it, the entities that actually needed it would magically pop up
(spoiler alert -- *SpongeBob narrator voice*: several years later, they
didn't).
> Otherwise, we will be left with LL's advantage being that LND supports
> Taro, and weird narratives that Taro is somehow superior because LND
> specifically added support for it, without creating a generic spec or BOLT
> that all nodes could adopt for multi-network, multi-asset LN-as-rails use
> cases.
Given that all the specs so far are in the open, and we opted to first build
out the specifications before releasing our own implementation, I don't
foresee Taro being something that only LL or lnd implements. All the BIPs
are public, and the bLIP will be soon as well, so any motivated individual
or set of individuals will also be able to implement and adopt the protocol.
If you or anyone else reading this is interested in contributing: I'm
accepting PRs to my fork of the BIP repo [1] (where I've already made
several modifications based on feedback from the wider community, and merged
a few PRs as well), and I'm also hanging out on IRC at ##taro on Libera.
[1]: https://github.com/Roasbeef/bips/tree/bip-taro
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220502/d9b6768e/attachment.html>

2023-06-09 13:05:47

- reply

📅 Original date posted:2022-04-11
📝 Original message:
Hi Ruben,
> Also, the people that are responsible for the current shape of RGB aren't
> the people who originated the idea, so it would not be fair to the
> originators either (Peter Todd, Alekos Filini, Giacomo Zucco).
Sure I have no problems acknowledging them in the current BIP draft. Both
the protocols build off of ideas re client-side-validation, but then end up
exploring different parts of the large design space. Peter Todd is already
there, but I can add the others you've listed. I might even just expand that
section into a longer "Related Work" section along the way.
> What I tried to say was that it does not make sense to build scripting
> support into Taro, because you can't actually do anything interesting with
> it due to this limitation. can do with their own Taro tokens, or else he
> will burn them – not very useful
I agree that the usage will be somewhat context specific, and dependent on
the security properties one is after. In the current purposefully simplified
version, it's correct that ignoring the rules leads to assets being burnt,
but in most cases imo that's a sufficient enough incentive to maintain and
validate the relevant set of witnesses.
I was thinking about the scripting layer a bit over the weekend, and came up
with a "issuance covenant" design sketch that may or may not be useful. At a
high level, lets say we extend the system to allow a specified (so a new
asset type) or generalized script to be validated when an asset issuance
transaction is being validated. If we add some new domain specific covenant
op codes at the Taro level, then we'd be able to validate issuance events
like:
* "Issuing N units of this assets can only be done if 1.5*N units of BTC
are present in the nth output of the minting transaction. In addition,
the output created must commit to a NUMs point for the internal key,
meaning that only a script path is possible. The script paths must be
revealed, with the only acceptable unlocking leaf being a time lock of 9
months".
I don't fully have a concrete protocol that would use something like that,
but that was an attempt to express certain collateralization requirements
for issuing certain assets. Verifiers would only recognize that asset if the
issuance covenant script passes, and (perhaps) the absolute timelock on
those coins hasn't expired yet. This seems like a useful primitive for
creating assets that are somehow backed by on-chain BTC collateralization.
However this is just a design sketch that needs to answer questions like:
* are the assets still valid after that timeout period, or are they
considered to be burnt?
* assuming that the "asset key family" (used to authorize issuance of
related assets) are jointly owned, and maintained in a canonical
Universe, then would it be possible for 3rd parties to verify the level
of collateralization on-chain, with the join parties maintaining the
pool of collateralized assets accordingly?
* continuing with the above, is it feasible to use a DLC script within one
of these fixed tapscript leaves to allow more collateral to be
added/removed from the pool backing those assets?
I think it's too early to conclude that the scripting layer isn't useful.
Over time I plan to add more concrete ideas like the above to the section
tracking the types of applications that can be built on Taro.
> So theoretically you could get Bitcoin covenants to enforce certain
> spending conditions on Taro assets. Not sure how practical that ends up
> being, but intriguing to consider.
Exactly! Exactly how practical it ends up being would depend on the types of
covenants deployed in the future. With something like a TLUV and OP_CAT (as
they're sufficiently generalized vs adding op codes to very the proofs) a
Script would be able to re-create the set of commitments to restrict the set
of outputs that can be created after spending. One would use OP_CAT to
handle re-creating the taro asset root, and TLUV (or something similar) to
handle the Bitcoin tapscript part (swap out leaf index 0 where the taro
commitment is, etc).
> The above also reminds me of another potential issue which you need to be
> aware of, if you're not already. Similar to my comment about how the
> location of the Taro tree inside the taproot tree needs to be
> deterministic for the verifier, the output in which you place the Taro
> tree also needs to be
Yep, the location needs to be fully specified which includes factoring the
output index as well. A simple way to restrict this would just to say it's
always the first output. Otherwise, you could lift the output index into the
asset ID calculation.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220411/b1c5440a/attachment-0001.html>

2023-06-09 13:05:45

- reply

📅 Original date posted:2022-04-08
📝 Original message:
Hi Ruben,
Thanks! I don't really consider things final until we have a good set of
test
vectors in the final set, after which we'd start to transition the set of
documents beyond the draft state.
> Seeing as there's a large amount of overlap with RGB, a protocol which I
have
> examined quite extensively, I believe some of the issues I uncovered in
that
> project also apply here.
I'm happy to hear that someone was actually able to extract enough details
from
the RGB devs/docs to be able to analyze it properly! In the past I tried to
ask
their developers questions about how things like transfers worked[1][2],
but it
seemed either people didn't know, or they hadn't finished the core design
(large TBD sections) as they were working on adding other components to
create
a "new new Internet".
> Furthermore, the Taro script is not enforced by Bitcoin, meaning those who
> control the Bitcoin script can always choose to ignore the Taro script and
> destroy the Taro assets as a result.
This is correct, as a result in most contexts, an incentive exists for the
holder of an asset to observe the Taro validation rules as otherwise, their
assets are burnt in the process from the PoV of asset verifiers. In the
single
party case things are pretty straight forward, but more care needs to be
taken
in cases where one attempts to express partial application and permits
anyone
to spend a UTXO in question.
By strongly binding all assets to Bitcoin UTXOs, we resolve issues related
to
double spending or duplicate assets, but needs to mind the fact that assets
can
be burnt if a user doesn't supply a valid witness. There're likely ways to
get
around this by lessening the binding to Bitcoin UTXO's, but then the system
would need to be able to collect, retain and order all the set of possible
spends, essentially requiring a parallel network. The core of the system as
it
stands today is pretty simple (which was an explicit design goal to avoid
getting forever distracted by the large design space), with a minimal
implementation being relatively compact given all the Bitcoin context/design
re-use.
Also one cool trait of the way commitments are designed is that the Taro
commitment impact the final derived taproot output key. As a result,
potential
Script extensions like TAPLEAF_UPDATE_VERIFY can actually be used to further
_bind_ Taro transitions at the Bitcoin level, without Bitcoin explicitly
needing to be aware of the Taro rules. In short, covenants can allow Bitcoin
Script to bind Taro state transitions, without any of the logic bleeding
over,
as the covenant just checks for a certain output key, which is a function of
the Taro commitment being present.
> There are two possible designs here: a.) The token history remains
separate –
> Dave receives Alice's 2 tokens, Bob's tokens are split and he receives 2
(or
> 3 from Bob 1 from Alice). b.) The token history gets merged – Dave
receives
> 4 tokens (linking the new output with both Alice and Bob's history).
Mechanically, with respect to the way the change/UTXOs work in the system,
both
are expressible: Dave can chose to merge them into a single UTXO (with the
appropriate witnesses included for each of them), or Dave can keep them
distinct in the asset tree. You're correct in that asset issuers may opt to
issue assets in denominations vs allowing them to be fully divisible.
Ultimately, the compatibility with the LN layer will be the primary way to
keep
asset histories compressed, without relying on another trust model, or
relying
on the incentive of an asset issuer to do a "re-genesis" which would
effectively re-create assets in a supply-preserving manner (burn N units,
then
produce a new genesis outpoint for N units). Alternatively, implementations
can
also chose to utilize a checkpointing system similar to what some Bitcoin
full
node clients do today.
> is that you end up with a linked transaction graph, just like in Bitcoin
This is correct, the protocol doesn't claim to achieve better privacy
guarantees than the base chain. However inheriting this transaction graph
model
imo makes it easier for existing Bitcoin developers to interact with the
system, and all the data structures are very familiar tooling wise. However
any
privacy enhancing protocol used for on-chain top-level Bitcoin UTXOs can
also
be applied to Taro, so people can use things like coinswap and coinjoin,
along
with LN to shed prior coin lineages.
> This implies the location of the Taro tree inside the taproot tree is not
> fixed. What needs to be prevented here is that a taproot tree contains
more
> than one Taro tree, as that would enable the owner of the commitment to
show
> different histories to different people.
Great observation, I patched a similar issue much earlier in the design
process
by strongly binding all signatures to a prevOut super-set (so the outpoint
along with the unique key apth down into the tree), which prevents
duplicating
the asset across outputs, as signature verification would fail.
In terms of achieving this level of binding within the Taro tree itself, I
can
think of three options:
1. Require the Taro commitment to be in the first/last position within the
(fully sorted?) Tapscript tree, and also require its sibling to be the
hash
of some set string (all zeroes or w/e). We'd require the sibling to the
empty
as the tapscript hashes are sorted before hashing so you sort of lose that
final ordering information.
2. Include the position of the Taro commitment within the tapscript tree
within the sighash digest (basically the way the single input in the
virtual
transaction is created from the TLV structure).
3. Include the position of the Taro commitment within the tapscript tree
as
part of the message that's hashed to derive asset IDs.
AFAICT, #1 resolves the issue entirely, #2 renders transfers outside of the
canonical history invalid, and #2 minds hte asset ID to the initial position
meaning you can track a canonical lineage from the very start.
> Finally, let me conclude with two questions. Could you clarify the
purpose of
> the sparse merkle tree in your design?
Sure, it does a few things:
* Non-inclusion proofs so I can do things like prove to your I'm no longer
committing to my 1-of-1 holographic beefzard card when we swap.
* The key/tree structure means that the tree is history independent,
meaning
that if you and I insert the same things into the tree in a different
order, we'll get the same root hash. This is useful for things like
tracking all the issuance events for a given asset, or allowing two
entities to sync their knowledge/history of a single asset, or a set of
assets.
* Each asset/script mapping to a unique location within the tree means
it's
easy to ensure uniqueness of certain items/commitments (not possible to
commit to the same asset ID twice in the tree as an example).
* The merkle-sum trait means I that validation is made simpler, as you
just
check that the input+output commitment sum to the same value, and I can
also verify that if we're swapping, then you aren't committing to more
units that exist (so I make sure I don't get an invalid split).
> And the second question – when transferring Taro token ownership from one
> Bitcoin UTXO to another, do you generate a new UTXO for the recipient or
do
> you support the ability to "teleport" the tokens to an existing UTXO like
how
> RGB does it? If the latter, have you given consideration to timing issues
> that might occur when someone sends tokens to an existing UTXO that
> simultaneously happens to get spent by the owner?
So for interactive transfers, the UTXOs generated as just the ones part of
the
MIMO transaction. When sending via the address format, a new non-dust
output is
created which holds the new commitment, and uses an internal key provided by
the receiver, so only they can move the UTXO. Admittedly, I'm not familiar
with
how the RGB "teleport" technique works, I checked out some slide decks a
while
back, but they were mostly about all the new components they were creating
and
their milestone of 1 million lines of code. Can you point me to a coherent
explanation of the technique? I'd love to compare/contrast so we can analyze
the diff tradeoffs being made here.
Thanks for an initial round of feedback/analysis, I'll be updating the draft
over the next few days to better spell things out and particularly that
commitment/sighash uniqueness trait.
-- Laolu
[1]:
https://twitter.com/roasbeef/status/1330654936074371073?s=20&t=feV0kWAjJ6MTQlFm06tSxA
[2]:
https://twitter.com/roasbeef/status/1330692571736117249?s=20&t=feV0kWAjJ6MTQlFm06tSxA
On Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen <rsomsen at gmail.com> wrote:
> Hi Laolu,
>
> Nice work. This is an interesting protocol, in my opinion.
>
> Seeing as there's a large amount of overlap with RGB, a protocol which I
> have examined quite extensively, I believe some of the issues I uncovered
> in that project also apply here.
>
> The biggest issue revolves around the scripting expectations for this
> protocol. Taro is described as being able to have its own scripting
> capabilities that will initially be similar to Bitcoin and eventually be
> made to do more. I'm afraid this is fundamentally impossible. Conditional
> scripts (and thus most scripts that could potentially be of interest) won't
> be possible if the satisfaction of the condition is not recorded publicly
> on-chain.
>
> The core problem here is that you have two levels of scripting. At the
> Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the
> Taro level you have yet another script. This may seem similar at first
> glance to how taproot has a key path and a script path, but there are a few
> key differences. In taproot only one of the two needs to be satisfied,
> while here you need to satisfy both. Furthermore, the Taro script is not
> enforced by Bitcoin, meaning those who control the Bitcoin script can
> always choose to ignore the Taro script and destroy the Taro assets as a
> result.
>
> I'll describe an example. Imagine Alice wants to send Bob a payment inside
> Taro, but she wants to make it conditional. Bob gets the Taro tokens if he
> reveals a pre-image, while Alice can claim the tokens back after the
> timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice
> starts by locking up coins in a 2-of-2 multisig on the mainchain with some
> Taro tokens inside. She then gives Bob a pre-signed transaction that only
> requires him to reveal the pre-image in order to claim the tokens. The
> issue here is that from Bitcoin's perspective, you're giving Bob a valid
> transaction, regardless of whether he reveals the pre-image. If Bob
> maliciously broadcasts it without the pre-image, he will have destroyed
> your tokens.
>
> Of course this was a contrived example, as these conditions could simply
> take place entirely in Bitcoin script, but it demonstrates that Taro script
> fundamentally cannot handle conditional payments, which is the basis for
> any meaningful script other than self-encumbering covenants (i.e. if you
> send your Taro tokens in any way other than specified, the tokens will be
> destroyed). Luckily this has no effect on whether Taro can function over
> Lightning, because solely relying on Bitcoin's scripting capabilities
> should be sufficient for that use case.
>
> As a side note, it may be worth pointing out that it *is* possible to
> create conditional payments if the satisfaction of the condition is
> recorded publicly on the mainchain (e.g. in an op_return), making it sort
> of a hybrid on-chain/off-chain model, but it would increase complexity
> considerably. I can explain this model in more detail, if it happens to
> interest you.
>
> Now there's a second issue I want to bring up, but unfortunately my
> understanding of how exactly you made assets divisible is not complete
> enough to know how this problem might have manifested in Taro. Nonetheless,
> I'll try to describe it.
>
> One of the core concepts of Taro/RGB is that the sender of the token has
> to reveal the history to the recipient. In case of an NFT the history is
> simply every prior owner and grows linearly, but in the case of fungible
> tokens things are more complicated. Let's say Carol receives 2 fungible
> Taro tokens from Alice and 3 fungible Taro tokens from Bob. Now Carol wants
> to send 4 of them to Dave and keep 1. There are two possible designs here:
>
> a.) The token history remains separate – Dave receives Alice's 2 tokens,
> Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice).
>
> b.) The token history gets merged – Dave receives 4 tokens (linking the
> new output with both Alice and Bob's history).
>
> The issue with a.) is that you're only ever fragmenting tokens, so
> eventually you end up with lots of tiny but separate amounts. This will
> cause making large payments to involve sending lots of tokens, each with
> their own history. Under this model, I suspect the fixed value token model
> (e.g. 1, 2, 4, 8) might be preferable, as this prevents the entire supply
> from getting split into tiny fragments.
>
> The issue with b.) is that you end up with a linked transaction graph,
> just like in Bitcoin. If you pick a random Bitcoin UTXO and try to trace it
> back to a coinbase, you'll quickly find that it could have come from many
> of them. The graph that you'd traverse to get to all of these coinbases is
> equivalent to the amount of history that a recipient of a Taro token has to
> validate in order to accept it, which I suspect quickly becomes a
> bottleneck that is not unlike that of a regular blockchain.
>
> It'd probably be wise to make a model of the potential transaction flow,
> and simulate how it affects the size of the history in order to determine
> what's the best approach and to generally get a better idea of how it
> affects scaling. Also, the repeated sharing of history makes me skeptical
> about the privacy this protocol may provide. If large amounts of history
> moved through the hands of a large number of people, it wouldn't be very
> private.
>
> There's a third third smaller issue I want to point out, which is easily
> fixable and perhaps was just a typo. In your slides, you showed a
> screenshot of a taproot tree containing the Taro tree as the third element
> of four. This implies the location of the Taro tree inside the taproot tree
> is not fixed. What needs to be prevented here is that a taproot tree
> contains more than one Taro tree, as that would enable the owner of the
> commitment to show different histories to different people.
>
> Finally, let me conclude with two questions. Could you clarify the purpose
> of the sparse merkle tree in your design? I suppose you want to be able to
> open a commitment and show it contains a certain asset without having to
> reveal any of the other assets and simultaneously guarantee that you
> haven't committed to the same asset twice (i.e. the SMT guarantees each
> asset gets a specific location in the tree)? Or is there another reason?
>
> And the second question – when transferring Taro token ownership from one
> Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do
> you support the ability to "teleport" the tokens to an existing UTXO like
> how RGB does it? If the latter, have you given consideration to timing
> issues that might occur when someone sends tokens to an existing UTXO that
> simultaneously happens to get spent by the owner?
>
> In any case, I hope this email was useful. Feel free to reach out if I can
> clarify anything.
>
> Good luck with the protocol.
>
> Best regards,
> Ruben
>
> On Tue, Apr 5, 2022 at 5:06 PM Olaoluwa Osuntokun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi y'all,
>>
>> I'm excited to publicly publish a new protocol I've been working on over
>> the
>> past few months: Taro. Taro is a Taproot Asset Representation Overlay
>> which
>> allows the issuance of normal and also collectible assets on the main
>> Bitcoin
>> chain. Taro uses the Taproot script tree to commit extra asset structured
>> meta
>> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree
>> or
>> MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
>> sparse
>> merkle tree, enabling things like easily verifiable asset supply proofs
>> and
>> also efficient proofs of non existence (eg: you prove to me you're no
>> longer
>> committing to the 1-of-1 holographic beefzard card during our swap). Taro
>> asset
>> transfers are then embedded in a virtual/overlay transaction graph which
>> uses a
>> chain of asset witnesses to provably track the transfer of assets across
>> taproot outputs. Taro also has a scripting system, which allows for
>> programmatic unlocking/transfer of assets. In the first version, the
>> scripting
>> system is actually a recursive instance of the Bitcoin Script Taproot VM,
>> meaning anything that can be expressed in the latest version of Script
>> can be
>> expressed in the Taro scripting system. Future versions of the scripting
>> system
>> can introduce new functionality on the Taro layer, like covenants or other
>> updates.
>>
>> The Taro design also supports integration with the Lightning Network
>> (BOLTs) as
>> the scripting system can be used to emulate the existing HTLC structure,
>> which
>> allows for multi-hop transfers of Taro assets. Rather than modify the
>> internal
>> network, the protocol proposes to instead only recognize "assets at the
>> edges",
>> which means that only the sender+receiver actually need to know about and
>> validate the assets. This deployment route means that we don't need to
>> build up
>> an entirely new network and liquidity for each asset. Instead, all asset
>> transfers will utilize the Bitcoin backbone of the Lightning Network,
>> which
>> means that the internal routers just see Bitcoin transfers as normal, and
>> don't
>> even know about assets at the edges. As a result, increased demand for
>> transfers of these assets as the edges (say like a USD stablecoin), which
>> in
>> will turn generate increased demand of LN capacity, result in more
>> transfers, and
>> also more routing revenue for the Bitcoin backbone nodes.
>>
>> The set of BIPs are a multi-part suite, with the following breakdown:
>> * The main Taro protocol:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
>> * The MS-SMT structure:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
>> * The Taro VM:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
>> * The Taro address format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
>> * The Taro Universe concept:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
>> * The Taro flat file proof format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
>>
>> Rather than post them all in line (as the text wouldn't fit in the
>> allowed size
>> limit), all the BIPs can be found above.
>>
>> -- Laolu
>> _______________________________________________
>> 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/lightning-dev/attachments/20220408/7193e07c/attachment-0001.html>

2023-06-09 13:05:43

- reply

📅 Original date posted:2022-04-05
📝 Original message:
Hi y'all,
I'm excited to publicly publish a new protocol I've been working on over the
past few months: Taro. Taro is a Taproot Asset Representation Overlay which
allows the issuance of normal and also collectible assets on the main
Bitcoin
chain. Taro uses the Taproot script tree to commit extra asset structured
meta
data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or
MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
sparse
merkle tree, enabling things like easily verifiable asset supply proofs and
also efficient proofs of non existence (eg: you prove to me you're no longer
committing to the 1-of-1 holographic beefzard card during our swap). Taro
asset
transfers are then embedded in a virtual/overlay transaction graph which
uses a
chain of asset witnesses to provably track the transfer of assets across
taproot outputs. Taro also has a scripting system, which allows for
programmatic unlocking/transfer of assets. In the first version, the
scripting
system is actually a recursive instance of the Bitcoin Script Taproot VM,
meaning anything that can be expressed in the latest version of Script can
be
expressed in the Taro scripting system. Future versions of the scripting
system
can introduce new functionality on the Taro layer, like covenants or other
updates.
The Taro design also supports integration with the Lightning Network
(BOLTs) as
the scripting system can be used to emulate the existing HTLC structure,
which
allows for multi-hop transfers of Taro assets. Rather than modify the
internal
network, the protocol proposes to instead only recognize "assets at the
edges",
which means that only the sender+receiver actually need to know about and
validate the assets. This deployment route means that we don't need to
build up
an entirely new network and liquidity for each asset. Instead, all asset
transfers will utilize the Bitcoin backbone of the Lightning Network, which
means that the internal routers just see Bitcoin transfers as normal, and
don't
even know about assets at the edges. As a result, increased demand for
transfers of these assets as the edges (say like a USD stablecoin), which in
will turn generate increased demand of LN capacity, result in more
transfers, and
also more routing revenue for the Bitcoin backbone nodes.
The set of BIPs are a multi-part suite, with the following breakdown:
* The main Taro protocol:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
* The MS-SMT structure:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
* The Taro VM:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
* The Taro address format:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
* The Taro Universe concept:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
* The Taro flat file proof format:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
Rather than post them all in line (as the text wouldn't fit in the allowed
size
limit), all the BIPs can be found above.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220405/930b239c/attachment.html>

2023-06-09 13:05:39

- reply

📅 Original date posted:2022-03-24
📝 Original message:
Hi y'all,
## Dynamic Commitments Retrospective
Two years-ish ago I made a mailing list post on some ideas re dynamic
commitments [1], and how the concept can be used to allow us to upgrade
channel types on the fly, and also remove pesky hard coded limits like the
483 HTLC in-flight limit that's present today. Back then my main target was
upgrading all the existing channels over to the anchor output commitment
variant, so the core internal routing network would be more resilient in a
persistent high fee environment (which hasn't really happened over the past
2 years for various reasons tbh). Fast forward to today, and with taproot
now active on mainnet, and some initial design work/sketches for
taproot-native channels underway, I figure it would be good to bump this
concept as it gives us a way to upgrade all 80k+ public channels to taproot
without any on chain transactions.
## Updating Across Witness Versions w/ Adapter Commitments
In my original mail, I incorrectly concluded that the dynamic commitments
concept would only really work within the confines of a "static" multi-sig
output, meaning that it couldn't be used to help channels upgrade to future
segwit witness versions. Thankfully this reply [2] by ZmnSCPxj, outlined a
way to achieve this in practice. At a high level he proposes an "adaptor
commitment" (similar to the kickoff transaction in eltoo/duplex), which is
basically an upgrade transaction that spends one witness version type, and
produces an output with the next (upgraded) type. In the context of
converting from segwit v0 to v1 (taproot), two peers would collaboratively
create a new adapter commitment that spends the old v0 multi-sig output, and
produces a _new_ v1 multi-sig output. The new commitment transaction would
then be anchored using this new output.
Here's a rough sequence diagram of the before and after state to better
convey the concept:
* Before: fundingOutputV0 -> commitmentTransaction
* After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
commitmentTransaction
It *is* still the case that _ultimately_ the two transactions to close the
old segwit v0 funding output, and re-open the channel with a new segwit v1
funding output are unavoidable. However this adapter commitment lets peers
_defer_ these two transactions until closing time. When force closing two
transactions need to be confirmed before the commitment outputs can be
resolved. However, for co-op close, you can just spend the v0 output, and
deliver to the relevant P2TR outputs. The adapter commitment can leverage
sighash anyonecanpay to let both parties (assuming it's symmetric) attach
additional inputs for fees (to avoid introducing the old update_fee related
static fee issues), or alternatively inherit the anchor output pattern at
this level.
## Existing Dynamic Commitments Proposals
Assuming this concept holds up, then we need an actual concrete protocol to
allow for dynamic commitment updates. Last year, Rusty made a spec PR
outlining a way to upgrade the commitment type (leveraging the new
commitment type feature bits) upon channel re-establish [3]. The proposal
relies on another message that both sides send (`stfu`) to clear the
commitment (similar to the shutdown semantics) before the switch over
happens. However as this is tied to the channel re-establish flow, it
doesn't allow both sides to do things like only allow your peer to attach N
HTLCs to start with, slowing increasing their allotted slots and possibly
reducing them (TCP AIMD style).
## A Two-Phase Dynamic Commitment Update Protocol
IMO if we're adding in a way to do commitment/channel upgrades, then it may
be worthwhile to go with a more generalized, but slightly more involved
route instead. In the remainder of this mail, I'll describe an alternative
approach that would allow upgrading nearly all channel/commitment related
values (dust limit, max in flight, etc), which is inspired by the way the
Raft consensus protocol handles configuration/member changes.
For those that aren't aware, Raft is a consensus protocol analogous to Paxos
(but isn't byzantine fault tolerant out of the box) that was designed as a
more understandable alternative to Paxos for a pedagogical environment.
Typically the algorithm is run in the context of a fixed cluster with N
machines, but supports adding/removing machines from the cluster with a
configuration update protocol. At a high level the way this works is that a
new config is sent to the leader, with the leader synchronizing the config
change with the other members of the cluster. Once a majority threshold is
reached, the leader then commits the config change with the acknowledged
parties using the new config (basically a two phase commit). I'm skipping
over some edge cases here that can arise if the new nodes participate
consensus too early, which can cause a split majority leading to two leaders
being elected.
Applying this to the LN context is a bit simpler than a generalized
protocol, as we typically just have two parties involved. The initiator is
already naturally a "leader" in our context, as they're the only ones that
can do things like trigger fee updates.
### Message Structure
At a high level I propose we introduce two new messages, with the fields
looking something like this for `commitment_update_propose`:
* type: 0 (`channel_id`)
* value: [`32*byte`:`chan_id`]
* type: 1 (`propose_sig`)
* value: [`64*byte`:`sig`]
* type: 2 (`update_payload`)
* value: [`*byte`:`tlv_payload`]
and this `commitment_update_apply`:
* type: 0 (`channel_id`)
* value: [`32*byte`:`chan_id`]
* type: 1 (`local_propose`)
* value: [`*byte`:`commitment_update_propose`]
* type: 2 (`remote_propose`)
* value: [`*byte`:`commitment_update_propose`]
### Protocol Flow
The core idea here is that either party can propose a commitment/channel
param update, but only the initiator can actually apply it. The
`commitment_update_propose` encodes the new set of updates, with a signature
covering the TLV blob for the new params (more on why that's needed later).
The `commitment_update_apply` includes up to _two_
`commitment_update_propose` messages (one for the initiator and one for the
responder, as nested TLV messages). The `commitment_update_propose` message
would be treated like any other `update_*` message, in that it takes a new
commitment signature to properly commit/apply it.
The normal flow takes the form of both sides sending a
`commitment_update_propose` message, with the initiator finally committing
both by sending a `commitment_update_apply` message. In the event that only
the responder wants to apply a param change/update, then the initiator can
reply immediately with a `commitment_update_apply` message that doesn't
include a param change for their commitment (or they just echo the
parameters if they're acceptable).
### Handling Retransmissions
The role of the signature it to prevent "spoofing" by one of the parties
(authenticate the param change), and also it serves to convince a party that
they actually sent a prior commitment propose update during the
retransmission phase. As the `commitment_update_propose` message would be
retransmitted like any other message, if the initiator attempts to commit
the update but the connection dies, they'll retransmit it as normal along
with their latest signature.
### Nested TLV Param Generality
The messages as sketched out here just have an opaque nested TLV field which
makes it extensible to add in other things like tweaking the total number of
max HTLCs, the current dust values, min/max HTLCs, etc (all things that are
currently hard coded for the lifetime of the channel). An initial target
would likely just be a `chan_type` field, with future feature bits governing
_what_ type of commitment updates both parties understand in the future.
In the past, when ideas like this were brought up, some were concerned that
it wouldn't really be possible to do this type of updates while existing
HTLCs were in flight (hence some of the ideas to clear out the commitment
beforehand). I don't see a reason why this fundamentally _shouldn't_ be
allowed, as from the point of view of the channel update state machine, all
updates (adds/removes) get applied as normal, but with this _new_ commitment
type/params. The main edge case we'll need to consider is cases where the
new params make older HTLCs invalid for some reason.
## Conclusion
Using the adapter commitment idea combined with a protocol for updating
commitments on the fly, would potentially allow us to update all 80k+ segwit
v0 channels to the base level of taprooty channels without any on chain
transactions. The two transactions (open+close) must happen eventually, but
by holding another layer of spends off-chain we can defer them (potentially
indefinitely, as we have channels today that have been opened for over a
year).
Deploying a generalised on-the-fly dynamic commitment update protocol gives
us a tool to future proof the _existing_ anchored multi-sig outputs in the
chain, and also a way to remove many of the hard coded parameters we have
today in the protocol. One overly inflexible parameter we have today in the
network is the 483 HTLC limit. Allowing this value to float would allow
peers to apply similar congestion avoidance algorithm that are used in TCP
today, and also give us a way to protect the network against future
unforeseen widespread policy changes (like a raising of the dust limit).
-- Laolu
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
[3]: https://github.com/lightning/bolts/pull/868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220324/bbeddde8/attachment.html>

2023-06-09 13:05:39

- reply

📅 Original date posted:2022-03-24
📝 Original message:
Oh one other thing I forgot to mention is that switching over the _existing_
channels using w/e update protocol presents an accelerated path to
taproot/PTLC for the existing channels, as they don't necessarily need any
new gossip announcement messages. Instead, after making the switch over,
they can start to advertise the new relevant set of feature bits for
PTLC-like stuff.
This gives us a bit more freedom as moving the existing channels over to
taproot isn't necessarily blocked on deciding which path we want to go re
channel announcement evolution.
-- Laolu
On Thu, Mar 24, 2022 at 3:52 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi y'all,
>
> ## Dynamic Commitments Retrospective
>
> Two years-ish ago I made a mailing list post on some ideas re dynamic
> commitments [1], and how the concept can be used to allow us to upgrade
> channel types on the fly, and also remove pesky hard coded limits like the
> 483 HTLC in-flight limit that's present today. Back then my main target was
> upgrading all the existing channels over to the anchor output commitment
> variant, so the core internal routing network would be more resilient in a
> persistent high fee environment (which hasn't really happened over the past
> 2 years for various reasons tbh). Fast forward to today, and with taproot
> now active on mainnet, and some initial design work/sketches for
> taproot-native channels underway, I figure it would be good to bump this
> concept as it gives us a way to upgrade all 80k+ public channels to taproot
> without any on chain transactions.
>
> ## Updating Across Witness Versions w/ Adapter Commitments
>
> In my original mail, I incorrectly concluded that the dynamic commitments
> concept would only really work within the confines of a "static" multi-sig
> output, meaning that it couldn't be used to help channels upgrade to future
> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj, outlined a
> way to achieve this in practice. At a high level he proposes an "adaptor
> commitment" (similar to the kickoff transaction in eltoo/duplex), which is
> basically an upgrade transaction that spends one witness version type, and
> produces an output with the next (upgraded) type. In the context of
> converting from segwit v0 to v1 (taproot), two peers would collaboratively
> create a new adapter commitment that spends the old v0 multi-sig output,
> and
> produces a _new_ v1 multi-sig output. The new commitment transaction would
> then be anchored using this new output.
>
> Here's a rough sequence diagram of the before and after state to better
> convey the concept:
>
> * Before: fundingOutputV0 -> commitmentTransaction
>
> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
> commitmentTransaction
>
> It *is* still the case that _ultimately_ the two transactions to close the
> old segwit v0 funding output, and re-open the channel with a new segwit v1
> funding output are unavoidable. However this adapter commitment lets peers
> _defer_ these two transactions until closing time. When force closing two
> transactions need to be confirmed before the commitment outputs can be
> resolved. However, for co-op close, you can just spend the v0 output, and
> deliver to the relevant P2TR outputs. The adapter commitment can leverage
> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
> additional inputs for fees (to avoid introducing the old update_fee related
> static fee issues), or alternatively inherit the anchor output pattern at
> this level.
>
> ## Existing Dynamic Commitments Proposals
>
> Assuming this concept holds up, then we need an actual concrete protocol to
> allow for dynamic commitment updates. Last year, Rusty made a spec PR
> outlining a way to upgrade the commitment type (leveraging the new
> commitment type feature bits) upon channel re-establish [3]. The proposal
> relies on another message that both sides send (`stfu`) to clear the
> commitment (similar to the shutdown semantics) before the switch over
> happens. However as this is tied to the channel re-establish flow, it
> doesn't allow both sides to do things like only allow your peer to attach N
> HTLCs to start with, slowing increasing their allotted slots and possibly
> reducing them (TCP AIMD style).
>
> ## A Two-Phase Dynamic Commitment Update Protocol
>
> IMO if we're adding in a way to do commitment/channel upgrades, then it may
> be worthwhile to go with a more generalized, but slightly more involved
> route instead. In the remainder of this mail, I'll describe an alternative
> approach that would allow upgrading nearly all channel/commitment related
> values (dust limit, max in flight, etc), which is inspired by the way the
> Raft consensus protocol handles configuration/member changes.
>
> For those that aren't aware, Raft is a consensus protocol analogous to
> Paxos
> (but isn't byzantine fault tolerant out of the box) that was designed as a
> more understandable alternative to Paxos for a pedagogical environment.
> Typically the algorithm is run in the context of a fixed cluster with N
> machines, but supports adding/removing machines from the cluster with a
> configuration update protocol. At a high level the way this works is that a
> new config is sent to the leader, with the leader synchronizing the config
> change with the other members of the cluster. Once a majority threshold is
> reached, the leader then commits the config change with the acknowledged
> parties using the new config (basically a two phase commit). I'm skipping
> over some edge cases here that can arise if the new nodes participate
> consensus too early, which can cause a split majority leading to two
> leaders
> being elected.
>
> Applying this to the LN context is a bit simpler than a generalized
> protocol, as we typically just have two parties involved. The initiator is
> already naturally a "leader" in our context, as they're the only ones that
> can do things like trigger fee updates.
>
> ### Message Structure
>
> At a high level I propose we introduce two new messages, with the fields
> looking something like this for `commitment_update_propose`:
> * type: 0 (`channel_id`)
> * value: [`32*byte`:`chan_id`]
> * type: 1 (`propose_sig`)
> * value: [`64*byte`:`sig`]
> * type: 2 (`update_payload`)
> * value: [`*byte`:`tlv_payload`]
>
> and this `commitment_update_apply`:
> * type: 0 (`channel_id`)
> * value: [`32*byte`:`chan_id`]
> * type: 1 (`local_propose`)
> * value: [`*byte`:`commitment_update_propose`]
> * type: 2 (`remote_propose`)
> * value: [`*byte`:`commitment_update_propose`]
>
> ### Protocol Flow
>
> The core idea here is that either party can propose a commitment/channel
> param update, but only the initiator can actually apply it. The
> `commitment_update_propose` encodes the new set of updates, with a
> signature
> covering the TLV blob for the new params (more on why that's needed later).
> The `commitment_update_apply` includes up to _two_
> `commitment_update_propose` messages (one for the initiator and one for the
> responder, as nested TLV messages). The `commitment_update_propose` message
> would be treated like any other `update_*` message, in that it takes a new
> commitment signature to properly commit/apply it.
>
> The normal flow takes the form of both sides sending a
> `commitment_update_propose` message, with the initiator finally committing
> both by sending a `commitment_update_apply` message. In the event that only
> the responder wants to apply a param change/update, then the initiator can
> reply immediately with a `commitment_update_apply` message that doesn't
> include a param change for their commitment (or they just echo the
> parameters if they're acceptable).
>
> ### Handling Retransmissions
>
> The role of the signature it to prevent "spoofing" by one of the parties
> (authenticate the param change), and also it serves to convince a party
> that
> they actually sent a prior commitment propose update during the
> retransmission phase. As the `commitment_update_propose` message would be
> retransmitted like any other message, if the initiator attempts to commit
> the update but the connection dies, they'll retransmit it as normal along
> with their latest signature.
>
> ### Nested TLV Param Generality
>
> The messages as sketched out here just have an opaque nested TLV field
> which
> makes it extensible to add in other things like tweaking the total number
> of
> max HTLCs, the current dust values, min/max HTLCs, etc (all things that are
> currently hard coded for the lifetime of the channel). An initial target
> would likely just be a `chan_type` field, with future feature bits
> governing
> _what_ type of commitment updates both parties understand in the future.
>
> In the past, when ideas like this were brought up, some were concerned that
> it wouldn't really be possible to do this type of updates while existing
> HTLCs were in flight (hence some of the ideas to clear out the commitment
> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
> allowed, as from the point of view of the channel update state machine, all
> updates (adds/removes) get applied as normal, but with this _new_
> commitment
> type/params. The main edge case we'll need to consider is cases where the
> new params make older HTLCs invalid for some reason.
>
> ## Conclusion
>
> Using the adapter commitment idea combined with a protocol for updating
> commitments on the fly, would potentially allow us to update all 80k+
> segwit
> v0 channels to the base level of taprooty channels without any on chain
> transactions. The two transactions (open+close) must happen eventually, but
> by holding another layer of spends off-chain we can defer them (potentially
> indefinitely, as we have channels today that have been opened for over a
> year).
>
> Deploying a generalised on-the-fly dynamic commitment update protocol gives
> us a tool to future proof the _existing_ anchored multi-sig outputs in the
> chain, and also a way to remove many of the hard coded parameters we have
> today in the protocol. One overly inflexible parameter we have today in the
> network is the 483 HTLC limit. Allowing this value to float would allow
> peers to apply similar congestion avoidance algorithm that are used in TCP
> today, and also give us a way to protect the network against future
> unforeseen widespread policy changes (like a raising of the dust limit).
>
> -- Laolu
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
> [2]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
> [3]: https://github.com/lightning/bolts/pull/868
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220324/19cab603/attachment-0001.html>

2023-06-09 13:05:37

- reply

📅 Original date posted:2022-03-22
📝 Original message:
Hi Rusty,
> Timestamps are replaced with block heights.
This is a conceptually small change, but would actually make things like
rate limiting updates for implementations easier and more uniform. A simple
rule would be only allowing an update per block, which cuts down a lot on
potential chatter traffic, but maybe it's _too_ restrictive? Based on my
network observations, these days some many power user nodes more
aggressively
update their fee schedules in response to liquidity imbalances or as an
attempt to incentive usage of some channels vs others.
> 1. Nodes send out weekly node_announcement_v2, proving they own some
> UTXOs.
If a node doesn't send out this announcement, then will others start to
ignore their "channels"?
> 3. This uses UTXOs for anti-spam, but doesn't tie them to channels
> directly.
As I hinted a bit in prior discussion, and also my recent ML [1] post
outlining a possible "do most of the same things" stop gap, this has the
potentially undesirable effect of allowing parties on the network to utilize
_existing_ outputs to advertise false channels and inflate the "total
network capacity" metric. We'd effectively be moving away from "Alice and
Bob have N BTC of bound capacity between them to", "Bob has N BTC he can use
for signing these proofs".
Also while we're at it, why not add a merkle proof here (independent of
which direction we go with) which makes it possible for constrained/mobile
nodes to more easily verify gossip data (could be an optional query flag).
> FIXME: what about tapscripts?
Yeah, one side effect of moving to nodes advertising how much BTC they can
sign w/ vs the _actual_ BTC they have in "channels", is that to extend
validation here, the verifiers would need to fully verify possible script
path spends (assuming a scenario where a NUMs point is used as the internal
key).
> Legacy proofs are two signatures, similar to the existing
> channel_announcement.
Why not musig2? We'd be able to get away with just a single sig with this
modified `node_announcement_v2` and if we go the `channel_announcement2`
route, we'd be able to compress those 4 sigs into one.
> - If two node_announcement_v2 claim the same UTXO, use the first seen,
> discard any others.
So then this would mean that nodes that _actually_ have a channel between
them can't _individually_ claim the capacity?
> - node_announcement_v2 are discarded after a week (1000 blocks). - Nodes
> do not need to monitor existence of UTXOs after initial check (since they
> will automatically prune them after a week).
A side effect of this would be _continual_ gossip churn in order to keep
channels alive. Today we do have the 2 week `channel_update` heart beat, but
channel updates are relatively small compared to this `node_announcement_v2`
message.
> - The total proved utxo value (not counting any utxos which are spent) is
> multiplied by 10 to give the "announcable_channel_capacity" for that node.
I don't see how this is at all useful in practice. We'd end up with inflated
numbers for the total node capacity, and path finding would be more
difficult as it isn't clear exactly how large an HTLC I can send over the
"channel". Sure there's the existence of max_htlc, but in that case why add
this "leverage" factor in the first place?
> 1. type: 273 (`channel_update_v2`)
This seems to allow the advertisement of channels which aren't actually
anchored in the chain, which I *think* is a cool thing to have? On the other
hand, the graph at the _edge_ level would be far more dynamic than it is
today (Bob can advertise an entirely distinct topology from one day to
another). Would need to think about the implications here for path finding
algorithms and nodes that want to maintain an update to date view of the
network...
> - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
> used in onion_messages, and a one bit stolen for the `claim` flag.
Where would this `channel_id` be derived from? FWIW, using this value in the
onion means we get a form of pubkey based routing [3] depending on how these
are derived.
> This simplifies gossip, requiring only two messages instead of three,
> and reducing the UTXO validation requirements to per-node instead of
> per-channel.
I'm not sure this would actually _simplify_ gossip in practice, given that
we'd be moving to a channel graph that isn't entirely based in the reality
of what's routable, and would be far more dynamic than it is today.
> We can use a convention that a channel_update_v2 with no `capacity` is a
> permanent close.
On the neutrino side, we tried to do something where if we see both channels
be disabled, then we'd mark the channel as closed. But in practice if you're
not syncing _every_ channel update every transmitted, then you'll end up
actually missing them.
> It also allows "leasing" of UTXOs: you could pay someone to sign their
> UTXO for your node_announcement, with some level of trust.
I'm not sure this is entirely a *good* thing, as the graph becomes more
decoupled with the _actual_ on-chain relationships...
-- Laolu
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html
[2]: https://github.com/lightning/bolts/pull/814
On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell <rusty at blockstream.com>
wrote:
> Hi all,
>
> I've floated this idea before, but this is a more concrete
> proposal for a "v2" gossip protocol.
>
> It assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses
> modern TLVs for all optional or extensible fields. Timestamps are
> replaced with block heights.
>
> 1. Nodes send out weekly node_announcement_v2, proving they own some
> UTXOs.
> 2. This entitles them to broadcast channels, using channel_update_v2; a
> channel_update_v2 from both peers means the channel exists.
> 3. This uses UTXOs for anti-spam, but doesn't tie them to channels
> directly.
> 4. Future ZKP proofs are could be added.
>
> 1. type: 271 (`node_announcement_v2`)
> 2. data:
> * [`bip340sig`:`signature`]
> * [`point32`:`node_id`]
> * [`u32`:`blockheight`]
> * [`node_announcement_v2_tlvs`:`tlvs`]
>
> 1. `tlv_stream`: `node_announcement_v2_tlvs`
> 2. types:
> 1. type: 2 (`features`)
> 2. data:
> * [`...*byte`:`featurebits`]
> 1. type: 3 (`chain_hash`)
> 2. data:
> * [`chain_hash`:`chain`]
> 1. type: 4 (`taproot_utxo_proofs`)
> 2. data:
> * [`...*taproot_utxo_proof`:`proofs`]
> 1. type: 6 (`legacy_utxo_proofs`)
> 2. data:
> * [`...*legacy_utxo_proof`:`proofs`]
> 1. type: 127 (`ipv4_addresses`)
> 2. data:
> * [`...*ipv4`:`addresses`]
> 1. type: 129 (`ipv6_addresses`)
> 2. data:
> * [`...*ipv6`:`addresses`]
> 1. type: 131 (`torv3_addresses`)
> 2. data:
> * [`...*torv3`:`addr`]
> # Maybe alias, color, etc?
>
> Taproot proofs are a signature of the v1 output over the `node_id`,
> `utxo` and `blockheight` with prefix "lightingtaproot_utxo_proofsig"
> (using the tagged signatures as per BOLT12). (FIXME: what about
> tapscripts?).
>
> Legacy proofs are two signatures, similar to the existing
> channel_announcement.
>
> 1. subtype: `taproot_utxo_proof`
> 2. data:
> * [`short_channel_id`:`utxo`]
> * [`signature`:`sig`]
>
> 1. subtype: `legacy_utxo_proof`
> 2. data:
> * [`short_channel_id`:`utxo`]
> * [`point`:`bitcoin_key_1`]
> * [`point`:`bitcoin_key_2`]
> * [`signature`:`sig_1`]
> * [`signature`:`sig_2`]
>
> - node_announcement_v2 are discarded after a week (1000 blocks).
> - If two node_announcement_v2 claim the same UTXO, use the first seen,
> discard any others.
> - Nodes do not need to monitor existence of UTXOs after initial check
> (since
> they will automatically prune them after a week).
> - The total proved utxo value (not counting any utxos which are spent)
> is multiplied by 10 to give the "announcable_channel_capacity" for that
> node.
>
> 1. type: 273 (`channel_update_v2`)
> 2. data:
> * [`bip340sig`:`signature`]
> * [`point32`:`local_node_id`]
> * [`point32`:`remote_node_id`]
> * [`u32`:`blockheight`]
> * [`u32`:`channel_id_and_claimant`]
> * [`channel_update_v2_tlvs`:`tlvs`]
>
> 1. `tlv_stream`: `channel_update_v2_tlvs`
> 2. types:
> 1. type: 2 (`features`)
> 2. data:
> * [`...*byte`:`featurebits`]
> 1. type: 3 (`chain_hash`)
> 2. data:
> * [`chain_hash`:`chain`]
> 1. type: 4 (`capacity`)
> 2. data:
> * [`tu64`:`satoshis`]
> 1. type: 5 (`cost`)
> 2. data:
> * [`u16`:`cltv_expiry_delta`]
> * [`u32`:`fee_proportional_millionths`]
> * [`tu32`:`fee_base_msat`]
> 1. type: 6 (`min_msat`)
> 2. data:
> * [`tu64`:`min_htlc_sats`]
>
> - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
> used in onion_messages, and a one bit stolen for the `claim` flag.
> - A channel is not considered to exist until both peers have sent a
> channel_update_v2, at least one of which must set the `claim` flag.
> - If a node sets `claim`, the capacity of the channel is subtracted from
> the remaining announcable_channel_capacity for that node (minimum
> 10,000 sats).
> - If there is insufficient total `announcable_channel_capacity` for a
> node, it is used by the lower `channel_id`s first.
>
> Implications
> ------------
>
> This simplifies gossip, requiring only two messages instead of three,
> and reducing the UTXO validation requirements to per-node instead of
> per-channel. We can use a convention that a channel_update_v2 with no
> `capacity` is a permanent close.
>
> We might want to add a taproot_utxo_delegated_proof where UTXOs can
> sign over to another key, so cold storage only needs to sign once, and
> the other key can sign weekly.
>
> It also allows "leasing" of UTXOs: you could pay someone to sign their
> UTXO for your node_announcement, with some level of trust. They could
> spend the UTXO, which gives you a slow degredation as new nodes don't
> accept your channels but existing nodes don't check until it's due for a
> refresh). Or they could sign one UTXO for multiple node_announcements,
> which is why preference is given to the first-seen. But it's a weekly
> business so there's incentive for them not to.
>
> Between nodes there's the question of "who claims this new channel?",
> which I didn't address here. Opener claims is logical, but leaks
> information (though you could definitely pay for the peer to claim it).
> With dual-funding, it's more complex (some kind of proportional coinflip
> protocol is possible), but basically you can always wait for your peer,
> and if they don't set the claim bit you can.
>
> 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/20220322/23c944d8/attachment-0001.html>

2023-06-09 13:05:36

- reply

📅 Original date posted:2022-03-22
📝 Original message:
Hi y'all,
On the lnd side we've nearly finished fully integrating taproot into the
codebase [1] (which includes the btcsuite set of libraries and also full
btcwallet support), scheduled to ship in 0.15 (~April), which will enable
existing users of lnd's on-chain wallet and APIs to start getting taprooty
wit it. As any flavor of taproot will mean a different on-chain funding
output, the _existing_ gossip layer needs some sort of modification, as the
BOLTs today don't define how to validate that a given output is actually a
taproot channel. Discussions during the prior spec meetings seem to have
centered in on two possible paths:
1. Use this as an opportunity to entirely redesign the channel validation
portion of the gossip layer (ring sigs? zkps? less validation? better
privacy?).
2. Defer the above, and instead go with a more minimal mostly the same
channel_announcement-like message for taproot channels.
In this mail, I want to explore the second option in detail, as Rusty has
already started a thread on what option #1 may look like [2].
## A new taproot-aware `channel_announcement2` message
A simple `channel_announcement2` message that was taproot aware could look
something like:
1. type: xxx (`channel_announcement2`) 2. data:
* [`signature`:`announcement_sig`]
* [`u16`:`len`]
* [`len*byte`:`features`]
* [`chain_hash`:`chain_hash`]
* [`short_channel_id`:`short_channel_id`]
* [`point`:`node_id_1`]
* [`point`:`node_id_2`]
* [`point`:`bitcoin_key_1`]
* [`point`:`bitcoin_key_2`]
(can assume it'll be just native TLV prob also)
This is pretty much the same as the _existing_ `channel_announcement`
message but instead of us carrying around 4 signatures, we'd use musig2 to
generate a _single_ signature under the aggregate public key
(`node_id_1`+`node_id_2`+`bitcoin_key_1`+`bitcoin_key_2`).
While were here, similar to what's been proposed in [2], it likely makes
sense to add an optional (?) merkle proof here to make channel validation
more feasible for constrained/mobile clients (they don't need to fetch all
those blocks any longer). The tradeoff here is that the merkle proof would
potentially be the largest part of the message, which means more on-chain
data needed to store the full channel graph. Alternatively, we could make
this into another gossip query option, with nodes only fetching the proofs
if they actually need it (full nodes with a txindex and just fetch the
transaction).
### Should the proof+verification strongly bind to the LN context?
As far as on-chain output validation, the main difference would be how nodes
actually validate the Bitcoin output (referenced by the `short_channel_id`)
on chain. Today, nodes use the two bitcoin keys and construct a p2wsh
multi-sig script and then verify that the script matches what has been
confirmed on chain. With taproot, the output is actually just a single key.
So if we want to maintain the same level of binding (which makes it harder
to advertise fake channels using just a change output have or something),
then we'd specify that nodes reconstruct the aggregated bitcoin public key
(Q = a_1*B_1 + a_2*_B_2, where a_i is a blinding factor derived using the
target key and every other key in the signing set) and assert that this
matches the pkScript on chain.
By verifying that this output key is just an aggregated key, then we can
also ensure that there's no actual committed script root (a la BIP 86 [3])
which binds the output to our context further. However maybe we want to also
include a `tapscript_root` field as well (so use the musig2 key as the
internal key and then apply the tweaking operations and verify things match
up), which would enable more elaborate unlocking/multi-sig functionality for
the normal funding output.
Alternatively, if we decided that this strong binding isn't as desirable
(starting to get into option 1 territory), then we'd specify just a single
Bitcoin key and look for that directly in the on chain script. IMO, if we're
going the route of something that very closely resembles what we have today,
then we shouldn't drop the strong binding, and fully verify that the key is
indeed a musig2 aggregated public key.
## `announcement_signatures2` and musig2 awareness
The `announcement_signatures` message would also need to change as we'd only
be sending a single signature across the wire: the musig2 _partial_
signature.
1. type: xxx (`announcement_signatures2`) 2. data:
* [`channel_id`:`channel_id`]
* [`short_channel_id`:`short_channel_id`]
* [`signature`:`partial_chan_proof_sig`]
Once both sides exchange this, as normal either party can generate the
`channel_announcement` message to broadcast to the network.
The addition of musig2 carries with it an additional dependency: before
these signatures can be generated, both sides need to exchange their public
nonce (in practice it's two nonces points R_1 and R_2), which is then used
to generate the aggregated nonce using for signing. Thankfully, I don't
think we actually need an additional message here, and instead we can piggy
back the public nonces on top of the _existing_ funding message flow. So in
this case, we'd just add a `66*byte`:`public_nonce` (the public nonces use
the full compressed encoding for the points, which is why it isn't jut 64
bytes) field to the open+accept channel messages, which MUST be present if
the channel was to be advertised.
## Conclusion
In this mail, I've sketched out a mostly mechanical mapping of taproot
awareness to our existing gossip message flow. This contrasts the approach
to re-design the channel advertisement as it doesn't deviate too much from
the current flow (same verification with a slight twist), which may make it
easier to deploy (but ofc the devil is in the details as always).
Thoughts?
-- Laolu
[1]: https://github.com/lightningnetwork/lnd/pull/6263
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
[3]:
https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki#address-derivation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220322/e6936024/attachment.html>

2023-06-09 13:05:23

- reply

📅 Original date posted:2022-02-23
📝 Original message:
Hi y'all,
(TL;DR: a way to nodes to get paid to forward onion messages by adding an
upfront session creation phase that uses AMP tender a messaging session to a
receiver, with nodes being paid upfront for purchase of forwarding
bandwidth, and a session identifier being transmitted alongside onion
messages to identify paid sessions)
Onion messaging has been proposed as a way to do things like fetch invoices
directly from a potential receiver _directly_ over the existing LN. The
current proposal (packaged under the BOLT 12 umbrella) uses a new message
(`onion_message`) that inherits the design of the existing Sphinx-based
onion blob included in htlc_add messages as a way to propagate arbitrary
messages across the network. Blinded paths which are effectively an unrolled
Sphinx SURB (single use reply block), are used to support reply messages in
a more private manner. Compared to SURBs, blinded paths are more flexible as
they don't lock in things like fees or CLTV values.
A direct outcome of widespread adoption of the proposal is that the scope of
LN is expanded beyond "just" a decentralized p2p payment system, with the
protocol evolving to also support pseudonymous messaging and arbitrary data
transfer across the network. This expanded network (payments + arbitrary
data transfer) enables use cases like streaming video transfer, network
tunneled VPNs, large file download, popcorn time, etc -- . Depending on
one's view, the existence of such a combined protocol/network may either
elicit feelings of dread (can we really do _both_ payments _and_ data
properly in the same network?) or excitement (I finally have a censorship
resistant way to watch unboxing videos of all my favorite gadgets!).
Putting aside the discussion w.r.t if such an expanded network is desirable
and also if the combined functionality fundamentally _needs_ to exist in the
confines of a single protocol stack (eg: if LN impls packaged tor clients
would that be enough?), IMO onion messaging as currently proposed has
a few issues:
1. As there's no explicit session creation/acceptance, a node can be
spammed with unsolicited messages with no way to deny unwanted messages nor
explicitly allow messages from certain senders.
2. Nodes that forward these messages (up to 32 KB per message) receive no
compensation for the network bandwidth their expend, effectively shuffling
around messages for free.
3. Rate limiting isn't concretely addressed, which may result in
heterogeneous rate limiting policies enforced around the network, which can
degrade the developer/user experience (why are my packets being randomly
dropped?).
In this email I propose a way to address the issues mentioned above by
adding explicit onion messaging session creation as well as a way for nodes
to be (optionally) paid for any onion messages they forward. In short, an
explicit session creation phase is introduced, with the receiver being able
to accept/deny the session. If the session is accepted, then all nodes that
comprise the session route are compensated for allotting a certain amount of
bandwidth to the session (which is ephemeral by nature).
# High-Level Overview
Inspired by HORNETs two-phase session creation (first phase makes the
circuit, send allows data transfers), I propose we break up onion messaging
session creation into two phases. In the first phase a sender purchases
_forwarding bandwidth_ from a series of intermediate nodes and also requests
creation of a messaging session to the receiver in a single _atomic_ step.
In the second phase, assuming the session creation was successful, the
sender is able to use the purchased forwarding bandwidth to send messages to
the receiver. The session stays open until either it expires, or the
receiver runs out of cumulative forwarding bandwidth and needs to repeat the
first step.
As we'll see shortly, the created onion messaging sessions aren't tightly
coupled to the nodes that are a part of the initial session creation.
Instead session creation creates a sort of overlay network from the PoV of
the sender that can be used to transmit messages. The same route doesn't
need to be used by subsequent onion message transmissions as the sending
node may already have existing bandwidth sessions it can put together to
send a new/existing message.
One trade-off of the current approach is that a small amount of per-session
state is added to nodes that want to be paid to forward onion messages. The
current onion messaging proposal takes care to _not_ introduce any extra
state to nodes in an onion messaging path: they just decrypt/unblinded and
forward to the next hop. This proposal as it stands adds just 40-bytes-ish
of storage overhead per session (which are ephemeral so this state can be
forgotten over time). In practice, as nodes are being paid to forward, they
can ensure their pricing (more on that later) properly compensates then for
this added storage per session.
# AMP + Onion Messaging == Paid Onion Messaging
What follows is a concrete-ish sketch of how something like this can be
implemented in practice. At a high level, we use AMP to extend a push
payment to a would be receiver (which can actually just be oneself in
practice to purchase bandwidth sessions). Nodes add a new TLV to their node
announcement (alongside a new feature bit that says they only accept
payment for forwarding) that allows them to express a _new_ fee rate for
forwarding messages (distinct from normal fees as one pay per byte
transferred). Using another new TLV within the existing HTLC onion blob, the
sender transmits a 32-byte session identifier (may be distinct for each
route) to each intermediate hop. The final hop of the HTLC includes yet
another new TLV in the onion that specifies that this is an AMP payment
wishing to establish an onion messaging session that terminates at that
final hop. In the data transfer phase, the `encrypted_data_tlv` for each hop
is extended with a new type that stores the session identifier, with nodes
keeping track of the remaining forwarding bandwidth allotted to the,
rejecting messages if the session has expired or not bandwidth remains.
## Node Announcement TLV Extension
In order to allow nodes to signal that they want to be paid to forward onion
messages and also specify their pricing, we add two new TLV to the node_ann
message:
* type: 1 (`sats_per_byte`)
* data:
* [`uint64`:`forwarding_rate`]
* type: 2 (`sats_per_block`)
* data:
* [`uint64`:`per_block_rate`]
The `sats_per_byte` field allows nodes to price their bandwidth, ensuring
that they get paid for each chunk of allocated bandwidth. As sessions have a
fixed time frame and nodes need to store additional data within that time
frame, the `sats_per_block` allows nodes to price this cost, as they'll hold
onto the session identifier information until the specified block height
(detailed below).
As onion messages will _typically_ be fixed sized we may want to use
coursers
metering here instead of bytes, possibly paying for 1.3KB or 32 KB chunks
instead.
## Onion Messaging Identifiers
With the above nodes are able to express that they're willing to forward
messages for sats, and how much they charge per byte as well as per block.
Next we add a new TLV in the _existing_ HTLC onion blob that allows a
sending node to tender paid onion message session creation. A sketch of this
type would look something like:
* type: 14 (`onion_session_id`)
* data:
* [`32*byte`:`session_id`]
After session creation succeeds, nodes will forward onion messages that
include that `onion_session_id`. The set of `encrypted_data_tlv` for onion
messages is extended to also specify a new type that stores the session ID:
* type: 10 (`onion_session_id`)
* data:
* [`32*byte`:`session_id`]
When forwarding an onion message that includes an `onion_session_id` (a node
may only forward messages that contain such an ID), nodes do the necessary
bookkeeping to tally how much bandwidth if left in this session, and also
check that the session hasn't expired before forwarding.
## Session Creation
During session creation, the sender creates a series of new
`onion_session_id`'s (or a single one) for all nodes in the messaging route
it
doesn't already have an active session with. To initiate session creation,
the
node sends an AMP payment to the receiver (a push payment) that drops off
the
proper fee (as specified by the `sats_per_byte` and `sats_per_block` rate)
to
each intermediate hop along with the proposed `onion_session_id`. We also
add
another TLV (to the base onion blob) that specifies the indented lifetime of
the session:
* type: 10 (`onion_session_expiry_height`)
* data:
* [`uint32`:`expiry_height`]
To accept a session, the receiver waits until all payment parts have arrived
(senders can either purchase bandwidth in bulk sessions, or do little by
little, tit-for-tat style) and pulls the payment. As the receiver needs to
receive the message in the first place, they're also compensated in a
similar manner.
Session creation is rejected (I don't want to receive messages) if the
receiver chooses to fail back _any_ of the AMP HTLC splits (they don't need
to wait until they all arrive). If a session is rejected, then nodes forget
that session ID, and its treated like any other failed HTLC. If a session is
accepted (the pre-image gets pulled and all nodes get their upfront
bandwidth payment as fees) then nodes are to remember that session ID as
they need to account for the remaining bandwidth and lifetime.
## Data Transmission + Forwarding
Once a session has been finalized, the sender can use it to send messages to
the receiver. To do so, in addition to specifying the `next_node_if` field,
they also specify the purchased `onion_session_id` in the set of
`encrypted_data_tlv`. Note that a node may already have active sessions
across the network, so initial session creation may not be required for each
new destination they want to send a message to. Over time if they're sending
frequent messages, they'll create what's effectively a personal overlay
network that they can use to send messages to any node in that set.
When forwarding onion messages, in addition to the normal
decryption/unblinding, nodes also check that the session hasn't expired and
the session also has enough bandwidth left.
# Conclusion
With the above sketch, we gain a way for nodes to be compensated for
forwarding onion messages on the network. This supplements their existing
fee revenue, potentially making it more sustainable to run a Lightning node,
depending on the demand for forwarding bandwidth by
wallets/services/applications. Onion messaging is left mostly unchained,
aside from the addition of some new TLV types and an added storage
requirement. Clients need to keep track of these session identifiers, which
adds a small storage requirement that scales according to their number of
established sessions (decays like the node storage requirement as well).
Examining the BOLT 12 use case of using onion messaging to fetch invoices,
this scheme adds a cost to sending arbitrary messages which includes invoice
messages. To address this the receiver can do things like include the
session ID as part of the blinded paths, and prepay forwarding bandwidth for
nodes along that path. As the session IDs are in the onion itself, the
sender doesn't learn of them so they can't use them for their own arbitrary
purposes.
As AMP payments are used to create initial sessions, forwarding paid
messages across the network requires a channel to exist between all hops in
the route, unlike base onion messages that specifies one should allow
messages to nodes you don't have a channel open with.
There're still some details that need to be filled in here (in particular
how pathfinding is modified by the initial session creation, but I figure
it's useful to at least throw this out there to add some more nuance to the
conversation related to onion messaging and the added DoS potential. If
nodes are given a way to be paid for forwarding onion messages instead of
doing it for free, from my PoV it's safe to assume that they'll
overwhelmingly prefer to be paid (other than nodes that use uniform zero
fees across all channels I guess).
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220223/e40bf6f2/attachment-0001.html>

2023-06-09 13:04:03

- reply

📅 Original date posted:2021-10-12
📝 Original message:
Hi Fabrice,
> I believe that was a mistake: a few days ago, Arcane Research published a
> fairly detailed report on the state of the Lightning Network:
> https://twitter.com/ArcaneResearch/status/1445442967582302213. They
> obviously did some real work there, and seem to imply that their report
> was vetted by Open Node and Lightning Labs.
Appreciate the hard work from Arcane on putting together this report. That
said, our role wasn't to review the entire report, but instead to provide
feedback on questions they had. Had we reviewed the section in question, we
would have spotted those errors and told the authors to fix them. Mistakes
happen, and we're glad it got corrected.
Also note that lnd has _never_ referred to itself as the "reference"
implementation. A few years ago some other implementations adopted that
title themselves, but have since adopted softer language.
> So I'm proposing that lnd's source code be removed from
> https://github.com/lightningnetwork/ (and moved to
> https://github.com/lightninglabs for example, with the rest of their
> Lightning tools, but it's up to Lightning Labs).
I think it's worth briefly revisiting a bit of history here w.r.t the github
org in question. In the beginning, the lightningnetwork github org was
created by Joseph, and the lightningnetwork/paper repo was added, the
manuscript that kicked off this entire thing. Later lightningnetwork/lnd was
created where we started to work on an initial implementation (before the
BOLTs in their current form existed), and we were added as owners.
Eventually we (devs of current impls) all met up in Milan and decided to
converge on a single specification, thus we added the BOLTs to the same
repo, despite it being used for lnd and knowingly so.
We purposefully made a _new_ lightninglabs github org as we wanted to keep
lnd, the implementation distinct from any of our future commercial
products/services. To this day, we've architected all our paid products to
be built _on top_ of lnd, rather than within it. As a result, users always
opt into these services.
As it seems the primary grievance here is collocating an implementation of
Lightning along with the _specification_ of the protocol, and given that the
spec was added last, how about we move the spec to an independent repo owned
by the community? I currently have github.com/lightning, and would be happy
to donate it to the community, or we could create a new org like
"lightning-specs" or something similar. We could then move the spec (the
BOLTs and also potentially the bLIPs since some devs want it to be within
its own repo) there, and have it be the home for any other
community-backed/owned projects. I think the creation of a new github
organization would also be a good opportunity to further formalize the set
of stakeholders and the general process related to the evolution of
Lightning the protocol.
Thoughts?
-- Laolu
On Fri, Oct 8, 2021 at 5:25 PM Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:
> Hello,
>
> When you navigate to https://github.com/lightningnetwork/ you find
> - the Lightning Network white paper
> - the Lightning Network specifications
> - and ... the source code for lnd!
>
> This has been an anomaly for years, which has created some confusion
> between Lightning the open-source protocol and Lightning Labs, one of
> the companies specifying and implementing this protocol, but we didn't
> do anything about it.
>
> I believe that was a mistake: a few days ago, Arcane Research
> published a fairly detailed report on the state of the Lightning
> Network: https://twitter.com/ArcaneResearch/status/1445442967582302213.
> They obviously did some real work there, and seem to imply that their
> report was vetted by Open Node and Lightning Labs.
>
> Yet in the first version that they published you’ll find this:
>
> "Lightning Labs, founded in 2016, has developed the reference client
> for the Lightning Network called Lightning Network Daemon (LND)....
> They also maintain the network standards documents (BOLTs)
> repository."
>
> They changed it because we told them that it was wrong, but the fact
> that in 2021 people who took time do do proper research, interviews,
> ... can still misunderstand that badly how the Lightning developers
> community works means that we ourselves badly underestimated how
> confusing mixing the open-source specs for Lightning and the source
> code for one of its implementations can be.
>
> To be clear, I'm not blaming Arcane Research that much for thinking
> that an implementation of an open-source protocol that is hosted with
> the white paper and specs for that protocol is a "reference"
> implementation, and thinking that since Lightning Labs maintains lnd
> then they probably maintain the other stuff too. The problem is how
> that information is published.
>
> So I'm proposing that lnd's source code be removed from
> https://github.com/lightningnetwork/ (and moved to
> https://github.com/lightninglabs for example, with the rest of their
> Lightning tools, but it's up to Lightning Labs).
>
> Thanks,
>
> Fabrice
> _______________________________________________
> 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/20211012/53ceba64/attachment.html>

2023-06-09 13:03:52

- reply

📅 Original date posted:2021-09-22
📝 Original message:
Hi Ole,
It's generally known that one can use out of band transaction construction,
and the push_amt feature in the base funding protocol to simulate dual
funded channels.
The popular 'balanceofsatoshis' tool has a command that packages up the
interaction (`open-balanced-channel`) into an easier to use format, IIRC it
uses key send to ask a peer if they'll accept one and negotiate some of the
params.
The one thing you need to take mind of when doing this manually is that by
default lnd will only lock the UTXOs allocated for the funding attempt for a
few minutes. As a result, you need to make sure the process is finalized
during that interval or the UTXOs will be unlocked and you risk accidentally
double spending yourself.
Lightning Pool also uses this little trick to allows users to purchase
channels that are 50/50 balanced, and also purchase channel leases _for_ a
third party (called sidecar channels) to help on board them onto Lightning:
https://lightning.engineering/posts/2021-05-26-sidecar-channels/. Compared
to the above approaches, the process can be automatically batched w/ other
channels created in that epoch, and uses traits of the Pool account system
to make things atomic.
Ultimately, the balanced-ness of a channel is a transitory state (for
routing nodes, it's great for on-boarding end-users) and opening channels
like these only serves to allow the channel to _start_ in the state. If your
fees and channel policies aren't set accordingly, then it's possible that a
normal payment or balance flow shifts the channel away from equilibrium
shortly after the channel is open.
-- Laolu
On Tue, Sep 21, 2021 at 10:30 PM Ole Henrik Skogstrøm <
oleskogstrom at gmail.com> wrote:
> Hi
>
> I have found a way of opening balanced channels using LND's psbt option
> when opening channels. What I'm doing is essentially just joining funded
> PSBTs before signing and submitting them. This makes it possible to open a
> balanced channel between two nodes or open a ring of balanced channels
> between multiple nodes (ROF).
>
> I found this interesting, however I don't know if this is somehow unsafe
> or for some other reason a bad idea. If not, then it could be an
> interesting alternative to only being able to open unbalanced channels.
>
> To do this efficiently, nodes need to collaborate by sending PSBTs back
> and forth to each other and doing this manually is a pain, so if this makes
> sense to do, it would be best to automate it through a client.
>
> ----------------------
> --- Here is an example of the complete flow for a single channel:
> ----------------------
>
> ** Node A: generates a new address and sends address to Node B *(lncli
> newaddress p2wkh)
>
> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
> (lncli openchannel --psbt <node_b_pubkey> 2000000 1000000)
>
> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B funds the refund transaction to Node A and sends PSBT back to
> Node A (*bitcoin-cli walletcreatefundedpsbt []
> '[{"<node_a_return_address>":0.01}]')
>
> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
> joinpsbts '["<channel_open_psbt>", "<node_b_return_to_node_a_psbt>"]')
>
> ** Node B verifies the content and signs the joined PSBT before sending it
> back to Node A *(bitcoin-cli walletprocesspsbt <joined_psbt>)
>
> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
> walletprocesspsbt <joined_psbt>)
>
> ** Node A: Completes channel open by publishing the fully signed PSBT*
>
>
> ----------------------
> --- Here is an example of the complete flow for a ring of channels between
> multiple nodes:
> ----------------------
>
> ** Node A starts an Interactive open channel to Node B using psbt* (lncli
> openchannel --psbt --no_publish <node_b_pubkey> 2000000 1000000)
> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B starts an Interactive open channel to Node C using psbt* (lncli
> openchannel --psbt --no_publish <node_b_pubkey> 2000000 1000000)
> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node C starts an Interactive open channel to Node A using psbt* (lncli
> openchannel --psbt <node_b_pubkey> 2000000 1000000)
> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B and C sends Node A their PSBTs*
>
> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
> '["<A_funded_channel_psbt>", "<B_funded_channel_psbt>",
> "<C_funded_channel_psbt>"]')
>
> Using (bitcoin-cli walletprocesspsbt <joined_psbt>):
>
>
>
> ** Node A verifies and signs the PSBT and sends it to Node B (1/3
> signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3
> signatures)* Node C verifies and signs the PSBT (3/3 signatures) before
> sending it to Node A and B.*
>
>
> ** Node A completes channel open (no_publish)* Node B completes channel
> open (no_publish)* Node C completes channel open and publishes the
> transaction.*
>
> --
> Ole Henrik Skogstrøm
>
> _______________________________________________
> 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/20210922/b4281beb/attachment.html>

2023-06-09 13:02:52

- reply

📅 Original date posted:2021-07-01
📝 Original message:
> But they don't address the first point at all, they instead work around
> it. To be fair, I don't think we can completely address that first point:
> properly reviewing spec proposals takes a lot of effort and accepting
> complex changes to the BOLTs shouldn't be done lightly.
I think this is a fair characterization that I agree with. I also agree that
there isn't really a way to fundamentally address it. The issue of scarce
review resources is something just about any large open source project needs
to deal with: everyone wants to make a PR, but no one wants to review the
PRs of others, unless it scratches some tangential itch they may have. IMO
it's also the case that the problem/solution space of LN is so large, that
it's hard to expect every developer to review each new proposal that comes
in, as they themselves have their own set of priorities (product,
businesses, protocol, personal, etc).
In the end though, I think when there've been critical items that affect all
implementations and/or the existence of the protocol itself, developers
typically band together to commit resources to help a proposal move forward.
One upcoming example of this will be the "base" taproot channel type (the
design space is pretty large in that it even permits a new type of symmetric
state revocation-based channel).
> it will add fragmentation to the network, it will add maintenance costs
> and backwards-compatibility issues
Will it actually add any more fragmentation that already exists? Due to all
the extensibility we've added in the protocol, it's already possible for any
implementation to start to work on their own sub-protocols. This just gives
them a new venue to at least _describe_ what they're using. As usual, it's
up to other implementations if they want to adopt it or not, or advise
against its use.
> many bLIPs will be sub-optimal solutions to the problem they try to solve
> and some bLIPs will be simply insecure and may put users' funds at risk
> (L2 protocols are hard and have subtle issues that can be easily missed)
This may be the case, but I guess at times it's hard to know if something is
objectively sub-optimal without further exploration of the design space,
which usually means either more people involved, or more time examining the
problem. Ultimately, different wallets/implementations may also be willing
to make different usability/security trade-offs. One example here is zero
conf channels: they assume a greater degree of trust with the party you're
_accepting_ the channel from, as if you receive funds over the channel, they
can be double spent away. However it's undeniable that they improve the UX
by reducing the amount of time a user needs to wait around before they can
actually jump in and use LN.
In the end though, there's no grand global committee that prevents people
from deploying software they think is interesting or useful. In the long
run, I guess one simply needs to hope that bad ideas die out, or speak out
against them to the public. As LN sits a layer above the base protocol,
widespread global consensus isn't really required to make certain classes of
changes, and you can't stop people from experimenting on their own.
> We can't have collisions on any of these three things.
Yeah, collisions are def possible. IMO, this is where the interplay with
BOLTs comes in: BOLTs are the global feature bit/tlv/message namespace. A
bLIP might come with the amendment of BOLT 9 to define feature bits they
used. Of course, this should be done on a best effort basis, as even if you
assign a bit for your idea, someone can just go ahead and deploy something
else w/ that same bit, and they may never really intersect depending on the
nature or how widespread the new feature is.
It's also likely the case that already implementations, or typically forks
of implementations are already using "undocumented" TLVs or feature bits in
the wild today. I don't know exactly which TLV type things like applications
that tunnel messages over the network use, but afaik so far there haven't
been any disastrous collisions in the wild.
-- Laolu
On Thu, Jul 1, 2021 at 2:19 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Thanks for starting that discussion.
>
> In my opinion, what we're really trying to address here are the two
> following
> points (at least from the point of view of someone who works on the spec
> and
> an implementation):
>
> - Implementers get frustrated when they've worked on something that they
> think
> is useful and they can't get it into the BOLTs (the spec PR isn't reviewed,
> it progresses too slowly or there isn't enough agreement to merge it)
> - Implementers expect other implementers to specify the optional features
> they
> ship: we don't want to have to reverse-engineer a sub-protocol when users
> want our implementation to provide support for feature XXX
>
> Note that these are two very different concerns.
>
> bLIPs/SPARKS/BIPs clearly address the second point, which is good.
> But they don't address the first point at all, they instead work around it.
> To be fair, I don't think we can completely address that first point:
> properly
> reviewing spec proposals takes a lot of effort and accepting complex
> changes
> to the BOLTs shouldn't be done lightly.
>
> I am mostly in favor of this solution, but I want to highlight that it
> isn't
> only rainbows and unicorns: it will add fragmentation to the network, it
> will
> add maintenance costs and backwards-compatibility issues, many bLIPs will
> be
> sub-optimal solutions to the problem they try to solve and some bLIPs will
> be
> simply insecure and may put users' funds at risk (L2 protocols are hard
> and have
> subtle issues that can be easily missed). On the other hand, it allows for
> real
> world experimentation and iteration, and it's easier to amend a bLIP than
> the
> BOLTs.
>
> On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully
> bazaar
> style of evolution. Most of them will need:
>
> - to assign feature bit(s)
> - to insert new tlv fields in existing messages
> - to create new messages
>
> We can't have collisions on any of these three things. bLIP XXX cannot use
> the
> same tlv types as bLIP YYY otherwise we're creating network
> incompatibilities.
> So they really need to be centralized, and we need a process to assign
> these
> and ensure they don't collide. It's not a hard problem, but we need to be
> clear
> about the process around those.
>
> Regarding the details of where they live, I don't have a strong opinion,
> but I
> think they must be easy to find and browse, and I think it's easier for
> readers
> if they're inside the spec repository. We already have PRs that use a
> dedicated
> "proposals" folder (e.g. [1], [2]).
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightningnetwork/lightning-rfc/pull/829
> [2] https://github.com/lightningnetwork/lightning-rfc/pull/854
>
> Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces <arielluaces at gmail.com> a
> écrit :
>
>> BIPs are already the Bazaar style of evolution that simultaneously
>> allows flexibility and coordination/interoperability (since anyone can
>> create a BIP and they create an environment of discussion).
>>
>> BOLTs are essentially one big BIP in the sense that they started as a
>> place for discussion but are now more rigid. BOLTs must be followed
>> strictly to ensure a node is interoperable with the network. And BOLTs
>> should be rigid, as rigid as any widely used BIP like 32 for example.
>> Even though BOLTs were flexible when being drafted their purpose has
>> changed from descriptive to prescriptive.
>> Any alternatives, or optional features should be extracted out of
>> BOLTs, written as BIPs. The BIP should then reference the BOLT and the
>> required flags set, messages sent, or alterations made to signal that
>> the BIP's feature is enabled.
>>
>> A BOLT may at some point organically change to reference a BIP. For
>> example if a BIP was drafted as an optional feature but then becomes
>> more widespread and then turns out to be crucial for the proper
>> operation of the network then a BOLT can be changed to just reference
>> the BIP as mandatory. There isn't anything wrong with this.
>>
>> All of the above would work exactly the same if there was a bLIP
>> repository instead. I don't see the value in having both bLIPs and
>> BIPs since AFAICT they seem to be functionally equivalent and BIPs are
>> not restricted to exclude lightning, and never have been.
>>
>> I believe the reason this move to BIPs hasn't happened organically is
>> because many still perceive the BOLTs available for editing, so
>> changes continue to be made. If instead BOLTs were perceived as more
>> "consensus critical", not subject to change, and more people were
>> strongly encouraged to write specs for new lightning features
>> elsewhere (like the BIP repo) then you would see this issue of growing
>> BOLTs resolved.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>>
>> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
>> wrote:
>> >
>> > > That being said I think all the points that are addressed in Ryan's
>> mail
>> > > could very well be formalized into BOLTs but maybe we just need to
>> rethink
>> > > the current process of the BOLTs to make it more accessible for new
>> ideas
>> > > to find their way into the BOLTs?
>> >
>> > I think part of what bLIPs are trying to solve here is promoting more
>> loosely
>> > coupled evolution of the network. I think the BOLTs do a good job
>> currently of
>> > specifying what _base_ functionality is required for a routing node in a
>> > prescriptive manner (you must forward an HTLC like this, etc). However
>> there's
>> > a rather large gap in describing functionality that has emerged over
>> time due
>> > to progressive evolution, and aren't absolutely necessary, but enhance
>> > node/wallet operation.
>> >
>> > Examples of include things like: path finding heuristics (BOLTs just
>> say you
>> > should get from Alice to Bob, but provides no recommendations w.r.t
>> _how_ to do
>> > so), fee bumping heuristics, breach retribution handling, channel
>> management,
>> > rebalancing, custom records usage (like the podcast index meta-data,
>> messaging,
>> > etc), JIT channel opening, hosted channels, randomized channel IDs, fee
>> > optimization, initial channel boostrapping, etc.
>> >
>> > All these examples are effectively optional as they aren't required for
>> base
>> > node operation, but they've organically evolved over time as node
>> > implementations and wallet seek to solve UX and operational problems for
>> > their users. bLIPs can be a _descriptive_ (this is how things can be
>> done)
>> > home for these types of standards, while BOLTs can be reserved for
>> > _prescriptive_ measures (an HTLC looks like this, etc).
>> >
>> > The protocol as implemented today has a number of extensions (TLVs,
>> message
>> > types, feature bits, etc) that allow implementations to spin out their
>> own
>> > sub-protocols, many of which won't be considered absolutely necessary
>> for node
>> > operation. IMO we should embrace more of a "bazaar" style of evolution,
>> and
>> > acknowledge that loosely coupled evolution allows participants to more
>> broadly
>> > explore the design space, without the constraints of "it isn't a thing
>> until N
>> > of us start to do it".
>> >
>> > Historically, BOLTs have also had a rather monolithic structure. We've
>> used
>> > the same 11 or so documents for the past few years with the size of the
>> > documents swelling over time with new exceptions, features,
>> requirements,
>> > etc. If you were hired to work on a new codebase and saw that
>> everything is
>> > defined in 11 "functions" that have been growing linearly over time,
>> you'd
>> > probably declare the codebase as being unmaintainable. By having
>> distinct
>> > documents for proposals/standards, bLIPs (author documents really),
>> each new
>> > standard/proposal is able to be more effectively explained, motivated,
>> versionsed,
>> > etc.
>> >
>> > -- Laolu
>> >
>> >
>> > On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
>> lightning-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> Hey everyone,
>> >>
>> >> just for reference when I was new here (and did not understand the
>> processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.:
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
>> >>
>> >> I wonder what exactly has changed in the reasoning by roasbeef which I
>> will repeat here:
>> >>
>> >> > We already have the equiv of improvement proposals: BOLTs.
>> Historically
>> >>
>> >> > new standardization documents are proposed initially as issues or
>> PR's when
>> >>
>> >> > ultimately accepted. Why do we need another repo?
>> >>
>> >>
>> >> As far as I can tell there was always some form of (invisible?)
>> barrier to participate in the BOLTs but there are also new BOLTs being
>> offered:
>> >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
>> >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
>> >> and topics to be included like:
>> >> * dual funding
>> >> * splicing
>> >> * the examples given by Ryan
>> >>
>> >> I don't see how a new repo would reduce that barrier - Actually I
>> think it would even create more confusion as I for example would not know
>> where something belongs. That being said I think all the points that are
>> addressed in Ryan's mail could very well be formalized into BOLTs but maybe
>> we just need to rethink the current process of the BOLTs to make it more
>> accessible for new ideas to find their way into the BOLTs? One thing that I
>> can say from answering lightning-network questions on stackexchange is that
>> it would certainly help if the BOLTs where referenced on lightning.network
>> web page and in the whitepaper as the place to be if one wants to learn
>> about the Lightning Network
>> >>
>> >> with kind regards Rene
>> >>
>> >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
>> lightning-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>>
>> >>> The recent thread around zero-conf channels [1] provides an
>> opportunity to discuss how the BOLT process handles features and best
>> practices that arise in the wild vs. originating within the process itself.
>> Zero-conf channels are one of many LN innovations on the app layer that
>> have struggled to make their way into the spec. John Carvalho and Bitrefill
>> launched Turbo channels in April 2019 [2], Breez posted their solution to
>> the mailing list for feedback in August 2020 [3], and we know at least
>> ACINQ and Muun (amongst others) have their own implementations. In an ideal
>> world there would be a descriptive design document that the app layer
>> implementers had collaborated on over the years that the spec group could
>> then pick up and merge into the BOLTs now that the feature is deemed
>> spec-worthy.
>> >>>
>> >>>
>> >>> Over the last couple of months, we have discussed the idea of adding
>> a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
>> members of the community, and have received positive feedback from both app
>> layer and protocol devs. This would not affect the existing BOLT process at
>> all, but simply add a place for app layer best practices to be succinctly
>> described and organized, especially those that require coordination. These
>> features are being built outside of the BOLT process today anyways, so
>> ideally a bLIP process would bring them into the fold instead of leaving
>> them buried in old ML posts or not documented at all.
>> >>>
>> >>>
>> >>> Some potential bLIP ideas that people have mentioned include: each
>> lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
>> payment metadata, p2p messaging formats, new pathfinding heuristics, remote
>> node connection standards, etc.
>> >>>
>> >>>
>> >>> If the community is interested in moving forward, we've started a
>> branch [5] describing such a process. It's based on BIP-0002, so not trying
>> to reinvent any wheels. It would be great to have developers from various
>> implementations and from the broader app layer ecosystem volunteer to be
>> listed as editors (basically the same role as in the BIPs).
>> >>>
>> >>>
>> >>> Looking forward to hearing your thoughts!
>> >>>
>> >>>
>> >>> Best,
>> >>> Ryan
>> >>>
>> >>>
>> >>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>> >>>
>> >>> [2]
>> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>> >>>
>> >>> [3]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>> >>>
>> >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
>> Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>> >>>
>> >>> [5]
>> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>> >>>
>> >>> _______________________________________________
>> >>> Lightning-dev mailing list
>> >>> Lightning-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >>
>> >>
>> >>
>> >> --
>> >> https://www.rene-pickhardt.de
>> >> _______________________________________________
>> >> 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/20210701/21d65d9a/attachment-0001.html>

2023-06-09 13:01:01

- reply

📅 Original date posted:2020-10-12
📝 Original message:
> It seems to me that the "funder pays all the commit tx fees" rule exists
> solely for simplicity (which was totally reasonable).
At this stage, I've learned that simplicity (when doing anything that
involves multi-party on-chain fee negotiating/verification/enforcement can
really go a long way). Just think about all the edge cases w.r.t _allocating
enough funds to pay for fees_ we've discovered over the past few years in
the state machine. I fear adding a more elaborate fee splitting mechanism
would only blow up the number of obscure edge cases that may lead to a
channel temporarily or permanently being "borked".
If we're going to add a "fairer" way of splitting fees, we'll really need to
dig down pre-deployment to ensure that we've explored any resulting edge
cases within our solution space, as we'll only be _adding_ complexity to fee
splitting.
IMO, anchor commitments in their "final form" (fixed fee rate on commitment
transaction, only "emergency" use of update_fee) significantly simplifies
things as it shifts from "funding pay fees", to "broadcaster/confirmer pays
fees". However, as you note this doesn't fully distribute the worst-case
cost of needing to go to chain with a "fully loaded" commitment transaction.
Even with HTLCs, they could only be signed at 1 sat/byte from the funder's
perspective, once again putting the burden on the broadcaster/confirmer to
make up the difference.
-- Laolu
On Mon, Oct 5, 2020 at 6:13 AM Bastien TEINTURIER via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> It seems to me that the "funder pays all the commit tx fees" rule exists
> solely for simplicity
> (which was totally reasonable). I haven't been able to find much
> discussion about this decision
> on the mailing list nor in the spec commits.
>
> At first glance, it's true that at the beginning of the channel lifetime,
> the funder should be
> responsible for the fee (it's his decision to open a channel after all).
> But as time goes by and
> both peers earn value from this channel, this rule becomes questionable.
> We've discovered since
> then that there is some risk associated with having pending HTLCs
> (flood-and-loot type of attacks,
> pinning, channel jamming, etc).
>
> I think that *in some cases*, fundees should be paying a portion of the
> commit-tx on-chain fees,
> otherwise we may end up with a web-of-trust network where channels would
> only exist between peers
> that trust each other, which is quite limiting (I'm hoping we can do
> better).
>
> Routing nodes may be at risk when they *receive* HTLCs. All the attacks
> that steal funds come from
> the fact that a routing node has paid downstream but cannot claim the
> upstream HTLCs (correct me
> if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of
> the HTLCs they offer
> while they're pending in the commit-tx, regardless of whether they're
> funder or fundee.
>
> The simplest way to do this would be to deduce the HTLC cost (172 *
> feerate) from the offerer's
> main output (instead of the funder's main output, while keeping the base
> commit tx weight paid
> by the funder).
>
> A more extreme proposal would be to tie the *total* commit-tx fee to the
> channel usage:
>
> * if there are no pending HTLCs, the funder pays all the fee
> * if there are pending HTLCs, each node pays a proportion of the fee
> proportional to the number of
> HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob
> pays 75% of the
> commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is
> redistributed.
>
> This model uses the on-chain fee as collateral for usage of the channel.
> If Alice wants to forward
> HTLCs through this channel (because she has something to gain - routing
> fees), she should be taking
> on some of the associated risk, not Bob. Bob will be taking the same risk
> downstream if he chooses
> to forward.
>
> I believe it also forces the fundee to care about on-chain feerates, which
> is a healthy incentive.
> It may create a feedback loop between on-chain feerates and routing fees,
> which I believe is also
> a good long-term thing (but it's hard to predict as there may be negative
> side-effects as well).
>
> What do you all think? Is this a terrible idea? Is it okay-ish, but not
> worth the additional
> complexity? Is it an amazing idea worth a lightning nobel? Please don't
> take any of my claims
> for granted and challenge them, there may be negative side-effects I'm
> completely missing, this is
> a fragile game of incentives...
>
> Side-note: don't forget to take into account that the fees for HTLC
> transactions (second-level txs)
> are always paid by the party that broadcasts them (which makes sense). I
> still think this is not
> enough and can even be abused by fundees in some setups.
>
> Thanks,
> Bastien
> _______________________________________________
> 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/20201012/148e00a3/attachment-0001.html>

2023-06-09 13:00:58

- reply

📅 Original date posted:2020-10-12
📝 Original message:
> I suggest adding tlv records in `commitment_signed` to tell our channel >
> peer that we're changing the values of these fields.
I think this fits in nicely with the "parameter re-negotiation" portion of
my
loose Dynamic commitments proposal. Note that in that paradigm, something
like this would be a distinct message, and also only be allowed with a
"clean commitment" (as otherwise what if I reduce the number of slots to a
value that is lower than the number of active slots?). With this, both sides
would be able to propose/accept/deny updates to the flow control parameters
that can be used to either increase the security of a channel, or implement
a sort of "slow start" protocol for any new peers that connect to you.
Similar to congestion window expansion/contraction in TCP, when a new peer
connects to you, you likely don't want to allow them to be able to consume
all the newly allocated bandwidth in an outgoing direction. Instead, you may
want to only allow them to utilize say 10% of the available HTLC bandwidth,
slowly increasing based on successful payments, and drastically
(multiplicatively) decreasing when you encounter very long lived HTLCs, or
an excessive number of failures.
A dynamic HTLC bandwidth allocation mechanism would serve to mitigate
several classes of attacks (supplementing any mitigations by "channel
acceptor" hooks), and also give forwarding nodes more _control_ of exactly
how their allocated bandwidth is utilized by all connected peers. This is
possible to some degree today (by using an implicit value lower than
the negotiated values), but the implicit route doesn't give the other party
any information, and may end up in weird re-send loops (as they _why_ an
HTLC was rejected) wasn't communicated. Also if you end up in a half-sign
state, since we don't have any sort of "unadd", then the channel may end up
borked if the violating party keeps retransmitting the same update upon
reconnection.
> Are there other fields you think would need to become dynamic as well?
One other value that IMO should be dynamic to protect against future
unexpected events is the dust limit. "It Is Known", that this value "doesn't
really change", but we should be able to upgrade _all_ channels on the fly
if it does for w/e reason.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/1700eb6d/attachment.html>

2023-06-09 13:00:51

- reply

📅 Original date posted:2020-09-10
📝 Original message:
Hi Antoine,
Great findings!
I think an even simpler mitigation is just for the non-initiator to _reject_
update_fee proposals that are "unreasonable". The non-initiator can run a
"fee leak calculation" to compute the worst-case leakage of fees in the
revocation case. This can be done to day without any significant updates to
implementations, and some implementations may already be doing this.
One issue is that we don't have a way to do a "soft reject" of an update_fee
as is. However, depending on the implementations, it may be possible to just
reconnect and issue a co-op close if there're no HTLCs on the commitment
transaction.
As you mentioned by setting proper values for max allowed htlcs, max in
flight, reserve, etc, nodes are able to quantify this fee leak risk ahead of
time, and set reasonable parameters based on their security model. One issue
is that these values are set in stone rn when the channel is opened, but
future iterations of dynamic commitments may allow us to update them on the
fly.
In the mid-term, implementations can start to phase out usage of update_fee
by setting a minimal commitment fee when the channel is first opened, then
relying on CPFP to bump up the commitment and any HTLCs if needed. This
discovery might very well hasten the demise of update_fee in the protocol
all together as well. I don't think we need to depend entirely on a
theoretical package relay Bitcoin p2p upgrade assuming implementations are
willing to make an assumption that say 20 sat/byte or w/e has a good chance
of widespread propagation into mempools.
>From the perspective of channel safety, and variations of attacks like
"flood & loot", imo it's absolutely critical that nodes are able to update
the fees on their second-level HTLC transactions. As this is where the real
danger lies: if nodes aren't able to get 2nd level HTLCs in the chain in
time, then the incoming HTLC expiry will expire, creating a race condition
across both commitments which can potentially cascade.
In lnd today, anchors is still behind a build flag, but we plan to enable
it by default for our upcoming 0.12 release. The blockers on our end were to
add support for towers, and add basic deadline aware bumping, both of which
are currently on track. We'll now also look into setting clamps on the
receiver end to just not accept unreasonable values for the fee rate of a
commitment, as this ends up eating into the true HTLC values for both sides.
-- Laolu
On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi,
>
> In this post, I would like to expose a potential vulnerability introduced
> by the recent anchor output spec update related to the new usage of
> SIGHASH_SINGLE for HTLC transactions. This new malleability combined with
> the currently deployed mechanism of `update_fee` is likely harmful for
> funds safety.
>
> This has been previously shared with deployed implementations devs, as
> anchor channels are flagged as experimental it's better to discuss and
> solve this publicly. That said, if you're currently running experimental
> anchor channels with non-trusted parties on mainnet, you might prefer to
> close them.
>
> # SIGHASH_SINGLE and `update_fee` (skip it if you're familiar)
>
> First, let's get started by a quick reminder of the data set committed by
> signature digest algorithm of Segwit transactions (BIP 143):
> * nVersion
> * hashPrevouts
> * hashSequence
> * outpoint
> * scriptCode of the input
> * value of the output spent by this input
> * nSequence of the input
> * hashOutputs
> * nLocktime
> * sighash type of the signature
>
> Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE
> | SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty. Thus
> it can spend non-cooperatively its HTLC outputs on its commitment
> transactions. I.e when Alice broadcasts her commitment transaction, every
> Bob's signatures on Alice's HTLC-Success/Timeout transactions are now
> flagging the new sighash type.
>
> Thus `hashPrevouts`, `hashSequence` (ANYONECANPAY) and `hashOutputs`
> (SINGLE) aren't committed anymore. SINGLE only enforces commitment to the
> output scriptpubkey/amount at the same index that
> the spending input. Alice is free to attach additional inputs/outputs to
> her HTLC transaction. This change is aiming to let a single-party bump the
> feerate of 2nd-stage HTLC transactions in case of mempool-congestion,
> without counterparty cooperation and thus make HTLC funds safer.
>
> The attached outputs are _not_ encumbered by a revokeable redeemscript for
> a potential punishment.
>
> That said, anchor ouput spec didn't change disable the current fee
> mechanism already covering HTLC transactions. Pre/post-anchor channels are
> negotiating a feerate through `update_fee` exchange, initiated by the
> channel funder. This `update_fee` can be rejected by the receiver if it's
> deemed unreasonable compared to your local fee estimator view, but as of
> today implementations are pretty liberal in their acceptance, admitting a
> divergence from a scale of 1 to no-bound at all.
>
> This negotiated feerate (`feerate_per_kw`) is used by channel participants
> to compute effective fees which have to be deduced either from the funder
> balance output for commitment transactions or from HTLC output value for
> HTLC transactions.
>
> # The Vulnerability : a Penalty Escape Vector
>
> By increasing the feerate thanks to `update_fee`, a malicious party can
> inflate fees committed on HTLC input/output pairs and redirect this
> inflated fee to a single-controlled output attached to these malleable
> pairs. This won't be punishable by an honest party in case of revoked state
> broadcast and thus enable to partially escape the penalty.
>
> As an example, Alice and Bob have a 100_000 sats channel. `feerate_per_kw`
> is 10000 sats.
>
> At state N, Alice balance is all on her side. She announces 10 outgoing
> HTLCs of value 7000 sats.
>
> As Commitment tx weight with 10 outputs is 2844 (post-anchor), the
> absolute fee committed is 28440 sats.
>
> As HTLC-timeout weight is 666 (post-anchor), the absolute fee committed is
> of 6660 sat, the HTLC tx output as counter-signed by Bob is of 340 sat.
> This absolute fee aims to pay the miner fee in case Alice needs to timeout
> HTLC onchain.
>
> Her remaining balance is 1560 sat, above both dust_limit_satoshi and the
> channel reserve as constrained by Bob (likely 1%).
>
> Alice waits for HTLCs to expire and advances state to N+1. Then she
> empties her balance minus reserve by sending a HTLC relayed by Bob either
> to a colluding channel on the rest of network or back to an onchain address
> thanks to a swap service.
>
> At state N+2, Alice finalizes HTLC-timeout of state N by capturing almost
> all of the absolute fee to a new P2WPKH output only controlled by her. She
> broadcasts the revoked commitment tx N and burns 28440 sats in commitment
> fee.
>
> Her balance of 1560 sats is punished by Bob's justice transaction.
>
> After confirmation and thus maturing of the CSV of 1 on her HTLC output
> Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to
> pay a low-fee. Bob punishes the 10 HTLC-timeout outputs of 340 sats.
>
> Alice gain = 99_000 (swap spend) + 66_660 (HTLCs escape) - 1560
> (commitment balance punishment) - 28440 (commitment fee) - 660*10 (HTLCs
> fees) - 340*10 (HTLCs output) = 125600 sats.
>
> Alice's gain is superior at channel value as it has been partially
> double-spend by bypassing the revocation punishment.
>
> # Limitations of Attacker Success
>
> A first limitation of attack success which can be point of is the fact
> that post-anchor HTLC outputs are CSV'ed by 1, which means in theory a
> honest party can punish this output before the malicious spend them with
> the revoked HTLC txn. In practice a malicious party can attach a branch of
> descendants to its anchor output and that way only allowing one more
> mempool victim's transaction on the revoked commitment. The victim must
> spend all outputs at once or otherwise they're going to obstrucate each
> other at mempool acceptance.
>
> Secondly, other limitations are the per-implementation channel policy
> `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and
> acceptance bound of `update_fee`. A quick look at default policies, even if
> they vary between deploy implementations, let it think there is room to
> escape a substantial part of channel value.
>
> Lastly, after the revoked commitment transaction is confirmed, both
> attacker and victim are in a feerate race to confirm either a justice
> transaction or a malicious HTLC-timeout. As fee estimator logic of the
> victim's implementation is a public piece of knowledge, it shouldn't be
> hard for the attacker to know the range of the first fee bid and override
> it by a bit to confirm it before the victim RBF at next block. Currently,
> not all implementations have RBF of justice transactions.
>
> As of today, if anchor output is deployed and given how LN implementations
> are managing fees/rebroadcast of onchain transactions, the chance of attack
> success sounds high in my opinion.
>
> # Countermeasures
>
> Channel policies could be tighter, like bounded further down
> `max_accepted_htlcs` or restraining acceptance of `update_fee`. For the
> latter, it's pretty hard as a) fee estimators diverge on mempool views b)
> an attacker can craft escape HTLC-txn in a period of high-fee and patiently
> waits a low-fee period to launch the exploitation.
>
> Justice transactions can adopt a scorched earth approach binding their
> feerate to the max to increase odds of winning the feerate race and thus
> deter attackers. But this sounds like introducing a griefing attack vector.
> Your counterparty can burn more of your lawful balance in fees than you'll
> punish its revoked balance.
>
> A workable option would be to patch current anchor spec to remove
> `feerate_per_kw` appliance on 2nd-stage transactions, maybe just committing
> a minimal relay fee.
>
> Thoughts of further countermeasures ?
>
> I think the vulnerability described is mostly right but please point any
> missing details.
>
> Cheers,
>
> Antoine
> _______________________________________________
> 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/20200910/24240038/attachment-0001.html>

2023-06-09 13:00:36

- reply

📅 Original date posted:2020-07-20
📝 Original message:
Hi y'all,
In this post, I'd like to share an early version of an extension to the spec
and channel state machine that would allow for on-the-fly commitment
_format/type_ changes. Notably, this would allow for us to _upgrade_
commitment types without any on-chain activity, executed in a
de-synchronized and distributed manner. The core realization these proposal
is based on the fact that the funding output is the _only_ component of a
channel that's actually set in stone (requires an on-chain transaction to
modify).
# Motivation
(you can skip this section if you already know why something like this is
important)
First, some motivation. As y'all are likely aware, the current deployed
commitment format has changed once so far: to introduce the
`static_remote_key` variant which makes channels safer by sending the funds
of the party that was force closed on to a plain pubkey w/o any extra tweaks
or derivation. This makes channel recovery safer, as the party that may have
lost data (or can't continue the channel), no longer needs to learn of a
secret value sent to them by the other party to be able to claim their
funds. However, as this new format was introduced sometime after the initial
bootstrapping phase of the network, most channels in the wild today _are
not_ using this safer format. Transitioning _all_ the existing channels to
this new format as is, would require closing them _all_, generating tens of
thousands of on-chain transactions (to close, then re-open), not to mention
chain fees.
With dynamic commitments, users will be able to upgrade their _existing_
channels to new safer types, without any new on-chain transactions!
Anchor output based commitments represent another step forward in making
channels safer as they allow users/software to no longer have to predict
chain fees ahead of time, and also bump up the fee of a
commitment/2nd-level-htlc-transaction, which is extremely important when it
comes to timely on-chain resolution of HTLC contracts. This upgrade process
(as touched on below) can either be manually triggered, or automatically
triggered once the software updates and finds a new preferable default
commitment format is available.
As many of us are aware, the addition of schnorr and taproot to the Bitcoin
protocol dramatically increases the design space for channels as a whole. It
may take some time to explore this design space, particularly as entirely
new channel/commitment formats [1] continue to be discovered. The roll out
of dynamic commitments allows us to defer the concrete design of the future
commitment formats, yet still benefit from the immediate improvement that
comes with morphing the funding output to be a single-key (non-p2wsh, though
the line starts to blur w/ taproot) output. With this new funding output
format in place, users/software will then be able to update to the latest
and greatest commitment format that starts to utilize all the new tools
available (scriptless script based htlcs, etc) at a later date.
Finally, the ability to update the commitment format itself will also allow
us to re-parametrize portions of the channels which are currently set in
stone. As an example, right now the # of max allowed outstanding HTLCs is
set in stone once the channel has opened. With the ability to also swap out
commitment _parameters_, we can start to experiment with flow-control like
ideas such as limiting a new channel peer to only a handful of HTLC slots,
which is then progressively increased based on "good behavior" (or the other
way around as well). Beyond just updating the channel parameters, it's also
possible to "change the rules" of a channel on the fly. An example of this
variant would be creating a new psuedo-type that implements a fee policy
other than "the initiator pays all fees".
# Protocol Changes
With the motivation/background set up, let's dig into some potential ways
the protocol can be modified to support this new meta-feature. As this
change is more of a meta-change, AFAICT, the amount of protocol changes
doesn't appear to be _too_ invasive ;). Most of the heavy lifting is done by
the wondrous TLV message field extensions.
## Explicit Channel Type Negotiation
Right now in the protocol, as new channel types are introduced (static key,
and now anchors) we add a new feature bit. If both nodes have the feature
bit set, then that new channel type is to be used. Notice how this is an
_implicit_ upgrade: there's no explicit signalling during the _funding_
process that a new channel type is to be used. This works OK, if there's one
major accepted "official" channel type, but not as new types are introduced
for specific use cases or applications. The implicit negotiation also makes
things a bit ambiguous at times. As an example, if both nodes have the
`static_remote_key` _and_ anchor outputs feature bit set, which channel type
should they open?
To resolve this existing ambiguity in the channel type negotiation, we'll
need to make the channel type used for funding _explicit_. Thankfully, we
recently modified the message format to be forwarding looking in order to
allow _TLV extensions_ to be added for all existing message types. A new
`channel_type` (type #???) TLV would be added which makes the channel type
used in funding explicit, with the existing feature bit advertisement system
being kept in place.
A draft of the changes in this area would be something like:
* `open_channel` and `accept_channel` gain a new `channel_type` TLV field.
* retroactively the OG commitment format is numbered as `channel_type=0`,
`static_remote_key`, as `channel_type=1`, and anchors as
`channel_type=2`
* if one receives an `open_channel`, or `accept_channel` message with an
unknown `channel_type`, they're to fail the funding flow
* nodes MUST NOT send an `open_channel` or `accept_channel` message with a
`channel_type` that isn't covered by their existing advertise feature
bits
* a mapping between feature bits and expected `channel_type` values would
then be added
* during funding negotiation, the _commitment_ type itself is parametrized
based on the `channel_type` value
* as we've all implemented `static_remote_key` commitments at this
point, I assume the necessary code-level abstractions are already
in-place
## Commitment State Machine Changes
With the changes described in the above section, we're now able to
explicitly identify _which_ channel type we want to enter a funding flow
for. As we add more types, there may not be a "default" type, so making this
process explicit is important to future exploration and extensibility. In
this section, we'll introduce a series of small changes to the `commit_sig`,
and `revoke_and_ack` messages which'll allow us to implement the "dynamic"
portion of this proposal.
Relying once again on the wondrous power of TLV message extensions we'll
carry over the `channel_type` TLV (just the name, # may be diff since this
is a diff message context) to the `commit_sig`, and `revoke_and_ack`
messages. The following guidelines on inclusion and interpretation would
then be applied:
* the `channel_type` specified on a given `commit_sig` message should be
the `channel_type` of the _new_ commitment being _created_
* when receiving a `commit_sig` with a `channel_type` that differs from
the `channel_type` of one's on revoked commitment:
* if the `channel_type` is unknown (or the `channel_type` transition
isn't allowed or defined), then the _p2p_ connection should be
aborted
* otherwise, using the `channel_type` as a parameter for commitment
transaction construction, a new commitment adhering to the rules of
the `channel_type` should be constructed
* the `channel_type` sent in the `revoke_and_ack` message should be the
`channel_type` of the commitment that's being _revoked_
With the above new rules, let's say Alice and Bob upgrade to new versions of
their LN software that support a new channel type `1`, while they're on
channel type `0`. Either triggered automatically, or manually (by either
side), the commitment flow would look something like:
1. sig_c_1 ->
2. <- revoke_c_0
3. <- sig_c_1
4. revoke_c_0 ->
By exchanging 4 messages, both sides are able to upgrade to a new commitment
format. However, one issue with the above flow is that it currently isn't
allowed by the spec, since we disallow sending a `commit_sig` message that
doesn't cover any updates. If we end up going with this route, then we'd
have to relax that constraint to something like:
* an empty `commit_sig` message (one that covers no updates) is
disallowed, unless the `commit_sig` has a `channel_type`, `c_n` that
differs from the channel type of the prior commitment, `c_n-1`.
It would then be up to _new protocol extension documents_ to define _how_ to
construct those new channel types, and also any changes to the on-chain
handling that are required by those channel types. Also certain transitions
may be disallowed. As an example, implementations may want to prevent a user
from going back to the non-static remote key channels from the
`static_remote_key` format.
In order to prepare for these changes, implementations need to be able to
handle "holding" unrevoked commitments of heterogeneous types, as if either
of them hit the chain, they'll need to be able to resolve all contracts
properly.
An alternative to attaching the `channel_type` message to the `commit_sig`
and having _that_ kick off the commitment upgrade, we could instead possibly
add a _new_ update message (like `update_fee`) to make the process more
explicit. In either case, we may want to restrict things a bit by only
allowing the initiator to trigger a commitment format update.
## Further Channel Type Parameterization
With the above protocol sketch, we're able to handle "simple" upgrades,
where some/all of the parameters of the channel are hard coded and/or have
been negotiated out of band. More complex channel types may require the
exchange of additional keys or parameters which need to be known in order to
reconstruct the _new_ commitment format and verify the new signature. This
additional information can possibly be piggy-backed on the `commit_sig`
message in the form of a _nested TLV_ type:
* a msg-local TLV type `channel_params` is added
* the value of this TLV type is a nested TLV blob, that contains all the
necessary fields and values needed to properly handle the channel switch
over
Returning to the flow control example earlier in this post, the new limits
for `max_allowed_htlcs`, can be included in this blob. More complex channel
types could send information such as new keys to be used, or other
parameters
that govern how a commitment is to be constructed (like the size of the
anchor outputs).
# Conclusion
Summarizing, in this post we've proposed a series of protocol modifications
(with TLV fields doing most of the heavy lifting) that allows LN nodes to
upgrade their commitments _without any on-chain_ transactions. Depending on
the architecture of a node, new types may even be added/removed without
actual downtime.
The ability to upgrade commitments after the fact lessens the pressure of
newer possibly experimental channel types to get all the details (and
explore the rather large design space) correct up front. Once Taproot rolls
around, we can simply update the funding output, roll that out, then
continue to hash out the details on the possibly new channel type(s) that
take advantage of all the new tools.
Allowing channel types to be upgraded on the fly let's us update the network
to the new _safer_ channel types in a de-synchronized, distributed manner
that doesn't require any on-chain transactions! Dynamic commitments as a
whole also creates another point of extensibility in the protocol so we can
start to explore all the variants on channels as we know them that exist.
I'm keen to gather feedback, as internally for `lnd` we've committed to
exploring this direction so we can start to upgrade _all_ the existing
lnd-involved channels to the new anchor commitment format, which is the
safest format yet.
[1]: https://eprint.iacr.org/2020/476
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200720/67ee7ab2/attachment.html>

2023-06-09 13:00:27

- reply

📅 Original date posted:2020-06-21
📝 Original message:
Hi Rene,
IMO this is mostly mitigated by anchor commitments. The impact of this
attack is predicated on the "victim" paying 5x on-chain fees (for their
confirmation target) to sweep all their HTLCs. Anchor commitments let the
initiator of the channel select a very low starting fee (just enough to get
into the mempool), and also let them actually bump the fees of second-level
HTLC transactions.
In addition to being able to pay much lower fees ("just enough" to get into
the chain), anchor commitments allow second-level HTLC _aggregation_, This
means that for HTLCs with the same expiry height, a peer is able to _batch_
them all into a single transaction, further saving on fees.
lnd shipped with a form of anchor commitments in our past major release
(v0.10.0-beta). In that release the format is opt in, and is enabled with a
startup command-line flag. For 0.11, we're planning on making this the
default commitment type, giving all users that update the ability to
_finally_ have proper fee control of their commitments, and second-level
HTLC transactions.
> The direction of HTLCs are chosen so that the amount is taken from the
> `to_remote` output of the attacker (obviously on the victims side it will
> be the `to_local` output)
One relevant detail here is that if the attacker is to attempt this with
minimal setup, then they'll need to be the ones that open the channel.
Since they're the initiator, they'll actually be the ones paying the fees
rendering this attempt moot.
Alternatively, they could use something like Lightning Loop to gain the
_outbound_ bandwidth (Loop In) needed to attempt this attack (using inbound
opened channels, but they'll need to pay for that bandwidth, adding a
further cost to the attack. Not to mention that they'll need to pay on-chain
fees to sweep the HTLCs they created themselves. In short, this attack isn't
costless as they'll need to acquire outbound liquidity for an incoming
channel, and also need to pay fees independent of the "success" of their
attack.
> I quote from BOLT 02 which suggests a buffer of a factor of 5
I'm not sure how many implementations actually follow this in practice.
FWIW, lnd doesn't.
> Additionally the victim will also have to swipe all offered HTLCs (which
> will be additional costs but could be done once the fees came down) so we
> neglect them.
No, the attacker is the one that needs to sweep these HTLCs, since they
offered them. This adds to their costs.
> Knowing that this will happen and that the victim has to spend those funds
> (publishing old state obviously does not work!) the attacker has a time
> window to blackmail the victim outside of the lightning network protocol
I don't think this is always the case. Depending on the minimum HTLC
settings in the channel (another mitigation), and the distribution of funds
in the channel, it may be the case that the victim doesn't have any funds in
the channel at all (everything was on the attacker's side). In that case,
the "victim" doesn't really care if this channel is clogged up as they
really have no stake in this channel.
> Also you might say that an attacker needs many incoming channels to
> execute this attack. This can be achieved by gaming the autopilot.
As mentioned above, gaining purely incoming channels doesn't allow the
attacker to launch this attack, as they'll be unable to _send out_ from any
of those channels.
> 1. The current solution is to just not use up the max value of htlc's.
> Eclaire and c-lightning by default only use up to 30 htlcs.
IMO, this isn't a solution. Lowering the max number of HTLCs in-flight just
makes it easier (lowers the capital costs) to jam a channel. The authors of
the paper you linked have another paper exploring these types of attacks
[1], and cite the _hard coded_ limit of 483 HTLCS as an enabling factor.
> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core
I think you're misinterpreting this PR, but see my first paragraph about
anchor commitments which that PR enables.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
Anchors let you do this ;)
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts.
This is already how "dust HTLCs" are calculated. The amount remaining from
the HTLC after it pays for its second-level transaction needs to be above
dust. This policy can be asymmetric across commitments in the channel.
> 5. Somehow be able to aggregate htlc's.
Anchors let you do this on the transaction level (MIMO 2nd level HTLC
transactions).
I hope other implementations join lnd in deploying anchor commitments to
mitigate nuisance attacks like this, and _finally_ give users better fee
control for channels and any off-chain contracts within those channels.
BTW, the "Flood & Loot" paper you linked mentions anchor commitments as a
solution towards the end of the paper. However, they erroneously state that
an attacker would be able to spend their HTLC with a _non replaceable_
transaction. This isn't the case since all redemption paths are encumbered
with a CSV delay of 1. This delay forces the attacker to spend the output
with an input that has a non-final sequence, meaning the transaction is
RBF-able.
[1]: https://arxiv.org/abs/2002.06564
-- Laolu
On Wed, Jun 17, 2020 at 3:30 AM René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hey everyone and of course good morning ZmnSCPxj (:
>
> about 11 months ago I discovered a potential blackmail attack with HTLCs
> after answering this question on stack exchange (c.f
> https://bitcoin.stackexchange.com/questions/89232/why-is-my-spendable-msat-much-lower-than-msatoshi-to-us/89235#89235).
> This attack is similar to the one that was possible with tx malleability on
> the funding transaction without the segwit upgrade (c.f.
> https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf&page=126).
> Meaning an attacker can force a victim to lose money and use this fact to
> blackmail the victim, to potentially gain / steal some of the lost funds.
>
> TL;DR:
> =====
> * Depending on the circumstances this attack allows an attacker to make
> channel partners lose a substantial amount of BTC without substantial costs
> for the attacker.
> * Depending on the exact circumstances this could be for example ~0.15
> BTC. In particular it demonstrates why opening a channel is not an entirely
> trustless activity.
> * The attacker will reliably only be able to force the victim to lose this
> amount of Bitcoin.
> * It is not clear how in practice the attacker could gain this amount or
> parts of it as this would involve not only game theory but also rather
> quick communication between attacker and victim and customized Lightning
> nodes which at least for the victim would be unlikely to exist.
> * None of the suggested fixes seems to be satisfying though the current
> solution of lowering the maximum amount of HTLCs that can concurrently be
> in flight seems to be a reasonable start for now.
>
>
> Timeline on Disclosure
> =================
> I have disclosed this attack on Sunday July 21st 2019 to Fabrice Drouin
> (and shortly after to Christian Decker) in a phone call who in turn has
> discussed it with people from the other implementations. From his feedback
> I understood that people working on implementations have been more or less
> aware of the possibility of this attack. Fabrice also mentioned that he
> believed implementations currently try to mitigate this by setting low
> limits of allowed / accepted HTLCs in flight. However at that time this was
> only true for e-clair. It is now also true for c-lightning and as far as I
> know still not true for lnd. Fabrice said that the people he talked to have
> suggested that I should eventually describe the attack in public to raise
> awareness (also from the group of node operators) for the problems related
> to this attack. He also suggested that - if I wanted to - I should update
> the rfc with recommendations and warnings. While I already have in mind
> how to change the rfc I wanted to start the discussion first. Maybe some
> people find better fixes than just a warning that I have in mind. So far I
> didn't do anything because I wanted to also give lnd the chance to handle
> the problem.
>
> There are two reasons I disclose this attack today:
> 1.) I think almost 1 year is enough time to do something about it. The
> only implementation that afaik didn't yet is lnd (see below) but I got
> roasbeefs ok last week to go ahead and publish the attack anyway so that we
> can have a broader discussion on mitigation strategies.
> 2.) The attack seems actually very similar to the one described in the
> "Flood & Loot: A Systemic Attack On The Lightning Network" - paper which
> came out 2 days ago (c.f.: https://arxiv.org/abs/2006.08513 ). I believe
> any person reading that paper will understand the possibility of the attack
> that I describe anyway so I believe it is now more or less public anyway
> and thus time for an open / public discussion.
>
> The main difference between the two attacks (if I understand this novel
> paper correctly) is: In the "flood and loot"-attack one tries to steal the
> HTLC output of the victims. Where in the "flood and blackmail"-attack that
> I describe I try to to force the victim to lose almost all its funds due to
> high on chain fees (Which I could use to blackmail the victim)
>
> Description of the attack
> ===================
> Let us assume the victim has funded a channel with an attacker meaning it
> will have to pay the fees for the commitment transaction in case of a force
> close.
>
> During a fee spike (let us assume fee estimators suggest 150 sat / byte)
> the attacker spams this channel with the maximum possible amount of HTLCs
> that the protocol allows. The HTLCs can be of a small value but need to be
> bigger than the dust limit so that additional outputs are actually added to
> the commitment transaction which makes it quite large in Bytes. According
> to the BOLTs these are 483 additional outputs to the commitment
> transaction.
> The direction of HTLCs are chosen so that the amount is taken from the
> `to_remote` output of the attacker (obviously on the victims side it will
> be the `to_local` output) For the actual attack it does not matter in which
> direction the HTLCs are spammed but economically the direction I propose
> makes even more sense for the attacker and can be achieved with circular
> onions.
>
> The attacked channel partner will happily - according to the protocol -
> use a higher fee than the current fee rate. I quote from BOLT 02 which
> suggests a buffer of a factor of 5
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee:
>
>
> > The node responsible for paying the Bitcoin fee [...] SHOULD send
> update_fee to ensure the current fee rate is sufficient (by a significant
> margin) for timely processing of the commitment transaction. [...] Given
> the variance in fees, and the fact that the transaction may be spent in the
> future, it's a good idea for the fee payer to keep a good margin (say 5x
> the expected fee requirement); but, due to differing methods of fee
> estimation, an exact value is not specified.
>
> This overpayment of fees will result in 750 sat / byte for this fee spike
> scenario. This is by the way not completely unrealistic [I recently opened
> a channel with 2.56 sat / byte (c.f.:
> https://www.smartbit.com.au/tx/c0ac6cfe15e0d0c921362ab9fad998a8a8e16cd8d9d4159487dd69141ea2b9b0)
> and the channel was force closed a couple minutes later due to an
> implementation bug resulting in fees of 101.17 sat / byte (c.f.:
> https://www.smartbit.com.au/tx/e32135315ec147bb27f771b2e15c7178ea573afd16cd4970bf814c9b18bc46e3
> )
>
> As far as I understand the appendix of BOLT 03 offered HTLCs are 43 Byte
> in size (c.f.:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights)
> resulting in the following additional fees for the spammed commitment
> transaction:
>
> fee (for 483 htlcs) = 483 * 43 byte * 750 sat / byte = 15576750 sat =
> 0.1557675 BTC
>
> Additionally the victim will also have to swipe all offered HTLCs (which
> will be additional costs but could be done once the fees came down) so we
> neglect them.
>
> Once all HTLCs are set up the attacker will stop signing commitment
> transactions. In the beginning this is not suspicious as the HTLCs will
> take some time to settle anyway. But also when fees go down and the victim
> who funded the channel wants to update the fees the attacker will just not
> be responsive. Eventually the victim will dare to force close the channel
> with all those expensive HTLCs.
>
> Knowing that this will happen and that the victim has to spend those funds
> (publishing old state obviously does not work!) the attacker has a time
> window to blackmail the victim outside of the lightning network protocol:
> "Either you will pay those 0.1557675 BTC of fees or we will collaboratively
> close the channel but that will cost you part of the amount you lost." Game
> theory suggests that the attacker will be able to claim the major fraction
> of the BTC (c.f. https://en.wikipedia.org/wiki/Ultimatum_game that are
> frozen in tx fees as the victim effectively already has lost that money and
> can only gain something back.
>
>
> Thoughts
> =======
> You might say that the blackmail part of this attack is unrealistic as the
> blackmailing person will not have enough time to successfully do the
> blackmail as the channel that is not operational will fail.
>
> 1.) The only thing that lightning nodes might do is a fee update as the
> htlcs stuffed the channel so I believe there is actually some time to
> contact the victim.
> 2.) What if the attacker is a mining pool who is just interested in high
> fees who does not even need to do the blackmailing stuff but will just
> force close the channel once the htlcs are set up?
> 3.) The attacker might not even be interested in blackmailing the victim.
> The attacker could just be interested in harming the victim. Though it
> might certainly be a challenge to target a specific victim and trick it
> into opening a channel with an attacker.
>
> Also you might say that an attacker needs many incoming channels to
> execute this attack. This can be achieved by gaming the autopilot. an
> attacker can start by creating many channels making him a highly likely
> channel partner for autopilot users (who will also fund the channel). Such
> a highly connected node might also be interesting for non autopilot users.
>
> Implementations
> ============
>
> I looked at the code myself. I hope I do oversee things but to me it looks
> like only eclaire was somehow mitigating this attack from being exploited.
> (by a default config of 30 accepted htlcs which will protect the average
> user and is much lower than the 483) and c-lightning has merged a patch
> from me which I provided after I disclosed the attack:
>
> ## clightning:
>
> c-lightning did not by default set a hard cap on htlcs before version
> 0.7.2 but then merged my patch
> https://github.com/ElementsProject/lightning/pull/2858 which tried to
> resemble the eclair defaults
>
> ## eclaire:
>
> the max accepted htlc value per channel is set as a constant to 483 which
> follows the recommendation of the BOLTs:
>
> https://github.com/ACINQ/eclair/blob/e62adf2deae213d2cd0f2a6874227dcfc57880ae/eclair-core/src/main/scala/fr/acinq/eclair/channel/Channel.scala#L52
>
> The value is tested against at:
>
> https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L99
>
> and:
>
> https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L132
>
> and:
>
> https://github.com/ACINQ/eclair/blob/93d9369f900766171f2ddf579e8b12e28d8f0d25/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L154
>
> However the default config file specifies a maximum amount of 30 accepted
> htlcs at:
>
> https://github.com/ACINQ/eclair/blob/9afb26e09c69dd5d6a14732baf5dcdf2b7a9142b/eclair-core/src/main/resources/reference.conf#L62
>
>
> ## lnd
> It seems like lnd did not and last time I checked (maybe I oversaw
> something) does not set a hard cap on htlcs by default. The way how I
> understand the code they allow up to 483 htlcs by default:
>
> The test when adding an htlc if it is beyond the maximum accepted values
> is here:
>
> https://github.com/lightningnetwork/lnd/blob/970d7604071baae227db42d4665ef9d1b56988e8/lnwallet/channel.go#L3795
>
> the default configuration seems to be here (and in the most recent commit
> the line still exists):
>
> https://github.com/lightningnetwork/lnd/blob/8b04cfbf12f460853e8c55611cd1bba21b1510ef/input/size.go#L187
>
> the software will accept up to 483 htlcs according to this line:
>
> https://github.com/lightningnetwork/lnd/blob/111cbeaa990cba78563d6cc8c19b152e2d3042f6/lnwallet/reservation.go#L314
>
> I could not find any spec lower than that in the suggested sample config
> at:
> https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf
>
>
> Ideas for Fixes
> ===========
>
> I am completely unhappy with each of the following ideas. I hope you will
> come up with smarter solutions. I believe the solution is not obvious. Thus
> I thought it makes sense in the brainstorm phase to even post some ideas
> with obvious drawbacks.
>
> 1. The current solution is to just not use up the max value of
> htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core (c.f.
> https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get
> it correctly with that we could always have low fees and ask the person who
> want to claim their outputs to pay fees. This excludes overpayment and
> could happen at a later stage when fees are not spiked. Still the victim
> who offered the htlcs would have to spend those outputs at some time.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts. This would
> at least make the attack expensive as the attacker would have to bind a lot
> of liquidity.
> 5. Somehow be able to aggregate htlc's. In a world where we use payment
> points instead of preimages we might be able to do so. It would be really
> cool if separate HTLC's could be combined to 1 single output. I played
> around a little bit but I have not come up with a scheme that is more
> compact in all cases. Thus I just threw in the idea.
> 6. Split onchain fees differently (now the attacker would also lose fees
> by conducting this attack) - No I don't want to start yet another fee
> bikeshadding debate. (In particular I believe that a different split of
> fees might make the Flood & Loot attack economically more viable which
> relies on the same principle)
>
> Independently I think we should have a hint in our readme file about where
> and how people can disclose attacks and vulnerabilities. Implementations
> have this but the BOLTs do not.
>
> with kind regards Rene
>
> --
>
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
> _______________________________________________
> 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/20200621/992826d6/attachment-0001.html>

2023-06-09 13:00:26

- reply

📅 Original date posted:2020-06-21
📝 Original message:
Hi Jeremy,
The up-front costs can be further mitigated even without something like CTV
(which makes things more efficient) by adding a layer of in-direction w.r.t
how
HTLCs are manifested within the commitment transactions. To do this, we add
a
new 2-of-2 multi-sig output (an HTLC indirect block) to the commitment
transactions. This is then spent by a new transaction (the HTLC block) that
actually manifests (creates the HTLC outputs) the HTLCs.
With this change, the cost to have a commitment be mined in the chain is now
_independent of the number of HTLCs in the channel_. In the past I've called
this construction "coupe commitments" (lol).
Other flavors of this technique are possible as well, allowing both sides to
craft varying HTLC indirection trees (double layers of indirection are
possible, etc) which may factor in traits like HTLC expiration time (HTLCs
that
expire later are further down in the tree).
Something like CTV does indeed make this technique more powerful+efficient
as
it allows one to succinctly commit to all the relevant desirable
combinations
of HTLC indirect blocks, and HTLC fan-out transactions.
-- Laolu
On Sat, Jun 20, 2020 at 4:14 PM Jeremy <jlrubin at mit.edu> wrote:
> I am not steeped enough in Lightning Protocol issues to get the full
> design space, but I'm fairly certain BIP-119 Congestion Control trees would
> help with this issue.
>
> You can bucket a tree by doing a histogram of HTLC size, so that all small
> HTLCs live in a common CTV subtree and don't interfere with higher value
> HTLCs. You can also play with sequencing to prevent those HTLCs from
> getting longchains in the mempool until they're above a certain value.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Rene,
>>
>> Thanks for disclosing this vulnerability,
>>
>> I think this blackmail scenario holds but sadly there is a lower scenario.
>>
>> Both "Flood & Loot" and your blackmail attack rely on `update_fee`
>> mechanism and unbounded commitment transaction size inflation. Though the
>> first to provoke block congestion and yours to lockdown in-flight fees as
>> funds hostage situation.
>>
>> > 1. The current solution is to just not use up the max value of
>> htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
>>
>> As of today, yes I would recommend capping commitment size both for
>> ensuring competitive propagation/block selection and limiting HTLC exposure.
>>
>> > 2. Probably the best fix (not sure if I understand the consequences
>> correctly) is coming from this PR to bitcoin core (c.f.
>> https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get
>> it correctly with that we could always have low fees and ask the person who
>> want to claim their outputs to pay fees. This excludes overpayment and
>> could happen at a later stage when fees are not spiked. Still the victim
>> who offered the htlcs would have to spend those outputs at some time.
>>
>> It's a bit more complex, carve-out output, even combined with anchor
>> output support on the LN-side won't protect against different flavors of
>> pinning. I invite you to go through logs of past 2 LN dev meetings.
>>
>> > 3. Don't overpay fees in commitment transactions. We can't foresee the
>> future anyway
>>
>> Once 2. is well-addressed we may deprecate `update_fee`.
>>
>> > 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
>> value (like we do with sub dust amounts and sub satoshi amounts. This would
>> at least make the attack expensive as the attacker would have to bind a lot
>> of liquidity.
>>
>> Ideally we want dust_limit to be dynamic, dust cap should be based on
>> HTLC economic value, feerate of its output, feerate of HTLC-transaction,
>> feerate estimation of any CPFP to bump it. I think that's kind of worthy to
>> do once we solved 3. and 4
>>
>> > 5. Somehow be able to aggregate htlc's. In a world where we use payment
>> points instead of preimages we might be able to do so. It would be really
>> cool if separate HTLC's could be combined to 1 single output. I played
>> around a little bit but I have not come up with a scheme that is more
>> compact in all cases. Thus I just threw in the idea.
>>
>> Yes we may encode all HTLC in some Taproot tree in the future. There are
>> some wrinkles but for a high-level theoretical construction see my post on
>> CoinPool.
>>
>> > 6. Split onchain fees differently (now the attacker would also lose
>> fees by conducting this attack) - No I don't want to start yet another fee
>> bikeshadding debate. (In particular I believe that a different split of
>> fees might make the Flood & Loot attack economically more viable which
>> relies on the same principle)
>>
>> Likely a bit more of fee bikeshedding is something we have to do to make
>> LN secure... Switching fee from pre-committed ones to a single-party,
>> dynamic one.
>>
>> > Independently I think we should have a hint in our readme file about
>> where and how people can disclose attacks and vulnerabilities.
>> Implementations have this but the BOLTs do not.
>>
>> I 100% agree, that's exactly
>> https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
>> your feedback :)
>>
>> Cheers,
>>
>> Antoine
>>
>> Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
>> lightning-dev at lists.linuxfoundation.org> a écrit :
>>
>>>
>>> Good morning all,
>>>
>>> >
>>> > Fee futures could help against this.
>>> > I remember writing about this some time ago but cannot find where (not
>>> sure if it was in lightning-dev or bitcoin-dev).
>>>
>>> `harding` found it:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>>>
>>> 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
>>
> _______________________________________________
> 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/20200621/934a081d/attachment.html>

2023-06-09 12:59:54

- reply

📅 Original date posted:2020-04-23
📝 Original message:
(this may be kind of off-topic, more about DLC deployment than PTLCs
themselves)
>From my PoV, new technologies aren't what has held back DLC deployment to
this date since the paper was originally released. Tadge has had working
code than can be deployed today for some time now, and other parties like
DG-Lab have created full-fledge demos with the system working end to end.
Instead, the real impediment has been the bootstrapping of the oracles
which the scheme critically depends upon.
Without oracles, none of it really works. Although, it's also the case that
there're measures to prevent the oracles from equivocating (reporting two
conflicting prices/events for a particular instance), bootstrapping a new
oracle still requires a very high degree of trust as they can lie or report
incorrect data. As a result, actually deploying an oracle for a system like
this is tricky business, as it's a trusted centralized entity, so it will
run into all the normal meatspace/legal/operational risk that any trusted
centralized service would encounter.
Earlier today, Coinbase announced that they were releasing a new price
oracle for the ETH ecosystem [1]. This caught my attention as one can
imagine, that it would be even simpler for them to deploy a DLC oracle which
exports an API to obtain signed prices/events. As an existing large company
in the space (depending on who you talk to), they're a trusted entity, which
has earned a good reputation over the years (solving this
bootstrapping/trust issue). If they do eventually grow the service to also
encompass this use case, then it enables a number of possibilities, as
there's still a ton of value in just base DLC-specific channels (or one off
contracts), without all the fancy barrier escrow scriptless scipts swappy
swap swap stuff.
-- Laolu
[1]:
https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068
On Thu, Apr 23, 2020 at 7:52 AM Nadav Kohen <nadav at suredbits.com> wrote:
> Hi Laolu,
>
> Thanks for the response :)
>
> I agree that some more framing probably would have been good to have in my
> update.
>
> First, I want to clarify that my intention is not to implement a
> PTLC-based lightning network on top of ECDSA adaptor signatures, as I do
> believe that using Schnorr will be superior, but rather I wish to get some
> PoC sandbox with which to start implementing and testing out the long list
> of currently theoretical proposals surrounding PTLCs, most of which are
> implementation agnostic (to a degree anyway). I think it would be super
> beneficial to have more fleshed out with respect to what some challenges of
> a Payment Point LN are going to be than we understand now, before Schnorr
> is implemented and it is time to commit to some PTLC scheme for real.
>
> Second, I agree that I've probably understated somewhat the changes that
> will be needed in most implementations as I was mostly thinking about what
> would need to change in the BOLTs, which does actually seem relatively
> minimal (although as you mention, these minimal changes to the BOLTs do
> trigger large changes in many implementations). Also, good point on how
> BOLT 11 (invoicing) will have to be altered as well, must've slipped my
> mind.
>
> Best,
> Nadav
>
> On Wed, Apr 22, 2020 at 8:17 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> Hi Nadav,
>>
>> Thanks for the updates! Super cool to see this concept continue to evolve
>> and integrate new technologies as they pop up.
>>
>> > I believe this would only require a few changes to existing nodes:
>>
>> Rather than a "few changes", this would to date be the largest
>> network-level
>> update undertaken to the Lightning Network thus far. In the past, we
>> rolled
>> out the new onion blob format (which enables changes like this), but none
>> of
>> the intermediate nodes actually need to modify their behavior. New payment
>> types like MPP+AMP only needed the _end points_ to update making this an
>> end-to-end update that has been rolled out so far in a de-synchronized
>> manner.
>>
>> Re-phrasing deploying this requires changes to: the core channel state
>> machine (the protocol we use to make commitment updates), HTLC scripts,
>> on-chain HTLC handling and resolution, path finding algorithms (to only
>> see
>> out the new PTLC-enabled nodes), invoice changes and onion blob
>> processing.
>> I'd caution against underestimating how long all of this will take in
>> practice, and the degree of synchronization required to pull it all off
>> properly.
>>
>> For a few years now the question we've all been pondering is: do we wait
>> for
>> scnhorr to roll out multi-hop locks, or just use the latest ECDSA based
>> technique? As dual deployment is compatible (we can make the onion blobs
>> for
>> both types the same), a path has always existed to first roll out with the
>> latest ECDSA based technique then follow up later to roll out the schnorr
>> version as well. However there's also a risk here as depending on how
>> quickly things can be rolled out, schnorr may become available
>> mid-development, which would possibly cause us to reconsider the ECDSA
>> path
>> and have the network purely use scnhorr to make things nice and uniform.
>>
>> Zooming out for a bit, the solution space of "how channels can look post
>> scriptless-scripts + taproot" is rather large [1], and the addition of
>> this
>> new technique allows for an even larger set of deployment possibilities.
>> This latest ECDSA variant is much simpler than the prior ones (which had a
>> few rounds of more involved ZKPs), but since it still uses OP_CMS, it
>> can't
>> be used to modify the funding output.
>>
>> [1]:
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
>>
>> -- Laolu
>>
>>
>> On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen <nadav at suredbits.com> wrote:
>>
>>> Hello all,
>>>
>>> I'd like to give an update on the current state of thinking and coding
>>> surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock
>>> Contracts (PTLCs) (aka Payment Hashes -> Payment Points) in hopes of
>>> sparking interest, discussion, development, etc.
>>>
>>>
>>> We Want Payment Points!
>>> -----------------------
>>>
>>> Using point-locks (in PTLCs) instead of hash-locks (in HTLCs) for
>>> lightning payments is an all around improvement. HTLCs require the use of
>>> the same hash across payment routes (barring fancy ZKPs which are inferior
>>> to PTLCs) while PTLCs allow for payment de-correlation along routes. For an
>>> introduction to the topic, see
>>> https://suredbits.com/payment-points-part-1/.
>>>
>>> In addition to improving privacy in this way and protecting against
>>> wormhole attacks, PTLC-based lightning channels open the door to a large
>>> variety of interesting applications that cannot be accomplished with HTLCs:
>>>
>>> Stuckless (retry-able) Payments with proof of payment (
>>> https://suredbits.com/payment-points-part-2-stuckless-payments/)
>>>
>>> Escrow contracts over Lightning (
>>> https://suredbits.com/payment-points-part-3-escrow-contracts/)
>>>
>>> High/DLOG AMP (
>>> https://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40
>>> )
>>>
>>> Stuckless + AMP (an improvement on Boomerang) (
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html
>>> )
>>>
>>> Pay-for-signature (
>>> https://suredbits.com/payment-points-part-4-selling-signatures/)
>>>
>>> Pay-for-commitment (
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html
>>> )
>>>
>>> Monotonic access structures on payment completion (
>>> https://suredbits.com/payment-points-monotone-access-structures/)
>>>
>>> Ideal Barrier Escrow Implementation (
>>> https://suredbits.com/payment-points-implementing-barrier-escrows/)
>>>
>>> And allowing for Barrier Escrows, we can even have
>>>
>>> Atomic multi-payment setup (
>>> https://suredbits.com/payment-points-and-barrier-escrows/)
>>>
>>> Lightning Discreet Log Contract (
>>> https://suredbits.com/discreet-log-contracts-on-lightning-network/)
>>>
>>> Atomic multi-payment update (
>>> https://suredbits.com/updating-and-transferring-lightning-payments/)
>>>
>>> Lightning Discreet Log Contract Novation/Transfer (
>>> https://suredbits.com/transferring-lightning-dlcs/)
>>>
>>> There are likely even more things that can be done with Payment Points
>>> so make sure to respond if I've missed any known ones.
>>>
>>>
>>> How Do We Get Payment Points?
>>> -----------------------------
>>>
>>> Eventually, once we have Taproot, we can use 2p-Schnorr adaptor
>>> signatures in Lightning channels. For a detailed thread by ZmnSCPxj, see
>>> here
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
>>>
>>> In the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor
>>> sigs (https://github.com/LLFourn/one-time-VES) which can be paired with
>>> OP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!
>>>
>>> Nickler has implemented this in a branch of secp256k1 (
>>> https://github.com/jonasnick/secp256k1/pull/14) and I have implemented
>>> it in Bouncy Castle in Bitcoin-S with some testing against this branch (
>>> https://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note
>>> that as nickler states on his PR, "IT IS EXTREMELY DANGEROUS AND RECKLESS
>>> TO USE THIS MODULE IN PRODUCTION. DON'T!"
>>>
>>> A demo of an on-chain PTLC I executed using nickler's implementation on
>>> the backend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno
>>>
>>> And waxwing did a lovely write-up about the crypto itself
>>> https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/
>>>
>>> I would be very interested in having a fork of (at least) one lightning
>>> implementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node
>>> with which we can test and play with the plethora of PTLC-based proposals
>>> above.
>>>
>>> I believe this would only require a few changes to existing nodes:
>>>
>>> 1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather
>>> than a 32 byte hash. Additionally the onion's hop_data will contain a 32
>>> byte scalar tweak for each hop. As per [link multi-hop locks]. The last
>>> hop_data will instead include a 32 byte scalar equal to the sum of all
>>> tweaks.
>>>
>>> 2) commitment_signed will have 162 byte adaptor ptlc_signatures rather
>>> than valid (71/72 byte) ECDSA signatures on PTLC-success transactions.
>>>
>>> 3) The in-flight outputs on the commitment transaction itself become a
>>> little simpler as we no longer need to explicitly check the payment
>>> pre-image against a hash. Instead, delete all instances of "OP_HASH160
>>> <RIPEMD160(payment_hash)> OP_EQUALVERIFY" in the scripts (leaving the rest
>>> the same) and require no pre-image in the witness, only a valid signature.
>>> The pre-image check is implicitly enforced by the <remoteptlc_sig> witness
>>> since only an adaptor signature was provided by remote so that the payment
>>> pre-image is required to create the valid signature (from which the
>>> pre-image can be then deduced by comparing adaptor and valid signatures).
>>>
>>> If I've missed any other changes that need to happen, do respond with
>>> them!
>>>
>>> I hope that as a community we can work towards having a PTLC-based
>>> Lightning Network that is safe and stable as soon as possible, and so I
>>> encourage further thinking, development and expirementation with PTLCs now
>>> so that when Taproot is finally at our disposal we can cleanly start moving
>>> towards a more ideal Lightning :)
>>>
>>> Best,
>>> Nadav
>>> _______________________________________________
>>> 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/20200423/61661e72/attachment-0001.html>

2023-06-09 12:59:52

- reply

📅 Original date posted:2020-04-22
📝 Original message:
Hi Nadav,
Thanks for the updates! Super cool to see this concept continue to evolve
and integrate new technologies as they pop up.
> I believe this would only require a few changes to existing nodes:
Rather than a "few changes", this would to date be the largest network-level
update undertaken to the Lightning Network thus far. In the past, we rolled
out the new onion blob format (which enables changes like this), but none of
the intermediate nodes actually need to modify their behavior. New payment
types like MPP+AMP only needed the _end points_ to update making this an
end-to-end update that has been rolled out so far in a de-synchronized
manner.
Re-phrasing deploying this requires changes to: the core channel state
machine (the protocol we use to make commitment updates), HTLC scripts,
on-chain HTLC handling and resolution, path finding algorithms (to only see
out the new PTLC-enabled nodes), invoice changes and onion blob processing.
I'd caution against underestimating how long all of this will take in
practice, and the degree of synchronization required to pull it all off
properly.
For a few years now the question we've all been pondering is: do we wait for
scnhorr to roll out multi-hop locks, or just use the latest ECDSA based
technique? As dual deployment is compatible (we can make the onion blobs for
both types the same), a path has always existed to first roll out with the
latest ECDSA based technique then follow up later to roll out the schnorr
version as well. However there's also a risk here as depending on how
quickly things can be rolled out, schnorr may become available
mid-development, which would possibly cause us to reconsider the ECDSA path
and have the network purely use scnhorr to make things nice and uniform.
Zooming out for a bit, the solution space of "how channels can look post
scriptless-scripts + taproot" is rather large [1], and the addition of this
new technique allows for an even larger set of deployment possibilities.
This latest ECDSA variant is much simpler than the prior ones (which had a
few rounds of more involved ZKPs), but since it still uses OP_CMS, it can't
be used to modify the funding output.
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
-- Laolu
On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen <nadav at suredbits.com> wrote:
> Hello all,
>
> I'd like to give an update on the current state of thinking and coding
> surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock
> Contracts (PTLCs) (aka Payment Hashes -> Payment Points) in hopes of
> sparking interest, discussion, development, etc.
>
>
> We Want Payment Points!
> -----------------------
>
> Using point-locks (in PTLCs) instead of hash-locks (in HTLCs) for
> lightning payments is an all around improvement. HTLCs require the use of
> the same hash across payment routes (barring fancy ZKPs which are inferior
> to PTLCs) while PTLCs allow for payment de-correlation along routes. For an
> introduction to the topic, see
> https://suredbits.com/payment-points-part-1/.
>
> In addition to improving privacy in this way and protecting against
> wormhole attacks, PTLC-based lightning channels open the door to a large
> variety of interesting applications that cannot be accomplished with HTLCs:
>
> Stuckless (retry-able) Payments with proof of payment (
> https://suredbits.com/payment-points-part-2-stuckless-payments/)
>
> Escrow contracts over Lightning (
> https://suredbits.com/payment-points-part-3-escrow-contracts/)
>
> High/DLOG AMP (
> https://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40
> )
>
> Stuckless + AMP (an improvement on Boomerang) (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html
> )
>
> Pay-for-signature (
> https://suredbits.com/payment-points-part-4-selling-signatures/)
>
> Pay-for-commitment (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html
> )
>
> Monotonic access structures on payment completion (
> https://suredbits.com/payment-points-monotone-access-structures/)
>
> Ideal Barrier Escrow Implementation (
> https://suredbits.com/payment-points-implementing-barrier-escrows/)
>
> And allowing for Barrier Escrows, we can even have
>
> Atomic multi-payment setup (
> https://suredbits.com/payment-points-and-barrier-escrows/)
>
> Lightning Discreet Log Contract (
> https://suredbits.com/discreet-log-contracts-on-lightning-network/)
>
> Atomic multi-payment update (
> https://suredbits.com/updating-and-transferring-lightning-payments/)
>
> Lightning Discreet Log Contract Novation/Transfer (
> https://suredbits.com/transferring-lightning-dlcs/)
>
> There are likely even more things that can be done with Payment Points so
> make sure to respond if I've missed any known ones.
>
>
> How Do We Get Payment Points?
> -----------------------------
>
> Eventually, once we have Taproot, we can use 2p-Schnorr adaptor signatures
> in Lightning channels. For a detailed thread by ZmnSCPxj, see here
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
>
> In the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor sigs
> (https://github.com/LLFourn/one-time-VES) which can be paired with
> OP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!
>
> Nickler has implemented this in a branch of secp256k1 (
> https://github.com/jonasnick/secp256k1/pull/14) and I have implemented it
> in Bouncy Castle in Bitcoin-S with some testing against this branch (
> https://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note
> that as nickler states on his PR, "IT IS EXTREMELY DANGEROUS AND RECKLESS
> TO USE THIS MODULE IN PRODUCTION. DON'T!"
>
> A demo of an on-chain PTLC I executed using nickler's implementation on
> the backend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno
>
> And waxwing did a lovely write-up about the crypto itself
> https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/
>
> I would be very interested in having a fork of (at least) one lightning
> implementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node
> with which we can test and play with the plethora of PTLC-based proposals
> above.
>
> I believe this would only require a few changes to existing nodes:
>
> 1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather
> than a 32 byte hash. Additionally the onion's hop_data will contain a 32
> byte scalar tweak for each hop. As per [link multi-hop locks]. The last
> hop_data will instead include a 32 byte scalar equal to the sum of all
> tweaks.
>
> 2) commitment_signed will have 162 byte adaptor ptlc_signatures rather
> than valid (71/72 byte) ECDSA signatures on PTLC-success transactions.
>
> 3) The in-flight outputs on the commitment transaction itself become a
> little simpler as we no longer need to explicitly check the payment
> pre-image against a hash. Instead, delete all instances of "OP_HASH160
> <RIPEMD160(payment_hash)> OP_EQUALVERIFY" in the scripts (leaving the rest
> the same) and require no pre-image in the witness, only a valid signature.
> The pre-image check is implicitly enforced by the <remoteptlc_sig> witness
> since only an adaptor signature was provided by remote so that the payment
> pre-image is required to create the valid signature (from which the
> pre-image can be then deduced by comparing adaptor and valid signatures).
>
> If I've missed any other changes that need to happen, do respond with them!
>
> I hope that as a community we can work towards having a PTLC-based
> Lightning Network that is safe and stable as soon as possible, and so I
> encourage further thinking, development and expirementation with PTLCs now
> so that when Taproot is finally at our disposal we can cleanly start moving
> towards a more ideal Lightning :)
>
> Best,
> Nadav
> _______________________________________________
> 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/20200422/9849bd91/attachment-0001.html>

2023-06-09 12:59:48

- reply

📅 Original date posted:2020-04-22
📝 Original message:
> Indeed, that is what I’m suggesting
Gotcha, if this is indeed what you're suggesting (all HTLC spends are now
2-of-2 multi-sig), then I think the modifications to the state machine I
sketched out in an earlier email are required. An exact construction which
achieves the requirements of "you can't broadcast until you have a secret
which I can obtain from the htlc sig for your commitment transaction, and my
secret is revealed with another swap", appears to be an open problem, atm.
Even if they're restricted in this fashion (must be a 1-in-1 out,
sighashall, fees are pre agreed upon), they can still spend that with a CPFP
(while still unconfirmed in the mempool) and create another heavy tree,
which puts us right back at the same bidding war scenario?
> There are a bunch of ways of doing pinning - just opting into RBF isn’t
> even close to enough.
Mhmm, there're other ways of doing pinning. But with anchors as is defined
in that spec PR, they're forced to spend with an RBF-replaceable
transaction, which means the party wishing to time things out can enter into
a bidding war. If the party trying to impeded things participates in this
progressive absolute fee increase, it's likely that the war terminates
with _one_ of them getting into the block, which seems to resolve
everything?
-- Laolu
On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
>
>
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
>
> > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> > braodcasted transactions, but instead to CPFP a maybe-broadcasted
> > transaction by sending a transaction which spends it and seeing if it is
> > accepted
>
> Sorry I still don't follow. By "we clearly need to go the other direction -
> all HTLC output spends need to be pre-signed.", you don't mean that the
> HTLC
> spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig
> covenant? If the other party isn't restricted w.r.t _how_ they can spend
> the
> output (non-rbf'd, ect), then I don't see how that addresses anything.
>
>
> Indeed, that is what I’m suggesting. Anchor output and all. One thing we
> could think about is only turning it on over a certain threshold, and
> having a separate “only-kinda-enforceable-on-chain-HTLC-in-flight” limit.
>
> Also see my mail elsewhere in the thread that the other party is actually
> forced to spend their HTLC output using an RBF-replaceable transaction.
> With
> that, I think we're all good here? In the end both sides have the ability
> to
> raise the fee rate of their spending transactions with the highest winning.
> As long as one of them confirms within the CLTV-delta, then everyone is
> made whole.
>
>
> It does seem like my cached recollection of RBF opt-in was incorrect but
> please re-read the intro email. There are a bunch of ways of doing pinning
> - just opting into RBF isn’t even close to enough.
>
> [1]: https://github.com/bitcoin/bitcoin/pull/18191
>
>
> On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> A few replies inline.
>>
>> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
>> > Hi Matt,
>> >
>> >
>> >> While this is somewhat unintuitive, there are any number of good
>> anti-DoS
>> >> reasons for this, eg:
>> >
>> > None of these really strikes me as "good" reasons for this limitation,
>> which
>> > is at the root of this issue, and will also plague any more complex
>> Bitcoin
>> > contracts which rely on nested trees of transaction to confirm (CTV,
>> Duplex,
>> > channel factories, etc). Regarding the various (seemingly arbitrary)
>> package
>> > limits it's likely the case that any issues w.r.t computational
>> complexity
>> > that may arise when trying to calculate evictions can be ameliorated
>> with
>> > better choice of internal data structures.
>> >
>> > In the end, the simplest heuristic (accept the higher fee rate package)
>> side
>> > steps all these issues and is also the most economically rationale from
>> a
>> > miner's perspective. Why would one prefer a higher absolute fee package
>> > (which could be very large) over another package with a higher total
>> _fee
>> > rate_?
>>
>> This seems like a somewhat unnecessary drive-by insult of a project you
>> don't contribute to, but feel free to start with
>> a concrete suggestion here :).
>>
>> >> You'll note that B would be just fine if they had a way to safely
>> monitor the
>> >> global mempool, and while this seems like a prudent mitigation for
>> >> lightning implementations to deploy today, it is itself a quagmire of
>> >> complexity
>> >
>> > Is it really all that complex? Assuming we're talking about just
>> watching
>> > for a certain script template (the HTLC scipt) in the mempool to be
>> able to
>> > pull a pre-image as soon as possible. Early versions of lnd used the
>> mempool
>> > for commitment broadcast detection (which turned out to be a bad idea
>> so we
>> > removed it), but at a glance I don't see why watching the mempool is so
>> > complex.
>>
>> Because watching your own mempool is not guaranteed to work, and during
>> upgrade cycles that include changes to the
>> policy rules an attacker could exploit your upgraded/non-upgraded status
>> to perform the same attack.
>>
>> >> Further, this is a really obnoxious assumption to hoist onto lightning
>> >> nodes - having an active full node with an in-sync mempool is a lot
>> more
>> >> CPU, bandwidth, and complexity than most lightning users were
>> expecting to
>> >> face.
>> >
>> > This would only be a requirement for Lightning nodes that seek to be a
>> part
>> > of the public routing network with a desire to _forward_ HTLCs. This
>> isn't
>> > doesn't affect laptops or mobile phones which likely mostly have private
>> > channels and don't participate in HTLC forwarding. I think it's pretty
>> > reasonable to expect a "proper" routing node on the network to be
>> backed by
>> > a full-node. The bandwidth concern is valid, but we'd need concrete
>> numbers
>> > that compare the bandwidth over head of mempool awareness (assuming the
>> > latest and greatest mempool syncing) compared with the overhead of the
>> > channel update gossip and gossip queries over head which LN nodes face
>> today
>> > as is to see how much worse off they really would be.
>>
>> If mempool-watching were practical, maybe, though there are a number of
>> folks who are talking about designing
>> partially-offline local lightning hubs which would be rendered
>> impractical.
>>
>> > As detailed a bit below, if nodes watch the mempool, then this class of
>> > attack assuming the anchor output format as described in the open
>> > lightning-rfc PR is mitigated. At a glance, watching the mempool seems
>> like
>> > a far less involved process compared to modifying the state machine as
>> its
>> > defined today. By watching the mempool and implementing the changes in
>> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10
>> > doesn't yet watch the mempool (but does include anchors [1]), but
>> unless I'm
>> > missing something it should be pretty straight forward to add which mor
>> or less
>> > resolves this issue all together.
>> >
>> >> not fixing this issue seems to render the whole exercise somewhat
>> useless
>> >
>> > Depends on if one considers watching the mempool a fix. But even with
>> that a
>> > base version of anchors still resolves a number of issues including:
>> > eliminating the commitment fee guessing game, allowing users to pay
>> less on
>> > force close, being able to coalesce 2nd level HTLC transactions with the
>> > same CLTV expiry, and actually being able to reliably enforce multi-hop
>> HTLC
>> > resolution.
>> >
>> >> Instead of making the HTLC output spending more free-form with
>> >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other
>> >> direction - all HTLC output spends need to be pre-signed.
>> >
>> > I'm not sure this is actually immediately workable (need to think about
>> it
>> > more). To see why, remember that the commit_sig message includes HTLC
>> > signatures for the _remote_ party's commitment transaction, so they can
>> > spend the HTLCs if they broadcast their version of the commitment (force
>> > close). If we don't somehow also _gain_ signatures (our new HTLC
>> signatures)
>> > allowing us to spend HTLCs on _their_ version of the commitment, then if
>> > they broadcast that commitment (without revoking), then we're unable to
>> > redeem any of those HTLCs at all, possibly losing money.
>>
>> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
>> braodcasted transactions, but instead to CPFP
>> a maybe-broadcasted transaction by sending a transaction which spends it
>> and seeing if it is accepted. You only need to
>> know the transaction's exact format (ie txid, which we do, since we sent
>> a signature for it long ago) to do this, you
>> don't have to actually *have* the fully-signed transaction (and you
>> don't).
>>
>> > In an attempt to counteract this, we might say ok, the revoke message
>> also
>> > now includes HTLC signatures for their new commitment allowing us to
>> spend
>> > our HTLCs. This resolves things in a weaker security model, but doesn't
>> > address the issue generally, as after they receive the commit_sig, they
>> can
>> > broadcast immediately, again leaving us without a way to redeem our
>> HTLCs.
>> >
>> > I'd need to think about it more, but it seems that following this path
>> would
>> > require an overhaul in the channel state machine to make presenting a
>> new
>> > commitment actually take at least _two phases_ (at least a full round
>> trip).
>> > The first phase would tender the commitment, but render them unable to
>> > broadcast it. The second phase would then <insert something something
>> > scriptless scripts here> enter a new sub-protocol which upon conclusion,
>> > gives the commitment proposer valid HTLC signatures, and gives the
>> responder
>> > what they need to be able to broadcast their commitment and claim their
>> > HTCLs in an atomic manner.
>> >
>> > -- Laolu
>> >
>> > [1]: https://github.com/lightningnetwork/lnd/pull/3821
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/ec41b541/attachment-0001.html>

2023-06-09 12:59:46

- reply

📅 Original date posted:2020-04-22
📝 Original message:
> This seems like a somewhat unnecessary drive-by insult of a project you
> don't contribute to, but feel free to start with a concrete suggestion
> here :).
This wasn't intended as an insult at all. I'm simply saying if there's
concern about worst case eviction/replacement, optimizations likely exist.
Other developers that are interested in more complex multi-transaction
contracts have realized this as well, and there're various open PRs that
attempt to propose such optimizations [1].
> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> braodcasted transactions, but instead to CPFP a maybe-broadcasted
> transaction by sending a transaction which spends it and seeing if it is
> accepted
Sorry I still don't follow. By "we clearly need to go the other direction -
all HTLC output spends need to be pre-signed.", you don't mean that the HTLC
spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig
covenant? If the other party isn't restricted w.r.t _how_ they can spend the
output (non-rbf'd, ect), then I don't see how that addresses anything.
Also see my mail elsewhere in the thread that the other party is actually
forced to spend their HTLC output using an RBF-replaceable transaction. With
that, I think we're all good here? In the end both sides have the ability to
raise the fee rate of their spending transactions with the highest winning.
As long as one of them confirms within the CLTV-delta, then everyone is
made whole.
[1]: https://github.com/bitcoin/bitcoin/pull/18191
On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> A few replies inline.
>
> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> > Hi Matt,
> >
> >
> >> While this is somewhat unintuitive, there are any number of good
> anti-DoS
> >> reasons for this, eg:
> >
> > None of these really strikes me as "good" reasons for this limitation,
> which
> > is at the root of this issue, and will also plague any more complex
> Bitcoin
> > contracts which rely on nested trees of transaction to confirm (CTV,
> Duplex,
> > channel factories, etc). Regarding the various (seemingly arbitrary)
> package
> > limits it's likely the case that any issues w.r.t computational
> complexity
> > that may arise when trying to calculate evictions can be ameliorated with
> > better choice of internal data structures.
> >
> > In the end, the simplest heuristic (accept the higher fee rate package)
> side
> > steps all these issues and is also the most economically rationale from a
> > miner's perspective. Why would one prefer a higher absolute fee package
> > (which could be very large) over another package with a higher total _fee
> > rate_?
>
> This seems like a somewhat unnecessary drive-by insult of a project you
> don't contribute to, but feel free to start with
> a concrete suggestion here :).
>
> >> You'll note that B would be just fine if they had a way to safely
> monitor the
> >> global mempool, and while this seems like a prudent mitigation for
> >> lightning implementations to deploy today, it is itself a quagmire of
> >> complexity
> >
> > Is it really all that complex? Assuming we're talking about just watching
> > for a certain script template (the HTLC scipt) in the mempool to be able
> to
> > pull a pre-image as soon as possible. Early versions of lnd used the
> mempool
> > for commitment broadcast detection (which turned out to be a bad idea so
> we
> > removed it), but at a glance I don't see why watching the mempool is so
> > complex.
>
> Because watching your own mempool is not guaranteed to work, and during
> upgrade cycles that include changes to the
> policy rules an attacker could exploit your upgraded/non-upgraded status
> to perform the same attack.
>
> >> Further, this is a really obnoxious assumption to hoist onto lightning
> >> nodes - having an active full node with an in-sync mempool is a lot more
> >> CPU, bandwidth, and complexity than most lightning users were expecting
> to
> >> face.
> >
> > This would only be a requirement for Lightning nodes that seek to be a
> part
> > of the public routing network with a desire to _forward_ HTLCs. This
> isn't
> > doesn't affect laptops or mobile phones which likely mostly have private
> > channels and don't participate in HTLC forwarding. I think it's pretty
> > reasonable to expect a "proper" routing node on the network to be backed
> by
> > a full-node. The bandwidth concern is valid, but we'd need concrete
> numbers
> > that compare the bandwidth over head of mempool awareness (assuming the
> > latest and greatest mempool syncing) compared with the overhead of the
> > channel update gossip and gossip queries over head which LN nodes face
> today
> > as is to see how much worse off they really would be.
>
> If mempool-watching were practical, maybe, though there are a number of
> folks who are talking about designing
> partially-offline local lightning hubs which would be rendered impractical.
>
> > As detailed a bit below, if nodes watch the mempool, then this class of
> > attack assuming the anchor output format as described in the open
> > lightning-rfc PR is mitigated. At a glance, watching the mempool seems
> like
> > a far less involved process compared to modifying the state machine as
> its
> > defined today. By watching the mempool and implementing the changes in
> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10
> > doesn't yet watch the mempool (but does include anchors [1]), but unless
> I'm
> > missing something it should be pretty straight forward to add which mor
> or less
> > resolves this issue all together.
> >
> >> not fixing this issue seems to render the whole exercise somewhat
> useless
> >
> > Depends on if one considers watching the mempool a fix. But even with
> that a
> > base version of anchors still resolves a number of issues including:
> > eliminating the commitment fee guessing game, allowing users to pay less
> on
> > force close, being able to coalesce 2nd level HTLC transactions with the
> > same CLTV expiry, and actually being able to reliably enforce multi-hop
> HTLC
> > resolution.
> >
> >> Instead of making the HTLC output spending more free-form with
> >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other
> >> direction - all HTLC output spends need to be pre-signed.
> >
> > I'm not sure this is actually immediately workable (need to think about
> it
> > more). To see why, remember that the commit_sig message includes HTLC
> > signatures for the _remote_ party's commitment transaction, so they can
> > spend the HTLCs if they broadcast their version of the commitment (force
> > close). If we don't somehow also _gain_ signatures (our new HTLC
> signatures)
> > allowing us to spend HTLCs on _their_ version of the commitment, then if
> > they broadcast that commitment (without revoking), then we're unable to
> > redeem any of those HTLCs at all, possibly losing money.
>
> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> braodcasted transactions, but instead to CPFP
> a maybe-broadcasted transaction by sending a transaction which spends it
> and seeing if it is accepted. You only need to
> know the transaction's exact format (ie txid, which we do, since we sent a
> signature for it long ago) to do this, you
> don't have to actually *have* the fully-signed transaction (and you don't).
>
> > In an attempt to counteract this, we might say ok, the revoke message
> also
> > now includes HTLC signatures for their new commitment allowing us to
> spend
> > our HTLCs. This resolves things in a weaker security model, but doesn't
> > address the issue generally, as after they receive the commit_sig, they
> can
> > broadcast immediately, again leaving us without a way to redeem our
> HTLCs.
> >
> > I'd need to think about it more, but it seems that following this path
> would
> > require an overhaul in the channel state machine to make presenting a new
> > commitment actually take at least _two phases_ (at least a full round
> trip).
> > The first phase would tender the commitment, but render them unable to
> > broadcast it. The second phase would then <insert something something
> > scriptless scripts here> enter a new sub-protocol which upon conclusion,
> > gives the commitment proposer valid HTLC signatures, and gives the
> responder
> > what they need to be able to broadcast their commitment and claim their
> > HTCLs in an atomic manner.
> >
> > -- Laolu
> >
> > [1]: https://github.com/lightningnetwork/lnd/pull/3821
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/2392c438/attachment-0001.html>

2023-06-09 12:59:45

- reply

📅 Original date posted:2020-04-22
📝 Original message:
Hi Matt,
> While this is somewhat unintuitive, there are any number of good anti-DoS
> reasons for this, eg:
None of these really strikes me as "good" reasons for this limitation, which
is at the root of this issue, and will also plague any more complex Bitcoin
contracts which rely on nested trees of transaction to confirm (CTV, Duplex,
channel factories, etc). Regarding the various (seemingly arbitrary) package
limits it's likely the case that any issues w.r.t computational complexity
that may arise when trying to calculate evictions can be ameliorated with
better choice of internal data structures.
In the end, the simplest heuristic (accept the higher fee rate package) side
steps all these issues and is also the most economically rationale from a
miner's perspective. Why would one prefer a higher absolute fee package
(which could be very large) over another package with a higher total _fee
rate_?
> You'll note that B would be just fine if they had a way to safely monitor
the
> global mempool, and while this seems like a prudent mitigation for
> lightning implementations to deploy today, it is itself a quagmire of
> complexity
Is it really all that complex? Assuming we're talking about just watching
for a certain script template (the HTLC scipt) in the mempool to be able to
pull a pre-image as soon as possible. Early versions of lnd used the mempool
for commitment broadcast detection (which turned out to be a bad idea so we
removed it), but at a glance I don't see why watching the mempool is so
complex.
> Further, this is a really obnoxious assumption to hoist onto lightning
> nodes - having an active full node with an in-sync mempool is a lot more
> CPU, bandwidth, and complexity than most lightning users were expecting to
> face.
This would only be a requirement for Lightning nodes that seek to be a part
of the public routing network with a desire to _forward_ HTLCs. This isn't
doesn't affect laptops or mobile phones which likely mostly have private
channels and don't participate in HTLC forwarding. I think it's pretty
reasonable to expect a "proper" routing node on the network to be backed by
a full-node. The bandwidth concern is valid, but we'd need concrete numbers
that compare the bandwidth over head of mempool awareness (assuming the
latest and greatest mempool syncing) compared with the overhead of the
channel update gossip and gossip queries over head which LN nodes face today
as is to see how much worse off they really would be.
As detailed a bit below, if nodes watch the mempool, then this class of
attack assuming the anchor output format as described in the open
lightning-rfc PR is mitigated. At a glance, watching the mempool seems like
a far less involved process compared to modifying the state machine as its
defined today. By watching the mempool and implementing the changes in
#lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10
doesn't yet watch the mempool (but does include anchors [1]), but unless I'm
missing something it should be pretty straight forward to add which mor or
less
resolves this issue all together.
> not fixing this issue seems to render the whole exercise somewhat useless
Depends on if one considers watching the mempool a fix. But even with that a
base version of anchors still resolves a number of issues including:
eliminating the commitment fee guessing game, allowing users to pay less on
force close, being able to coalesce 2nd level HTLC transactions with the
same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC
resolution.
> Instead of making the HTLC output spending more free-form with
> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other
> direction - all HTLC output spends need to be pre-signed.
I'm not sure this is actually immediately workable (need to think about it
more). To see why, remember that the commit_sig message includes HTLC
signatures for the _remote_ party's commitment transaction, so they can
spend the HTLCs if they broadcast their version of the commitment (force
close). If we don't somehow also _gain_ signatures (our new HTLC signatures)
allowing us to spend HTLCs on _their_ version of the commitment, then if
they broadcast that commitment (without revoking), then we're unable to
redeem any of those HTLCs at all, possibly losing money.
In an attempt to counteract this, we might say ok, the revoke message also
now includes HTLC signatures for their new commitment allowing us to spend
our HTLCs. This resolves things in a weaker security model, but doesn't
address the issue generally, as after they receive the commit_sig, they can
broadcast immediately, again leaving us without a way to redeem our HTLCs.
I'd need to think about it more, but it seems that following this path would
require an overhaul in the channel state machine to make presenting a new
commitment actually take at least _two phases_ (at least a full round trip).
The first phase would tender the commitment, but render them unable to
broadcast it. The second phase would then <insert something something
scriptless scripts here> enter a new sub-protocol which upon conclusion,
gives the commitment proposer valid HTLC signatures, and gives the responder
what they need to be able to broadcast their commitment and claim their
HTCLs in an atomic manner.
-- Laolu
[1]: https://github.com/lightningnetwork/lnd/pull/3821
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200421/6cae2a06/attachment.html>

2023-06-09 12:59:44

- reply

📅 Original date posted:2020-04-22
📝 Original message:
Hi Z,
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
pretty
> low-weight mitigation against this attack.
I think this works...so they're forced to spend the output with a non-final
sequence number, meaning it *must* signal RBF. In this case, now it's the
timeout-er vs the success-er racing based on fee rate. If the honest party
(the
one trying to time out the HTLC) bids a fee rate higher (need to also
account
for the whole absolute fee replacement thing), then things should generally
work out in their favor.
-- Laolu
On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Laolu, Matt, and list,
>
>
> > > * With `SIGHASH_NOINPUT` we can make the C-side signature
> > > `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> > > signature for a higher-fee version of HTLC-Timeout (assuming my cached
> > > understanding of `SIGHASH_NOINPUT` still holds).
> >
> > no_input isn't needed. With simply single+anyone can pay, then B can
> attach
> > a new input+output pair to increase the fees on their HTLC redemption
> > transaction. As you mention, they now enter into a race against this
> > malicious ndoe to bump up their fees in order to win over the other
> party.
>
> Right, right, that works as well.
>
> >
> > If the malicious node uses a non-RBF signalled transaction to sweep their
> > HTLC, then we enter into another level of race, but this time on the
> mempool
> > propagation level. However, if there exists a relay path to a miner
> running
> > full RBF, then B's higher fee rate spend will win over.
>
> Hmm.
>
> So basically:
>
> * B has no mempool, because it wants to reduce its costs and etc.
> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
> * B does not notice this tx because:
> 1. The tx is too low fee to be put in a block.
> 2. B has no mempool so it cannot see the tx being propagated over the
> P2P network.
> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
> cannot replace a non-RBF tx.
> * After L+1, C contacts the miners off-band and offers fee payment by
> other means.
>
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty
> low-weight mitigation against this attack.
>
> So I think the combination below gives us good size:
>
> * The HTLC-Timeout signature from C is flagged with
> `OP_SINGLE|OP_ANYONECANPAY`.
> * Normally, the HTLC-Timeout still deducts the fee from the value of the
> UTXO being spent.
> * However, if B notices that the L+1 timeout is approaching, it can
> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
> but reusing the (still valid) C signature.
> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
> preventing C from broadcasting a low-fee claim tx.
>
> This has the advantages:
>
> * B does not need a mempool still and can run in `blocksonly`.
> * The normal path is still the same as current behavior, we "only" add a
> new path where if the L+1 timeout is approaching we fee-bump the
> HTLC-Timeout.
> * Costs are pretty low:
> * No need for extra RBF carve-out txo.
> * Just two additional witness bytes in the hashlock branch.
> * No mempool rule changes needed, can be done with the P2P network of
> today.
> * Probably still resilient even with future changes in mempool rules, as
> long as typical RBF behaviors still remain.
>
> Is my understanding correct?
>
> Regards,
> ZmnSCPxj
>
> >
> > -- Laolu
> >
> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > Good morning Matt, and list,
> > >
> > > > RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds,
> how, now?")
> > > > =============================
> > > >
> > > > You'll note that in the discussion of RBF pinning we were pretty
> broad, and that that discussion seems to in fact cover
> > > > our HTLC outputs, at least when spent via (3) or (4). It does,
> and in fact this is a pretty severe issue in today's
> > > > lightning protocol [2]. A lightning counterparty (C, who
> received the HTLC from B, who received it from A) today could,
> > > > if B broadcasts the commitment transaction, spend an HTLC using
> the preimage with a low-fee, RBF-disabled transaction.
> > > > After a few blocks, A could claim the HTLC from B via the
> timeout mechanism, and then after a few days, C could get the
> > > > HTLC-claiming transaction mined via some out-of-band agreement
> with a small miner. This leaves B short the HTLC value.
> > >
> > > My (cached) understanding is that, since RBF is signalled using
> `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the
> requirement "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
> > > Adding that clause (2 bytes in witness if my math is correct) to the
> hashlock branch may be sufficient to prevent C from making an RBF-disabled
> transaction.
> > >
> > > But then you mention out-of-band agreements with miners, which
> basically means the transaction might not be in the mempool at all, in
> which case the vulnerability is not really about RBF or relay, but sheer
> economics.
> > >
> > > The payment is A->B->C, and the HTLC A->B must have a larger timeout
> (L + 1) than the HTLC B->C (L), in abstract non-block units.
> > > The vulnerability you are describing means that the current time must
> now be L + 1 or greater ("A could claim the HTLC from B via the timeout
> mechanism", meaning the A->B HTLC has timed out already).
> > >
> > > If so, then the B->C transaction has already timed out in the past and
> can be claimed in two ways, either via B timeout branch or C hashlock
> branch.
> > > This sets up a game where B and C bid to miners to get their version
> of reality committed onchain.
> > > (We can neglect out-of-band agreements here; miners have the incentive
> to publicly leak such agreements so that other potential bidders can offer
> even higher fees for their versions of that transaction.)
> > >
> > > Before L+1, C has no incentive to bid, since placing any bid at all
> will leak the preimage, which B can then turn around and use to spend from
> A, and A and C cannot steal from B.
> > >
> > > Thus, B should ensure that *before* L+1, the HTLC-Timeout has been
> committed onchain, which outright prevents this bidding war from even
> starting.
> > >
> > > The issue then is that B is using a pre-signed HTLC-timeout, which is
> needed since it is its commitment tx that was broadcast.
> > > This prevents B from RBF-ing the HTLC-Timeout transaction.
> > >
> > > So what is needed is to allow B to add fees to HTLC-Timeout:
> > >
> > > * We can add an RBF carve-out output to HTLC-Timeout, at the cost of
> more blockspace.
> > > * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of HTLC-Timeout (assuming my cached
> understanding of `SIGHASH_NOINPUT` still holds).
> > >
> > > With this, B can exponentially increase the fee as L+1 approaches.
> > > If B can get HTLC-Timeout confirmed before L+1, then C cannot steal
> the HTLC value at all, since the UTXO it could steal from has already been
> spent.
> > >
> > > In particular, it does not seem to me that it is necessary to change
> the hashlock-branch transaction of C at all, since this mechanism is enough
> to sidestep the issue (as I understand it).
> > > But it does point to a need to make HTLC-Timeout (and possibly
> symmetrically, HTLC-Success) also fee-bumpable.
> > >
> > > Note as well that this does not require a mempool: B can run in
> `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout
> is not confirmed, feebump HTLC-Timeout.
> > > In particular, HTLC-Timeout comes into play only if B broadcast its
> own commitment transaction, and B *should* be aware that it did so ---
> there is still no need for mempool monitoring here.
> > >
> > > Now, of course this only delays the war.
> > > Let us now consider what C can do to ensure that the bidding war will
> happen eventually.
> > >
> > > * C can bribe a miner to prevent HTLC-Timeout from confirming between
> L and L+1.
> > > * Or in other words, this is a censorship attack.
> > > * The Bitcoin censorship-resistance model is that censored
> transactions can be fee-bumped, which attracts non-censoring miners to try
> their luck at mining and evict the censoring miner.
> > > * Thus, letting B bump the fee on HTLC-Timeout is precisely the
> mechanism we need.
> > > * This sets up a bidding war between C requesting miners to
> censor, vs. B requesting miners to confirm, but that only sets the stage
> for a second bidding war later between C and B, thus C is at a
> disadvantage: it has to bribe miners to censor continuously from L to L+1
> *and* additional bribe miners to confirm its transaction after L+1, whereas
> B can offer its bribe as being something that miners can claim now without
> waiting after L+1.
> > >
> > > The issue of course is the additional output that bloats the UTXO set
> and requires another transaction to claim later.
> > > And if we have `SIGHASH_NOINPUT`, it seems to me that
> Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out
> HTLC can be claimed with a fee-bumpable transaction directly without
> RBF-carve-out.
> > > (As well, it seems to me that, if both nodes support doing so, a
> Poon-Dryja channel can be upgraded, without onchain activity, to a
> Decker-Russell-Osuntokun channel: sign a transaction spending the funding
> tx to a txo that has been set up as Decker-Russell-Osuntokun, do not
> broadcast that transaction, then revoke the latest Poon-Dryja commitment
> transactions, then switch the mechanism over to Decker-Russell-Osuntokun;
> you still need to monitor for previous Poon-Dryja commitment transactions,
> but HTLCs now sidestep the issue under discussion here.)
> > >
> > > Regards,
> > > ZmnSCPxj
> > > _______________________________________________
> > > 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/lightning-dev/attachments/20200422/3fdeb85d/attachment-0001.html>

2023-06-09 12:59:44

- reply

📅 Original date posted:2020-04-22
📝 Original message:
Hi z,
Actually, the current anchors proposal already does this, since it enforces
a
CSV of 1 block before the HTLCs can be spent (the block after
confirmation). So
I think we already do this, meaning the malicious node is already forced to
use
an RBF-replaceable transaction.
-- Laolu
On Wed, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi Z,
>
> > It seems to me that, if my cached understanding that `<0>
> > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then
> adding
> > that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
> pretty
> > low-weight mitigation against this attack.
>
> I think this works...so they're forced to spend the output with a non-final
> sequence number, meaning it *must* signal RBF. In this case, now it's the
> timeout-er vs the success-er racing based on fee rate. If the honest party
> (the
> one trying to time out the HTLC) bids a fee rate higher (need to also
> account
> for the whole absolute fee replacement thing), then things should generally
> work out in their favor.
>
> -- Laolu
>
>
> On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Laolu, Matt, and list,
>>
>>
>> > > * With `SIGHASH_NOINPUT` we can make the C-side signature
>> > > `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
>> > > signature for a higher-fee version of HTLC-Timeout (assuming my
>> cached
>> > > understanding of `SIGHASH_NOINPUT` still holds).
>> >
>> > no_input isn't needed. With simply single+anyone can pay, then B can
>> attach
>> > a new input+output pair to increase the fees on their HTLC redemption
>> > transaction. As you mention, they now enter into a race against this
>> > malicious ndoe to bump up their fees in order to win over the other
>> party.
>>
>> Right, right, that works as well.
>>
>> >
>> > If the malicious node uses a non-RBF signalled transaction to sweep
>> their
>> > HTLC, then we enter into another level of race, but this time on the
>> mempool
>> > propagation level. However, if there exists a relay path to a miner
>> running
>> > full RBF, then B's higher fee rate spend will win over.
>>
>> Hmm.
>>
>> So basically:
>>
>> * B has no mempool, because it wants to reduce its costs and etc.
>> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
>> * B does not notice this tx because:
>> 1. The tx is too low fee to be put in a block.
>> 2. B has no mempool so it cannot see the tx being propagated over the
>> P2P network.
>> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
>> cannot replace a non-RBF tx.
>> * After L+1, C contacts the miners off-band and offers fee payment by
>> other means.
>>
>> It seems to me that, if my cached understanding that `<0>
>> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
>> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty
>> low-weight mitigation against this attack.
>>
>> So I think the combination below gives us good size:
>>
>> * The HTLC-Timeout signature from C is flagged with
>> `OP_SINGLE|OP_ANYONECANPAY`.
>> * Normally, the HTLC-Timeout still deducts the fee from the value of
>> the UTXO being spent.
>> * However, if B notices that the L+1 timeout is approaching, it can
>> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
>> but reusing the (still valid) C signature.
>> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
>> preventing C from broadcasting a low-fee claim tx.
>>
>> This has the advantages:
>>
>> * B does not need a mempool still and can run in `blocksonly`.
>> * The normal path is still the same as current behavior, we "only" add a
>> new path where if the L+1 timeout is approaching we fee-bump the
>> HTLC-Timeout.
>> * Costs are pretty low:
>> * No need for extra RBF carve-out txo.
>> * Just two additional witness bytes in the hashlock branch.
>> * No mempool rule changes needed, can be done with the P2P network of
>> today.
>> * Probably still resilient even with future changes in mempool rules,
>> as long as typical RBF behaviors still remain.
>>
>> Is my understanding correct?
>>
>> Regards,
>> ZmnSCPxj
>>
>> >
>> > -- Laolu
>> >
>> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > > Good morning Matt, and list,
>> > >
>> > > > RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal
>> funds, how, now?")
>> > > > =============================
>> > > >
>> > > > You'll note that in the discussion of RBF pinning we were
>> pretty broad, and that that discussion seems to in fact cover
>> > > > our HTLC outputs, at least when spent via (3) or (4). It does,
>> and in fact this is a pretty severe issue in today's
>> > > > lightning protocol [2]. A lightning counterparty (C, who
>> received the HTLC from B, who received it from A) today could,
>> > > > if B broadcasts the commitment transaction, spend an HTLC using
>> the preimage with a low-fee, RBF-disabled transaction.
>> > > > After a few blocks, A could claim the HTLC from B via the
>> timeout mechanism, and then after a few days, C could get the
>> > > > HTLC-claiming transaction mined via some out-of-band agreement
>> with a small miner. This leaves B short the HTLC value.
>> > >
>> > > My (cached) understanding is that, since RBF is signalled using
>> `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the
>> requirement "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
>> > > Adding that clause (2 bytes in witness if my math is correct) to the
>> hashlock branch may be sufficient to prevent C from making an RBF-disabled
>> transaction.
>> > >
>> > > But then you mention out-of-band agreements with miners, which
>> basically means the transaction might not be in the mempool at all, in
>> which case the vulnerability is not really about RBF or relay, but sheer
>> economics.
>> > >
>> > > The payment is A->B->C, and the HTLC A->B must have a larger timeout
>> (L + 1) than the HTLC B->C (L), in abstract non-block units.
>> > > The vulnerability you are describing means that the current time must
>> now be L + 1 or greater ("A could claim the HTLC from B via the timeout
>> mechanism", meaning the A->B HTLC has timed out already).
>> > >
>> > > If so, then the B->C transaction has already timed out in the past
>> and can be claimed in two ways, either via B timeout branch or C hashlock
>> branch.
>> > > This sets up a game where B and C bid to miners to get their version
>> of reality committed onchain.
>> > > (We can neglect out-of-band agreements here; miners have the
>> incentive to publicly leak such agreements so that other potential bidders
>> can offer even higher fees for their versions of that transaction.)
>> > >
>> > > Before L+1, C has no incentive to bid, since placing any bid at all
>> will leak the preimage, which B can then turn around and use to spend from
>> A, and A and C cannot steal from B.
>> > >
>> > > Thus, B should ensure that *before* L+1, the HTLC-Timeout has been
>> committed onchain, which outright prevents this bidding war from even
>> starting.
>> > >
>> > > The issue then is that B is using a pre-signed HTLC-timeout, which is
>> needed since it is its commitment tx that was broadcast.
>> > > This prevents B from RBF-ing the HTLC-Timeout transaction.
>> > >
>> > > So what is needed is to allow B to add fees to HTLC-Timeout:
>> > >
>> > > * We can add an RBF carve-out output to HTLC-Timeout, at the cost of
>> more blockspace.
>> > > * With `SIGHASH_NOINPUT` we can make the C-side signature
>> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
>> signature for a higher-fee version of HTLC-Timeout (assuming my cached
>> understanding of `SIGHASH_NOINPUT` still holds).
>> > >
>> > > With this, B can exponentially increase the fee as L+1 approaches.
>> > > If B can get HTLC-Timeout confirmed before L+1, then C cannot steal
>> the HTLC value at all, since the UTXO it could steal from has already been
>> spent.
>> > >
>> > > In particular, it does not seem to me that it is necessary to change
>> the hashlock-branch transaction of C at all, since this mechanism is enough
>> to sidestep the issue (as I understand it).
>> > > But it does point to a need to make HTLC-Timeout (and possibly
>> symmetrically, HTLC-Success) also fee-bumpable.
>> > >
>> > > Note as well that this does not require a mempool: B can run in
>> `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout
>> is not confirmed, feebump HTLC-Timeout.
>> > > In particular, HTLC-Timeout comes into play only if B broadcast its
>> own commitment transaction, and B *should* be aware that it did so ---
>> there is still no need for mempool monitoring here.
>> > >
>> > > Now, of course this only delays the war.
>> > > Let us now consider what C can do to ensure that the bidding war will
>> happen eventually.
>> > >
>> > > * C can bribe a miner to prevent HTLC-Timeout from confirming between
>> L and L+1.
>> > > * Or in other words, this is a censorship attack.
>> > > * The Bitcoin censorship-resistance model is that censored
>> transactions can be fee-bumped, which attracts non-censoring miners to try
>> their luck at mining and evict the censoring miner.
>> > > * Thus, letting B bump the fee on HTLC-Timeout is precisely the
>> mechanism we need.
>> > > * This sets up a bidding war between C requesting miners to
>> censor, vs. B requesting miners to confirm, but that only sets the stage
>> for a second bidding war later between C and B, thus C is at a
>> disadvantage: it has to bribe miners to censor continuously from L to L+1
>> *and* additional bribe miners to confirm its transaction after L+1, whereas
>> B can offer its bribe as being something that miners can claim now without
>> waiting after L+1.
>> > >
>> > > The issue of course is the additional output that bloats the UTXO set
>> and requires another transaction to claim later.
>> > > And if we have `SIGHASH_NOINPUT`, it seems to me that
>> Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out
>> HTLC can be claimed with a fee-bumpable transaction directly without
>> RBF-carve-out.
>> > > (As well, it seems to me that, if both nodes support doing so, a
>> Poon-Dryja channel can be upgraded, without onchain activity, to a
>> Decker-Russell-Osuntokun channel: sign a transaction spending the funding
>> tx to a txo that has been set up as Decker-Russell-Osuntokun, do not
>> broadcast that transaction, then revoke the latest Poon-Dryja commitment
>> transactions, then switch the mechanism over to Decker-Russell-Osuntokun;
>> you still need to monitor for previous Poon-Dryja commitment transactions,
>> but HTLCs now sidestep the issue under discussion here.)
>> > >
>> > > Regards,
>> > > ZmnSCPxj
>> > > _______________________________________________
>> > > 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/lightning-dev/attachments/20200422/b51b1fe1/attachment.html>

2023-06-09 12:59:41

- reply

📅 Original date posted:2020-04-22
📝 Original message:
> So what is needed is to allow B to add fees to HTLC-Timeout:
Indeed, anchors as defined in #lightning-rfc/688 allows this.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of HTLC-Timeout (assuming my cached
> understanding of `SIGHASH_NOINPUT` still holds).
no_input isn't needed. With simply single+anyone can pay, then B can attach
a new input+output pair to increase the fees on their HTLC redemption
transaction. As you mention, they now enter into a race against this
malicious ndoe to bump up their fees in order to win over the other party.
If the malicious node uses a non-RBF signalled transaction to sweep their
HTLC, then we enter into another level of race, but this time on the mempool
propagation level. However, if there exists a relay path to a miner running
full RBF, then B's higher fee rate spend will win over.
-- Laolu
On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Matt, and list,
>
>
>
> > RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds,
> how, now?")
> > =============================
> >
> > You'll note that in the discussion of RBF pinning we were pretty
> broad, and that that discussion seems to in fact cover
> > our HTLC outputs, at least when spent via (3) or (4). It does, and
> in fact this is a pretty severe issue in today's
> > lightning protocol [2]. A lightning counterparty (C, who received
> the HTLC from B, who received it from A) today could,
> > if B broadcasts the commitment transaction, spend an HTLC using the
> preimage with a low-fee, RBF-disabled transaction.
> > After a few blocks, A could claim the HTLC from B via the timeout
> mechanism, and then after a few days, C could get the
> > HTLC-claiming transaction mined via some out-of-band agreement with
> a small miner. This leaves B short the HTLC value.
>
> My (cached) understanding is that, since RBF is signalled using
> `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the
> requirement "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
> Adding that clause (2 bytes in witness if my math is correct) to the
> hashlock branch may be sufficient to prevent C from making an RBF-disabled
> transaction.
>
> But then you mention out-of-band agreements with miners, which basically
> means the transaction might not be in the mempool at all, in which case the
> vulnerability is not really about RBF or relay, but sheer economics.
>
> The payment is A->B->C, and the HTLC A->B must have a larger timeout (L +
> 1) than the HTLC B->C (L), in abstract non-block units.
> The vulnerability you are describing means that the current time must now
> be L + 1 or greater ("A could claim the HTLC from B via the timeout
> mechanism", meaning the A->B HTLC has timed out already).
>
> If so, then the B->C transaction has already timed out in the past and can
> be claimed in two ways, either via B timeout branch or C hashlock branch.
> This sets up a game where B and C bid to miners to get their version of
> reality committed onchain.
> (We can neglect out-of-band agreements here; miners have the incentive to
> publicly leak such agreements so that other potential bidders can offer
> even higher fees for their versions of that transaction.)
>
> Before L+1, C has no incentive to bid, since placing any bid at all will
> leak the preimage, which B can then turn around and use to spend from A,
> and A and C cannot steal from B.
>
> Thus, B should ensure that *before* L+1, the HTLC-Timeout has been
> committed onchain, which outright prevents this bidding war from even
> starting.
>
> The issue then is that B is using a pre-signed HTLC-timeout, which is
> needed since it is its commitment tx that was broadcast.
> This prevents B from RBF-ing the HTLC-Timeout transaction.
>
> So what is needed is to allow B to add fees to HTLC-Timeout:
>
> * We can add an RBF carve-out output to HTLC-Timeout, at the cost of more
> blockspace.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of HTLC-Timeout (assuming my cached
> understanding of `SIGHASH_NOINPUT` still holds).
>
> With this, B can exponentially increase the fee as L+1 approaches.
> If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the
> HTLC value at all, since the UTXO it could steal from has already been
> spent.
>
> In particular, it does not seem to me that it is necessary to change the
> hashlock-branch transaction of C at all, since this mechanism is enough to
> sidestep the issue (as I understand it).
> But it does point to a need to make HTLC-Timeout (and possibly
> symmetrically, HTLC-Success) also fee-bumpable.
>
> Note as well that this does not require a mempool: B can run in
> `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout
> is not confirmed, feebump HTLC-Timeout.
> In particular, HTLC-Timeout comes into play only if B broadcast its own
> commitment transaction, and B *should* be aware that it did so --- there is
> still no need for mempool monitoring here.
>
>
> Now, of course this only delays the war.
> Let us now consider what C can do to ensure that the bidding war will
> happen eventually.
>
> * C can bribe a miner to prevent HTLC-Timeout from confirming between L
> and L+1.
> * Or in other words, this is a censorship attack.
> * The Bitcoin censorship-resistance model is that censored
> transactions can be fee-bumped, which attracts non-censoring miners to try
> their luck at mining and evict the censoring miner.
> * Thus, letting B bump the fee on HTLC-Timeout is precisely the
> mechanism we need.
> * This sets up a bidding war between C requesting miners to censor,
> vs. B requesting miners to confirm, but that only sets the stage for a
> second bidding war later between C and B, thus C is at a disadvantage: it
> has to bribe miners to censor continuously from L to L+1 *and* additional
> bribe miners to confirm its transaction after L+1, whereas B can offer its
> bribe as being something that miners can claim now without waiting after
> L+1.
>
>
>
> The issue of course is the additional output that bloats the UTXO set and
> requires another transaction to claim later.
> And if we have `SIGHASH_NOINPUT`, it seems to me that
> Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out
> HTLC can be claimed with a fee-bumpable transaction directly without
> RBF-carve-out.
> (As well, it seems to me that, if both nodes support doing so, a
> Poon-Dryja channel can be upgraded, without onchain activity, to a
> Decker-Russell-Osuntokun channel: sign a transaction spending the funding
> tx to a txo that has been set up as Decker-Russell-Osuntokun, do not
> broadcast that transaction, then revoke the latest Poon-Dryja commitment
> transactions, then switch the mechanism over to Decker-Russell-Osuntokun;
> you still need to monitor for previous Poon-Dryja commitment transactions,
> but HTLCs now sidestep the issue under discussion here.)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/lightning-dev/attachments/20200421/fd98ca19/attachment-0001.html>

2023-06-09 12:57:11

- reply

📅 Original date posted:2019-11-05
📝 Original message:
Hi Rusty,
Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other
alternatives for a few years now, and none of them seems to resolve the
series of routing related incentive issues that prepaid HTLCs would.
> Since both Offers and Joost's WhatSat are looking at sending messages,
> it's time to float actual proposals.
IMO both should just be done over HORNET, so we don't need introduce a new
set of internal protocol level messages whenever we have some new
control/signalling need. Instead, we'd have a control/signal channel (give
me
routes, invoices, sign this, etc), and a payment channel (HTLCs as used
today).
> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed
> (new field), and a hash.
The prepay amount should be signalled in the update add message instead.
This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we
need a new onion field as well to signal the incoming amount the node
_should_ have received (allows them to detect deviations in the sender's
intended route).
> 3. Failing/succeeding an HTLC returns some of those msat, and a count and
> preimage (new fields).
Failing shouldn't return the prepay amount, otherwise extending long lived
HTLCs then cancelling them at the last minute is still costless. This
costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the
biggest incentive flaw that exists today in the greater routing network.
> You get to keep 50 msat[1] per preimage you present[2].
We should avoid introducing any new constants to the protocol, as they're
typically dreamed up independent of any empirical lessons learned from
deployment.
On the topic of the prepay cost, the channel update message should be
extended to allow nodes to signal prepay costs similar to the way we handle
regular payment success fees. In order to eliminate a number of costless
attacks possible today on the routing network, nodes should also be able to
signal a new coefficient used to _scale_ the prepay fee as a function of the
CLTV value of the incoming HTLC. With this addition, senders need to pay to
_add_ an HTLC to a remote commitment transaction (fixed base cost), then
also need to pay a variable rate that scales with the duration of the
proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once
we introduce this, loop attacks and the like are no longer free to launch,
and nodes can dynamically respond to congestion in the network by raising
their prepay prices.
-- Laolu
On Mon, Nov 4, 2019 at 6:25 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> It's been widely known that we're going to have to have up-front
> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
> spam).
>
> Since both Offers and Joost's WhatSat are looking at sending
> messages, it's time to float actual proposals. I've been trying to come
> up with something for several years now, so thought I'd present the best
> I've got in the hope that others can improve on it.
>
> 1. New feature bit, extended messages, etc.
> 2. Adding an HTLC causes a *push* of a number of msat on
> commitment_signed (new field), and a hash.
> 3. Failing/succeeding an HTLC returns some of those msat, and a count
> and preimage (new fields).
>
> How many msat can you take for forwarding? That depends on you
> presenting a series of preimages (which chain into a final hash given in
> the HTLC add), which you get by decoding the onion. You get to keep 50
> msat[1] per preimage you present[2].
>
> So, how many preimages does the user have to give to have you forward
> the payment? That depends. The base rate is 16 preimages, but subtract
> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
> onion. The blockhash is the hash of the block specified in the onion:
> reject if it's not in the last 3 blocks[3].
>
> This simply adds some payment noise, while allowing a hashcash style
> tradeoff of sats for work.
>
> The final node gets some variable number of preimages, which adds noise.
> It should take all and subtract from the minimum required invoice amount
> on success, or take some random number on failure.
>
> This leaks some forward information, and makes an explicit tradeoff for
> the sender between amount spent and privacy, but it's the best I've been
> able to come up with.
>
> Thoughts?
> Rusty.
>
> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
> 655msat per message. Flat pricing for simplicity; we're trying to
> prevent spam, not create a spam market.
> [2] Actually, a number and a single preimage; you can check this is
> indeed the n'th preimage.
> [3] This reduces incentive to grind the damn things in advance, though
> maybe that's dumb? We can also use a shorter hash (siphash?), or
> even truncated SHA256 (128 bits).
> _______________________________________________
> 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/20191105/b461390a/attachment-0001.html>

2023-06-09 12:54:13

- reply

📅 Original date posted:2019-02-08
📝 Original message:
Hi y'all,
I'm not sure how good defenses are on implementations other than lnd, but
all implementations *should* be keeping a Sphinx reply cache of the past
shared secrets they know of [1]. If a node comes across an identical shared
secret of that in the cache, then they should reject that packet. Otherwise,
it's possible for an adversary to inject a stale packet back into the
network in order to observe the propagation of the packet through the
network. This is referred to as a "replay" attack, and is a de-anonymization
vector.
Typically mix nets enforce some sort of session lifetime identifier to allow
nodes to garbage collect their old shared secrets state, otherwise it grows
indefinitely. As our messages are actually payments with a clear expiration
date (the absolute CLTV), we can use this as the lifetime of a payment
circuit session. The sphinx packet construction allows some optional
plaintext data to be authenticated along side the packet. In the current
protocol we use this to bing the payment hash along with the packet. The
rationale is that in order for me to accept the packet, the attacker must
use the _same_ payment hash. If the pre-image has already been revealed,
then the "victim" can instantly pull the payment, attaching a cost to a
replay attempt.
However, since the CLTV isn't also authenticated, then it's possible to
attempt to inject a new HTLC with a fresher CLTV. If the node isn't keeping
around all pre-images, then they might forward this since it passes the
regular expiry tests. If we instead extend the associated data payload to
cover the CLTV as well, then this binds the adversary to using the same CLTV
details. As a result, the "victim" node will reject the HTLC since it has
already expired. Continuing down this line, if we progressively add more
payment details, for example the HTLC amount, then this forces the adversary
to commit the same amount as the original HTLC, potentially making the
probing vector more expensive (as they're likely to lose the funds on
attempt).
If this were to be deployed, then we can do it by using a new packet version
in the Sphinx packet. Nodes that come across this new version (signalled by
a global feature bit) would then know to include the extra information in
the AD for their MAC check. While we're at it, we should also actually
*commit* to the packet version. Right now nodes can swap out the version to
anything they want, potentially causing another node to reject the packet.
This should also be added to the AD to ensure the packet can't be modified
without another node detecting it.
Longer term, we may end up with _all_ payment details in the Sphinx packet.
The only thing outside in the update_add_htlc message would be link level
details such as the HTLC ID.
Thoughts?
[1]:
https://github.com/lightningnetwork/lightning-onion/blob/master/replaylog.go
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190207/895c8f9c/attachment.html>

2023-06-09 12:54:11

- reply

📅 Original date posted:2019-02-07
📝 Original message:
Hi y'all,
Recently we've started to do more design work related to the Sphinx packet
(EOB format, rendezvous protocol). This prompted me to re-visit the original
Sphinx paper to refresh my memory w.r.t some of the finer details of the
protocol. While I was re-reading the paper, I realized that we may be able
to use use SURBs (single-use-reply-blocks) to implement a "payment ACK" for
each sent HTLC.
(it's worth mentioning that switching to HORNET down the line would solve
this problem as well since the receiver already gets a multi-use backwards
route that they can use to send information back to the receiver)
Right now HTLC routing is mainly a game of "send and hope it arrives", as
you have no clear indication of the _arrival_ of an HTLC at the destination.
Instead, you only receive a protocol level message if the HTLC failed for
w/e reason, or if it was successfully redeemed. As part of BOLT 1.1, it was
agreed upon that we should implement some sort of "payment ACK" feature. A
payment ACK scheme is strongly desired as it:
* Allows the sender to actually know when a payment has reached the
receiver which is useful for many higher level protocols. Atm, the
sender is unable to distinguish an HTLC being "black holed" from one
that's actually reached the sender, and they're just holding on to it.
* AMP implementations would be aided by being able to receive feedback on
successfully routed splits. If we're able to have the receiver ACK each
partial payment, then implementations can more aggressively split
payments as they're able to gain assurance that the first 2 BTC of 5
total have actually reached the sender, and weren't black holed.
* Enforcing and relying on ACKs may also thwart silly games receivers
might play, claiming that the HTLC "didn't actually arrive".
Some also call this feature a "soft error" as a possible implementation
might to re-use the existing onion error protocol we've deployed today. For
reference, in order to send back errors back long the route in a way that
doesn't reveal the sender of the HTLC to the receiver (or any of the
intermediate nodes) we re-use the shared secret each hop has derived, and
onion wrap a MAC'd error to the sender. Each hop can't actually check that
they've received a well formed error, but the sender is able to attribute an
error to a node in the route based on which shared secret they're able to
check the MAC with.
The original Sphinx packet format has a way for the receiver to send a
message back to the sender. This was originally envisioned to allow the
receiver to send a replay email/message back to the sender without knowing
who they were, and also in a manner that was bit-wise indistinguishable from
a regular forwarded packet. This is called a SURB or "single use reply
block". A SURB is composed of: a pre-crafted sphinx packet for the
"backwards route" (which can be distinct from the forwards route), the first
hop of the backwards route, and finally a symmetric key to use when
encrypting the reply.
When we more or less settled on using Sphinx, we started to remove things
that we didn't have a clear use for at the time. Two things that were
removed were the original end-to-end payload, and also the SURB. Removing
the payload made the packet size smaller, and it didn't seem realistic to
give _each_ hop a SURB to send reply back.
In order to implement payment ACKs, we can have the sender craft a SURB (for
the ACK), and mark the receipt of the SURB as the payment ACK itself.
Creating and processing a SURB is identical to the regular HTLC packets we
use today. As a result, the code impact to the code sphinx packet logic is
minimal. We'd then also re-introduce the e2e payload so we can carry the
SURB in the forward direction (HLTC add). The backwards packet would also
have a payload of random bytes with the same size as a regular packet to
make them look identical on the wire.
This payload can further be put to use in order to implement streaming or
subscription payments in a way. Since we must add a payload for in order to
send/reply look the same, we can also piggy back some useful additional
data. Each time a payment is sent, the receiver can use the extra payload to
stack on details such as:
* A new invoice to pay for the metered service being paid for.
* An invoice along with a deadline for when this must be paid, lest the
subscription service expire.
* Details of lightning-native API
* etc, etc
IMO, this approach is better than a potential client-server payment
negotiation protocol as it doesn't require any additional servers along side
the node, also maintains sender anonymity, and doesn't rely on any sort of
PKI.
>From the prospective of packet-analysis, errors today are identifiable due
to the packet size (though we do pad them out to avoid being able to
distinguish some errors from others on the wide). SURBs on the other hand,
have the same profile as regular HTLC adds since they use the same Sphinx
packet format. Unlike the wrapped onion errors, intermediate nodes are also
able to validate the integrity of the payment ACK as they'll check the
per-hop
MAC as normal. Additionally, the replies naturally create cover traffic as
they look like regular payments.
One down side is that this would essentially double the size of HTLC
messages on the network today, as they need to also carry SURB. Most
candidates for possible rendezvous schemes to deploy would also increase the
packet size if up to 20 hops it be allowed in both directions. We also
(from my PoV), don't really have a feel on how much of an issue the 1.2KB
HTLC packet size is today in the network.
By re-introducing SURBs, we have an opportunity to cleanly solve the payment
ACK issue, re-use a component of our favorite thing in Lightning, enable
protocol-level streaming/subscription payments and also make replies
indistinguishable-ish from regular payments.
Thoughts?
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190207/77cde3d7/attachment.html>

2023-06-09 12:53:57

- reply

📅 Original date posted:2019-01-14
📝 Original message:
It isn't mandatory. It can be left blank, none of the existing wallets
require users to input a description when they make an invoice.
On Mon, Jan 14, 2019, 3:28 PM Francis Pouliot <francis at satoshiportal.com
wrote:
> I'm currently in the process of building the Lightning Network payout
> feature which will allow users to purchase bitcoins with fiat and have the
> coins sent to the via LN rather than on-chain. The main issue I'm facing is
> ensuring that recipients generate the correct Bolt11 invoice.
>
> Having the "d" and "h" fields mandatory creates a UX issue for Bitcoin
> services that are performing payouts/withdrawals (in the absence of a
> widely adopted payment protocol).
>
> It seems to me that the design of Bolt11 may have been biased towards
> merchants, because normally merchants, as recipients, decide on what the
> invoice is going to be and the sender doesn't have a choice but to conform
> (since the recipient is the service provider).
>
> But for LN payouts (e.g. withdrawal from an exchange or a poker site), the
> Sender is the services provider, and it is the Sender who will be creating
> (most likely programatically) the terms of the payment. However, this means
> that the Sender must be able to communicate to his end-user exactly what
> type of Bolt11 invoice he wants the user to create. This means, in most
> cases, that the user will have to manually enter some fields in his wallet.
> And if the content doesnt match, there will be a payment failure.
>
> Here is how I picture the ux issues taking place.
>
> 1. User goes on my app to buy Bitcoin with fiat, and opts to be paid
> out via LN rather than on-chain BTC.
> 2. My app will tell him: "make an invoice with the following:
> msatoshi, description.
> 3. He will go in his wallet and type msatoshi, description.
> 4. It's likey he won't pay too much attention, make a typo in
> description, leave it blank, write his own description, etc.
> 5. When my app tries to pay, we of course have to decode his bolt11
> first.
> 6. We have to have some logic that will compare the "h" or "d" that we
> instructed him to create and the "h" or "d" that we got from the decoded
> bolt 11 (which is an extra hassle for devs)
> 7. In the cases there they are not the same, we need to instruct the
> user to create a new bolt 11 invoice because the one he created was not
> correct.
>
> What this ends up doing is create a situation where the service provider
> depends on his user to create a correct invoice before sending him the
> funds, and creates an added (unecessary) requirement for communication, and
> lower payment success rates, and likely higher abandonment rate.
>
> Question: what is the logic behind making "d" and "h" mandatory? I think
> business logic should be left to Bitcoin businesses.
>
> Can we simply not make "d" or "h" mandatory without breaking anything?
>
> TL;DR users already have troube entering the correct amount of BTC when
> paying invoices that aren't BIP21, so I am afraid that there will be tons
> of issues with them writing down the correct description.
>
> P.s. I'm using c-lightning right now and would like to not have to switch
>
> P.s.s. this will likely be fixed with a standardised payment protocol but
> addressing this issue seems a lower hanging fruit.
>
> Issue: https://github.com/lightningnetwork/lightning-rfc/issues/541
>
> Thanks is for your time,
>
> Francis
> _______________________________________________
> 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/20190114/09200bcf/attachment-0001.html>

2023-06-09 12:52:37

- reply

📅 Original date posted:2018-11-16
📝 Original message:
> OG AMP is inherently spontaneous in nature, therefore invoice might not
exist
> to put the feature on.
That is incorrect. One can use an invoice along with AMP as is, in order to
tag
a payment. As an example, I want to deposit to an exhcange, so I get an
invoice
from them. I note that the invoice has a special (new) field that indicates
they accept AMP payments, and include an 8-byte identifier. Each of the
payment
shards I send over to the exchange will carry this 8-byte identifier.
Inclusion
of this identifier signals to them to credit my account with the deposit
once
all the payments arrive. This generalizes to any case where a service or
good
is to be dispersed once a payment is received.
-- Laolu
On Mon, Nov 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good Morning Rusty,
>
> OG AMP is inherently spontaneous in nature, therefore invoice might not
> exist to put the feature on.
> Thus it should be global feature.
>
> Do we tie spontaneous payment to OG AMP or do we support one which is
> payable by base AMP or normal singlepath?
>
> Given that both `option_switch_ephkey` and `option_og_amp` require
> understanding extended onion packet types, would it not be better to merge
> them into `option_extra_onion_packet_types`?
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, November 13, 2018 7:49 AM, Rusty Russell <
> rusty at blockstream.com> wrote:
>
> > Hi all,
> >
> > I went through the wiki and made up option names (not yet
> > numbers, that comes next). I re-read our description of global vs local
> > bits:
> >
> > The feature masks are split into local features (which only
> > affect the protocol between these two nodes) and global features
> > (which can affect HTLCs and are thus also advertised to other
> > nodes).
> >
> > You might want to promote your local bit to a global bit so you can
> > advertize them (wumbo?)? But if it's expected that every node will
> > eventually support a bit, then it should probably stay local.
> >
> > Please edit your bits as appropriate, so I can assign bit numbers soon:
> >
> >
> https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States
> >
> > Thanks!
> > 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/20181115/5940c292/attachment.html>

2023-06-09 12:52:21

- reply

📅 Original date posted:2018-11-08
📝 Original message:
Was approaching more so from the angle of a node new node with no existing
channels seeking to bootstrap connections to the network.
-- Sent from my Spaceship
On Fri, Nov 9, 2018, 9:10 AM Anthony Towns <aj at erisian.com.au wrote:
> On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote:
> > > A node, via their node_announcement,
> > Most implementations today will ignore node announcements from nodes that
> > don't have any channels, in order to maintain the smallest routing set
> > possible (no zombies, etc). It seems for this to work, we would need to
> undo
> > this at a global scale to ensure these announcements propagate?
>
> Having incoming capacity from a random node with no other channels doesn't
> seem useful though? (It's not useful for nodes that don't have incoming
> capacity of their own, either)
>
> Cheers,
> aj
>
> _______________________________________________
> 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/0f7898fc/attachment.html>

2023-06-09 12:52:20

- reply

📅 Original date posted:2018-11-08
📝 Original message:
> A node, via their node_announcement,
Most implementations today will ignore node announcements from nodes that
don't have any channels, in order to maintain the smallest routing set
possible (no zombies, etc). It seems for this to work, we would need to undo
this at a global scale to ensure these announcements propagate?
Aside from the incentives for leaches to arise that accept the fee then
insta close (they just drain the network and then no one uses this), I think
this is a dope idea in general! In the past, I've mulled over similar
constructions under a general umbrella of "Channel Liquidity Markets" (CLM),
though via extra-protocol negotiation.
-- Laolu
On Wed, Nov 7, 2018 at 2:38 PM lisa neigut <niftynei at gmail.com> wrote:
> Problem
> ====================================
> Currently it’s difficult to reliably source inbound capacity for your
> node. This is incredibly problematic for vendors and nodes hoping to setup
> shop as a route facilitator. Most solutions at the moment require an
> element of out of band negotiation in order to find other nodes that can
> help with your capacity needs.
>
> While splicing and dual funding mechanisms will give some relief by
> allowing for the initial negotiation to give the other node an opportunity
> to put funds in either at channel open or after the fact, the problem of
> finding channel liquidity is still left as an offline problem.
>
> Proposal
> =====================================
> To solve the liquidity discovery problem, I'd like to propose allowing
> nodes to advertise initial liquidity matching. The goal of this proposal
> would be to allow nodes to independently source inbound capacity from a
> 'market' of advertised liquidity rates, as set by other nodes.
>
> A node, via their node_announcement, can advertise that they will match
> liquidity and a fee rate that they will provide to any incoming
> open_channel request that indicates requests it.
>
> `node_announcement`:
> new feature flag: option_liquidity_provider
> data:
> [4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee
> charged per satoshi of liquidity added at channel open
> [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged
> for providing liquidity at channel open
>
> `open_channel`:
> new feature flag (channel_flags): option_liquidity_buy [2nd least
> significant bit]
> push_msat: set to fee payment for requested liquidity
> [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
> requested at channel open
>
> `accept_channel`:
> tbd. hinges on a dual funding proposal for how second node would send
> information about their funding input.
>
> If a node cannot provide the liquidity requested in `open_channel`, it
> must return an error.
> If the amount listed in `push_msat` does not cover the amount of liquidity
> provided, the liquidity provider node must return an error.
>
> Errata
> ======================================
> It's an open question as to whether or not a liquidity advertising node
> should also include a maximum amount of liquidity that they will
> match/provide. As currently proposed, the only way to discover if a node
> can meet your liquidity requirement is by sending an open channel request.
>
> This proposal depends on dual funding being possible.
>
> Should a node be able to request more liquidity than they put into the
> channel on their half? In the case of a vendor who wants inbound capacity,
> capping the liquidity request allowed seems unnecessary.
>
> Conclusion
> =======================================
> Allowing nodes to advertise liquidity paves the way for automated node
> re-balancing. Advertised liquidity creates a market of inbound capacity
> that any node can take advantage of, reducing the amount of out-of-band
> negotiation needed to get the inbound capacity that you need.
>
>
> Credit to Casey Rodamor for the initial idea.
> _______________________________________________
> 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/20181108/fedb1500/attachment.html>

2023-06-09 12:52:13

- reply

📅 Original date posted:2018-11-06
📝 Original message:
> Mainly limitations of our descriptor language, TBH.
I don't follow...so it's a size issue? Or wanting to avoid "repeated"
fields?
> I thought about restarting the revocation sequence, but it seems like that
> only saves a tiny amount since we only store log(N) entries
Yeah that makes sense, forgetting the HTLC state is a big enough win in and
of itself.
>>> Splice Signing
>>
>> It seems that we're missing some fields here if we're to allow the
splicing
>> of inputs to be done in a non-blocking manner. We'll need to send two
>> revocation points for the new commitment: one to allow it to be created,
and
>> another to allow updates to proceed right after the signing is
completed. In
>> this case we'll also need to update both commitments in tandem until the
>> splicing transaction has been sufficiently confirmed.
>
>I think we can use the existing revocation points for both.
Yep, if we retain the existing shachain trees, then we just continue to
extend the leaves!
> We're basically co-generating a tx here, just like shutdown, except it's
> funding a new replacement channel. Do we want to CPFP this one too?
It'd be nice to be able to also anchor down this splicing transaction given
that we may only allow a single outstanding splicing operation to begin
with. Being able to CPFP it (and later on provide arbitrary fee inputs)
allows be to speed up the process if I want to queue another operation up
right afterwards.
-- Laolu
On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> > Hi Rusty,
> >
> > Happy to get the splicing train rolling!
> >
> >> We've had increasing numbers of c-lightning users get upset they can't
> >> open multiple channels, so I guess we're most motivated to allow
> splicing
> > of
> >> existing channels
> >
> > Splicing isn't a substitute for allowing multiple channels. Multiple
> > channels allow nodes to:
> >
> > * create distinct channels with distinct acceptance policies.
> > * create a mix of public and non-advertised channels with a node.
> > * be able to send more than the (current) max HTLC amount
> > using various flavors of AMP.
> > * get past the (current) max channel size value
> > * allow a link to carry more HTLCs (due to the current super low max
> HTLC
> > values) given the additional HTLC pressure that
> > AMP may produce (alternative is a commitment fan out)
>
> These all seem marginal to me. I think if we start hitting max values,
> we should discuss increasing them.
>
> > Is there a fundamental reason that CL will never allow nodes to create
> > multiple channels? It seems unnecessarily limiting.
>
> Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1
> channel. My own fault: I was the one who insisted we mux multiple
> connections over the same transport; if we'd gone for independent
> connections our implementation would have been trivial.
>
> >> Splice Negotiation:
> >
> > 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.
>
> Mainly limitations of our descriptor language, TBH.
>
> > I like that the intro messages have already been designed with the
> > concurrent case in mind beyond a simpler propose/accept flow. However is
> > there any reason why it doesn't also allow either side to fully
> re-negotiate
> > _all_ the funding details? Splicing is a good opportunity to garbage
> collect
> > the prior revocation state, and also free up obsolete space in watch
> towers.
>
> 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.
>
> > 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.
>
> Yep, good idea! I missed that.
>
> Brings up a side point about these values, which deserves its own
> post...
>
> >> 1. type: 40 (`splice_add_input`) (`option_splice`)
> >
> > In order to add nested p2sh inputs, we'll need to also expose the redeem
> > script here, or add additional fields to allow sides to set a sig script
> as
> > well as witness during the signing phase.
> >
> >> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash>
> EQUAL'
> >
> > So no P2SH? :(
>
> Another omission, yeah, we'd want that too I think.
>
> >> * [`4`:`feerate_per_kw`]
> >
> > What fee rate is this? IMO we should do commitmentv2 before splicing as
> then
> > we can more or less do away with the initiator distinction and have most
> > fees be ad hoc.
>
> We're basically co-generating a tx here, just like shutdown, except it's
> funding a new replacement channel. Do we want to CPFP this one too?
>
> >> Splice Signing
> >
> > It seems that we're missing some fields here if we're to allow the
> splicing
> > of inputs to be done in a non-blocking manner. We'll need to send two
> > revocation points for the new commitment: one to allow it to be created,
> and
> > another to allow updates to proceed right after the signing is
> completed. In
> > this case we'll also need to update both commitments in tandem until the
> > splicing transaction has been sufficiently confirmed.
>
> I think we can use the existing revocation points for both.
>
> > Also, what about change addresses? Are they to be explicitly specified as
> > splice outs?
>
> They'd be splice-outs, yeah.
>
> >> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)
> >
> > It may be worth pointing out there that we're able to transfer all
> existing
> > HTLCs over to the new commitment as additional context.
>
> Yeah, I think people missed that it was non-blocking like that.
>
> >> 1. type: 45 (`splice_witness`) (`option_splice`)
> >
> > Should also allow either side to specify the sig script here if we're to
> > allow nested p2sh (which we should IMO!).
>
> Yep.
>
> >> * [`2`:`len`]
> >> * [`len`:`witnesses`]
> >
> > Is the extra length needed if all the witness elements themselves are
> length
> > delimited?
>
> Yes, we always length-delimit fields so we can add options later.
>
> >
> > It isn't clear in the current draft, but I take it that the
> splice_signature
> > is for the old multi-sig?
>
> Yes, that's the signature required to spend the old funding txout.
>
> >> so we append to the existing `channel_update` for the original channel,
> >> using a new `message_flags` field:
> >
> > IMO, we need to hold off on optional fields for now, until we revisit the
> > formatting in order to actually get it right. As is now, all the optional
> > fields are basically serial mandatory soft forks. So clients must
> understand
> > the prior in order to understand the following fields. Instead, we
> > essentially need more of a map design.
>
> You need to add prior options to your wire parser, but that's usually
> the most trivial part of handling them. And they may waste space on the
> wire since we treat them as append-only, but OTOH it avoids
> combinatorial testing explosion.
>
> >> The post-splice reserve is 1% of post-splice capcacity (rounded down).
> >
> > This should be re-negotiated at time of splice creation, rather than a
> new
> > hard coded value in the protocol.
> >
> >> In addition, you can forget everything about the old channel (including
> >> old HTLCs and revocation requirements).
> >
> > We still have the same shachain state however (if we don't allow new
> state
> > to be exchanged during the start of the splicing scenario), correct?
>
> Yep.
>
> Thanks,
> Rusty.
>
> > -- Laolu
> >
> > -- Laolu
>
> PS, Damn, I always suspected there were multiple Roasbeefs, and we're
> simply
> dealing with the output of an advanced multiplexing protocol. I present
> the above as conclusive evidence of this thesis...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/15a6f5a1/attachment-0001.html>

2023-06-09 12:52:11

- reply

📅 Original date posted:2018-11-06
📝 Original message:
Hi Rusty,
I'm a big fan in general of most of this! Amongst many other things, it'll:
simplify the whole static channel backup + recovery workflow, and avoid all
the fee related headaches we've run into over the past few months.
> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
Would this mean that we no longer extend fees to the second-level
transactions as well? If so, then a dusty HTLC would be determined solely by
looking at the direct output, rather than the resulting output in the second
layer.
> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`,
> `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a
> two-stage unhardened BIP-32 derivation based on the commitment number.
It seems enough to _only_ modify the derivation for local+remote pubkey (so
the direct "settle" keys). This constrains the change to only what's
necessary to simplify the backup+recovery workflow with the current
commitment design. By restricting the change to these two keys, we minimize
the code impact to the existing implementations, and avoid unnecessary
changes that don't make strides towards the immediate goal.
> - `to_remote` is now a P2WSH of:
> `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG
This seems at odds with the goal of "if the remote party force closes, then
I get my funds back immediately without requiring knowledge of any secret
data". If it was just a plain p2wkh, then during a routine seed import and
rescan (assuming ample look ahead as we know this is a "special" key), I
would pick up outputs of channels that were force closed while I was down
due to my dog eating my hard drive.
Alternatively, since the range of CSV values can be known ahead of time, I
can brute force a set of scripts to look for in the chain. However, this
results in potentially a very large number of scripts (depending on how many
channels one has, and bounds on the acceptable CSV) I need to scan for.
-- Laolu
On Fri, Oct 12, 2018 at 3:57 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> There have been a number of suggested changes to the commitment
> transaction format:
>
> 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)
> 2. The `remotepubkey` should be a BIP-32-style, to avoid the
> option_data_loss_protect "please tell me your current
> per_commitment_point" problem[1]
> 3. The CLTV timeout should be symmetrical to avoid trying to game the
> peer into closing. (Connor IIRC?).
>
> It makes sense to combine these into a single `commitment_style2`
> feature, rather than having a testing matrix of all these disabled and
> enabled.
>
> BOLT #2:
>
> - If `commitment_style2` negotiated, update_fee is a protocol error.
>
> This mainly changes BOLT #3:
>
> - The feerate for commitment transactions is always 253 satoshi/Sipa.
> - Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi.
> - Fees, OP_TRUE are always paid by the initial funder, because it's simple,
> unless they don't have funds (eg. push_msat can do this, unless we
> remove it?)
> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`,
> `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`
> derivation now uses a two-stage unhardened BIP-32 derivation based on
> the commitment number. Two-stage because we can have 2^48 txs and
> BIP-32 only supports 2^31: the first 17 bits are used to derive the
> parent for the next 31 bits?
> - `to_self_delay` for both sides is the maximum of either the
> `open_channel` or `accept_channel`.
> - `to_remote` is now a P2WSH of:
> `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG
>
> Cheers,
> Rusty.
>
> [1] I recently removed checking this field from c-lightning, as I
> couldn't get it to reliably work under stress-test. I may just have
> a bug, but we could just fix the spec instead, then we can get our
> funds back even if we never talk to the peer.
> _______________________________________________
> 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/20181106/9aa80d96/attachment.html>

2023-06-09 12:51:44

- reply

📅 Original date posted:2018-10-15
📝 Original message:
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling),
The on-chain footprint is a shame, and also it gets worse if we start to
allow multiple pending splices. Also the lack of a non-blocking splice in is
a big draw back IMO.
> but mostly because I do not see splicing as being as important as AMP or
> watchtowers (and payment decorrelation seems to affect how AMP can be
> implemented, so its priority also goes up).
Most of what you mention here have _very_ different deployment timelines and
synchronization requirements across clients. For example, splicing is a link
level change and can start to be rolled out immediately. Decorrelation on
the other hand, is a _network_ level change, and would take a considerable
amount of time to reach widespread deployment as it essentially splits the
rouble paths in the network until all/most are upgraded.
If you think any of these items is a higher priority than splicing then you
can simply start working on them! There's no agency that prescribes what
should and shouldn't be pursued or developed, just your willingness to
write some code.
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.
-- Laolu
On Thu, Oct 11, 2018 at 11:14 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Rusty,
>
> >
> > > It may be good to start brainstorming possible failure modes during
> splice, and how to recover, and also to indicate the expected behavior in
> the proposal, as I believe these will be the points where splicing must be
> designed most precisely. What happens when a splice is ongoing and the
> communication gets disconnected? What happens when some channel failure
> occurs during splicing and we are forced to drop onchain? And so on.
> >
> > Agreed, but we're now debating two fairly different methods for
> > splicing. Once we've decided on that, we can try to design the
> > proposals themselves.
>
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling), but mostly because I do not see
> splicing as being as important as AMP or watchtowers (and payment
> decorrelation seems to affect how AMP can be implemented, so its priority
> also goes up). So I think getting *some* splicing design out would be
> better even if imperfect. Others may disagree on priority.
>
> 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/20181015/dca18600/attachment.html>

2023-06-09 12:51:44

- reply

📅 Original date posted:2018-10-15
📝 Original message:
Hi Rusty,
Happy to get the splicing train rolling!
> We've had increasing numbers of c-lightning users get upset they can't
> open multiple channels, so I guess we're most motivated to allow splicing
of
> existing channels
Splicing isn't a substitute for allowing multiple channels. Multiple
channels allow nodes to:
* create distinct channels with distinct acceptance policies.
* create a mix of public and non-advertised channels with a node.
* be able to send more than the (current) max HTLC amount
using various flavors of AMP.
* get past the (current) max channel size value
* allow a link to carry more HTLCs (due to the current super low max HTLC
values) given the additional HTLC pressure that
AMP may produce (alternative is a commitment fan out)
Is there a fundamental reason that CL will never allow nodes to create
multiple channels? It seems unnecessarily limiting.
> Splice Negotiation:
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.
I like that the intro messages have already been designed with the
concurrent case in mind beyond a simpler propose/accept flow. However is
there any reason why it doesn't also allow either side to fully re-negotiate
_all_ the funding details? Splicing is a good opportunity to garbage collect
the prior revocation state, and also free up obsolete space in watch towers.
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.
> 1. type: 40 (`splice_add_input`) (`option_splice`)
In order to add nested p2sh inputs, we'll need to also expose the redeem
script here, or add additional fields to allow sides to set a sig script as
well as witness during the signing phase.
> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
So no P2SH? :(
> * [`4`:`feerate_per_kw`]
What fee rate is this? IMO we should do commitmentv2 before splicing as then
we can more or less do away with the initiator distinction and have most
fees be ad hoc.
> Splice Signing
It seems that we're missing some fields here if we're to allow the splicing
of inputs to be done in a non-blocking manner. We'll need to send two
revocation points for the new commitment: one to allow it to be created, and
another to allow updates to proceed right after the signing is completed. In
this case we'll also need to update both commitments in tandem until the
splicing transaction has been sufficiently confirmed.
Also, what about change addresses? Are they to be explicitly specified as
splice outs?
> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)
It may be worth pointing out there that we're able to transfer all existing
HTLCs over to the new commitment as additional context.
> 1. type: 45 (`splice_witness`) (`option_splice`)
Should also allow either side to specify the sig script here if we're to
allow nested p2sh (which we should IMO!).
> * [`2`:`len`]
> * [`len`:`witnesses`]
Is the extra length needed if all the witness elements themselves are length
delimited?
It isn't clear in the current draft, but I take it that the splice_signature
is for the old multi-sig?
> so we append to the existing `channel_update` for the original channel,
> using a new `message_flags` field:
IMO, we need to hold off on optional fields for now, until we revisit the
formatting in order to actually get it right. As is now, all the optional
fields are basically serial mandatory soft forks. So clients must understand
the prior in order to understand the following fields. Instead, we
essentially need more of a map design.
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
This should be re-negotiated at time of splice creation, rather than a new
hard coded value in the protocol.
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
We still have the same shachain state however (if we don't allow new state
to be exchanged during the start of the splicing scenario), correct?
-- Laolu
-- Laolu
On Tue, Oct 9, 2018 at 8:46 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all!
>
> We've had increasing numbers of c-lightning users get upset they
> can't open multiple channels, so I guess we're most motivated to allow
> splicing of existing channels. Hence this rough proposal.
>
> For simplicity, I've chosen to only allow a single splice at a time.
> It's still complex :(
>
> Feedback welcome!
> --
> Splice Negotiation:
>
> 1. type: 40 (`splice_add_input`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`: `satoshis`]
> * [`32`: `prevtxid`]
> * [`4`: `prevtxoutnum`]
> * [`2`: `scriptlen`]
> * [`scriptlen`: `scriptpubkey`]
>
> 1. type: 41 (`splice_add_output`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`: `satoshis`]
> * [`2`: `scriptlen`]
> * [`scriptlen`: `outscript`]
>
> 1. type: 42 (`splice_all_added`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`4`:`feerate_per_kw`]
> * [`4`:`minimum_depth`]
>
> Each side sends 0 or more `splice_add_input` and 0 or more
> `splice_add_output` followed by `spice_all_added` to complete the splice
> proposal. This is done either to initiate a splice, or to respond to a
> `splice_*` from the other party.
>
> `splice_add_input` is checked for the following:
> - must not be during a current splice
> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
> - `satoshis` doesn't wrap on addition.
> - MAY check that it matches outpoint specified (sig will simply be
> invalid if so), and that outpoint is segwit.
>
> `splice_add_output` is checked for the following:
> - must not be during a current splice
> - `satoshis` is less than or equal to amount owing to proposer, minus
> current reserve, and greater than or equal to `dust_limit_satoshis` we
> sent in our open_channel/accept_channel ,sg.
> - script is one of the approved forms as it is for `shutdown`.
>
> FIXME: Do we disallow splice-out if they specified
> option_upfront_shutdown_script?
>
> `splice_all_added` is checked for the following:
> - average of `feerate_per_kw` by both sides (round down) is sufficient.
> - average of `feerate_per_kw` by both sides not grossly excessive, if we're
> paying some of the fees (see below!)
> - both sides can afford the fees from their post-splice funds (see
> Verification Changes below)
> - maximum of the two `minimum_depth` is not grossly excessive.
> - There is at least one splice_add_input or splice_add_output.
>
> Splice negotiation, like closing negotiation, does not have persistent
> state. Reconnecting forgets previous negotiation.
>
>
> Splice Signing
> --------------
>
> Once `splice_all_added` is both sent and received, we need to create and
> sign both the splice tx itself, and the first commitment transaction
> which spends it (but not in that order!).
>
> 1. One input spends the current funding tx output.
> 2. There is one additional input for each splice_add_input.
> 3. One output creates the new funding tx.
> 4. There is one additional output for each splice_add_output.
> 5. The entire transaction is sorted into BIP69 order.
> 6. The feerate is the sum of the two `feerate_per_kw` divided by 2,
> rounded down.
>
> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`64`:`commitment_signature`]
> * [`2`:`num_htlcs`]
> * [`num_htlcs*64`:`htlc_signature`]
>
> 1. type: 44 (`splice_signature`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`64`:`splice_signature`]
>
> 1. type: 45 (`splice_witness`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`2`: `num_witness_elements`
> * [`2`:`len`]
> * [`len`:`witnesses`]
>
> `witnesses` itself is serialized as `num_witness_elements` of:
> * `2`:`len`
> * `len`: `witness_element`
>
> Each side sends `splice_commitment_signature` and waits to receive and
> verify the other side's `splice_commitment_signature` before sending
> `splice_signature` and `splice_witness` for each `splice_add_input` it
> proposed, in BIP69 input order.
>
> Once a node has sent `splice_commitment_signature` it should remember
> the splice proposal across reconnects. Once it has both sent
> `splice_signature`, the splice is locked in.
>
>
> Splice Announcement
> -------------------
>
> We have to tell the network about the new channel, otherwise there will
> be a distruption when it sees the old funding transaction spent. This
> is inevitable for older nodes who won't understand splicing anyway.
>
> We can't send out a `channel_announcement` or `channel_update` for the
> new channel until after the new funding transaction has 6 confirmations,
> so we append to the existing `channel_update` for the original channel,
> using a new `message_flags` field:
>
> | 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)
>
> If a current `channel_update` for a closing channel contains
> `option_channel_moving` a node SHOULD ignore the channel close for at
> least 100 blocks iff spent by `moving_txid`.
>
> A node SHOULD immediately forward a `channel_update` it sees containing
> `option_channel_moving` if neither previous `channel_update` for the
> channel contains `option_channel_moving`.
>
> Each side of the splice can send these unilaterally, and SHOULD allow a
> few minutes for propagation (remember, average propagation from old
> nodes is still 30 seconds) prior to broadcast of the splice transaction.
>
>
> Message Changes During Splicing
> -------------------------------
> Once you've sent `splice_commitment_signature` each commitment
> transaction is duplicated: one spends the old funding transaction, one
> spends the splice transaction:
>
> 1. type: 39 (`closing_signed`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`fee_satoshis`]
> * [`64`:`signature`]
> * [`64`:`splice_signature`] (`option_splice`)
>
> 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`)
>
> If a reconnection occurs between between sending and receiving
> `splice_commitment_signature`) the peer's status is uncertain (similarly
> for closing). This we have a new field in `channel_reestablish` to flag
> that we consider ourselves to be splicing:
>
> 1. type: 136 (`channel_reestablish`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`next_local_commitment_number`]
> * [`8`:`next_remote_revocation_number`]
> * [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
> * [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
> * [`32`:`splice_txid`] (`option_splice`)
>
> The splice_txid field indicates that this side considers itself to be
> splicing.
>
> The sender:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`, MUST set `splice_txid` to the txid of the splice tx.
> - Otherwise MUST NOT.
>
> The recipient:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`:
> - if `splice_txid` does not exist or does not match the current splice:
> - SHOULD fail the channel
> - otherwise:
> - MUST retransmit `splice_signature`
> - otherwise:
> - if `splice_txid` field exists and is not all zeroes:
> - MUST send `splice_closed`
>
>
> Validation Changes During Splicing
> ----------------------------------
> We track "post-splice" values as well as current values during
> splicing.
>
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
>
> The fees for the splicing transaction itself are divided into parts by
> the number of `splice_add_input` plus `splice_add_output`, rounded up.
> Each side pays as many parts as it proposed `splice_add_input` plus
> `splice_add_output`.
>
> (So if Alice proposes two and Bob proposes one, and the total fee is 1000
> satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)
>
> Each side's post-splice funds are debited their `splice_add_output`
> amounts, and credited their `splice_add_input` amounts, a debited the
> splice tx fees. If any debiting occurs, the funds must be above the
> post-splice reserve (ie. you can have below reserve, but you can't spend
> if you're below reserve).
>
> All update_add_htlc must be valid for the *both* the current and
> post-splice balances.
>
> Completing Splicing
> -------------------
> Once you've seen both side's `minimum_depth` confirmations of the splice
> transaction (ie. the maximum of the two `minimum_depth` values), you can
> complete the splice by sending:
>
> 1. type: 46 (`splice_closed`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
>
> Once you've sent and received `splice_closed` you can send
> `announcement_signatures` for the new channel as per normal rules (ie. 6
> confirmations, `announce_channel` bit set).
>
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
> _______________________________________________
> 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/20181015/493ab074/attachment-0001.html>

2023-06-09 12:51:31

- reply

📅 Original date posted:2018-09-21
📝 Original message:
> That might not be so desirable, since it leaks the current channel
> capacity to the user
>From my PoV, the only way a node can protect the _instantaneous_ available
bandwidth in their channel is to randomly reject packets, even if they have
the bandwidth to actually accept and forward them.
Observe that if a "prober" learns that you've _accepted_ a packet, then
they know you have at least that amount as available bandwidth. As a result,
I can simply send varying sat packet sizes over to you, either with the
wrong timelock, or an unknown payment hash. Since we don't yet have the
"unadd" feature in the protocol, you _must_ accept the HTLC before you can
cancel it. This is mitigated a bit by the max_htlc value in the channel
update (basically our version of an MTU), but I can still just send
_multiple_ HTLC's rather than one big one to attempt to ascertain your
available bandwidth.
-- Laolu
On Thu, Sep 20, 2018 at 1:31 AM Johan Torås Halseth <johanth at gmail.com>
wrote:
> I was thinking you could just make many requests to get the same
> information, but if you always choose the same channel as long as its
> capacity meets the requirement, then not much is learnt :)
>
>
>
> On Thu, Sep 20, 2018 at 9:26 AM Christian Decker <
> decker.christian at gmail.com> wrote:
>
>> That might not be so desirable, since it leaks the current channel
>> capacity to the user. Depending on how fine grained the amount in the
>> invoice is and how the user can control it, he could do a binary search
>> over capacities and very reliably tell how much capacity you have and
>> track it over time. That is still the case for a single channel, but if
>> you always chose the same channel it reduces how much info is leaked.
>>
>> Cheers,
>> Christian
>>
>> Johan Torås Halseth <johanth at gmail.com> writes:
>> > Any reason not to include _all_ (up to a limit) incoming channels with
>> > sufficient capacity?
>> >
>> > Cheers,
>> > Johan
>> >
>> > On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell <rusty at blockstream.com>
>> wrote:
>> >
>> >> Hi all,
>> >>
>> >> I'm considering a change to c-lightning, where `invoice` would
>> >> automatically append an 'r' field for a channel which has sufficient
>> >> *incoming* capacity for the amount (using a weighted probability across
>> >> our peers).
>> >>
>> >> This isn't quite what 'r' was for, but it would be a useful
>> >> hint for payment routing and also potentially for establishing an
>> >> initial channel. This is an issue for the Blockstream Store which
>> >> deliberately doesn't advertize an address any more to avoid
>> >> centralization.
>> >>
>> >> Thoughts welcome!
>> >> 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
>>
> _______________________________________________
> 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/20180921/034910ba/attachment.html>

2023-06-09 12:51:31

- reply

📅 Original date posted:2018-09-28
📝 Original message:
> This is orothogonal. There's no point probing your own channel, you're
> presumably probing someone else's.
In my scenario, you're receiving a new HTLC, from some remote party
unbeknownst to you. I was replying to cdecker's reply to johan that one
wouldn't always add this new type of routing hint for all channels since it
leaks available bandwidth information. Without something like an "unadd" you
can't do anything against an individual attempting to prob you other than
drop packets (drop as in don't even add to your commit, resulting in an HTLC
timeout), as if you cancel back, then they know that you had enough
bandwidth to _accept_ the HTLC in the first place.
-- Laolu
On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell <rusty at blockstream.com> wrote:
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> >> That might not be so desirable, since it leaks the current channel
> >> capacity to the user
> >
> >>From my PoV, the only way a node can protect the _instantaneous_
> available
> > bandwidth in their channel is to randomly reject packets, even if they
> have
> > the bandwidth to actually accept and forward them.
> >
> > Observe that if a "prober" learns that you've _accepted_ a packet, then
> > they know you have at least that amount as available bandwidth. As a
> result,
> > I can simply send varying sat packet sizes over to you, either with the
> > wrong timelock, or an unknown payment hash.
>
> Yes. You have to have a false capacity floor, which must vary
> periodically, to protect against this kind of probing (randomly failing
> attempts as you get close to zero capaicty is also subject to probing,
> AFAICT).
>
> > Since we don't yet have the
> > "unadd" feature in the protocol, you _must_ accept the HTLC before you
> can
> > cancel it. This is mitigated a bit by the max_htlc value in the channel
> > update (basically our version of an MTU), but I can still just send
> > _multiple_ HTLC's rather than one big one to attempt to ascertain your
> > available bandwidth.
>
> This is orothogonal. There's no point probing your own channel, you're
> presumably probing someone else's.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180928/3fae8786/attachment.html>

2023-06-09 12:51:05

- reply

📅 Original date posted:2018-07-05
📝 Original message:
> Was referring to losing proof-of-payment; that's vital in a system without
> intermediaries. We have to decide what the lesser evil is.
As is now, we don't have a proper proof of payment. We have a "proof that
someone paid". A proper proof of payment would be: "proof that bob paid
carol".
Aside from that, spontaneous payments is amongst the most request feature
request I get from users and developers.
There're a few ways to achieve this with dlog based AMPs.
As far hash based AMPs, with a bit more interaction, and something like
zkboo,
one can achieve stronger binding. However, we'd lose the nice "one shot"
property that dlog based AMPs allow.
> And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo
> pretty, but because actually capturing it will be a saga.
eltoo won't be the end-all-be-all as it comes along with several tradeoffs,
like everything else does.
Also, everything we can do with Schnorr, we can also do with ECDSA, but
today.
-- Laolu
On Wed, Jul 4, 2018 at 7:12 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> > What's the nasty compromise?
> >
> > Let's also not underestimate how big of an update switching to dlog based
> > HTLCs will be.
>
> Was referring to losing proof-of-payment; that's vital in a system
> without intermediaries. We have to decide what the lesser evil is.
>
> And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo
> pretty, but because actually capturing it will be a saga.
>
> Cheers,
> Rusty.
>
> > On Wed, Jul 4, 2018, 4:21 PM Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> >
> >> Christian Decker <decker.christian at gmail.com> writes:
> >>
> >> > ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
> >> writes:
> >> >> For myself, I think splice is less priority than AMP. But I prefer an
> >> >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
> >> >> implies receipt of payment at payee, to facilitate trustless
> >> >> on-to-offchain and off-to-onchain bridges).
> >> >
> >> > Agreed, multipath routing is a priority, but I think splicing is just
> as
> >> > much a key piece to a better UX, since it allows to ignore differences
> >> > between on-chain and off-chain funds, showing just a single balance
> for
> >> > all use-cases.
> >>
> >> Agreed, we need both. Multi-channel was a hack because splicing doesn't
> >> exist, and I'd rather not ever have to implement multi-channel :)
> >>
> >> AMP is important, but it's a nasty compromise with the current
> >> limitations. I want to have my cake and eat it too, and I'm pretty sure
> >> it's possible once the Scnorr-Eltoonicorn arrives.
> >>
> >> 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/20180704/27c23619/attachment-0001.html>

2023-06-09 12:51:04

- reply

📅 Original date posted:2018-07-04
📝 Original message:
What's the nasty compromise?
Let's also not underestimate how big of an update switching to dlog based
HTLCs will be.
On Wed, Jul 4, 2018, 4:21 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Christian Decker <decker.christian at gmail.com> writes:
>
> > ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
> writes:
> >> For myself, I think splice is less priority than AMP. But I prefer an
> >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
> >> implies receipt of payment at payee, to facilitate trustless
> >> on-to-offchain and off-to-onchain bridges).
> >
> > Agreed, multipath routing is a priority, but I think splicing is just as
> > much a key piece to a better UX, since it allows to ignore differences
> > between on-chain and off-chain funds, showing just a single balance for
> > all use-cases.
>
> Agreed, we need both. Multi-channel was a hack because splicing doesn't
> exist, and I'd rather not ever have to implement multi-channel :)
>
> AMP is important, but it's a nasty compromise with the current
> limitations. I want to have my cake and eat it too, and I'm pretty sure
> it's possible once the Scnorr-Eltoonicorn arrives.
>
> 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/20180704/f422b9e3/attachment.html>

2023-06-09 12:51:04

- reply

📅 Original date posted:2018-07-05
📝 Original message:
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out
> splice.
> For myself, I would rather leave out AMP and double-funding and splicing
> than remove ZKCP.
It isn't one or the other. ZKCPs are compatible with various flavors of AMP.
All of these technologies can be rolled out, some with less coordination
than others. Please stop presenting these upgrades as if they're opposing
and fundamental constrains only allow a handful of them to be deployed.
Dual funded channels allow for immediate bi-directional transfers between
endpoints. Splicing allows channels to contract or grow, as well as: pay out
to on chain addresses, fund new channel on the fly, close into old channels,
consolidate change addresses, create fee inputs for eltoo, orchestrate
closing/opening coin-joins, etc, etc.
-- Laolu
On Wed, Jul 4, 2018 at 10:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning all,
>
> > > What's the nasty compromise?
> > >
> > > Let's also not underestimate how big of an update switching to dlog
> based
> > >
> > > HTLCs will be.
> >
> > Was referring to losing proof-of-payment; that's vital in a system
> >
> > without intermediaries. We have to decide what the lesser evil is.
>
> Without the inherent ZKCP, it becomes impossible to build a trustless
> off-to-on/on-to-offchain bridge, since a trustless swap outside of
> Lightning becomes impossible. To my mind, ZKCP is an important building
> block in cryptocurrency: it is what we use in Lightning for routing.
> Further, ZKCP can be composed together to form a larger ZKCP, which again
> is what we use in Lightning for routing.
>
> The ZKCP here is what lets LN endpoint to interact with the chain and lets
> off-to-on/on-to-offchain bridges to be trustless.
>
> off/onchain bridges are important as they provide:
>
> 1. Incoming channels: Get some onchain funds from cold storage (or
> borrowed), create an outgoing channel (likely to the bridge for best chance
> of working), then ask bridge for an invoice to send money to an address you
> control onchain. The outgoing channel capacity becomes incoming capacity,
> you get (most of) your money back (minus fees) onchain.
> 2. Reloading spent channels. Give bridge an invoice and pay to the
> bridge to trigger it reloading your channel.
> 3. Unloading full channels. If you earn so much money (minus what you
> spend on expenses, subcontractors, employees, suppliers, etc.) you can use
> the bridge to send directly to your cold storage.
>
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out
> splice.
>
> The interaction between bridge and Lightning is simply via BOLT11
> invoices. Those provide the ZKCP necessary to make the bridge trustless.
>
> AMP enhances such a Lightning+bridge network, since the importance of
> maximum channel capacity is reduced if a ZKCP-providing AMP is available.
> For myself, I would rather leave out AMP and double-funding and splicing
> than remove ZKCP.
>
> One could imagine a semi-trusted ZKCP service for real-world items. Some
> semi-trusted institution provides special safeboxes for rent that can be
> unlocked either by seller private key after 1008 blocks, or by the
> recipient key and a proof-of-payment preimage (and records the preimage in
> some publicly-accessible website). To sell a real-world item, make a
> BOLT11 invoice, bring item to a safebox, lock it with appropriate keys and
> the invoice payment hash, give BOLT11 invoice to buyer. Buyer pays and
> gets proof-of-payment preimage, goes to safebox and gets item. Multi-way
> trades (A wants item from B, B wants item from C, C wants item from A) are
> just compositions of ZKCP.
>
> >
> > And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo
> >
> > pretty, but because actually capturing it will be a saga.
>
> Bards shall sing about The Hunt for Schnorr-Eltoonicorn for ages, until
> Satoshi himself is but a vague memory of a myth long forgotten.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180704/40862c92/attachment.html>

2023-06-09 12:51:00

- reply

📅 Original date posted:2018-07-03
📝 Original message:
Dmytro wrote:
> Yet the question remains — are there obvious advantages of cycle
> transactions over a smart fee/routing system?
That's a good question, it may be the case that by modifying the fee
structure to punish flows that unbalance channels further, then this can
simplify the problem as the heuristics can target solely the fee rate. The
earliest suggestion of this I can recall was from Tadge way back in like
2015 or so. The goal here is for a node to ideally maintain relatively
balanced channels, but then charge a payment an amount that scales super
linearly when flows consume most of their available balance.
The current fee schedule is essentially:
base_fee + amt*rate
clighting and lnd (borrowed from c-lightning) currently use a "risk factor"
to factor in the impact of the time lock on the "weight" of an edge when
path finding. With this, the fee schedule looks like:
(base_fee + amt*rate) + (cltv_delta * risk_factor / 1,000,0000)
In the future, we may want to allow nodes to also signal how they wish the
fee to scale with the absolute CLTV of the HTLC extend to this. This would
allow them to more naturally factor in their conception of the time value of
their BTC.
Finally, if we factor in an "balance disruption" factor, the fee schedule
may look something like this:
(base_fee + amt*rate) + (cltv_delta * risk_factor / 1,000,0000) +
gamma*f(capacity, amt)
Here f is a function whose output is proportional to the distance the
payment flow (assuming full capacity at that instance) puts the channel away
from being fully balanced, and gamma is a coefficient that allows nodes to
express the degree of penalty for unbalancing a channel. f itself is either
agreed upon by the network completely, or resembles a certain polynomial,
allowing nodes to select coefficients as they wish.
We may want to consider moving to something like this for BOLT 1.x+ as it
allows nodes to quantify their apprehension to time locks and also
channel balance equilibrium affinity.
Alternatively, if we move to something like HORNET, then during the set up
phase, nodes can ask for an initial "quote" for a set of payment ranges,
then just use that quote for all payments sent. This allows nodes to keep
their fee schedules private (for w/e reason) and also change them at a whim
if they wish.
-- Laolu
On Sun, Jul 1, 2018 at 8:39 AM Dmytro Piatkivskyi <
dmytro.piatkivskyi at ntnu.no> wrote:
> Hi Rene,
>
> Thanks for your answer!
>
> 1. The Lightning network operates under different assumptions, that is
> true. However, the difference is minor in terms of the issue posed. The
> premise for the quoted statement is that taking fees changes the nodes’
> balances, therefore selected paths affect the liquidity. In the Lightning
> network fees are very small, so the change in liquidity may be negligible.
> Moreover, intermediate nodes gain in fees, which only increases the
> liquidity.
>
> 2.A. It is too early to speculate where the privacy requirements will
> settle down. Flare suggests a mechanism of sharing the infrastructure view
> between nodes, possibly sharing weights. As the network grows routing will
> become more difficult, however we don’t know yet to which extent. It may
> organise itself in ‘domains’, so when we send a payment we know to which
> domain we are sending to, knowing the path to it beforehand. The point is
> we don’t know yet, so we can’t speculate.
>
> 2.B. That is surely an interesting aspect. HTLC locks
> temporarily downgrade the network liquidity. Now the question is how it
> changes the order of transactions and how that order change affects the
> transaction feasibility. Does it render some transactions infeasible or
> just defers them? It definitely needs a closer look.
>
> Yet the question remains — are there obvious advantages of cycle
> transactions over a smart fee/routing system? In any sense. Path lengths,
> for example. To answer that I am going to run a simulation, but also would
> appreciate your opinions.
>
> Best,
> Dmytro
>
> From: René Pickhardt <r.pickhardt at googlemail.com>
> Date: Sunday, 1 July 2018 at 13:59
> To: Dmytro Piatkivskyi <dmytro.piatkivskyi at ntnu.no>
> Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Rebalancing argument
>
> Hey Dmytro,
>
> thank your for your solid input to the discussion. I think we need to
> consider that the setting in the lightning network is not exactly
> comparable to the one described in the 2010 paper.
>
> 1st: the paper states in section 5.2: "It appears that a mathematical
> analysis of a transaction routing model where intermediate nodes charged a
> routing fee would require an entirely new approach since it would
> invalidate the cycle-reachability relation that forms the basis of our
> results."
> Since we have routing fees in the lightning network to my understanding
> the theorem and lemma you quoted in your medium post won't hold.
>
> 2nd: Even if we neglect the routing fees and assume the theorem still
> holds true we have two conditions that make the problem way more dynamic:
> A) In the lightning network we do not know the weights of the directed
> edges. (only the sum of two opposing edges) So while theoretically the flow
> in the network will only depend on the liquidity of the nodes I guess in
> practice well balanced channels will increase the probability to actually
> find a working route.
> B) I believe the HTLCs create a situation where funds are being locked up
> while routing takes place and thus have an impact to the entire flow of the
> network. While Alice searches for a route for her payment a proper route
> could be blocked do to the fact that Bob is using it currently. Since the
> funds of Bob have not arrived Alice might also not be able to find a
> different route.
>
> However those scientific results are a strong call for Atomic Multipath
> Payments. I personally think they are also a strong call for splicing since
> this allows to easilly increase the flow of the network by updating a
> channel (athough you might argue that following the paper this could be
> achieved by just creating a new channel)
>
> best Rene
>
> On Sun, Jul 1, 2018 at 12:21 PM Dmytro Piatkivskyi <
> dmytro.piatkivskyi at ntnu.no> wrote:
>
>> Hi everyone,
>>
>> I have been working academically on the Lightning network for a while
>> now. I didn’t not participate in the list to form my own vision of what it
>> should be. So please, bear with me if I’ll be saying nonsense sometimes.
>>
>> There has been a lot of discussion on sending cycle transactions to
>> oneself to ‘re-balance’ the network. On LN mailing list
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html> [1] or
>> numerous places elsewhere. There has been even a paper suggesting a smart
>> mechanism to do the re-balancing (see Revive or Liquidity network [2]). My
>> question is what do we actually get from it? [3] states that the
>> distribution of funds in channels does not really affect the network
>> liquidity. I can see cheaper fees or shorter paths if the network is kept
>> balanced. But don’t you think that a smart fee strategy will do the job?
>>
>> To save your time, [4] explains the gist from [3].
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
>> [2]
>> https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
>> [3] https://arxiv.org/abs/1007.0515
>> [4]
>> https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> www.rene-pickhardt.de
> <http://www.beijing-china-blog.com/>
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618 <+49%20176%2057623618>
> _______________________________________________
> 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/20180703/d412a8b5/attachment.html>

2023-06-09 12:51:00

- reply

📅 Original date posted:2018-07-03
📝 Original message:
Hi Dmytro,
Thanks for bringing this up! Sometime last year when I was at a developer
meetup that cdecker also attended, we briefly discussed a similar question.
We
we're discussing if "active rebalancing" was actually ever really necessary.
>From my PoV, active rebalancing is rebalancing done for the purpose of being
able to send/recv a particular payment. On white board, cdecer sketched out
a
similar argument as to Lemma 2 in that paper you linked: namely that there
will
exist an alternative path, therefore active rebalancing isn't necessary.
IMO, in a world pre-AMP, it is indeed necessary. Consider a node Bob that
wishes to receive a payment of 0.5 BTC. Bob has two channels, one with 2 BTC
max capacity, and the other with 1 BTC max capacity. If channel 1 only has
0.2
available for him to receive, and channel 2 only has 0.3 available for him
to
receive, then without active rebalancing, he's unable to receive the
payment.
However, if he completes a circular payment from channel 1 to channel 2 (or
the
other way around), then he's able to receive the payment (under ideal
conditions).
In a world post-AMP, then this would seem to no longer apply. Alice the
sender
may be able to utilize the aggregate bandwidth of the network to send
minimally
two payment flows (one 0.2 and one 0.3) to satisfy the payment. As a result,
active rebalancing isn't needed as payments can be split up to fully utilize
the payment bandwidth at both the sender and the receiver.
> total balances of nodes in the network define the feasibility of a
particular
> transaction, not the distribution of balances.
With multi-path payments this is precisely the case!
However, there might be an argument in favor of "passive rebalancing". I
define
passive rebalancing as rebalancing a node carries out independent of
needing to
send/receive payments themselves, in order to ensure an equilibrium state
amongst the available balances of their channels. In this case, equilibrium
means being able to recv as much as you can send on all your channels. The
argument here is that by maintaining this balance, one is likely to reduce
the
number of routing failures from failed HTLC forwarding, as the channel is
equally likely to be able to carry an HTLC in either direction.
One relevant detail w.r.t to the necessity of active rebalancing is the
directionality of payment flows in the network. If payment flows are more or
less balanced (kinda like the ideal world Byran Vu describes in the post
[1]),
meaning people are sending out as much as they receive (so they get their
paycheck streamed to them over LN, then stream BitFlix w/ that), then it's
possible passive rebalancing isn't really necessary. However if a few
sources/sinks dominate, then channels may regularly become biased requiring
more maintenance.
Also thanks for bringing this paper to my attention! Haven't yet read it in
full yet, but happy to discover that this isn't completes new territory and
is
a problem that's been explored in the existing literature.
[1]: https://blog.lightning.engineering/posts/2018/05/30/routing.html
-- Laolu
On Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi <
dmytro.piatkivskyi at ntnu.no> wrote:
> Hi everyone,
>
> I have been working academically on the Lightning network for a while now.
> I didn’t not participate in the list to form my own vision of what it
> should be. So please, bear with me if I’ll be saying nonsense sometimes.
>
> There has been a lot of discussion on sending cycle transactions to
> oneself to ‘re-balance’ the network. On LN mailing list
> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html> [1] or
> numerous places elsewhere. There has been even a paper suggesting a smart
> mechanism to do the re-balancing (see Revive or Liquidity network [2]). My
> question is what do we actually get from it? [3] states that the
> distribution of funds in channels does not really affect the network
> liquidity. I can see cheaper fees or shorter paths if the network is kept
> balanced. But don’t you think that a smart fee strategy will do the job?
>
> To save your time, [4] explains the gist from [3].
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
> [2]
> https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
> [3] https://arxiv.org/abs/1007.0515
> [4]
> https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
> _______________________________________________
> 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/20180703/29d80ad3/attachment-0001.html>

2023-06-09 12:50:39

- reply

📅 Original date posted:2018-05-08
📝 Original message:
FWIW, Conner pointed out that the initial ZK Proof for the correctness of
the
Paillier params (even w/ usage of bulletproofs) has multiple rounds of
interaction,
iirc up to 5+ (with additional pipelining) rounds of interaction.
-- Laolu
On Mon, May 7, 2018 at 5:14 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Actually, just thought about this a bit more and I think it's possible to
> deploy this in unison with (or after) any sort of SS based on schnorr
> becomes
> possible in Bitcoin. My observation is that since both techniques are
> based on
> the same underlying technique (revealing a secret value in a signature) and
> they center around leveraging the onion payload to drop off a payment point
> (G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be
> heterogeneous, as the same secret is still revealed in an end-to-end
> matter.
>
> As an illustration, consider: A <-> B <-> C. The A <-> B link could use
> the 2pc
> pailier technique, while the B <-> C link could use the OG SS technique
> based
> on schnorr. If i'm correct, then this would mean that we can deploy both
> techniques, without worrying about fragmenting the network due to the
> existence
> of two similar but incompatible e2e payment routing schemes!
>
> -- Laolu
>
>
> On Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> Hi Pedro,
>>
>> Very cool stuff! When I originally discovered the Lindell's technique, my
>> immediate thought was the we could phase this in as a way to
>> _immediately_ (no
>> additional Script upgrades required), replace the regular 2-of-2
>> mulit-sig with
>> a single p2wkh. The immediate advantages of this would: be lower fees for
>> opening/closing channels (as the public key script, and witness are
>> smaller),
>> openings and cooperative close transactions would blend in with the
>> anonymity
>> set of regular p2wkh transactions, and finally the htlc timeout+success
>> transactions can be made smaller as we can remove the multi-sig. The
>> second
>> benefit is nerfed a bit if the channel are advertised, but non-advertised
>> channels would be able to take advantage of this "stealth" feature.
>>
>> The upside of the original application I hand in mind is that it wouldn't
>> require any end-to-end changes, as it would only be a link level change
>> (diff
>> output for the funding transaction). If we wanted to allow these styles of
>> channels to be used outside of non-advertised channels, then we would
>> need to
>> update the way channels are verified in the gossip layer.
>>
>> Applying this to the realm of allowing us to use randomized payment
>> identifiers
>> across the route is obviously much, much doper. So then the question
>> would be
>> what the process of integrating the scheme into the existing protocol
>> would
>> look like. The primary thing we'd need to account for is the additional
>> cryptographic overhead this scheme would add if integrated. Re-reviewing
>> the
>> paper, there's an initial setup and verification phase (which was omitted
>> from
>> y'alls note for brevity) where both parties need to complete before the
>> actually signing process can take place. Ideally, we can piggy-back this
>> setup
>> on top of the existing accept_channel/open_channel dance both sides need
>> to go
>> through in order to advance the channel negotiation process today.
>>
>> Conner actually started to implement this when we first discovered the
>> scheme,
>> so we have a pretty good feel w.r.t the implementation of the initial set
>> of
>> proofs. The three proofs required for the set up phase are:
>>
>> 1. A proof that that the Paillier public key is well formed. In the
>> paper
>> they only execute this step for the party that wishes to _obtain_ the
>> signature. In our case, since we'll need to sign for HTLCs in both
>> directions, but parties will need to execute this step.
>>
>> 2. A dlog proof for the signing keys themselves. We already do this
>> more or
>> less, as if the remote party isn't able to sign with their target key,
>> then
>> we won't be able to update the channel, or even create a valid
>> commitment in
>> the first place.
>>
>> 3. A proof that value encrypted (the Paillier ciphertext) is actually
>> the
>> dlog of the public key to be used for signing. (as an aside this is the
>> part
>> of the protocol that made me do a double take when first reading it:
>> using one
>> cryptosystem to encrypt the private key of another cryptosystem in
>> order to
>> construct a 2pc to allow signing in the latter cryptosystem! soo
>> clever!)
>>
>> First, we'll examine the initial proof. This only needs to be done once
>> by both
>> parties AFAICT. As a result, we may be able to piggyback this onto the
>> initial
>> channel funding steps. Reviewing the paper cited on the Lindell paper
>> [1], it
>> appears this would take 1 RTT, so this shouldn't result in any additional
>> round
>> trips during the funding process. We should be able to use a Paillier
>> modulos
>> of 2048 bits, so nothing too crazy. This would just result in a slightly
>> bigger
>> opening message.
>>
>> Skipping the second proofs as it's pretty standard.
>>
>> The third proof as described (Section 6 of the Lindell paper) is
>> interactive.
>> It also contains a ZK range proof as a sub-protocol which as described in
>> Appendix A is also interactive. However, it was pointed out to us by Omer
>> Shlomovits on the lnd slack, that we can actually replace their custom
>> range
>> proofs with Bulletproofs. This would make this section non-interactive,
>> allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this
>> would only
>> need to be done once at the start, as AFIACT, we can re-use the
>> encryption of
>> the secp256k1 private key of both parties.
>>
>> The current channel opening process requires 2 RTT, so it seems that we'd
>> be
>> able to easily piggy back all the opening proofs on top of the existing
>> funding
>> protocol. The main cost would be the increased size of these opening
>> messages,
>> and also the additional computational cost of operations within the
>> Paillier
>> modulus and the new range proof.
>>
>> The additional components that would need to be modified are the process
>> of
>> adding+settling an HTLC, and also the onion payload that drops off the
>> point
>> whose dlog is r_1*alpha. Within the current protocol, adding and settling
>> an
>> HTLC are more or less non-interactive, we have a single message for each,
>> which
>> is then staged to be committed in new commitments for both parties. With
>> this
>> new scheme (if I follow it correctly), adding an HTLC now requires N RTT:
>> 1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.
>> 2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2
>> and
>> relation to A)
>> 3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as
>> above) 4.
>> Bob then computes c3 (the encrypted partial sig which when completed
>> will
>> reveal a) to Alice.
>> 5. Alice decrypts c3 to get the plaintext partial sig (s'), then
>> finalizes
>> the set up by sending s'' to Bob.
>>
>> This process takes 2.5 RTT, and would require re-working the state machine
>> slightly to only actually commit an HTLC after step 5 has been
>> completed. When
>> Bob obtains a from the next party in the path, we Alice can then then
>> over the
>> signature, from which Alice can extract alpha. So adding HTLCs is now a
>> bit
>> more interactive, but settling them is the same a before.
>>
>> Finally, the onion payload would need to be re-interpreted in order to
>> encode
>> G*alpha which takes 33 bytes. We can shave this down to 32 by selecting
>> the x
>> coordinate (at the sender) to always be either even or odd. Currently, we
>> have
>> 12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One
>> path
>> would be to allocate a portion of HMAC space to encoding this point. A
>> 16-byte
>> HMAC would probably have been enough in the beginning, so we can drop
>> down to
>> that. However, that still leaves 4 bytes somewhere that has to give...one
>> could
>> either obtain these extra bytes from the CLTV and Amount fields, or just
>> have
>> each hop consume an extra payload. The latter path would mean that the new
>> upper hop limit is actually 10.
>>
>> However, given that we would need need a new global feature bit in order
>> to
>> roll this out, it may make sense to re-work the onion format all together
>> which
>> would mean that we wouldn't need to hack the old format a bit to
>> accommodate
>> this additional data. One aspect of introducing a new end-to-end contract
>> type
>> which I hadn't considered before is that each new type effectively
>> partitions
>> the network. This is due to the fact that these HTLCs will now only be
>> able to
>> be carried along paths that understand this new feature. As a result,
>> plausible
>> path diversity takes as we can no longer utilize all channels on the
>> network
>> for routing. This would suggest that introducing new end to end contract
>> types
>> (if one wishes to use them widely across arbitrary channels and not for
>> specific contract protocols) may be a strong point of synchronization
>> w.r.t
>> updates across the network. As a result, we may need to be a bit more
>> discerning w.r.t new candidates for e2e contracts given the coordination
>> costs.
>>
>> So the takeaways are:
>> * we can probably piggy back the extra proofs onto the channel opening
>> process
>> * one of the subproofs can use bulletproofs to make the proof
>> shorter and
>> also non-interactive
>> * adding an HTLC would take 2.5 RTT's, but settling is just as quick as
>> before
>> * the onion payload would either need to be hacked, or extended to
>> support
>> packaging the point.
>> * the utility of the scheme won't shine until all/most of the network
>> uses it
>> * we could start w/ just the introduction of the OG 2PC scheme as a
>> multi-sig
>> replacement
>>
>>
>> [1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)
>>
>> -- Laolu
>>
>>
>> On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez <
>> pmorenos at purdue.edu> wrote:
>>
>>> Hello guys,
>>>
>>> as some of you already know, I am working on some cryptographic
>>> constructions that might be of interest and useful for the Lightning
>>> Network.
>>>
>>> Recently, I have come up with a scriptless version of the adaptor
>>> signatures and the contract required in the Lighting Network using only
>>> 2-party ECDSA signatures. The main advantage is that, instead of waiting
>>> for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
>>> scriptless scripts can be used, I believe that this ECDSA-version of the
>>> scriptless scripts can be directly applied today.
>>>
>>> Details are in the attached PDF. I am looking forward to hearing your
>>> comments and suggestions.
>>>
>>> Cheers,
>>> Pedro.
>>>
>>> _______________________________________________
>>> 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/20180508/23f2dfc3/attachment.html>

2023-06-09 12:50:38

- reply

📅 Original date posted:2018-05-07
📝 Original message:
Hi Pedro,
Very cool stuff! When I originally discovered the Lindell's technique, my
immediate thought was the we could phase this in as a way to _immediately_
(no
additional Script upgrades required), replace the regular 2-of-2 mulit-sig
with
a single p2wkh. The immediate advantages of this would: be lower fees for
opening/closing channels (as the public key script, and witness are
smaller),
openings and cooperative close transactions would blend in with the
anonymity
set of regular p2wkh transactions, and finally the htlc timeout+success
transactions can be made smaller as we can remove the multi-sig. The second
benefit is nerfed a bit if the channel are advertised, but non-advertised
channels would be able to take advantage of this "stealth" feature.
The upside of the original application I hand in mind is that it wouldn't
require any end-to-end changes, as it would only be a link level change
(diff
output for the funding transaction). If we wanted to allow these styles of
channels to be used outside of non-advertised channels, then we would need
to
update the way channels are verified in the gossip layer.
Applying this to the realm of allowing us to use randomized payment
identifiers
across the route is obviously much, much doper. So then the question would
be
what the process of integrating the scheme into the existing protocol would
look like. The primary thing we'd need to account for is the additional
cryptographic overhead this scheme would add if integrated. Re-reviewing the
paper, there's an initial setup and verification phase (which was omitted
from
y'alls note for brevity) where both parties need to complete before the
actually signing process can take place. Ideally, we can piggy-back this
setup
on top of the existing accept_channel/open_channel dance both sides need to
go
through in order to advance the channel negotiation process today.
Conner actually started to implement this when we first discovered the
scheme,
so we have a pretty good feel w.r.t the implementation of the initial set of
proofs. The three proofs required for the set up phase are:
1. A proof that that the Paillier public key is well formed. In the paper
they only execute this step for the party that wishes to _obtain_ the
signature. In our case, since we'll need to sign for HTLCs in both
directions, but parties will need to execute this step.
2. A dlog proof for the signing keys themselves. We already do this more
or
less, as if the remote party isn't able to sign with their target key,
then
we won't be able to update the channel, or even create a valid commitment
in
the first place.
3. A proof that value encrypted (the Paillier ciphertext) is actually the
dlog of the public key to be used for signing. (as an aside this is the
part
of the protocol that made me do a double take when first reading it:
using one
cryptosystem to encrypt the private key of another cryptosystem in order
to
construct a 2pc to allow signing in the latter cryptosystem! soo clever!)
First, we'll examine the initial proof. This only needs to be done once by
both
parties AFAICT. As a result, we may be able to piggyback this onto the
initial
channel funding steps. Reviewing the paper cited on the Lindell paper [1],
it
appears this would take 1 RTT, so this shouldn't result in any additional
round
trips during the funding process. We should be able to use a Paillier
modulos
of 2048 bits, so nothing too crazy. This would just result in a slightly
bigger
opening message.
Skipping the second proofs as it's pretty standard.
The third proof as described (Section 6 of the Lindell paper) is
interactive.
It also contains a ZK range proof as a sub-protocol which as described in
Appendix A is also interactive. However, it was pointed out to us by Omer
Shlomovits on the lnd slack, that we can actually replace their custom range
proofs with Bulletproofs. This would make this section non-interactive,
allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would
only
need to be done once at the start, as AFIACT, we can re-use the encryption
of
the secp256k1 private key of both parties.
The current channel opening process requires 2 RTT, so it seems that we'd be
able to easily piggy back all the opening proofs on top of the existing
funding
protocol. The main cost would be the increased size of these opening
messages,
and also the additional computational cost of operations within the Paillier
modulus and the new range proof.
The additional components that would need to be modified are the process of
adding+settling an HTLC, and also the onion payload that drops off the point
whose dlog is r_1*alpha. Within the current protocol, adding and settling an
HTLC are more or less non-interactive, we have a single message for each,
which
is then staged to be committed in new commitments for both parties. With
this
new scheme (if I follow it correctly), adding an HTLC now requires N RTT:
1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.
2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2 and
relation to A)
3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as above)
4.
Bob then computes c3 (the encrypted partial sig which when completed will
reveal a) to Alice.
5. Alice decrypts c3 to get the plaintext partial sig (s'), then finalizes
the set up by sending s'' to Bob.
This process takes 2.5 RTT, and would require re-working the state machine
slightly to only actually commit an HTLC after step 5 has been completed.
When
Bob obtains a from the next party in the path, we Alice can then then over
the
signature, from which Alice can extract alpha. So adding HTLCs is now a bit
more interactive, but settling them is the same a before.
Finally, the onion payload would need to be re-interpreted in order to
encode
G*alpha which takes 33 bytes. We can shave this down to 32 by selecting the
x
coordinate (at the sender) to always be either even or odd. Currently, we
have
12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One
path
would be to allocate a portion of HMAC space to encoding this point. A
16-byte
HMAC would probably have been enough in the beginning, so we can drop down
to
that. However, that still leaves 4 bytes somewhere that has to give...one
could
either obtain these extra bytes from the CLTV and Amount fields, or just
have
each hop consume an extra payload. The latter path would mean that the new
upper hop limit is actually 10.
However, given that we would need need a new global feature bit in order to
roll this out, it may make sense to re-work the onion format all together
which
would mean that we wouldn't need to hack the old format a bit to accommodate
this additional data. One aspect of introducing a new end-to-end contract
type
which I hadn't considered before is that each new type effectively
partitions
the network. This is due to the fact that these HTLCs will now only be able
to
be carried along paths that understand this new feature. As a result,
plausible
path diversity takes as we can no longer utilize all channels on the network
for routing. This would suggest that introducing new end to end contract
types
(if one wishes to use them widely across arbitrary channels and not for
specific contract protocols) may be a strong point of synchronization w.r.t
updates across the network. As a result, we may need to be a bit more
discerning w.r.t new candidates for e2e contracts given the coordination
costs.
So the takeaways are:
* we can probably piggy back the extra proofs onto the channel opening
process
* one of the subproofs can use bulletproofs to make the proof shorter
and
also non-interactive
* adding an HTLC would take 2.5 RTT's, but settling is just as quick as
before
* the onion payload would either need to be hacked, or extended to support
packaging the point.
* the utility of the scheme won't shine until all/most of the network
uses it
* we could start w/ just the introduction of the OG 2PC scheme as a
multi-sig
replacement
[1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)
-- Laolu
On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
wrote:
> Hello guys,
>
> as some of you already know, I am working on some cryptographic
> constructions that might be of interest and useful for the Lightning
> Network.
>
> Recently, I have come up with a scriptless version of the adaptor
> signatures and the contract required in the Lighting Network using only
> 2-party ECDSA signatures. The main advantage is that, instead of waiting
> for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
> scriptless scripts can be used, I believe that this ECDSA-version of the
> scriptless scripts can be directly applied today.
>
> Details are in the attached PDF. I am looking forward to hearing your
> comments and suggestions.
>
> Cheers,
> Pedro.
>
> _______________________________________________
> 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/20180507/32b51086/attachment-0001.html>

2023-06-09 12:50:38

- reply

📅 Original date posted:2018-05-07
📝 Original message:
Actually, just thought about this a bit more and I think it's possible to
deploy this in unison with (or after) any sort of SS based on schnorr
becomes
possible in Bitcoin. My observation is that since both techniques are based
on
the same underlying technique (revealing a secret value in a signature) and
they center around leveraging the onion payload to drop off a payment point
(G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be
heterogeneous, as the same secret is still revealed in an end-to-end matter.
As an illustration, consider: A <-> B <-> C. The A <-> B link could use the
2pc
pailier technique, while the B <-> C link could use the OG SS technique
based
on schnorr. If i'm correct, then this would mean that we can deploy both
techniques, without worrying about fragmenting the network due to the
existence
of two similar but incompatible e2e payment routing schemes!
-- Laolu
On Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Hi Pedro,
>
> Very cool stuff! When I originally discovered the Lindell's technique, my
> immediate thought was the we could phase this in as a way to _immediately_
> (no
> additional Script upgrades required), replace the regular 2-of-2 mulit-sig
> with
> a single p2wkh. The immediate advantages of this would: be lower fees for
> opening/closing channels (as the public key script, and witness are
> smaller),
> openings and cooperative close transactions would blend in with the
> anonymity
> set of regular p2wkh transactions, and finally the htlc timeout+success
> transactions can be made smaller as we can remove the multi-sig. The second
> benefit is nerfed a bit if the channel are advertised, but non-advertised
> channels would be able to take advantage of this "stealth" feature.
>
> The upside of the original application I hand in mind is that it wouldn't
> require any end-to-end changes, as it would only be a link level change
> (diff
> output for the funding transaction). If we wanted to allow these styles of
> channels to be used outside of non-advertised channels, then we would need
> to
> update the way channels are verified in the gossip layer.
>
> Applying this to the realm of allowing us to use randomized payment
> identifiers
> across the route is obviously much, much doper. So then the question would
> be
> what the process of integrating the scheme into the existing protocol would
> look like. The primary thing we'd need to account for is the additional
> cryptographic overhead this scheme would add if integrated. Re-reviewing
> the
> paper, there's an initial setup and verification phase (which was omitted
> from
> y'alls note for brevity) where both parties need to complete before the
> actually signing process can take place. Ideally, we can piggy-back this
> setup
> on top of the existing accept_channel/open_channel dance both sides need
> to go
> through in order to advance the channel negotiation process today.
>
> Conner actually started to implement this when we first discovered the
> scheme,
> so we have a pretty good feel w.r.t the implementation of the initial set
> of
> proofs. The three proofs required for the set up phase are:
>
> 1. A proof that that the Paillier public key is well formed. In the paper
> they only execute this step for the party that wishes to _obtain_ the
> signature. In our case, since we'll need to sign for HTLCs in both
> directions, but parties will need to execute this step.
>
> 2. A dlog proof for the signing keys themselves. We already do this more
> or
> less, as if the remote party isn't able to sign with their target key,
> then
> we won't be able to update the channel, or even create a valid
> commitment in
> the first place.
>
> 3. A proof that value encrypted (the Paillier ciphertext) is actually the
> dlog of the public key to be used for signing. (as an aside this is the
> part
> of the protocol that made me do a double take when first reading it:
> using one
> cryptosystem to encrypt the private key of another cryptosystem in order
> to
> construct a 2pc to allow signing in the latter cryptosystem! soo clever!)
>
> First, we'll examine the initial proof. This only needs to be done once by
> both
> parties AFAICT. As a result, we may be able to piggyback this onto the
> initial
> channel funding steps. Reviewing the paper cited on the Lindell paper [1],
> it
> appears this would take 1 RTT, so this shouldn't result in any additional
> round
> trips during the funding process. We should be able to use a Paillier
> modulos
> of 2048 bits, so nothing too crazy. This would just result in a slightly
> bigger
> opening message.
>
> Skipping the second proofs as it's pretty standard.
>
> The third proof as described (Section 6 of the Lindell paper) is
> interactive.
> It also contains a ZK range proof as a sub-protocol which as described in
> Appendix A is also interactive. However, it was pointed out to us by Omer
> Shlomovits on the lnd slack, that we can actually replace their custom
> range
> proofs with Bulletproofs. This would make this section non-interactive,
> allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would
> only
> need to be done once at the start, as AFIACT, we can re-use the encryption
> of
> the secp256k1 private key of both parties.
>
> The current channel opening process requires 2 RTT, so it seems that we'd
> be
> able to easily piggy back all the opening proofs on top of the existing
> funding
> protocol. The main cost would be the increased size of these opening
> messages,
> and also the additional computational cost of operations within the
> Paillier
> modulus and the new range proof.
>
> The additional components that would need to be modified are the process of
> adding+settling an HTLC, and also the onion payload that drops off the
> point
> whose dlog is r_1*alpha. Within the current protocol, adding and settling
> an
> HTLC are more or less non-interactive, we have a single message for each,
> which
> is then staged to be committed in new commitments for both parties. With
> this
> new scheme (if I follow it correctly), adding an HTLC now requires N RTT:
> 1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.
> 2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2
> and
> relation to A)
> 3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as
> above) 4.
> Bob then computes c3 (the encrypted partial sig which when completed will
> reveal a) to Alice.
> 5. Alice decrypts c3 to get the plaintext partial sig (s'), then
> finalizes
> the set up by sending s'' to Bob.
>
> This process takes 2.5 RTT, and would require re-working the state machine
> slightly to only actually commit an HTLC after step 5 has been completed.
> When
> Bob obtains a from the next party in the path, we Alice can then then over
> the
> signature, from which Alice can extract alpha. So adding HTLCs is now a bit
> more interactive, but settling them is the same a before.
>
> Finally, the onion payload would need to be re-interpreted in order to
> encode
> G*alpha which takes 33 bytes. We can shave this down to 32 by selecting
> the x
> coordinate (at the sender) to always be either even or odd. Currently, we
> have
> 12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One
> path
> would be to allocate a portion of HMAC space to encoding this point. A
> 16-byte
> HMAC would probably have been enough in the beginning, so we can drop down
> to
> that. However, that still leaves 4 bytes somewhere that has to give...one
> could
> either obtain these extra bytes from the CLTV and Amount fields, or just
> have
> each hop consume an extra payload. The latter path would mean that the new
> upper hop limit is actually 10.
>
> However, given that we would need need a new global feature bit in order to
> roll this out, it may make sense to re-work the onion format all together
> which
> would mean that we wouldn't need to hack the old format a bit to
> accommodate
> this additional data. One aspect of introducing a new end-to-end contract
> type
> which I hadn't considered before is that each new type effectively
> partitions
> the network. This is due to the fact that these HTLCs will now only be
> able to
> be carried along paths that understand this new feature. As a result,
> plausible
> path diversity takes as we can no longer utilize all channels on the
> network
> for routing. This would suggest that introducing new end to end contract
> types
> (if one wishes to use them widely across arbitrary channels and not for
> specific contract protocols) may be a strong point of synchronization w.r.t
> updates across the network. As a result, we may need to be a bit more
> discerning w.r.t new candidates for e2e contracts given the coordination
> costs.
>
> So the takeaways are:
> * we can probably piggy back the extra proofs onto the channel opening
> process
> * one of the subproofs can use bulletproofs to make the proof
> shorter and
> also non-interactive
> * adding an HTLC would take 2.5 RTT's, but settling is just as quick as
> before
> * the onion payload would either need to be hacked, or extended to
> support
> packaging the point.
> * the utility of the scheme won't shine until all/most of the network
> uses it
> * we could start w/ just the introduction of the OG 2PC scheme as a
> multi-sig
> replacement
>
>
> [1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)
>
> -- Laolu
>
>
> On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
> wrote:
>
>> Hello guys,
>>
>> as some of you already know, I am working on some cryptographic
>> constructions that might be of interest and useful for the Lightning
>> Network.
>>
>> Recently, I have come up with a scriptless version of the adaptor
>> signatures and the contract required in the Lighting Network using only
>> 2-party ECDSA signatures. The main advantage is that, instead of waiting
>> for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
>> scriptless scripts can be used, I believe that this ECDSA-version of the
>> scriptless scripts can be directly applied today.
>>
>> Details are in the attached PDF. I am looking forward to hearing your
>> comments and suggestions.
>>
>> Cheers,
>> Pedro.
>>
>> _______________________________________________
>> 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/20180508/04e449be/attachment-0001.html>

2023-06-09 12:50:36

- reply

📅 Original date posted:2018-05-09
📝 Original message:
> The current proposal kind-of limits the potential damage by still
committing
> to the prevout amount, but it still seems a big risk for all the people
that
> reuse addresses, which seems to be just about everyone.
The typical address re-use doesn't apply here as this is a sighash flag that
would only really be used for doing various contracts on Bitcoin. I don't
see any reason why "regular" wallets would update to use this sighash flag.
We've also seen first hand with segwit that wallet authors are slow to pull
in the latest and greatest features available, even if they solve nuisance
issues like malleability and can result in lower fees.
IMO, sighash_none is an even bigger footgun that already exists in the
protocol today.
-- Laolu
On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev
> wrote:
> > Given the general enthusiasm, and lack of major criticism, for the
> > `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so....
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
>
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
>
> Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
> wouldn't be equally effective for the forseeable usecases? That would
> ensure that a _NOINPUT signature is only ever valid for keys deliberately
> intended to be single use, rather than potentially valid for every key.
>
> It would be ~34 witness bytes worse than being able to spend a Schnorr
> aggregate key directly, I guess; but that's not worse than the normal
> taproot tradeoff: you spend the aggregate key directly in the normal,
> cooperative case; and reserve the more expensive/NOINPUT case for the
> unusual, uncooperative cases. I believe that works fine for eltoo: in
> the cooperative case you just do a SIGHASH_ALL spend of the original
> transaction, and _NOINPUT isn't needed.
>
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
>
> A new opcode has the theoretical advantage that it could be deployed
> into the existing segwit v0 address space, rather than waiting for segwit
> v1. Not sure that's really meaningful, though.
>
> Cheers,
> aj
>
> _______________________________________________
> 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/lightning-dev/attachments/20180509/ba4835de/attachment-0001.html>

2023-06-09 12:50:08

- reply

📅 Original date posted:2018-04-16
📝 Original message:
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.
> The WatchTower would have to store each and every justice transaction it
> received, and would not be able to compress it or use various techniques
to
> store data efficiently.
In our current implementation, we've abandoned the "savings" from
compressing the shachain/elkrem tree. When one factors in the space
complexity due the *just* the commitment signatures, the savings from
compression become less attractive. Going a step father, once you factor in
the space complexity of the 2-stage HTLC claims, then the savings from
compressing the revocation tree become insignificant.
It's also worth pointing out that if the server is able to compress the
revocation tree, then their necessarily linking new breach payloads with a
particular channel. Another downside, is that if you go to revocation tree
compression, then all updates *must* be sent in order, and updates cannot be
*skipped*.
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.
-- Laolu
On Sun, Apr 15, 2018 at 8:32 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Nicolas Dorier was requesting additional hooks in c-lightning for a simple
> WatchTower system:
> https://github.com/ElementsProject/lightning/issues/1353
>
> Unfortunately I was only able to provide an interface which requires a
> *trusted* WatchTower. Trust is of course a five-letter word and should not
> be used in polite company.
>
> My key problem is that I provide enough information to the WatchTower for
> the WatchTower to be able to create the justice transaction by itself. If
> so, the WatchTower could just make the justice transaction output to itself
> and the counterparty, so that the WatchTower and the counterparty can
> cooperate to steal the channel funds: the counterparty publishes a revoked
> transaction, the WatchTower writes a justice transaction on it that splits
> the earnings between itself and the counterparty.
>
> 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. The WatchTower would have to store each and every
> justice transaction it received, and would not be able to compress it or
> use various techniques to store data efficiently. The WatchTower would not
> have enough information to regenerate justice transactions (and in
> particular would not be able to create a travesty-of-justice transaction
> that pays out to itself rather than the protected party). In practice this
> would require that node software also keep around those transactions until
> some process has ensured that the WatchTower has received the justice
> transactions.
>
> Is there a good way to make trustless WatchTowers currently or did this
> simply not reach BOLT v1.0?
>
> 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/20180416/ed660fae/attachment-0001.html>

2023-06-09 12:48:58

- reply

📅 Original date posted:2018-02-06
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180207/3e9cf18e/attachment.html>

2023-06-09 12:48:57

- reply

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

2023-06-09 12:48:55

- reply

📅 Original date posted:2018-02-23
📝 Original message:
Hi Rusty,
> 1. query_short_channel_id
> IMPLEMENTATION: trivial
*thumbs up*
> 2. query_channel_range/reply_channel_range
> IMPLEMENTATION: requires channel index by block number, zlib
For the sake of expediency of deployment, if we add a byte (or two) to
denote the encoding/compression scheme, we can immediately roll out the
vanilla (just list the ID's), then progressively roll out more
context-specific optimized schemes.
> 3. A gossip_timestamp field in `init`
> This is a new field appended to `init`: the negotiation of this feature
bit
> overrides `initial_routing_sync`
As I've brought up before, from my PoV, we can't append any additional
fields to the innit message as it already contains *two* variable sized
fields (and no fixed size fields). Aside from this, it seems that the
`innit` message should be simply for exchange versioning information, which
may govern exactly *which* messages are sent after it. Otherwise, by adding
_additional_ fields to the `innit` message, we paint ourselves in a corner
and can never remove it. Compared to using the `innit` message to set up the
initial session context, where we can safely add other bits to nullify or
remove certain expected messages.
With that said, this should instead be a distinct `chan_update_horizon`
message (or w/e name). If a particular bit is set in the `init` message,
then the next message *both* sides send *must* be `chan_update_horizon`.
Another advantage of making this a distinct message, is that either party
can at any time update this horizon/filter to ensure that they only receive
the *freshest* updates.Otherwise, one can image a very long lived
connections (say weeks) and the remote party keeps sending me very dated
updates (wasting bandwidth) when I only really want the *latest*.
This can incorporate decker's idea about having a high+low timestamp. I
think this is desirable as then for the initial sync case, the receiver can
*precisely* control their "verification load" to ensure they only process a
particular chunk at a time.
Fabrice wrote:
> We could add a `data` field which contains zipped ids like in
> `reply_channel_range` so we can query several items with a single message
?
I think this is an excellent idea! It would allow batched requests in
response to a channel range message. I'm not so sure we need to jump
*straight* to compressing everything however.
> We could add an additional `encoding_type` field before `data` (or it
> could be the first byte of `data`)
Great minds think alike :-)
If we're in rough agreement generally about this initial "kick can"
approach, I'll start implementing some of this in a prototype branch for
lnd. I'm very eager to solve the zombie churn, and initial burst that can be
very hard on light clients.
-- Laolu
On Wed, Feb 21, 2018 at 10:03 AM Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:
> On 20 February 2018 at 02:08, Rusty Russell <rusty at rustcorp.com.au> wrote:
> > Hi all,
> >
> > This consumed much of our lightning dev interop call today! But
> > I think we have a way forward, which is in three parts, gated by a new
> > feature bitpair:
>
> We've built a prototype with a new feature bit `channel_range_queries`
> and the following logic:
> When you receive their init message and check their local features
> - if they set `initial_routing_sync` and `channel_range_queries` then
> do nothing (they will send you a `query_channel_range`)
> - if they set `initial_routing_sync` and not `channel_range_queries`
> then send your routing table (as before)
> - if you support `channel_range_queries` then send a
> `query_channel_range` message
>
> This way new and old nodes should be able to understand each other
>
> > 1. query_short_channel_id
> > =========================
> >
> > 1. type: 260 (`query_short_channel_id`)
> > 2. data:
> > * [`32`:`chain_hash`]
> > * [`8`:`short_channel_id`]
>
> We could add a `data` field which contains zipped ids like in
> `reply_channel_range` so we can query several items with a single
> message ?
>
> > 1. type: 262 (`reply_channel_range`)
> > 2. data:
> > * [`32`:`chain_hash`]
> > * [`4`:`first_blocknum`]
> > * [`4`:`number_of_blocks`]
> > * [`2`:`len`]
> > * [`len`:`data`]
>
> We could add an additional `encoding_type` field before `data` (or it
> could be the first byte of `data`)
>
> > Appendix A: Encoding Sizes
> > ==========================
> >
> > I tried various obvious compression schemes, in increasing complexity
> > order (see source below, which takes stdin and spits out stdout):
> >
> > Raw = raw 8-byte stream of ordered channels.
> > gzip -9: gzip -9 of raw.
> > splitgz: all blocknums first, then all txnums, then all outnums,
> then gzip -9
> > delta: CVarInt encoding:
> blocknum_delta,num,num*txnum_delta,num*outnum.
> > deltagz: delta, with gzip -9
> >
> > Corpus 1: LN mainnet dump, 1830 channels.[1]
> >
> > Raw: 14640 bytes
> > gzip -9: 6717 bytes
> > splitgz: 6464 bytes
> > delta: 6624 bytes
> > deltagz: 4171 bytes
> >
> > Corpus 2: All P2SH outputs between blocks 508000-508999 incl, 790844
> channels.[2]
> >
> > Raw: 6326752 bytes
> > gzip -9: 1861710 bytes
> > splitgz: 964332 bytes
> > delta: 1655255 bytes
> > deltagz: 595469 bytes
> >
> > [1] http://ozlabs.org/~rusty/short_channels-mainnet.xz
> > [2] http://ozlabs.org/~rusty/short_channels-all-p2sh-508000-509000.xz
> >
>
> Impressive!
> _______________________________________________
> 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/20180224/35572cad/attachment.html>

2023-06-09 12:48:55

- reply

📅 Original date posted:2018-02-25
📝 Original message:
> With that said, this should instead be a distinct `chan_update_horizon`
> message (or w/e name). If a particular bit is set in the `init` message,
> then the next message *both* sides send *must* be `chan_update_horizon`.
Tweaking this a bit, if we make it: don't send *any* channel updates at all
unless the other side sends this message, then this allows both parties to
precisely control their initial load, and also if they even *want*
channel_update messages at all.
Purely routing nodes don't need any updates at all. In the case they wish to
send (assumed to be infrequent in this model), they'll get the latest update
after their first failure.
Similarly, leaf/edge nodes can opt to receive the latest updates if they
wish to minimize payment latency due to routing failures that are the result
of dated information.
IMO, the only case where a node would want the most up to date link policy
state is for optimization/analysis, or to minimize payment latency at the
cost of additional load.
--Laolu
On Fri, Feb 23, 2018 at 4:45 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi Rusty,
>
> > 1. query_short_channel_id
> > IMPLEMENTATION: trivial
>
> *thumbs up*
>
> > 2. query_channel_range/reply_channel_range
> > IMPLEMENTATION: requires channel index by block number, zlib
>
> For the sake of expediency of deployment, if we add a byte (or two) to
> denote the encoding/compression scheme, we can immediately roll out the
> vanilla (just list the ID's), then progressively roll out more
> context-specific optimized schemes.
>
> > 3. A gossip_timestamp field in `init`
> > This is a new field appended to `init`: the negotiation of this feature
> bit
> > overrides `initial_routing_sync`
>
> As I've brought up before, from my PoV, we can't append any additional
> fields to the innit message as it already contains *two* variable sized
> fields (and no fixed size fields). Aside from this, it seems that the
> `innit` message should be simply for exchange versioning information,
> which
> may govern exactly *which* messages are sent after it. Otherwise, by adding
> _additional_ fields to the `innit` message, we paint ourselves in a corner
> and can never remove it. Compared to using the `innit` message to set up
> the
> initial session context, where we can safely add other bits to nullify or
> remove certain expected messages.
>
> With that said, this should instead be a distinct `chan_update_horizon`
> message (or w/e name). If a particular bit is set in the `init` message,
> then the next message *both* sides send *must* be `chan_update_horizon`.
>
> Another advantage of making this a distinct message, is that either party
> can at any time update this horizon/filter to ensure that they only receive
> the *freshest* updates.Otherwise, one can image a very long lived
> connections (say weeks) and the remote party keeps sending me very dated
> updates (wasting bandwidth) when I only really want the *latest*.
>
> This can incorporate decker's idea about having a high+low timestamp. I
> think this is desirable as then for the initial sync case, the receiver can
> *precisely* control their "verification load" to ensure they only process a
> particular chunk at a time.
>
>
> Fabrice wrote:
> > We could add a `data` field which contains zipped ids like in
> > `reply_channel_range` so we can query several items with a single
> message ?
>
> I think this is an excellent idea! It would allow batched requests in
> response to a channel range message. I'm not so sure we need to jump
> *straight* to compressing everything however.
>
> > We could add an additional `encoding_type` field before `data` (or it
> > could be the first byte of `data`)
>
> Great minds think alike :-)
>
>
> If we're in rough agreement generally about this initial "kick can"
> approach, I'll start implementing some of this in a prototype branch for
> lnd. I'm very eager to solve the zombie churn, and initial burst that can
> be
> very hard on light clients.
>
> -- Laolu
>
>
> On Wed, Feb 21, 2018 at 10:03 AM Fabrice Drouin <fabrice.drouin at acinq.fr>
> wrote:
>
>> On 20 February 2018 at 02:08, Rusty Russell <rusty at rustcorp.com.au>
>> wrote:
>> > Hi all,
>> >
>> > This consumed much of our lightning dev interop call today! But
>> > I think we have a way forward, which is in three parts, gated by a new
>> > feature bitpair:
>>
>> We've built a prototype with a new feature bit `channel_range_queries`
>> and the following logic:
>> When you receive their init message and check their local features
>> - if they set `initial_routing_sync` and `channel_range_queries` then
>> do nothing (they will send you a `query_channel_range`)
>> - if they set `initial_routing_sync` and not `channel_range_queries`
>> then send your routing table (as before)
>> - if you support `channel_range_queries` then send a
>> `query_channel_range` message
>>
>> This way new and old nodes should be able to understand each other
>>
>> > 1. query_short_channel_id
>> > =========================
>> >
>> > 1. type: 260 (`query_short_channel_id`)
>> > 2. data:
>> > * [`32`:`chain_hash`]
>> > * [`8`:`short_channel_id`]
>>
>> We could add a `data` field which contains zipped ids like in
>> `reply_channel_range` so we can query several items with a single
>> message ?
>>
>> > 1. type: 262 (`reply_channel_range`)
>> > 2. data:
>> > * [`32`:`chain_hash`]
>> > * [`4`:`first_blocknum`]
>> > * [`4`:`number_of_blocks`]
>> > * [`2`:`len`]
>> > * [`len`:`data`]
>>
>> We could add an additional `encoding_type` field before `data` (or it
>> could be the first byte of `data`)
>>
>> > Appendix A: Encoding Sizes
>> > ==========================
>> >
>> > I tried various obvious compression schemes, in increasing complexity
>> > order (see source below, which takes stdin and spits out stdout):
>> >
>> > Raw = raw 8-byte stream of ordered channels.
>> > gzip -9: gzip -9 of raw.
>> > splitgz: all blocknums first, then all txnums, then all
>> outnums, then gzip -9
>> > delta: CVarInt encoding:
>> blocknum_delta,num,num*txnum_delta,num*outnum.
>> > deltagz: delta, with gzip -9
>> >
>> > Corpus 1: LN mainnet dump, 1830 channels.[1]
>> >
>> > Raw: 14640 bytes
>> > gzip -9: 6717 bytes
>> > splitgz: 6464 bytes
>> > delta: 6624 bytes
>> > deltagz: 4171 bytes
>> >
>> > Corpus 2: All P2SH outputs between blocks 508000-508999 incl, 790844
>> channels.[2]
>> >
>> > Raw: 6326752 bytes
>> > gzip -9: 1861710 bytes
>> > splitgz: 964332 bytes
>> > delta: 1655255 bytes
>> > deltagz: 595469 bytes
>> >
>> > [1] http://ozlabs.org/~rusty/short_channels-mainnet.xz
>> > [2] http://ozlabs.org/~rusty/short_channels-all-p2sh-508000-509000.xz
>> >
>>
>> Impressive!
>> _______________________________________________
>> 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/20180225/3253059c/attachment-0001.html>

2023-06-09 12:48:50

- reply

📅 Original date posted:2018-02-06
📝 Original message:
Hi Y'all,
Definitely agree that we need a stop-gap solution to fix the naive table
dump on initial connect. I've been sketching out some fancier stuff, but we
would need time to properly tune the fanciness, and I'm inclined to get out
a stop-gap solution asap. On testnet, the zombie churn is pretty bad atm.
It results in uneasily wasted bandwidth as the churn is now almost constant.
There still exist some very old testnet nodes our there it seems. Beyond the
zombie churn, with the size of the testnet graph, we're forced to send tens
of thousands of messages (even if we're already fully synced) upon initial
connect, so very wasteful over all.
So I think the primary distinction between y'alls proposals is that
cdecker's proposal focuses on eventually synchronizing all the set of
_updates_, while Fabrice's proposal cares *only* about the newly created
channels. It only cares about new channels as the rationale is that if once
tries to route over a channel with a state channel update for it, then
you'll get an error with the latest update encapsulated.
Christian wrote:
> I propose adding a new feature bit (6, i.e., bitmask 0x40) indicating that
> the `init` message is extended with a u32 `gossip_timestamp`, interpreted
as
> a UNIX timestamp.
As the `init` message solely contains two variably sized byte slices, I
don't think we can actually safely extend it in this manner. Instead, a new
message is required, where the semantics of the feature bit _require_ the
other side to send it directly after receiving the `init` message from the
other side.
Aside from that, overall I like the simplicity of the protocol: it
eliminates both the zombie churn, and the intensive initial connection graph
dump without any extra messaging overhead (for reconciliation, etc).
Fabrice wrote:
> Just to be clear, you propose to use the timestamp of the most recent
> channel updates to filter the associated channel announcements ?
I think he's actually proposing just a general update horizon in which
vertexes+edges with a lower time stamp just shouldn't be set at all. In the
case of an old zombie channel which was resurrected, it would eventually be
re-propagated as the node on either end of the channel should broadcast a
fresh update along with the original chan ann.
> When a node that supports channel announcement filters receives
> a`channel_announcement_filters` message, it uses it to filter channel
> announcements (and, implicitly ,channel updates) before sending them
This seems to assume that both nodes have a strongly synchronized view of
the network. Otherwise, they'll fall back to sending everything that went on
during the entire epoch regularly. It also doesn't address the zombie churn
issue as they may eventually send you very old channels you'll have to deal
with (or discard).
> The use case we have in mind is mobile nodes, or more generally nodes
> which are often offline and need to resync very often.
How far back would this go? Weeks, months, years?
FWIW this approach optimizes for just learning of new channels instead of
learning of the freshest state you haven't yet seen.
-- Laolu
On Mon, Feb 5, 2018 at 7:08 AM Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:
> Hi,
>
> On 5 February 2018 at 14:02, Christian Decker
> <decker.christian at gmail.com> wrote:
> > Hi everyone
> >
> > The feature bit is even, meaning that it is required from the peer,
> > since we extend the `init` message itself, and a peer that does not
> > support this feature would be unable to parse any future extensions to
> > the `init` message. Alternatively we could create a new
> > `set_gossip_timestamp` message that is only sent if both endpoints
> > support this proposal, but that could result in duplicate messages being
> > delivered between the `init` and the `set_gossip_timestamp` message and
> > it'd require additional messages.
>
> We chose the other aproach and propose to use an optional feature
>
> > The reason I'm using timestamp and not the blockheight in the short
> > channel ID is that we already use the timestamp for pruning. In the
> > blockheight based timestamp we might ignore channels that were created,
> > then not announced or forgotten, and then later came back and are now
> > stable.
>
> Just to be clear, you propose to use the timestamp of the most recent
> channel updates to filter
> the associated channel announcements ?
>
> > I hope this rather simple proposal is sufficient to fix the short-term
> > issues we are facing with the initial sync, while we wait for a real
> > sync protocol. It is definitely not meant to allow perfect
> > synchronization of the topology between peers, but then again I don't
> > believe that is strictly necessary to make the routing successful.
> >
> > Please let me know what you think, and I'd love to discuss Pierre's
> > proposal as well.
> >
> > Cheers,
> > Christian
>
> Our idea is to group channel announcements by "buckets", create a
> filter for each bucket, exchange and use them to filter out channel
> announcements.
>
> We would add a new `use_channel_announcement_filters` optional feature
> bit (7 for example), and a new `channel_announcement_filters` message.
>
> When a node that supports channel announcement filters receives an
> `init` message with the `use_channel_announcement_filters` bit set, it
> sends back its channel filters.
>
> When a node that supports channel announcement filters receives
> a`channel_announcement_filters` message, it uses it to filter channel
> announcements (and, implicitly ,channel updates) before sending them.
>
> The filters we have in mind are simple:
> - Sort announcements by short channel id
> - Compute a marker height, which is `144 * ((now - 7 * 144) / 144)`
> (we round to multiples of 144 to make sync easier)
> - Group channel announcements that were created before this marker by
> groups of 144 blocks
> - Group channel announcements that were created after this marker by
> groups of 1 block
> - For each group, sort and concatenate all channel announcements short
> channel ids and hash the result (we could use sha256, or the first 16
> bytes of the sha256 hash)
>
> The new `channel_announcement_filters` would then be a list of
> (height, hash) pairs ordered by increasing heights.
>
> This implies that implementation can easily sort announcements by
> short channel id, which should not be very difficult.
> An additional step could be to send all short channel ids for all
> groups for which the group hash did not match. Alternatively we could
> use smarter filters
>
> The use case we have in mind is mobile nodes, or more generally nodes
> which are often offline and need to resync very often.
>
> Cheers,
> Fabrice
> _______________________________________________
> 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/2ea76f0a/attachment-0001.html>

2023-06-09 12:48:44

- reply

📅 Original date posted:2018-01-31
📝 Original message:
Segwit has been merged into btcd for for sometime now. It's also possible to
run with bitcoind. I encourage you to check out the documentation:
https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md
In lnd, the chain backend has already been abstracted[1]. This is what
allows
it to run with any of the three supported chain backends (btcd, bitcoind,
neutrino). I invite you to continue this conversation on #lnd on Freenode.
[1]:
https://github.com/lightningnetwork/lnd/blob/master/lnwallet/interface.go
On Wed, Jan 31, 2018 at 12:23 PM Benjamin Mord <ben at mord.io> wrote:
> Hi,
>
> I'm not finding evidence of segwit in btcd, yet choice of golang is
> appealing to me. Can one run lnd on bitcoind?
>
> More generally speaking, is there a plan for the layer 2 / layer 1
> protocol binding to be abstracted away from the implementation on either
> side, via SPI or such?
>
> Thanks,
> Ben
> _______________________________________________
> 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/20180131/b2f3e156/attachment.html>

2023-06-09 12:48:25

- reply

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

2023-06-09 12:47:52

- reply

📅 Original date posted:2017-11-29
📝 Original message:
FWIW, going by the bitnodes tracker [1], most upgraded nodes are currently
running a bitcoind version >= 0.14. With segwit widely deployed, I'd safe
say it's a safe bet to assume that most miners are already running with
the standard malleability reducing policy that shipped in that version.
However, as you point out there's still the possibility that the Eve's
first element of Eve's witness stack would pushes the fee rate of Alice's
justice transaction to an "insufficient" range. If the justice transaction
is delayed excessively, then there's a chance that the commitment output
of the peer breaching the transaction matures before Alice's justice
transaction is confirmed. In this case, Eve may successfully breach the
contract.
In lnd, we have plans to implement a scorched earth policy when responding
to on-chain contract breach event. With this policy, once our justice
transaction punishing the violator of the contract has been broadcast, for
each block it doesn't confirm in, we'll gradually bump of the fee on the
transaction (with RBF). The additional fee would be drawn from from the
*violator's* settled balance in that state. With each iteration (block, no
confirmation, fee bump) we gradually bleed away the funds of the violator,
supplementing the fee already present on that commitment state. Assuming
that rational miners accept the higher fee transaction (and the violator
isn't colluding with miners), then our justice transaction will make it
into the block before the transaction breaching the contract. In an
attempt to counter act this, the violator may try to use CPFP to anchor
the transaction into the chain with a more attractive fee package.
However, in order to beat us in, they must spend a total amount of fees
that is greater than the current cumulative fee rate on our justice
transaction. If they do so, they'll either end up net negative, or fail to
profit (as they'll also bleed away all their funds).
The vindication strategy described requires the justice transaction to
signal RBF. This serves as another reason to signal RBF in justice
transactions. I recommend that all implementations adopt the scorched
earth vindication strategy when handling breached contracts. It addresses
Dorier's malleability concern, and also further stack the incentives
against attempting a contract breach.
[1]: https://bitnodes.earn.com/nodes/
-- Laolu
On Tue, Nov 28, 2017 at 11:40 PM Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> Actually this was merged as policy rules in 0.14, not 0.15.1.
> Not as bad as I thought, but still a bit uneasy about someone malleating
> my transaction.
>
> Another way to fix the situation which would not require the BOLT to
> change is to enable RBF of the Penalty transaction so Eve transaction would
> be replaced by the initial one.
>
> Nicolas,
>
> On Wed, Nov 29, 2017 at 4:11 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> I noticed the Commitment Transaction Output script is weak to
>> malleability, this can be used to delay confirmation of the revocation.
>> Luckily, fixing the situation does not require lots of development.
>>
>> ```
>> OP_IF
>> # Penalty transaction
>> <revocationkey>
>> OP_ELSE
>> `to_self_delay`
>> OP_CSV
>> OP_DROP
>> <local_delayedkey>
>> OP_ENDIF
>> OP_CHECKSIG
>> ```
>>
>> An attacker can delay the Penalty Transaction by malleating it. Which can
>> lead to very bad outcome as Lightning dependant on time locks.
>>
>> The penalty transaction would have.
>>
>> ```
>> <revocation_sig> 1
>> ```
>>
>> Problem is that Eve could malleate OP_1 into a positive, huge number.
>> This would have for effect to fill the mempool of nodes/miners with the
>> malleated version which will have an higher fee rate, delaying the
>> confirmation of the penalty transaction.
>>
>> Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012
>> which was merged into v0.15.1. (
>> https://github.com/bitcoin/bitcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14
>> )
>>
>> I guess that by the time LN is ready, 0.15.1 will be spread enough among
>> miners, but still I think a 2 bytes overhead is well worth the fix.
>>
>> ```
>> 1 OP_EQUAL OP_IF
>> # Penalty transaction
>> <revocationkey>
>> OP_ELSE
>> `to_self_delay`
>> OP_CSV
>> OP_DROP
>> <local_delayedkey>
>> OP_ENDIF
>> OP_CHECKSIG
>> ```
>>
>> Nicolas,
>>
>
> _______________________________________________
> 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/20171129/ab719344/attachment-0001.html>

2023-06-09 12:47:50

- reply

📅 Original date posted:2017-11-25
📝 Original message:
On Sat, Nov 25, 2017 at 11:13 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
wrote:
> When you say "we have mechanisms in place", you refer to the
> descriptions available in
> https://github.com/lightningnetwork/lightning-rfc?
>
I think he's referring to the ability to add "routing" hints to the BOLT 11
payment requests.
>
> > Personally I'd like to separate the base routing layer and the onion
> > routing layer eventually. The base layer would provide end-to-end
> > connectivity between any two nodes and the onion layer would then simply
> > chose some random nodes in the network and not be bound to the networks
> > topology. The same way IP and TOR are not mixed.
>
> Yes, I totally agree. I also think that this separation would help us to
> better understand what are the necessary and/or sufficient guarantees
> required in both layers for the LN to work.
>
>
Not quite sure what y'all mean by this. If there doesn't exist a direct
path,
then how can one use onion routing to complete the transfer?
>
> Could you please point me to where this mechanism is described? I have
> been thinking about this, but the solution is not completely clear in my
> mind yet.
>
>
At my talk at Scaling Bitcoin, I outlined two possible paths:
1. Assuming a schnorr-like signature protocol eventually gets into
Bitcoin, nodes would use a cooperative signature in lieu of
mulit-sig.
2. Or today, use a 2-party ECDSA protocol to generate a joint key, and
sign using that to update the channel.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/891c0bb9/attachment.html>

2023-06-09 12:47:47

- reply

📅 Original date posted:2017-11-25
📝 Original message:
(final try as the prior mail hit the size limit, sorry for the spam!)
Hi Pedro,
I came across this paper a few weeks ago, skimmed it lightly, and noted a
few interesting aspects I wanted to dig into later. Your email reminded me
to re-read the paper, so thanks for that! Before reading the paper, I
wasn't aware of the concept of coordinate embedding, nor how that could be
leveraged in order to provide sender+receiver privacy in a payment network
using a distance-vector-like routing system. Very cool technique!
After reading the paper again, my current conclusion is that while the
protocol presents some novel traits in the design a routing system for
payment channel based networks, it lends much better to a
closed-membership, credit network, such as Ripple (which is the focus of
the paper).
In Ripple, there are only a handful of gateways, and clients that seek to
interact with the network must chose their gateways *very* carefully,
otherwise consensus faults can occur, violating safety properties of the
network. It would appear that this gateway model nicely translates well to
the concept of landmarks that the protocol is strongly dependant on.
Ideally, each gateway would be a landmark, and as there are a very small
number of gateways within Ripple (as you must be admitted to be a verified
gateway in the network), then parameter L (the total number of landmarks)
is kept small which minimizes routing overhead, the average path-length,
etc.
When we compare Ripple to LN, we find that the two networks are nearly
polar opposites of each other. LN is an open-membership network that
requires zero initial configuration by central administrators(s). It more
closely resembles *debit* network (a series of tubes of money), as the
funds within channels must be pre-committed in order to establish a link
between two nodes, and cannot be increased without an additional on-chain
control transaction (to add or remove funds). Additionally, AFAIK (I'm no
expert on Ripple of course), there's no concept of fees within the
network. While within LN, the fee structure is a critical component of the
inventive for node operators to lift their coins onto this new layer to
provider payment routing services. Finally, in LN we rely on time-locks
in order to ensure that all transactions are atomic which adds another set
of constraints. Ripple has no such constraint as transfers are based on
bi-lateral trust.
With that said, the primary difference between this protocol is that
currently we utilize a source-routed system which requires the sender to
know "most" of the path to the destination. I say "most" as currently,
it's possible for the receiver of a payment to use a poor man's rendezvous
system to provide the sender with a set of suffix paths form what one can
consider ad-hoc landmarks. The sender can then concatenate these with
their own paths, and construct the Sphinx routing package which encodes
the full route. This itself only gives sender privacy, and the receiver
doesn't know the identity of the sender, but the sender learns the
identity of the receiver.
We have plans to achieve proper sender/receiver privacy by extending our
Sphinx usage to leverage HORNET, such that the payment descriptor (payment
request containing details of the payment) also includes several paths
from rendezvous nodes (Rodrigo's) to the receiver. The rendezvous route
itself will be nested as a further Anonymous Header (AHDR) which includes
the information necessary to complete the onion circuit from Rodrigo to
the receiver. As onion routing is used, only Rodrigo can decrypt the
payload and finalize the route. With such a structure, the only nodes that
need to advertise their channels are nodes which seek to actively serve as
channel routers. All other nodes (phones, laptops, etc), don't need to
advertise their channels to the greater network, reducing the size of the
visible network, and also the storage and validation overhead. This serves
to extend the "scale ceiling" a bit.
My first question is: is it possible to adapt the protocol to allow each
intermediate node to communicate their time lock and fee references to the
sender? Currently, as the full path isn't known ahead of time, the sender
is unable to properly craft the timelocks to ensure safety+atomicity of
the payment. This would mean they don't know what the total timelock
should be on the first outgoing link. Additionally, as they don't know the
total path and the fee schedule of each intermediate node, then once
again, they don't know how much to send on the first out going link. It
would seem that one could extend the probing phase to allow backwards
communication by each intermediate node back to the sender, such that they
can properly craft a valid HTLC. This would increase the set up costs of
the protocol however, and may also increase routing failures as it's
possible incompatibilities arise at run-time between the preferences of
intermediate nodes. Additionally, routes may fail as an intermediate node
consumes too many funds as their fee, causing the funds to be insufficient
when it reaches the destination. One countermeasure would maybe: the
sender always sends waaay more than necessary, and gives the receiver a
one-time payment identifier, requiring that they route the remainder of
the funds *back* to them.
To solve this issue presently, we extend the header in Sphinx to include a
per-hop payload which allows the sender to precisely dictate the
structure of the route, allows the intermediate nodes to authenticate the
information given to it, and also allow the intermediate node to verify
that their policies have properly been respected. These payloads can also
be utilized by applications to communicate a small-ish amount of data to
construct higher-level protocols on top of the system. Examples include:
cross-chain swaps, chance payment games, higher-level B2B protocols,
flavors of ZKCP's, media streaming, internet access proxying, etc.
>From my point-of-view, when extended to LN, the core component of the
protocol (landmarks), becomes the weakest component. From my reading,
*all* nodes need to be ware of an *identical* set of landmarks (more or
less similar to the desired homogeneity of Gateways), otherwise the
coordinate embedding scheme breaks down. Currently, there's no requirement
that all nodes have a globally consistent view of the network. So then an
important questions arises: who choose the landmarks? A desirable property
of a routing system for LN (IMO) is that is has close to zero required
initial set up by a central administrator. With this protocol, it would
seem that all nodes much ship with a hard coded set of global landmarks
for the path finding to succeed. This itself pins a hard coordination
requirement amongst implementers to have something like this deployed.
Even ignoring this requirement for a minute, I see several other
downsides:
* As *all* payments must flow through landmarks (since nodes break up
their payment into L sub-flows), the landmarks must be very, very
well capitalized. This would cause strong consolidation of the
selection of landmarks, as they need extremely large channels in
order to facilitate transfer within the network.
* As landmarks must be globally known, this it seems this would
introduce fragility in the network. If most of the landmarks go down
(fails stop crashes) due to hardware issues, DoS, exploited bugs,
etc, then the network's throughput instantly becomes crippled.
* If all payment flow *must* go through landmarks, and the transfers
within the network are relatively uni-directional (all payment going
to Candy Crush Ultra: Lighting Strikes Twice), then their
channels would become unbalanced very quickly.
The last point there invokes another component of the network: passive
channel rebalancing. With source routing, it's possible for nodes to
passive rebalance their channels, in order to keep the in equilibrium,
such that on average they'll be able to handle a payment flow coming from
any direction. This is possible as with source routing, it's easy for a
node to simply send a payment to himself incoming/outgoing from the pair
of channels they wish to adjust the available flow of. With
distance-vector-like protocols, this doesn't seem possible, as the node
doesn't have any control of the incoming channel that the payment will
arrive on.
Finally, the notion of value privacy within the scheme seems a bit weak.
>From this definition, any protocol that didn't broadcast intents to send
payments to the world would achieve this trait. The base Bitcoin
blockchain doesn't mask the values of transfers (yet), but even if it did
unconditionally maintaining value privacy of channel doesn't seem
compatible with multi-hop payment networks (nodes can simply perform
probing/tagging attacks to ascertain a range of the size of a channel). A
possible mitigation would be for nodes to probabilistically drop incoming
payments, with all nodes sampling from the same distribution. However,
this would dramatically increase routing failures by senders, removing the
"low-latency" trait of payment networks that many find desirable.
Personally, I've very excited to see additional research on the front of
routing within the network! Excellent work by all authors.
In the end, I don't think it'll be a one-size fits all solution, as each
routing protocol delivers with it a set of tradeoffs that should be
weighed depending on target characteristics, and use-cases. There's no
strong requirement that the network as a whole uses a *single* routing
protocol. Instead several distinct protocols can be deployed based on
use-case requirements, as we only need to share a single end-to-end
construct: the HTLC. I could see a future in a few years where we have
several deployed protocols, similar to the wide array of existing routing
protocols deployed on the Internet. What we have currently gets us from
Zero to One. We'll definitely need to experiment with additional
approaches as the size of the network grows, and the true economic flow
patterns emerge after we all deploy to mainnet.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/d57bbed0/attachment-0001.html>

2023-06-09 12:47:47

- reply

📅 Original date posted:2017-11-25
📝 Original message:
(re-sending as doesn't look like my original mail went through to the list?)
Hi Pedro,
I came across this paper a few weeks ago, skimmed it lightly, and noted a
few interesting aspects I wanted to dig into later. Your email reminded me
to re-read the paper, so thanks for that! Before reading the paper, I
wasn't aware of the concept of coordinate embedding, nor how that could be
leveraged in order to provide sender+receiver privacy in a payment network
using a distance-vector-like routing system. Very cool technique!
After reading the paper again, my current conclusion is that while the
protocol presents some novel traits in the design a routing system for
payment channel based networks, it lends much better to a
closed-membership, credit network, such as Ripple (which is the focus of
the paper).
In Ripple, there are only a handful of gateways, and clients that seek to
interact with the network must chose their gateways *very* carefully,
otherwise consensus faults can occur, violating safety properties of the
network. It would appear that this gateway model nicely translates well to
the concept of landmarks that the protocol is strongly dependant on.
Ideally, each gateway would be a landmark, and as there are a very small
number of gateways within Ripple (as you must be admitted to be a verified
gateway in the network), then parameter L (the total number of landmarks)
is kept small which minimizes routing overhead, the average path-length,
etc.
When we compare Ripple to LN, we find that the two networks are nearly
polar opposites of each other. LN is an open-membership network that
requires zero initial configuration by central administrators(s). It more
closely resembles *debit* network (a series of tubes of money), as the
funds within channels must be pre-committed in order to establish a link
between two nodes, and cannot be increased without an additional on-chain
control transaction (to add or remove funds). Additionally, AFAIK (I'm no
expert on Ripple of course), there's no concept of fees within the
network. While within LN, the fee structure is a critical component of the
inventive for node operators to lift their coins onto this new layer to
provider payment routing services. Finally, in LN we rely on time-locks
in order to ensure that all transactions are atomic which adds another set
of constraints. Ripple has no such constraint as transfers are based on
bi-lateral trust.
With that said, the primary difference between this protocol is that
currently we utilize a source-routed system which requires the sender to
know "most" of the path to the destination. I say "most" as currently,
it's possible for the receiver of a payment to use a poor man's rendezvous
system to provide the sender with a set of suffix paths form what one can
consider ad-hoc landmarks. The sender can then concatenate these with
their own paths, and construct the Sphinx routing package which encodes
the full route. This itself only gives sender privacy, and the receiver
doesn't know the identity of the sender, but the sender learns the
identity of the receiver.
We have plans to achieve proper sender/receiver privacy by extending our
Sphinx usage to leverage HORNET, such that the payment descriptor (payment
request containing details of the payment) also includes several paths
from rendezvous nodes (Rodrigo's) to the receiver. The rendezvous route
itself will be nested as a further Anonymous Header (AHDR) which includes
the information necessary to complete the onion circuit from Rodrigo to
the receiver. As onion routing is used, only Rodrigo can decrypt the
payload and finalize the route. With such a structure, the only nodes that
need to advertise their channels are nodes which seek to actively serve as
channel routers. All other nodes (phones, laptops, etc), don't need to
advertise their channels to the greater network, reducing the size of the
visible network, and also the storage and validation overhead. This serves
to extend the "scale ceiling" a bit.
My first question is: is it possible to adapt the protocol to allow each
intermediate node to communicate their time lock and fee references to the
sender? Currently, as the full path isn't known ahead of time, the sender
is unable to properly craft the timelocks to ensure safety+atomicity of
the payment. This would mean they don't know what the total timelock
should be on the first outgoing link. Additionally, as they don't know the
total path and the fee schedule of each intermediate node, then once
again, they don't know how much to send on the first out going link. It
would seem that one could extend the probing phase to allow backwards
communication by each intermediate node back to the sender, such that they
can properly craft a valid HTLC. This would increase the set up costs of
the protocol however, and may also increase routing failures as it's
possible incompatibilities arise at run-time between the preferences of
intermediate nodes. Additionally, routes may fail as an intermediate node
consumes too many funds as their fee, causing the funds to be insufficient
when it reaches the destination. One countermeasure would maybe: the
sender always sends waaay more than necessary, and gives the receiver a
one-time payment identifier, requiring that they route the remainder of
the funds *back* to them.
To solve this issue presently, we extend the header in Sphinx to include a
per-hop payload which allows the sender to precisely dictate the
structure of the route, allows the intermediate nodes to authenticate the
information given to it, and also allow the intermediate node to verify
that their policies have properly been respected. These payloads can also
be utilized by applications to communicate a small-ish amount of data to
construct higher-level protocols on top of the system. Examples include:
cross-chain swaps, chance payment games, higher-level B2B protocols,
flavors of ZKCP's, media streaming, internet access proxying, etc.
>From my point-of-view, when extended to LN, the core component of the
protocol (landmarks), becomes the weakest component. From my reading,
*all* nodes need to be ware of an *identical* set of landmarks (more or
less similar to the desired homogeneity of Gateways), otherwise the
coordinate embedding scheme breaks down. Currently, there's no requirement
that all nodes have a globally consistent view of the network. So then an
important questions arises: who choose the landmarks? A desirable property
of a routing system for LN (IMO) is that is has close to zero required
initial set up by a central administrator. With this protocol, it would
seem that all nodes much ship with a hard coded set of global landmarks
for the path finding to succeed. This itself pins a hard coordination
requirement amongst implementers to have something like this deployed.
Even ignoring this requirement for a minute, I see several other
downsides:
* As *all* payments must flow through landmarks (since nodes break up
their payment into L sub-flows), the landmarks must be very, very
well capitalized. This would cause strong consolidation of the
selection of landmarks, as they need extremely large channels in
order to facilitate transfer within the network.
* As landmarks must be globally known, this it seems this would
introduce fragility in the network. If most of the landmarks go down
(fails stop crashes) due to hardware issues, DoS, exploited bugs,
etc, then the network's throughput instantly becomes crippled.
* If all payment flow *must* go through landmarks, and the transfers
within the network are relatively uni-directional (all payment going
to Candy Crush Ultra: Lighting Strikes Twice), then their
channels would become unbalanced very quickly.
The last point there invokes another component of the network: passive
channel rebalancing. With source routing, it's possible for nodes to
passive rebalance their channels, in order to keep the in equilibrium,
such that on average they'll be able to handle a payment flow coming from
any direction. This is possible as with source routing, it's easy for a
node to simply send a payment to himself incoming/outgoing from the pair
of channels they wish to adjust the available flow of. With
distance-vector-like protocols, this doesn't seem possible, as the node
doesn't have any control of the incoming channel that the payment will
arrive on.
Finally, the notion of value privacy within the scheme seems a bit weak.
>From this definition, any protocol that didn't broadcast intents to send
payments to the world would achieve this trait. The base Bitcoin
blockchain doesn't mask the values of transfers (yet), but even if it did
unconditionally maintaining value privacy of channel doesn't seem
compatible with multi-hop payment networks (nodes can simply perform
probing/tagging attacks to ascertain a range of the size of a channel). A
possible mitigation would be for nodes to probabilistically drop incoming
payments, with all nodes sampling from the same distribution. However,
this would dramatically increase routing failures by senders, removing the
"low-latency" trait of payment networks that many find desirable.
Personally, I've very excited to see additional research on the front of
routing within the network! Excellent work by all authors.
In the end, I don't think it'll be a one-size fits all solution, as each
routing protocol delivers with it a set of tradeoffs that should be
weighed depending on target characteristics, and use-cases. There's no
strong requirement that the network as a whole uses a *single* routing
protocol. Instead several distinct protocols can be deployed based on
use-case requirements, as we only need to share a single end-to-end
construct: the HTLC. I could see a future in a few years where we have
several deployed protocols, similar to the wide array of existing routing
protocols deployed on the Internet. What we have currently gets us from
Zero to One. We'll definitely need to experiment with additional
approaches as the size of the network grows, and the true economic flow
patterns emerge after we all deploy to mainnet.
-- Laolu
On Tue, Nov 21, 2017 at 9:38 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
wrote:
> Hello,
>
> my name is Pedro Moreno-Sanchez and I am a PhD student at the computer
> science department at Purdue. I would like to bring to your attention a
> novel routing algorithm suitable for the Lightning Network (LN) that I
> have been working on with my supervisor Prof. Aniket Kate (Purdue
> University) and my co-workers Stefanie Roos and Prof. Ian Goldberg
> (University of Waterloo).
>
> Our approach is called SpeedyMurmurs, a routing algorithm for
> decentralized payment networks such as the LN. SpeedyMurmurs uses an
> embedding-based approach, meaning that the algorithm assigns meaningful
> coordinates to nodes that enable efficient and effective discovery of
> payment paths. In a nutshell, SpeedyMurmurs creates a spanning tree by
> means of a Breadth-First Search and then associates a coordinate to each
> node depending on its position in the tree. A path from the sender to
> the receiver is then calculated in a flexible manner, with each
> intermediate node choosing the next node in the path as a function of
> its neighbors' coordinates, available funds and closeness to the
> receiver. To account for topology changes (e.g., a new channel is
> created), the routing information is locally updated by only those
> affected nodes in the network.
>
> We have simulated several configurations of SpeedyMurmurs using real
> data from the Ripple network and compared it with other routing
> algorithms available in the literature. Our simulation results show that
> SpeedyMurmurs is able to find paths at about twice faster, reduces the
> communication overhead by at least a factor of 2 and maintains a similar
> or higher payment success ratio. Our simulation framework is open source
> and we believe that it might be of independent interest for this
> community to test this and any other alternative protocols that you
> might have in mind. If you are interested, we are happy to extend on this.
>
> Finally, we also show that SpeedyMurmurs achieves the privacy notions of
> interest in the LN. In particular, SpeedyMurmurs achieves value privacy,
> i.e., the total value of a transaction remains hidden, as well as sender
> and receiver privacy, i.e., the identities of the two transacting nodes
> remain hidden from the adversary.
>
>
> You can find all the details in the draft of our paper [1]. The final
> version of this work will appear at NDSS 2018 conference [2]. We would
> be glad to hear any question and feedback from you and are open to carry
> out further collaborations if this line of work is of interest for you.
>
> Best regards,
> Pedro, Stef, Aniket and Ian.
>
> [1] https://arxiv.org/abs/1709.05748
> [2] https://www.ndss-symposium.org/
>
> On 11/17/17 8:09 PM, Saravanan Vijayakumaran wrote:
> > Hi Christian,
> >
> > Are there any open source simulators available for trying different
> > routing strategies? Or even a simulator for the Lightning network as a
> > whole?
> >
> > Regards
> > sarva
> >
> >
> > On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker
> > <decker.christian at gmail.com <mailto:decker.christian at gmail.com>> wrote:
> >
> > Oh yeah, my mail tool destroyed that mail quite expertly :-)
> >
> > The footnotes were
> > [1]
> >
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
> > <
> https://secure-web.cisco.com/1wkWGu7k6qIvsw8KxbTL8XXIpbTYjcgzOohVSUjpLJpNW0_r00YaFlguhX0pSCEAg2qU5kztXF4bxEpLbMz-RLAz9KTBvE0lh3kFGUjL5qke6yx8EcYvhHQQSttWjRX5HOt69vu8suXd7AhjEweVxeBFhvptINqjBarDx7woqCa14ZgWZdMk0dAt45Lnu_w1wjgn3j5sD7tBo187MGXR94eapimiMFjXySj70GeP1yiEA8rP0NUQ5CSXme2wQy-spVW_SLQpvkAQ01NlXUjK-ufQw_APez6C73Qx0bFh_9F-CPhKhhvM3tSs6IGNEM63aXMVeti2Ci0R5Xc15tvcT9gxpC32bNetja5ber6wbIHLbI9FWviQ63cWaNwhedQRN/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md
> >
> > [2]
> >
> https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad
> > <
> https://secure-web.cisco.com/1UG1OaEI1KFpQ4prjxrhN1Wsxs0P1Tco0MXQz0xltJZQjwI-sNi98eXMz-gW4qOQd2jJ4i0uktvL8CH-9RrmEg3GkxHfcxjnjxY_hlLP-ctXOYMSk4BFbySy7vD5xWivimHIfMHtr13ffgEoFLItUgoajxUe7tnkchPN_P5OZ_FOzYdpqW_UDdgWW0_VOsccR5yt1vh0MRyVxO2B2ua8k4NmbFgTmht6hxUlXDsXOsOSGDHm1WO5VNrRbUcGeTPpdBMx0xeyZ9FTMTBCIAMOZ6UEb_eAX3X1iVIFkP_MPtuJcp0q8t9Tk_UBs-dHVRjyYcCsnetXYNI_mEsdtyg63aLXuJE1pMLb8-eamWaFfklVo-w9N9F0XTbmbkgGfcWU4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad
> >
> > [3]
> >
> https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
> > <
> https://secure-web.cisco.com/1XOlJdRo0gtzmPhNfVlEpMsrVBAI6BSjdDawPogEDIwYDdva2BSx4H8F9B3E6bkVIqA7ByFEF85qVjJ775leFwE54p5G6-wHH4Cio0p9sYLJ14-NHwcwvYQ--zdI8hdAyjGQbcLltVFAmorMaTlHq4FGI1CmxlwiUYgH1tjZn3UAHOu5xm5pLVi6KTb9WsJvuJsOBJhLfRLWGcAhVbjRXuV8b3x_G4ybOg1CQYC9ZVq3RJCPnNgQ3BN3a5ZuzW4veOE_dgi80FEy1x7a8spH-TV-cb_fey6ud-S25AWQ1PbctVS5zgQ4Ki4XYkR5igotNGGbWhACevBJfU1Hxqk90_g-DgQtS9_e_UX_FsY-yAjw/https%3A%2F%2Fwww.tik.ee.ethz.ch%2Ffile%2Fa20a865ce40d40c8f942cf206a7cba96%2FScalable_Funding_Of_Blockchain_Micropayment_Networks%2520%281%29.pdf
> >
> >
> > We will eventually move away from the hash function based approach
> > in favor of something that allows us to decorrelate hops in a route.
> > We have indeed started writing down some of the ideas at least for
> > Lightning in the project's wiki [4], but they're definitely not
> > fleshed out.
> >
> > [4]
> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming
> > <
> https://secure-web.cisco.com/1XqVZXht8sW8tdbLxwEMjoU-hxxV6OJwpKqc2OudZy26Le21yvOIBPwqizepwLi9TBeEV2BMDc-nCiKpj3eryi59jqvoZcBRrSQSVt9Qrq8pIxNSvhIMlG4cRd3lnj17JT9mDRRt0lS51C_9gpryV6qFqdiROdyJeTKfqUGmnvPo3isfeUbC_TOOfWLDV16jYA38ytCfTOryyDvJgJdYw7ArAUEMg10jNv8lV9aTARBOcOmgLjqJt0ktecsUpUCfIVAQlJEvtAAbWAUKwMoXg6MpIQEA4NE1ATntmwjLGl4IqQEqRAGxkGxWI8yQDL74yPPTIQmGTxs_JXE6YYMrhuD93GR1kyUJkOAH3Z_5nL1bsr3ifW31PJtUckQNnwY8e/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fwiki%2FBrainstorming
> >
> >
> >
> > On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <ben at mord.io
> > <mailto:ben at mord.io>> wrote:
> >
> > "I think this is exactly the right venue to discuss these kinds
> > of issue..." - you are probably right! My bad.
> >
> > Christian, thank you for your knowledgable reply. The footnotes
> > did not come through on my end, I am especially interested in
> > [3]. Do you have a link? I am thrilled to hear of a
> > Bitcoin-compatible revive alternative! :)
> >
> > Are we keeping an inventory somewhere of the cryptographic
> > primitives being used in lightning and the specific assumptions
> > being made about them (e.g. preimage resistance vs collision
> > resistance and such)? One project I have not yet found but
> > believe we need across the entire cryptocurrency community, is a
> > (wiki-style?) inventory of unproven mathematical assumptions
> > (e.g. hardness of discrete logarithm) and/or cryptographic
> > primitives, cataloged in terms of the cryptocurrency
> > technologies which require them. Such a resource could help the
> > community respond more quickly, comprehensively, and
> > transparently to the inevitable cryptanalytic surprises that
> > will pop up over time (especially from the quantum cryptanalytic
> > area, but even the classical cryptanalytic community as well).
> >
> > Related, I believe the ideal end state would be to only assume
> > existence of a preimage-resistant hash function, and to code
> > such that one function could be quickly swapped with another and
> > thus update entire system. I'm not sure if that is a realistic
> > goal, but here is my first attempt to move in that direction in
> > case it is of interest to lightning. It is hard to imagine it
> > would be a new idea, although I have not yet found the precedent:
> > http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html
> > <
> http://secure-web.cisco.com/1ewGQFfIxw1QZwneD3sDbhSSWP-YTmBwOYe529E7_zeYZZADnASbspvBAftPFXX6ZxJI2l2-8-xEqdpkmFg3fEIfkfRBYN8oZ8Z0HpeHh73MnT3Zi3M8GUs8SGMww38ZPnzsc7xlt7H5KFlLMcCsTWIgEtq4roZHDkYasanNeViP_UA3DIod7A281fNvWnQ1mnLs6d8WN_uFx1diU_xr-EoMab3wyANozirDj1gZ2_yPBn6S8tePYMkTkhIZlLz_BlvIfk9_KCOOiUcWxDTtCq9KdvoqEzStC04Z6q8xS5rtSnmK9GZZxv30yrgT8eWA4eOzce6AA3m0WEClNzbzANgi11GXBVde9pNiUIRcLDNw/http%3A%2F%2Fben.mord.io%2Fp%2Fdelayed-chained-key-revelation-dckr.html
> >
> >
> > Thanks,
> > Ben
> >
> >
> > On Nov 17, 2017 8:04 AM, "Christian Decker"
> > <decker.christian at gmail.com <mailto:decker.christian at gmail.com>>
> > wrote:
> >
> > On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <ben at mord.io
> > <mailto:ben at mord.io>> wrote:
> >
> > Ivan,
> >
> > That is mostly false, but with bits of truth sprinkled
> > in. Contact me at ben at mord.io <mailto:ben at mord.io> for
> > further discussion so we tread lightly on the lists'
> > email inboxes.
> >
> >
> > I think this is exactly the right venue to discuss these
> > kinds of issue,
> > so please don't move the conversation somewhere else :-)
> >
> > Routing is still very much in flux, we have a minimally
> > viable routing
> > protocol in the spec [1]. It is minimal in the sense that we
> > just push
> > the entire network's topology to the edges, which can then
> > locally
> > compute routes. This is effectively a source-routed network,
> > which
> > matches the requirements of the onion routing protocol we
> > use for
> > privact as well. But this does not mean that this is
> > protocol is set in
> > stone. We are actively working on finding better solutions
> > to the
> > problem of finding routes across a vast network of millions
> > if not
> > billions of nodes. Distance vector routing such as BGP uses
> > may be one
> > option like Ben suggested.
> >
> > For now the network can easily scale to about 1 million
> > channels [2]
> > even on very limited devices, Upgrading to another protocol
> > at a later
> > point in time is trivial, since none of the routing
> > information is
> > consensus critical. We have all the extension points built
> > in to allow
> > future extensibility.
> >
> >
> > But briefly: scale-capable routing protocols are
> > possible as demonstrated by IP and thus by the internet
> > itself. As for centralizing flow through small number of
> > liquidity providers, yes that does seem economically
> > probable, at least unless / until off-chain channel
> > rebalancing mechanism (like the recently proposed
> > "revive" protocol) come about. Bitcoin script is not
> > currently revive-capable but Ethereum is, so either
> > Bitcoin revive could be enabled via two-way pegged
> > sidechain protocol with Ethereum, or even better, by a
> > purpose-built (yet still not Turing-complete) extension
> > to Bitcoin script itself in the future.
> >
> >
> > As a matter of fact, Conrad and I just published a similar
> > technique for
> > off-chain channel rebalancing and fund re-allocation based
> > solely on
> > Bitcoin [3] (major props to Conrad for the excellent
> > writeup!). The
> > flexibility in Bitcoin exists.
> >
> > As for the hubs everybody is assuming will form, I don't
> > think they're
> > as likely to form. Creating such a hub is extremely costly
> > since it'll
> > have to allocate sufficient funds to cover the maximum
> > imbalance of all
> > of its channels ahead of time. Then the fees must cover the
> > opportunity
> > cost of allocating all of those funds to channels instead of
> > investing
> > them somewhere else. On top of that the funds will not be
> > moved alot
> > since they serve only a small number of endpoints connected
> > through
> > those channels, this compounds the problem of having high
> > fees. The high
> > fees make the hub channels a really bad choice for your
> > payments, after
> > all you were looking for small fees for your payments,
> > right? It opens
> > up an opportunity for nodes to open bypasses that grab some
> > of the
> > traffic and associated fees from the expensive hub.
> >
> > All of that being said, we should be careful about our
> > predictions on
> > how the topology will look, I added some counter arguments
> to a
> > hub-and-spoke network forming, but nobody can really be sure
> > about
> > what'll happen.
> >
> >
> > In either case the lightning network seems a key first
> > step, and even were off-chain payment rebalancing not
> > possible for some odd reason, the lightning network
> > seems extremely valuable and scaleable - regardless
> > because the centralization you speak is not one that
> > affects safety of the money supply itself, and these
> > centralized hubs would be more dispensable / swappable
> > versus the mining centralization risk that people more
> > often talk about in Bitcoin. Lightning network
> > centralization, even if it persisted somehow despite
> > revive and future concepts, would not be an existential
> > risk.
> >
> >
> > Rebalancing is definitely possible, even without [3], you can
> > disincentivize the use of a channel until they have been
> > rebalanced. For
> > long term imbalance, opening another channel may be the best
> > option
> >
> >
> > As for transaction fees, the idea is only channel setup
> > / tear down are required greatly reducing fees. Yes if
> > txin fees were millions of dollars then people could not
> > practically penalize fraud, but that is unlikely. Even
> > if txin fees made fraud claims marginally unprofitable
> > (yet practical) that would still be ok - the judicial
> > systems of most countries prove that people go beyond
> > self-interest when sufficiently ticked, a fact of human
> > psychology which in turn creates the incentives that
> > support honest business. (Also please be aware I'm not a
> > lightning code contributor, so that team might also be
> > doing more to address already than I thought to mention
> > above.)
> >
> >
> > This is open to speculation as well. We hope to reduce the
> > load on the
> > on-chain network sufficiently to allow timely on-chain
> > settlements. By
> > aggregating payments off-chain we can also aggregate the
> > fees and then
> > use them to pay on-chain fees. So don't consider the
> > on-chain fees for
> > your channels as your sole loss, they are paid for by
> > payments you
> > forward. Ultimately this should encourage participants to
> > open channels
> > that support the network as a whole, not just themselves. We
> are
> > building automations that should take care of this, the user
> > won't have
> > to do anything to improve the network topology.
> >
> > Cheers,
> > Christian
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > <mailto:Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > <
> https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> >
> https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-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/20171125/ae4972f1/attachment-0001.html>

2023-06-09 12:47:46

- reply

📅 Original date posted:2017-11-25
📝 Original message:
Hi Pedro,
I came across this paper a few weeks ago, skimmed it lightly, and noted a
few interesting aspects I wanted to dig into later. Your email reminded me
to re-read the paper, so thanks for that! Before reading the paper, I
wasn't aware of the concept of coordinate embedding, nor how that could be
leveraged in order to provide sender+receiver privacy in a payment network
using a distance-vector-like routing system. Very cool technique!
After reading the paper again, my current conclusion is that while the
protocol presents some novel traits in the design a routing system for
payment channel based networks, it lends much better to a
closed-membership, credit network, such as Ripple (which is the focus of
the paper).
In Ripple, there are only a handful of gateways, and clients that seek to
interact with the network must chose their gateways *very* carefully,
otherwise consensus faults can occur, violating safety properties of the
network. It would appear that this gateway model nicely translates well to
the concept of landmarks that the protocol is strongly dependant on.
Ideally, each gateway would be a landmark, and as there are a very small
number of gateways within Ripple (as you must be admitted to be a verified
gateway in the network), then parameter L (the total number of landmarks)
is kept small which minimizes routing overhead, the average path-length,
etc.
When we compare Ripple to LN, we find that the two networks are nearly
polar opposites of each other. LN is an open-membership network that
requires zero initial configuration by central administrators(s). It more
closely resembles *debit* network (a series of tubes of money), as the
funds within channels must be pre-committed in order to establish a link
between two nodes, and cannot be increased without an additional on-chain
control transaction (to add or remove funds). Additionally, AFAIK (I'm no
expert on Ripple of course), there's no concept of fees within the
network. While within LN, the fee structure is a critical component of the
inventive for node operators to lift their coins onto this new layer to
provider payment routing services. Finally, in LN we rely on time-locks
in order to ensure that all transactions are atomic which adds another set
of constraints. Ripple has no such constraint as transfers are based on
bi-lateral trust.
With that said, the primary difference between this protocol is that
currently we utilize a source-routed system which requires the sender to
know "most" of the path to the destination. I say "most" as currently,
it's possible for the receiver of a payment to use a poor man's rendezvous
system to provide the sender with a set of suffix paths form what one can
consider ad-hoc landmarks. The sender can then concatenate these with
their own paths, and construct the Sphinx routing package which encodes
the full route. This itself only gives sender privacy, and the receiver
doesn't know the identity of the sender, but the sender learns the
identity of the receiver.
We have plans to achieve proper sender/receiver privacy by extending our
Sphinx usage to leverage HORNET, such that the payment descriptor (payment
request containing details of the payment) also includes several paths
from rendezvous nodes (Rodrigo's) to the receiver. The rendezvous route
itself will be nested as a further Anonymous Header (AHDR) which includes
the information necessary to complete the onion circuit from Rodrigo to
the receiver. As onion routing is used, only Rodrigo can decrypt the
payload and finalize the route. With such a structure, the only nodes that
need to advertise their channels are nodes which seek to actively serve as
channel routers. All other nodes (phones, laptops, etc), don't need to
advertise their channels to the greater network, reducing the size of the
visible network, and also the storage and validation overhead. This serves
to extend the "scale ceiling" a bit.
My first question is: is it possible to adapt the protocol to allow each
intermediate node to communicate their time lock and fee references to the
sender? Currently, as the full path isn't known ahead of time, the sender
is unable to properly craft the timelocks to ensure safety+atomicity of
the payment. This would mean they don't know what the total timelock
should be on the first outgoing link. Additionally, as they don't know the
total path and the fee schedule of each intermediate node, then once
again, they don't know how much to send on the first out going link. It
would seem that one could extend the probing phase to allow backwards
communication by each intermediate node back to the sender, such that they
can properly craft a valid HTLC. This would increase the set up costs of
the protocol however, and may also increase routing failures as it's
possible incompatibilities arise at run-time between the preferences of
intermediate nodes. Additionally, routes may fail as an intermediate node
consumes too many funds as their fee, causing the funds to be insufficient
when it reaches the destination. One countermeasure would maybe: the
sender always sends waaay more than necessary, and gives the receiver a
one-time payment identifier, requiring that they route the remainder of
the funds *back* to them.
To solve this issue presently, we extend the header in Sphinx to include a
per-hop payload which allows the sender to precisely dictate the
structure of the route, allows the intermediate nodes to authenticate the
information given to it, and also allow the intermediate node to verify
that their policies have properly been respected. These payloads can also
be utilized by applications to communicate a small-ish amount of data to
construct higher-level protocols on top of the system. Examples include:
cross-chain swaps, chance payment games, higher-level B2B protocols,
flavors of ZKCP's, media streaming, internet access proxying, etc.
>From my point-of-view, when extended to LN, the core component of the
protocol (landmarks), becomes the weakest component. From my reading,
*all* nodes need to be ware of an *identical* set of landmarks (more or
less similar to the desired homogeneity of Gateways), otherwise the
coordinate embedding scheme breaks down. Currently, there's no requirement
that all nodes have a globally consistent view of the network. So then an
important questions arises: who choose the landmarks? A desirable property
of a routing system for LN (IMO) is that is has close to zero required
initial set up by a central administrator. With this protocol, it would
seem that all nodes much ship with a hard coded set of global landmarks
for the path finding to succeed. This itself pins a hard coordination
requirement amongst implementers to have something like this deployed.
Even ignoring this requirement for a minute, I see several other
downsides:
* As *all* payments must flow through landmarks (since nodes break up
their payment into L sub-flows), the landmarks must be very, very
well capitalized. This would cause strong consolidation of the
selection of landmarks, as they need extremely large channels in
order to facilitate transfer within the network.
* As landmarks must be globally known, this it seems this would
introduce fragility in the network. If most of the landmarks go down
(fails stop crashes) due to hardware issues, DoS, exploited bugs,
etc, then the network's throughput instantly becomes crippled.
* If all payment flow *must* go through landmarks, and the transfers
within the network are relatively uni-directional (all payment going
to Candy Crush Ultra: Lighting Strikes Twice), then their
channels would become unbalanced very quickly.
The last point there invokes another component of the network: passive
channel rebalancing. With source routing, it's possible for nodes to
passive rebalance their channels, in order to keep the in equilibrium,
such that on average they'll be able to handle a payment flow coming from
any direction. This is possible as with source routing, it's easy for a
node to simply send a payment to himself incoming/outgoing from the pair
of channels they wish to adjust the available flow of. With
distance-vector-like protocols, this doesn't seem possible, as the node
doesn't have any control of the incoming channel that the payment will
arrive on.
Finally, the notion of value privacy within the scheme seems a bit weak.
>From this definition, any protocol that didn't broadcast intents to send
payments to the world would achieve this trait. The base Bitcoin
blockchain doesn't mask the values of transfers (yet), but even if it did
unconditionally maintaining value privacy of channel doesn't seem
compatible with multi-hop payment networks (nodes can simply perform
probing/tagging attacks to ascertain a range of the size of a channel). A
possible mitigation would be for nodes to probabilistically drop incoming
payments, with all nodes sampling from the same distribution. However,
this would dramatically increase routing failures by senders, removing the
"low-latency" trait of payment networks that many find desirable.
Personally, I've very excited to see additional research on the front of
routing within the network! Excellent work by all authors.
In the end, I don't think it'll be a one-size fits all solution, as each
routing protocol delivers with it a set of tradeoffs that should be
weighed depending on target characteristics, and use-cases. There's no
strong requirement that the network as a whole uses a *single* routing
protocol. Instead several distinct protocols can be deployed based on
use-case requirements, as we only need to share a single end-to-end
construct: the HTLC. I could see a future in a few years where we have
several deployed protocols, similar to the wide array of existing routing
protocols deployed on the Internet. What we have currently gets us from
Zero to One. We'll definitely need to experiment with additional
approaches as the size of the network grows, and the true economic flow
patterns emerge after we all deploy to mainnet.
-- Laolu
On Tue, Nov 21, 2017 at 9:38 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
wrote:
> Hello,
>
> my name is Pedro Moreno-Sanchez and I am a PhD student at the computer
> science department at Purdue. I would like to bring to your attention a
> novel routing algorithm suitable for the Lightning Network (LN) that I
> have been working on with my supervisor Prof. Aniket Kate (Purdue
> University) and my co-workers Stefanie Roos and Prof. Ian Goldberg
> (University of Waterloo).
>
> Our approach is called SpeedyMurmurs, a routing algorithm for
> decentralized payment networks such as the LN. SpeedyMurmurs uses an
> embedding-based approach, meaning that the algorithm assigns meaningful
> coordinates to nodes that enable efficient and effective discovery of
> payment paths. In a nutshell, SpeedyMurmurs creates a spanning tree by
> means of a Breadth-First Search and then associates a coordinate to each
> node depending on its position in the tree. A path from the sender to
> the receiver is then calculated in a flexible manner, with each
> intermediate node choosing the next node in the path as a function of
> its neighbors' coordinates, available funds and closeness to the
> receiver. To account for topology changes (e.g., a new channel is
> created), the routing information is locally updated by only those
> affected nodes in the network.
>
> We have simulated several configurations of SpeedyMurmurs using real
> data from the Ripple network and compared it with other routing
> algorithms available in the literature. Our simulation results show that
> SpeedyMurmurs is able to find paths at about twice faster, reduces the
> communication overhead by at least a factor of 2 and maintains a similar
> or higher payment success ratio. Our simulation framework is open source
> and we believe that it might be of independent interest for this
> community to test this and any other alternative protocols that you
> might have in mind. If you are interested, we are happy to extend on this.
>
> Finally, we also show that SpeedyMurmurs achieves the privacy notions of
> interest in the LN. In particular, SpeedyMurmurs achieves value privacy,
> i.e., the total value of a transaction remains hidden, as well as sender
> and receiver privacy, i.e., the identities of the two transacting nodes
> remain hidden from the adversary.
>
>
> You can find all the details in the draft of our paper [1]. The final
> version of this work will appear at NDSS 2018 conference [2]. We would
> be glad to hear any question and feedback from you and are open to carry
> out further collaborations if this line of work is of interest for you.
>
> Best regards,
> Pedro, Stef, Aniket and Ian.
>
> [1] https://arxiv.org/abs/1709.05748
> [2] https://www.ndss-symposium.org/
>
> On 11/17/17 8:09 PM, Saravanan Vijayakumaran wrote:
> > Hi Christian,
> >
> > Are there any open source simulators available for trying different
> > routing strategies? Or even a simulator for the Lightning network as a
> > whole?
> >
> > Regards
> > sarva
> >
> >
> > On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker
> > <decker.christian at gmail.com <mailto:decker.christian at gmail.com>> wrote:
> >
> > Oh yeah, my mail tool destroyed that mail quite expertly :-)
> >
> > The footnotes were
> > [1]
> >
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
> > <
> https://secure-web.cisco.com/1wkWGu7k6qIvsw8KxbTL8XXIpbTYjcgzOohVSUjpLJpNW0_r00YaFlguhX0pSCEAg2qU5kztXF4bxEpLbMz-RLAz9KTBvE0lh3kFGUjL5qke6yx8EcYvhHQQSttWjRX5HOt69vu8suXd7AhjEweVxeBFhvptINqjBarDx7woqCa14ZgWZdMk0dAt45Lnu_w1wjgn3j5sD7tBo187MGXR94eapimiMFjXySj70GeP1yiEA8rP0NUQ5CSXme2wQy-spVW_SLQpvkAQ01NlXUjK-ufQw_APez6C73Qx0bFh_9F-CPhKhhvM3tSs6IGNEM63aXMVeti2Ci0R5Xc15tvcT9gxpC32bNetja5ber6wbIHLbI9FWviQ63cWaNwhedQRN/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md
> >
> > [2]
> >
> https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad
> > <
> https://secure-web.cisco.com/1UG1OaEI1KFpQ4prjxrhN1Wsxs0P1Tco0MXQz0xltJZQjwI-sNi98eXMz-gW4qOQd2jJ4i0uktvL8CH-9RrmEg3GkxHfcxjnjxY_hlLP-ctXOYMSk4BFbySy7vD5xWivimHIfMHtr13ffgEoFLItUgoajxUe7tnkchPN_P5OZ_FOzYdpqW_UDdgWW0_VOsccR5yt1vh0MRyVxO2B2ua8k4NmbFgTmht6hxUlXDsXOsOSGDHm1WO5VNrRbUcGeTPpdBMx0xeyZ9FTMTBCIAMOZ6UEb_eAX3X1iVIFkP_MPtuJcp0q8t9Tk_UBs-dHVRjyYcCsnetXYNI_mEsdtyg63aLXuJE1pMLb8-eamWaFfklVo-w9N9F0XTbmbkgGfcWU4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad
> >
> > [3]
> >
> https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
> > <
> https://secure-web.cisco.com/1XOlJdRo0gtzmPhNfVlEpMsrVBAI6BSjdDawPogEDIwYDdva2BSx4H8F9B3E6bkVIqA7ByFEF85qVjJ775leFwE54p5G6-wHH4Cio0p9sYLJ14-NHwcwvYQ--zdI8hdAyjGQbcLltVFAmorMaTlHq4FGI1CmxlwiUYgH1tjZn3UAHOu5xm5pLVi6KTb9WsJvuJsOBJhLfRLWGcAhVbjRXuV8b3x_G4ybOg1CQYC9ZVq3RJCPnNgQ3BN3a5ZuzW4veOE_dgi80FEy1x7a8spH-TV-cb_fey6ud-S25AWQ1PbctVS5zgQ4Ki4XYkR5igotNGGbWhACevBJfU1Hxqk90_g-DgQtS9_e_UX_FsY-yAjw/https%3A%2F%2Fwww.tik.ee.ethz.ch%2Ffile%2Fa20a865ce40d40c8f942cf206a7cba96%2FScalable_Funding_Of_Blockchain_Micropayment_Networks%2520%281%29.pdf
> >
> >
> > We will eventually move away from the hash function based approach
> > in favor of something that allows us to decorrelate hops in a route.
> > We have indeed started writing down some of the ideas at least for
> > Lightning in the project's wiki [4], but they're definitely not
> > fleshed out.
> >
> > [4]
> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming
> > <
> https://secure-web.cisco.com/1XqVZXht8sW8tdbLxwEMjoU-hxxV6OJwpKqc2OudZy26Le21yvOIBPwqizepwLi9TBeEV2BMDc-nCiKpj3eryi59jqvoZcBRrSQSVt9Qrq8pIxNSvhIMlG4cRd3lnj17JT9mDRRt0lS51C_9gpryV6qFqdiROdyJeTKfqUGmnvPo3isfeUbC_TOOfWLDV16jYA38ytCfTOryyDvJgJdYw7ArAUEMg10jNv8lV9aTARBOcOmgLjqJt0ktecsUpUCfIVAQlJEvtAAbWAUKwMoXg6MpIQEA4NE1ATntmwjLGl4IqQEqRAGxkGxWI8yQDL74yPPTIQmGTxs_JXE6YYMrhuD93GR1kyUJkOAH3Z_5nL1bsr3ifW31PJtUckQNnwY8e/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fwiki%2FBrainstorming
> >
> >
> >
> > On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <ben at mord.io
> > <mailto:ben at mord.io>> wrote:
> >
> > "I think this is exactly the right venue to discuss these kinds
> > of issue..." - you are probably right! My bad.
> >
> > Christian, thank you for your knowledgable reply. The footnotes
> > did not come through on my end, I am especially interested in
> > [3]. Do you have a link? I am thrilled to hear of a
> > Bitcoin-compatible revive alternative! :)
> >
> > Are we keeping an inventory somewhere of the cryptographic
> > primitives being used in lightning and the specific assumptions
> > being made about them (e.g. preimage resistance vs collision
> > resistance and such)? One project I have not yet found but
> > believe we need across the entire cryptocurrency community, is a
> > (wiki-style?) inventory of unproven mathematical assumptions
> > (e.g. hardness of discrete logarithm) and/or cryptographic
> > primitives, cataloged in terms of the cryptocurrency
> > technologies which require them. Such a resource could help the
> > community respond more quickly, comprehensively, and
> > transparently to the inevitable cryptanalytic surprises that
> > will pop up over time (especially from the quantum cryptanalytic
> > area, but even the classical cryptanalytic community as well).
> >
> > Related, I believe the ideal end state would be to only assume
> > existence of a preimage-resistant hash function, and to code
> > such that one function could be quickly swapped with another and
> > thus update entire system. I'm not sure if that is a realistic
> > goal, but here is my first attempt to move in that direction in
> > case it is of interest to lightning. It is hard to imagine it
> > would be a new idea, although I have not yet found the precedent:
> > http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html
> > <
> http://secure-web.cisco.com/1ewGQFfIxw1QZwneD3sDbhSSWP-YTmBwOYe529E7_zeYZZADnASbspvBAftPFXX6ZxJI2l2-8-xEqdpkmFg3fEIfkfRBYN8oZ8Z0HpeHh73MnT3Zi3M8GUs8SGMww38ZPnzsc7xlt7H5KFlLMcCsTWIgEtq4roZHDkYasanNeViP_UA3DIod7A281fNvWnQ1mnLs6d8WN_uFx1diU_xr-EoMab3wyANozirDj1gZ2_yPBn6S8tePYMkTkhIZlLz_BlvIfk9_KCOOiUcWxDTtCq9KdvoqEzStC04Z6q8xS5rtSnmK9GZZxv30yrgT8eWA4eOzce6AA3m0WEClNzbzANgi11GXBVde9pNiUIRcLDNw/http%3A%2F%2Fben.mord.io%2Fp%2Fdelayed-chained-key-revelation-dckr.html
> >
> >
> > Thanks,
> > Ben
> >
> >
> > On Nov 17, 2017 8:04 AM, "Christian Decker"
> > <decker.christian at gmail.com <mailto:decker.christian at gmail.com>>
> > wrote:
> >
> > On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <ben at mord.io
> > <mailto:ben at mord.io>> wrote:
> >
> > Ivan,
> >
> > That is mostly false, but with bits of truth sprinkled
> > in. Contact me at ben at mord.io <mailto:ben at mord.io> for
> > further discussion so we tread lightly on the lists'
> > email inboxes.
> >
> >
> > I think this is exactly the right venue to discuss these
> > kinds of issue,
> > so please don't move the conversation somewhere else :-)
> >
> > Routing is still very much in flux, we have a minimally
> > viable routing
> > protocol in the spec [1]. It is minimal in the sense that we
> > just push
> > the entire network's topology to the edges, which can then
> > locally
> > compute routes. This is effectively a source-routed network,
> > which
> > matches the requirements of the onion routing protocol we
> > use for
> > privact as well. But this does not mean that this is
> > protocol is set in
> > stone. We are actively working on finding better solutions
> > to the
> > problem of finding routes across a vast network of millions
> > if not
> > billions of nodes. Distance vector routing such as BGP uses
> > may be one
> > option like Ben suggested.
> >
> > For now the network can easily scale to about 1 million
> > channels [2]
> > even on very limited devices, Upgrading to another protocol
> > at a later
> > point in time is trivial, since none of the routing
> > information is
> > consensus critical. We have all the extension points built
> > in to allow
> > future extensibility.
> >
> >
> > But briefly: scale-capable routing protocols are
> > possible as demonstrated by IP and thus by the internet
> > itself. As for centralizing flow through small number of
> > liquidity providers, yes that does seem economically
> > probable, at least unless / until off-chain channel
> > rebalancing mechanism (like the recently proposed
> > "revive" protocol) come about. Bitcoin script is not
> > currently revive-capable but Ethereum is, so either
> > Bitcoin revive could be enabled via two-way pegged
> > sidechain protocol with Ethereum, or even better, by a
> > purpose-built (yet still not Turing-complete) extension
> > to Bitcoin script itself in the future.
> >
> >
> > As a matter of fact, Conrad and I just published a similar
> > technique for
> > off-chain channel rebalancing and fund re-allocation based
> > solely on
> > Bitcoin [3] (major props to Conrad for the excellent
> > writeup!). The
> > flexibility in Bitcoin exists.
> >
> > As for the hubs everybody is assuming will form, I don't
> > think they're
> > as likely to form. Creating such a hub is extremely costly
> > since it'll
> > have to allocate sufficient funds to cover the maximum
> > imbalance of all
> > of its channels ahead of time. Then the fees must cover the
> > opportunity
> > cost of allocating all of those funds to channels instead of
> > investing
> > them somewhere else. On top of that the funds will not be
> > moved alot
> > since they serve only a small number of endpoints connected
> > through
> > those channels, this compounds the problem of having high
> > fees. The high
> > fees make the hub channels a really bad choice for your
> > payments, after
> > all you were looking for small fees for your payments,
> > right? It opens
> > up an opportunity for nodes to open bypasses that grab some
> > of the
> > traffic and associated fees from the expensive hub.
> >
> > All of that being said, we should be careful about our
> > predictions on
> > how the topology will look, I added some counter arguments
> to a
> > hub-and-spoke network forming, but nobody can really be sure
> > about
> > what'll happen.
> >
> >
> > In either case the lightning network seems a key first
> > step, and even were off-chain payment rebalancing not
> > possible for some odd reason, the lightning network
> > seems extremely valuable and scaleable - regardless
> > because the centralization you speak is not one that
> > affects safety of the money supply itself, and these
> > centralized hubs would be more dispensable / swappable
> > versus the mining centralization risk that people more
> > often talk about in Bitcoin. Lightning network
> > centralization, even if it persisted somehow despite
> > revive and future concepts, would not be an existential
> > risk.
> >
> >
> > Rebalancing is definitely possible, even without [3], you can
> > disincentivize the use of a channel until they have been
> > rebalanced. For
> > long term imbalance, opening another channel may be the best
> > option
> >
> >
> > As for transaction fees, the idea is only channel setup
> > / tear down are required greatly reducing fees. Yes if
> > txin fees were millions of dollars then people could not
> > practically penalize fraud, but that is unlikely. Even
> > if txin fees made fraud claims marginally unprofitable
> > (yet practical) that would still be ok - the judicial
> > systems of most countries prove that people go beyond
> > self-interest when sufficiently ticked, a fact of human
> > psychology which in turn creates the incentives that
> > support honest business. (Also please be aware I'm not a
> > lightning code contributor, so that team might also be
> > doing more to address already than I thought to mention
> > above.)
> >
> >
> > This is open to speculation as well. We hope to reduce the
> > load on the
> > on-chain network sufficiently to allow timely on-chain
> > settlements. By
> > aggregating payments off-chain we can also aggregate the
> > fees and then
> > use them to pay on-chain fees. So don't consider the
> > on-chain fees for
> > your channels as your sole loss, they are paid for by
> > payments you
> > forward. Ultimately this should encourage participants to
> > open channels
> > that support the network as a whole, not just themselves. We
> are
> > building automations that should take care of this, the user
> > won't have
> > to do anything to improve the network topology.
> >
> > Cheers,
> > Christian
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > <mailto:Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > <
> https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> >
> https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-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/20171125/fd3fb6d4/attachment-0001.html>

2023-06-09 12:47:32

- reply

📅 Original date posted:2017-09-04
📝 Original message:
Hi,
Welcome to the mailing list!
Replying here rather than the issue you filed on the lighting-rfc repo as
I'd say this is a better venue to discuss matters such as this. The
structure of the mailing list may be a bit strange initially, but once you
get over that hump, I think you'll find it's rather pleasant to use. Also,
if you stick around, you'll find that most members of the Bitcoin
development community use technical mailing lists such as this one to
share ideas, propose new solutions, analyze existing schemes, etc.
This list has been a bit lower traffic recently than compared to the past
as many of us have locked ourselves in dungeons coding without pants as
we're rapidly approaching the first mainnet release of our various
lightning node software. As a result, replies may have a bit of delay, but
that's nothing to fret about!
> I propose a protocol where each node knows about its own local network
> topology, and to find a final route, a transaction originator queries a
> number of its connections for routes to the intended destination.
For color, I'm one of the co-authors of the Flare paper. What you've
described in this email is close to the approach, but it utilizes a blind
all-the-links flood towards the destination, rather than a DFS search
guided by the distance metric proposed in the paper. One thing to note is
that Flare utilizes HORNET to allow senders to query their beacon nodes,
and also nodes beyond the horizon of their beacon nodes in a private
manner. By using the bi-directional communication circuit, we maintain
requester anonymity, and don't force those performing search to reveal
their identity nor intent. Also note that Flare itself also uses an
initial routing cache for a neighborhood of N nodes.
What you've described here is essentially Dynamic Source Routing (DSR)[1],
with a mix of components from Fisheye State Routing (FSR) making it a
hybrid protocol that combines reactive and proactive elements in order to
achieve its goals.
Our current stop-gap is a pure proactive protocol, meaning that nodes
gather all link state data and then make forwarding and
routing decisions based off of that. The clear trade off (as you point
out), is the increase in table state and bandwidth incurred due to keeping
up with the announcements. The upside is that the latency observed when
attempting payments to random sections of the graphs are minimized.
Additionally, as we have complete information, we can make more
intelligent path finding decisions, and also ensure that we collect a
redundant set of routes for each payment. By ensuring that we collect a
set of routes with high path diversity, we have many options to fall back
to in the case of a routing failure with one of the earlier routes in our
set.
However, protocols that have a reactive element for each circuit
establishment may not necessarily scale better. This is due to the
computational overhead of circuit establishment. Particularly in your
DSR+FSR combo as the flood proceeds in all directions. As a result,
circuit establishment may have latency in the seconds as each random
payment may potentially need to flood out in the graph in search of the
destination. Without a sort of distance metric to guide the search, it
may wastefully explore non-relevant sections, further increasing payment
latency and overhead for all other nodes. Finally, one aspect to consider
is how DoS-able schemes like this that require flooding for each circuit
establishment are.
> When a node wants to construct a route for a transaction:
> 2. It asks all the channels on the edge of its cached local view for
> their cheapest path
Simply _asking_ nodes for a path to a destination defeats the point of
using onion routing at all. If one is prepared to make that tradeoff, then
far more scalable routing protocols can be explored as at that point, one
would move to distance vector based algorithms.
Very happy to see that more folks are exploring alternative
routing/discovery solutions! In the future we'll definitely need to scale
up the network.
One beauty of the way the system is laid out is that multiple
heterogeneous routing protocols can be used within the network just as
within the Internet (eBGP vs iBGP), so different sub-graphs can chose
protocols that achieve their goals in light of the various tradeoffs. I
think I'll follow up this post with a general survey of potential
approaches I've come up with and come across in the literature along with
their various tradeoffs, and possible paths forward for the network as a
whole.
-- Laolu
[1]: https://arxiv.org/pdf/1507.05724.pdf
[2]: http://www.utdallas.edu/~ksarac/Papers/DSR.pdf
[3]:
http://nrlweb.cs.ucla.edu/publication/download/203/05_75_fisheye-state-routing-in.pdf
On Mon, Aug 21, 2017 at 6:09 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
> Hey Guys,
>
> I'm testing this mailing list out for the first time, so I'm probably
> gonna be doing it wrong.
>
> I want to talk about route discovery and route generation in the lightning
> network. It seems there's a couple types of things going on with routing:
>
> - Super basic flood-the-network style routing to get things up and
> running, as I believe is implicitly proposed here:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
> - More involved research projects that may not reach fruition any time
> soon. Eg this:
> http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf
>
> I'd like to discuss a near-term approach that can replace the basic
> flood-the-network style route discovery, but isn't so complicated that it
> needs a ton of study and work. This won't be the end-all solution to route
> discovery, but should take us a lot further than flood-the-network.
>
> I propose a protocol where each node knows about its own local network
> topology, and to find a final route, a transaction originator queries a
> number of its connections for routes to the intended destination. By doing
> this, it means that nodes are *not* receiving or storing the entire network
> topology, which makes route discovery a lot less taxing on the network (in
> terms of bandwidth and storage space).
>
> To go into more detail...
>
> When a node joins the network:
> 1. it broadcasts its information to all its channels (pretty much as
> proposed here
> <https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md>)
> announcing its relevant channel information
> 2. it requests local network topology information from all its channels
> for information about channels 1 hop beyond its direct connection (ie it
> will receive information about which addresses those channels are connected
> to, and their related fee info / etc)
> 3. it then requests topology information for channels 2 hops beyond, etc
> until it has filled its cache to its satisfaction (the user can choose some
> amount of megabytes as its limit of network topology data to store)
> 4. it also subscribes to topology changes for nodes at those distances (eg
> if a node has requested information from 3 hops away, it will receive info
> about any new channels or removed channels that fall within that distance)
>
> When a node receives an announcement message from a node joining the
> network:
> 1. it will store that node's info in its cache
> 2. it will also forward that info to any node that's subscribed to
> topology changes that fall within the relevant distance
>
> When a node wants to construct a route for a transaction:
> 1. It checks to see if it has a path to that node in its cache. If it
> does, it finds the cost of the cheapest path it has.
> 2. It asks all the channels on the edge of its cached local view for their
> cheapest path (however you want to define cheapest), specifying that it
> only care about paths with a maximum cost of the cheapest path it has
> already found in its cache. For example, if the node has nodes up to 3 hops
> away in its cache, it will *only* ask the nodes 3 hops away (it will not
> ask its direct connections, nor nodes 2 hops away, since it already has
> enough information to ignore them)
> 3. When it gets all its responses, it constructs a path
>
> When a node receives a path request from a node:
> 1. It checks its cache for its cheapest cache-only path
> 2. It asks nodes on the edge of its cached local view for their cheapest
> path, specifying that it only cares about paths with a maximum cost of
> either its cheapest cache-only path or the max-cost specified by the
> requesting node minus the channel cost between it and the requesting node
> (whichever is cheaper). A node on the edge of its cached local view is
> *not* asked for route information if the cost to that node exceeds the
> max-cost this relay node would specify.
> 3. It reports the results that satisfy the max-cost requirements of the
> requesting node
>
> And that's it. All the route information can be encrypted and signed so
> relaying nodes can't read the information inside, and so the requesting
> source node can verify which nodes sent that information.
>
> This protocol should keep both node-announcement messages *and* route
> request messages highly localized.
>
> Thoughts?
>
> ~BT
>
>
>
> _______________________________________________
> 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/20170904/fe7bbb32/attachment-0001.html>

2023-06-09 12:47:26

- reply

📅 Original date posted:2017-08-07
📝 Original message:
> I think it does already:
Yep! An oversight on my part.
> So, you're suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?
Precisely. The code modifications required to switch to this signing mode
are
trivial.
> though it's a pretty obscure case where we want to close out many HTLCs at
> once; this is more for fee bumping I think.
Well it's for both. In the case of a commitment transaction broadcast (for
what
ever reason) each party is able to group together HTLC's expiring around the
same height (in the case that the pre-image for a bunch was never revealed.
This leads to less transactions on-chain, and lower fees cumulative for
either
side to sweep all funds back into their primary wallet.
The fee bumping use case is also a bonus!
On Sat, Jul 29, 2017 at 10:36 PM Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Rusty Russell <rusty at rustcorp.com.au> writes:
>
> >
> https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing
>
> Some feedback, since I missed what seems like a very productive
> discussion!
>
> > HTLC floor created by second-level HTLC transactions
> > Pierre points out that should choose HTLC min high enough that don’t run
> into issues.
> > Laolu points out this means that unable to send and claim small-ish
> amounts chain.
> > Laolu points out that would basically CREATE a dust output in the
> process.
> > LAOLU SUGGESTS THAT TRIM OUTPUT SPEC PORTION SHOULD ALSO SAY DON’T
> CREATE DUST OUTPUT ON SECOND LEVEL TX
>
> I think it does already:
>
> For every offered HTLC, if the HTLC amount minus the HTLC-timeout fee
> would be less than `dust_limit_satoshis` set by the transaction owner,
> the commitment transaction MUST NOT contain that output
>
> (Similarly for received HTLCs)
>
> ie. don't create HTLC outputs which would need an HTLC tx with a dust
> output.
>
> > Don’t use sighash-all on the second-level HTLC transactions
> > Laolu points out that this would allow us to coalesce many HTLC
> > transactions into a single one. Saves on-chain foot print, and also
> > allows to add more fees. Basically like “Lighthouse” (by hearn).
>
> So, you're suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?
>
> I *think* this would work, though it's a pretty obscure case where we
> want to close out many HTLCs at once; this is more for fee bumping I
> think.
>
> There are two other cases where we don't rely on the TXID, and such an
> approach would be possible:
>
> 1. Commitment tx with no HTLC outputs.
> 2. The closing transaction.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170807/edb460af/attachment.html>

2023-06-09 12:47:12

- reply

📅 Original date posted:2017-05-28
📝 Original message:
Rusty wrote:
> Yes, I thought about this too, but I'm reluctant to assign those onion
> bytes as they're a limited resource. Easy to add later, though.
If y'all recall, the initial version of the Sphinx derived onion format
included an end-to-end payload. In the first revision, removed this
payload as at the time it was very large (1KB iirc), an at the time, we
didn't see nay clear use case for such a payload (and also due to MTU
constraints?). In my opinion, we should re-introduce this payload so we
aren't put into a corner where we need to shave bytes off of the per-hop
payload in order to accommodate application level schemes/apps.
Re-introducing the e2e payload would allow us to define a strict
separation of layers: h2h payload is reserved for _forwarding_ critical
information, while the e2e payload is reserved for _applications_ to place
relevant data which is also onion encrypted + authenticated. IMO, the e2e
payload doesn't need to be any where as large at it was previously (which
doubled the size of the onion packet). I'd proposed re-introducing it with
a size of somewhere around 200 bytes. With this, I could send you
something to tweet once the payment has been extended :p.
Fabrice wrote:
> Payment requests should also include a timestamp and an expiry date (they
> could be optional tagged items but I think it makes more sense to make
> them mandatory)
Agreed that that would make for a really useful tag. I had a user which
was making a store on lnd request such a feature as his use-case depended
on users only having a particular time window to make the payment. This
could of course be enforced server side, but allow senders to enforce it
at the origin of the payment saves them from extending an HTLC all
together. Also in the world of pre-paying for HTLC's, you'd only want to
extend an HTLC is you had a high degree of certainty that it'll be
claimed, otherwise you've just wasted your precious mSAT :(.
Rusty wrote:
> Note: we will lose this ability when we switch to Schnorr, apparently.
AFAIK, this isn't the case. With Schnorr signatures (that include the
entire point, instead of the hash), we actually won't need to include a
recovery ID at all.
Rusty wrote:
> OK, if people like this change, I think we can move start turning this
> into BOLT 10?
Let's do it (BOLT 11)! As were all getting pretty close to the stage of
cross-implementation interoperability tests, having a shared payment
request format will be super useful.
Christian wrote:
> Perfect, even though your price is already outdated, and it currently
> is $1700/BTC
Perfect, even through your price is already outdated, and it currently is
$2200/BTC :p.
-- Laolu
On Tue, May 9, 2017 at 10:18 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Christian Decker <decker.christian at gmail.com> writes:
> > On Tue, May 09, 2017 at 11:07:28AM +0930, Rusty Russell wrote:
> >> Hey, invoices are totally human readable, for some humans :)
> >>
> > I know Pieter can decode bech32 on the fly :-)
>
> Well, Pieter can pronounce them too apparently:
>
> http://pieterwuillefacts.com/?43
>
> >> But a good point. So let's use BTC with m (milli), u (micro), n (nano)
> >> and p (pico). In theory we could allow . in that part, but I think it's
> >> too distracting.
> >>
> >> At $1600/BTC:
> >>
> >> 0.01c = 62500p
> >> 1c = 6250n
> >> $1 = 625u
> >> $1000 = 625m
> >
> > Perfect, even though your price is already outdated, and it currently
> > is $1700/BTC. I mention the conversion confusion because I often run
> > into that problem myself (and keep typing 0s until the client
> > complains).
>
> I considered using the m/u/n modifier as the decimal point, eg:
>
> 0.0001c = 0n62
> 0.01c = 62n5
> 1c = 6u25
> $1 = 625u
> $1000 = 625m
>
> Unfortunately, it's horrible to write the code to encode/decode (I just
> spend an hour on it and I'm not happy with the result).
>
> >> OK, if people like this change, I think we can move start turning this
> >> into BOLT 10?
> >
> > Oops, I think I did what Luke hates, and sort of self assigned a
> > proposal number... I can of course assign the DNS bootstrap BOLT
> > another number.
>
> Huh? I just did exactly the same thing! So I'll take BOLT 11.
>
> 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/20170528/7dcd0cac/attachment.html>

2023-06-09 12:47:08

- reply

📅 Original date posted:2017-05-01
📝 Original message:
Hi Rusty,
I was thinking of proposing something similar recently, but looks like you
beat me to it!
I really like the flexibility of the tag format. Over the past few months, I
thought of quite a bit of things application developers can do by utilizing
a tag-based payment request format in conjunction with either: the spare
bytes of the onion payload or an abuse of the encrypted back errors (in
combo with some onion payload bytes).
On the topic of bech32: I'm all for piggybacking on existing emerging
standards in the space, but I'm not convinced we really gain anything by
using it outside of the initial prefix. The human-readable amount within the
prefix is nice for UX as you can eyeball exactly how much one is about to
pay/receive. However, these payment requests can get rather long, so I don't
envision any user typing them out by hand or reading them to someone over
the phone. As a result, I don't think we have much use for bech32 character
which has been optimized for manual-entry. Additionally, as this proposal
includes a signature that covers the entire payreq, what's the use of the
added checksum? Detecting 3 characters out of 1024+ is rather
insignificant.
On the topic of signatures: as is proposed now, a user isn't able to verify
the validity of the signature (and thereby authenticity of the payreq and
integrity of the contents) without first having a (direction || chanID) ->
pubKey mapping. In my opinion, the payreqs are already so long that
optimizing for size is a bit of a waste. By replacing the chanID with the
compressed serialized public key, users will be able to immediately verify
the signature without the use of an external mapping.
I think this is a good step in the right direction. However, it utilizes an
encoding whose rationale make sense for the Bitcoin address use-case, but in
my opinion, doesn't carry over those compelling traits to the LN payreq
use-case.
-- Laolu
On Fri, Apr 28, 2017 at 5:57 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all!
>
> I threw together this draft format for requesting lightning
> payments, and an (incomplete) implementation:
>
> - https://github.com/rustyrussell/lightning-payencode
>
> The representation size ranges from ~181 characters upwards: we could
> squeeze at least 5 of those out if we cared. Bech32 only guarantees to
> detect 3 errors at these lengths (beyond 1024 it's only 1), but the
> signature is the final error detection.
>
> You'll notice one optimization for the common case: we use the 8-byte
> chanid (stealing 1 bit) to compactly refer to the destination. This is
> shorter than a full 33-byte pubkey, and relies on the fact that the
> network topology is well-known. We use these same style of IDs in
> the channel announcement messages already.
>
> I look forward to both the bikeshed comments, and more substantive
> feedback :)
>
> Thanks!
> 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/20170501/98cf78f1/attachment.html>

2023-06-09 12:46:48

- reply

📅 Original date posted:2016-10-20
📝 Original message:
> I kept the shared secret backlog for now, since committing the routing
> information to the payment hash is awkward
When we agreed to include the payment hash in the MAC check within the
header, I assumed that the packet format wouldn't be modified to include the
payment hash (either in the header or e2e payload).
Instead, I envisioned that the payment hash would be a parameter to the
packet processing/creation function. When creating or processing the packet,
the payment hash would be concatenated to the material being authenticated
similar to the "associated data" in AEAD cipher modes. With this scheme,
there's no additional data added to the packets, but the payment hash is
authenticated as part of packet processing at each hop.
So if an adversary attempts a replay, then they're forced to use the same
payment hash, otherwise the packet won't propagate. Assuming all nodes
remember all payment hashes, then replay attempts always fail and come at a
direct monetary cost to the attacker.
-- Laolu
On Thu, Oct 20, 2016 at 6:41 AM Christian Decker <decker.christian at gmail.com>
wrote:
> Just a quick update on my side: I have updated the spec as discussed
> during the milan meetup and dropped the end-to-end payload, since we don't
> have any good usecase for it currently.
>
> I kept the shared secret backlog for now, since committing the routing
> information to the payment hash is awkward: either we include the payment
> hash in each per-hop payload, making it possible to stop a replay
> immediately, or we add it to the last per-hop payload, at which point only
> the last hop would be able to identify a replay attack, making it possible
> to replay and observe traffic patterns. In both cases we'd be increasing
> the per-hop payload size, which is pretty expensive to do.
>
> Both the C-lightning implementation and the lnd implementations have been
> adapted and can be used.
>
> Cheers,
> Christian
>
>
> On Mon, Oct 3, 2016 at 11:34 PM Christian Decker <
> decker.christian at gmail.com> wrote:
>
> On Mon, Oct 03, 2016 at 05:21:35PM +0000, Olaoluwa Osuntokun wrote:
> > > I think this only works if the on-chain keys are Schnorr, right?
> >
> > We'd use the same curve equation and domain parameters as Bitcoin uses
> > currently, but would swap out EC-DSA for EC-Schnorr. So as a result,
> > pub/priv keys stay the same, meaning the on-chain keys can be used for
> > signing/verifying the multi-sign for channel authentication proofs.
>
> So we'd still be using ECDSA for everything that could go to the
> bitcoin blockchain, and use Schnorr for all other crypto
> primitives. Sounds good to me, if we can be certain that reuse across
> different schemes does not open us to new threats.
>
> > > Separating onion privkey allows rotation; only a win if we get forward
> > > secrecy (not a win for this node, as much as for the network as a
> > > whole).
> >
> > Agreed, if we're not initially doing passive (or active) key rotation for
> > the onion keys, then coupling the identity and onion keys simplifies the
> > code at that level and nixes a few network layer control messages.
>
> I'd argue that rotating the onion key is already valuable in order to
> limit the shared secret backlog, allowing us to forget them after a
> rotation, even if we don't have forward secrecy. If we can get forward
> secrecy as well all the better though :-)
>
> Cheers,
> Christian
>
> _______________________________________________
> 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/20161020/40137071/attachment.html>

2023-06-09 12:46:47

- reply

📅 Original date posted:2016-10-03
📝 Original message:
> I think this only works if the on-chain keys are Schnorr, right?
We'd use the same curve equation and domain parameters as Bitcoin uses
currently, but would swap out EC-DSA for EC-Schnorr. So as a result,
pub/priv keys stay the same, meaning the on-chain keys can be used for
signing/verifying the multi-sign for channel authentication proofs.
> Indeed. Let me try to enumerate the different secrets we need to
> protect, and you tell me what I missed?
Excellent, this looks like an accurate breakdown to me. The only thing I'd
add is that compromise of the identity public key allows an attacker to
open/accept authenticated+confidential p2p connections on the network. In
isolation this seems pretty harmless as they're capabilities with one this
key is rather limited.
>From a compartmentalization standpoint, unless there are significant gains
from coupling keys from distinct categories, all keying material should be
as independent as possible.
At the very least (as you detailed), the commit keys should be rolled anew
for each channel. This opens up the doors to architectures such as
per-channel process signers w/ mlock'd secrets, dedicated hardware, etc.
> Separating onion privkey allows rotation; only a win if we get forward
> secrecy (not a win for this node, as much as for the network as a
> whole).
Agreed, if we're not initially doing passive (or active) key rotation for
the onion keys, then coupling the identity and onion keys simplifies the
code at that level and nixes a few network layer control messages.
> The comms symmetric key should be rotated with forward secrecy as
> well, for similar reasons.
Indeed, we can throw in a simple ratcheting scheme into the initial p2p
spec.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20161003/6a86cc38/attachment.html>

2023-06-09 12:46:42

- reply

📅 Original date posted:2016-09-09
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> wrote:
> Each node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum +
txnum).
Using blocknum+txnum to identify a channel doesn't account for the
possibility of a single transaction which opens multiple channels
concurrently. A possible use-case for such a transaction are coin-joined
channel openings which obfuscate the relationships being creating with a
channel opening. You'd need to tack on an extra byte (maybe two) to also
encode the output index of the channel within the transaction. Additionally,
identifying channels based solely from blockheight+offsets conjures up some
re-org safety concerns. It's also a bit less "verifiable" than referring via
the full outpoint.
> The proofs are larger: to prove which IDs owns a channel, each one needs a
> merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can skip
> some though), the two pubkeys (66 bytes), and a signature of the ID using
> those pubkeys (128 bytes, schnorr would be 64?).
Are those two pub keys the multi-sig pub keys, or the identity pub keys? In
either case, only requiring two pub keys to attest-to/authenticate the state
of a channel is insufficient. With only two signatures, then nodes can
advertise the same channel several times creating a non-canonical graphs
resulting in differing network views. If we'd like to eliminate such a
possibility, then we also need to cryptographically bind the two identities
to the proof. Using a schnorr multi-signature generated by the four pubkeys
would remedy this. Validators can use pubkey recovery to extract the "group
pubkey" from the single signature, ensure it's the result of point addition
of the four public keys, check the channel isn't closed, then verify the
signature over the advertisement as normal.
Christian Decker <decker.christian at gmail.com> wrote:
> I forgot that we have two potential key-rotations:
> - Rotating the key used in transactions that hit the Bitcoin network
If you mean the key included within the 2-of-2 multi-sig, I assume all
implementations will be using a fresh key with each channel either way, so
we don't need any explicit rotations here?
I've only been thinking of rotations for the onion pubkeys used for the DH
shared secret derivation for the onion packets. Identity keys could also
possibly either be rotated/revoked, or delegated with some sort of
"certificate".
> Another case we could consider is having passive rotations: when an
> endpoint announces a channel's existence it also sends its rotation
> interval along.
IMO a passive rotation scheme is superior due to the bandwidth savings of
pushing the onion key rotations to the edges themselves. As you said an
active rotation might be used in the emergency case of a forced key rotation
due to key compromise.
Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hmm, do we lose forward secrecy if we use a BIP32 chain? But we may be
> able to use another derivation method where we derive key N from key
> N-1. I'm looking at Laolu...
Well, sorta. If the master pubkey is published, and nodes use public
derivation on the edges to do passive key rotations, then if one of the
non-hardened child private keys is leaked, an adversary can derive the
master private key thereby gaining the ability to decrypt any
saved/intercepted onion packets to the compromised node.
Earlier in this email chain I suggested a scheme to regain forward secrecy
in the case of such a private key leak by requiring nodes to do some upfront
pre-computation involving an intermediate derivation point. This would still
allow passive rotation by the edges. However, in practice those
pre-generated would likely be stored in the same location? So that kinda
puts us back at the original exploit scenario.
If we were to involve some pairing crypto (IBE style), we would use say
block hashes to allow nodes to passively derive keys the "source" node is
able to generate the corresponding private key to...
IMO we need to more clearly state our security model/assumptions here to
reason about the attack scenarios we'll try to guard against.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160909/486374b1/attachment.html>

2023-06-09 12:46:32

- reply

📅 Original date posted:2016-08-12
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> wrote:
> In practice, you can do this one level up: simply agree with a rendevous
> node that a given H-hash is to be fwded to you. Then direct the payer
> to the rendevous node.
>
> So I don't think it's worth any complexity in the routing protocol.
Nevermind, I forgot that the nested header (assuming its the e2e payload)
would be wrapped in layers on onion encryption. So the hop *after* the
rendevous node is hidden from pre-rendevous node anyway :)
> Keep it simple; let's just support regular for now. Nodes will have to
> broadcast what extensions they support, and this can be used for
> extended formats later. Including ones we *didn't* think of yet...
Sure. Additionally, as Christian pointed out further down in the thread,
ideally we shoud aim to seamlessly integrate rendevous routing. If possible,
we should keep all onion packets indistinguishable from each other.
> I think we're over-designing. How about: daily key rotation (which we
> want anywat), remember all onions for current and previous key.
Yeah only daily key rotation should be sufficient. It seems that we need
either timestamps, or key rotation, not both.
> It'd be great to avoid it, but that seems complex enough to push to a
> future spec.
Agreed. When I first brought up key rotation eariler in the thread, I noted
it
might be better if it were deferred to a future spec. Nevertheless, the
I've found the resulting discussion very valuable.
> id and comms keys don't have to be bitcoin keys; could be Schnorr.
The EC Schnorr construction would likely use Bitcoin's curve, so there's no
meaningful distinction there. We're currently constrainted to ECDSA within
Bitcoin, but can freely use EC Schnorr within the network if the space
savings
are desirable (as you pointed out).
Christian Decker <decker.christian at gmail.com> writes:
> Sounds good, however I'm not clear on how the final recipient can provide
a
> precompiled valid header with the HMACs that include the per-hop payloads
> and the end-to-end payload without knowing them upfront.
>
> I'd prefer having a rendezvous scheme that merges the two ends of the
route
> in a seamless way, which should not be too hard to do, unless we keep the
> per-hop checkable HMACs.
Ahh, I see what you mean now. You're correct, it seems that we may be forced
to drop the per-hop HMAC in order to enable seamless rendevous routing.
> Do we need both a timestamped backlog of secrets and key-rotation? If we
> get the key rotation quick enough it's probably sufficient to simply keep
> all secrets for the current key, especially if we use bloom-filters to
> store the seen secrets.
Yeah, it seems that key rotation alone is much simpler than the timestamped
log
of secrets. So the key rotation alone should suffice.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160812/562993f0/attachment.html>

2023-06-09 12:46:29

- reply

📅 Original date posted:2016-08-16
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> wrote:
> Some node will have to straddle two chains, right? So you'd route A ->
> B -> C as normal, and C is (say) litecoin (B straddles both). You
> really want the onion to be explicit that this transfer to litecoin is
> what the sender intended. Or some sidechain.
>
> Now, we'd hope nobody would screw this up, but I think it's worth
> flagging since the sender really should know it's changing chains.
>
> Ahh, I'm starting to see your point now.
Agreed that it doesn't hurt to allocate an extra byte in order to make the
chain transitions *explicit*. Alternatively, (instead of modifying the
header) we can simply allocate the first byte of the per-hop payload for
this purpose.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160816/9a0bd76b/attachment-0001.html>

2023-06-09 12:46:29

- reply

📅 Original date posted:2016-08-04
📝 Original message:
> I'm going back and forth about including the payloads in the header HMAC.
I
> think we have three options here:
>
> 1) Include the payload in the header HMAC computation
I'd say personally, I prefer the first option. This results in "fail fast"
behavior w.r.t packet forwarding, and additionally adds the smallest
overhead.
> we also lose the ability to do anonymous rendezvous meetings, where the
final
> recipient provides half of the route in the form of a precompiled header
> (something that Hornet is using).
It doesn't appear that we loose the ability to do rendezvous routing if we
follow through with the first option. The final recipient can still provide
a
precompiled header which is the e2e payload sent from the source to the
rendezvous node. As the source knows the exact nested mix-header when
sending,
it can still be protected under the mix-header wide MAC.
Additionally, in order to hide the next-hop after the rendezvous node from
the
source node, the destination can wrap the nested header in a layer of
encryption, decryptable only by the rendezvous node.
> Both the per-hop checkable schemes, combined with nodes signing the
packets
> they forward, would give us the ability to identify misbehaving nodes and
> denounce them: if we receive a packet we check the integrity and if it
doesn't
> match then we can prove to others that the node forwarded something broken
> with its signature, or it did not check the packet itself.
Great observation. However, it seems like this is currently out of scope
(the
implications of "denouncing" a node") and should be re-visited at a future
time
when we brainstorm some sort of "reputation" scheme.
> There is a tradeoff between small packets and keeping the size uniform. I
think
> we could bucketize sizes, e.g., have multiples of 32 bytes or 64 bytes
for the
> fields, to have packets with similar sized payloads have the same packet
size.
> That would allow us to also drop the e2e payload by setting a size of 0,
and
> still be able to forward it, should we ever find a use for it.
Good point, we may have uses for non-uniform sizes as far as mix-headers in
the
future. So with this, then it appears there may be 3 types of mix-header
formats:
1. Regular. Meaning no e2e payload, weighing in at 1234 bytes.
2. Extended. Meaning bearing the e2e payload with a size of 2468 bytes.
3. Rendezvous. Which nests another mix-header within the end-to-end
payload,
with a size which is double that of the regular.
If we like this taxonomy, then we may want to reserve the first 2 version
bytes
within the draft. A version 0 packet would encompass processing the first
two
types, while a version 1 packet denotes that this is a rendezvous packet.
The
rendezvous case needs to be distinct as it modifies the
processing/forwarding
at the final hop.
Alternatively, we can use solely a version of 0 in the initial spec, with
the
final hop checking if the [1:34] bytes of the payload (if one is present)
are a
point on the curve. If so, this triggers the rendezvous forwarding, with
the
mid-point node processing the packet again as normal, completing the
rendezvous
route.
> We have to be careful when using timestamps in the packet as it makes
individual hops collatable.
Excellent observation. Assuming we roll out a reasonably efficient solution
for
the collatable HTLC R-values across hops, naively selecting timestamps would
present another correlation vector.
> So my proposal would be to include a timestamp rounded up to the closest
hour
> and have a sliding window of accepted timestamps of +/- 1 hour,
remembering the
> secrets for that period and rejecting anything that is too far in the
future or
> too far in the past.
This seems reasonable, also the size of the sliding window can easily be
tuned
in the future should we find it too large or small.
> The more coarse the bigger the less likely an attacker is to guess which
> packets belong to the same route, but the more storage is required on the
> node's side.
Yep, there's a clear trade off between the window size of the accepted
timestamps, and a node's storage overhead. We can tune this value to a
ballpark
estimate of the number of HTLCs/sec a large node with high frequency
bi-directional throughput may forward at peak times.
Let's say a HFB (High-Frequency Bitcoin) node on the network at peak
forwards
5k HTLC's per second: (5000/sec * 32 bytes) * 3600 sec = 576MB, if nodes are
required to wait 1 hour between log prunings, and 288MB if we use a
30-minute
interval. Even with such a high throughput value, that seems reasonable.
> We could just use the announced key, i.e., the one that participated in
the
> channel setup, as a root key for HD key derivation. The derivation path
could
> then be based on floor(blockheight / 144) so that we rotate keys every
day, and
> don't need any additional communication to announce new public keys.
Great suggestion! However, I think instead of directly using the key which
participated in the channel setup, we'd use a new independent key as the
root
for this HD onion derivation. This new independent key would then be
authenticated via a signature of a schnorr multi-sign of the channel
multi-sig
key and the node's identity key (or alternatively two sigs). This safeguards
against the compromise of one of the derived private keys leading to
compromise
of the master root HD priv key which would allow possibly stealing a node's
coins. Additionally, a node can switch keys more easily, avoiding a channel
tear down.
However, the HD Onion Key approach can potentially cancel out the forward
secrecy benefits. If an attacker gains access to the root HD pubkey, along
with
any of the child derived onion keys, then they can compute the root privkey.
This allows the attacker to derive all the child priv keys, giving them the
ability to decrypt all mix-headers encrypted since the HD Onion Key was
published.
I think we can patch this exploit by adding some precomputation for each
node,
and introducing an intermediate onion derivation point. Assuming we rotate
every 144+ (1 day) blocks, then using the HD Onion PrivKey, each node
pre-generates 365 (or a smaller batch size) keys. Then, generates an
independent "onion derivation" key. The OD key then combined with each of
the
child onion keys, produces the final child onion key (C_i = final onion key,
B_i = intermediate child key, A = OD):
* C_i = B_i + A
After the precomputation, the OD key (A) should be *destroyed*. If so, even
if
an attacker gains access to one of the intermediate child onion keys,
they're
unable to derive the final child onion key as the OD key has been destroyed.
This safeguards the forward secrecy of the scheme in the face of the HD
root+child exploit. As before, in the case of a root/child compromise the
original node can simply authenticate a new HD Onion Key.
So perhaps we can combine the two approaches, publishing a blockhash (buried
under a "safe" re-org depth), along with an authenticated HD root pubkey.
With
this new scheme we're able to push key rotation out to the edges in a
non-interactive manner. Having the blockhash as an anchor will reduce the
amount of guessing required by a node to fetch the correct onion key.
> I'm also trying to figure out how to enable intermediate nodes to reply
to a
> packet, e.g., if capacities are insufficient or the next node is
unreachable,
> by recycling the routing info.
Yeah I've also attempted to tackle this issue a bit myself. The inclusion of
onion routing certainly makes certain classes of failures harder to
reconcile.
There has been a bit of discussion of this in the past, at the time called
"unrolling the onion". In a similar vein it's also more difficult to
ascribe blame node's which directly cause a payment to fail.
One of my naive ideas was to include a "backwards" mix-header within each
node's per-hop payload (though I hadn't included the per-hop payload in my
mental model at the time), however this would result in a quadratic blow up
space complexity parametrized by our max-hop limit. Essentially, we'd
include
a SURB within the mix-header for each hop in the route.
> Maybe we could continue blinding the ephemeral key on the return path, and
> have a mechanism to tell the node the total blinding factor along the
path so
> that it can encrypt something in the routing info for the return path?
That
> would neatly combine Hornet and Sphinx, eliminating the initial roundtrip
to
> setup forwarding segments.
Could you elaborate on this a bit more? It seems that this alone is
insufficient to allow "backwards" replies to the source w/o revealing the
source's identity.
It seems the primary question is: how can we re-use the information present
at
a hop, post-processing to reply to the sender without an additional round
trip?
If we can solve this, then we can greatly increase the robustness of onion
routing within the network. I think they may be worth spinning some cycles
on,
although I don't consider it blocking w.r.t the initial specification.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160804/30f33520/attachment.html>

2023-06-09 12:46:28

- reply

📅 Original date posted:2016-08-22
📝 Original message:
On Sun, Aug 21, 2016 at 1:46 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> > This may not fully solve the problem, since if one presumes that the
> > second-to-last hop is malicious, they can re-create a new onion blob
> > (presuming consistent hashes for each hop, of course).
>
> Great catch. Oops...
>
During the whole payment negotiation process, the sender and receiver can
additionally agree on a shared secret-ish value (possibly the hash of the
contract) that should be included in the per-hop payload for the final hop.
If the portion of the per-hop payload doesn't match identically with this
value, then the payment should be rejected as a prior node has
unsuccessfully attempted re-create the onion packet.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160822/1a545f72/attachment.html>

2023-06-09 12:46:28

- reply

📅 Original date posted:2016-08-20
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> wrote:
> Which creates a subtle requirement: even the terminal onion should
include an
> amount.
With the current draft specification, all hops receive a per-hop payload
(unless we're now abandoning the payload for the final hop due to the
"terminal" byte?). This behavior isn't changed for the final hop, so they
also
extract a payload once they process the onion packet.
Christian Decker <decker.christian at gmail.com> wrote:
> If the recipient does not know the intended amount and accepts anything
then
> fee-shaving is very profitable.
In my mind (although it seems to be handled with the current onion-packet
format), this is an issue which should be resolved/negotiated at a higher
level. Ignoring the possibility of using the network as a general messaging
layer (which seems a bit ambitious, plus brings up DoS concerns), the
sender/receiver should have already negotiated all the details of the
payment.
If the receiver communicated the target r-hash, then they should also be
aware
of the associated value to be paid out with reveal of the corresponding
r-preimage. Joseph's description fits by current thought model.
Rusty Russell <rusty at rustcorp.com.au> wrote:
> Related: I can't seem to figure out why we're so concerned with onion
reuse?
> It seems if a node were to retransmit the same onion runs this same risk.
One might say that the concern is a bit "academic" in nature. In theory,
within
a mix-net (sending emails/messages, not HTLC's), an adversary shouldn't be
able
to re-inject an arbitrary previously processed packet thereby causing node
to
process and forward the packet as normal. If they're able to do this, then
in
conjunction with several nodes participating within the network, the
adversary
may be able to partially (worse, even fully) re-construct the original path
by
observing how the replays propagate throughout the network.
However, practically, we're currently building something that more
resembles an
onion routing network rather than a mix-net. Additionally, as all
communication
links are end-to-end encrypted+authenticated, in reality, the only party
able
to attempt to replay packet within the network are nodes whom have directly
received+processes the onion packet in the past. In our particular context,
assuming the onion packet is encapsulated within the message that adds a new
HTLC, then an attempt to replay would be foolish as if one assumes nodes
remember all r-preimages, then the first hop would just immediately pull the
funds (as Rusty points out).
Joseph Poon <joseph at lightning.network> wrote:
> This may not fully solve the problem, since if one presumes that the
> second-to-last hop is malicious, they can re-create a new onion blob
> (presuming consistent hashes for each hop, of course).
First, *all* hops receive a per-hop payload which ideally would includes
details such as payment, time-lock value, etc. Second, this is only
possible if
Bob (the second-to-last hop), *knows* that they are in fact, the
second-to-last
hop *and* already knows all identities following them within the route.
Otherwise, the route will fail as Bob is unable to construct a new fully
valid
onion packet.
Even in the case that Bob if able to do this, it shouldn't affect the
payment
as a whole assuming Dave (the final receiver) knows the value he's expecting
for each particular r-hash (as you detailed earlier).
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160820/81e0955d/attachment.html>

2023-06-09 12:46:25

- reply

📅 Original date posted:2016-08-12
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> wrote:
> Ephemeral key and mac make sense as a header, but it's fairly easy
> to image a different next hop address format for different networks.
> See also "realm byte" below.
>
> Thus I'm suggesting a format like:
>
> [ephemeral key] [mac] [realm] [per-realm-information]
>
> Per-realm-information is next-hop, amount, etc.
In order to maintain the security properties of the onion blob, each onion
blob
is required to be the exact same length. Therefore, the amount of bytes
allocated for the "next-hop" address needs to be uniform. In my mind, the
next-hop" field should just be an opaque blob (at the specification level)
with
no further explicit meaning. Nodes residing on various chains will parse the
address accordingly (they might be using a different curve, etc).
With this said, I fail to see what we gain by making the current
chain-boundary
explicit (within the onion blob's mix-header).
> An explicit network byte makes sense since we could eventually have
multiple
> networks (atomic cross-chain exchange). While node keys are network
globally
> unique (thus the exchange is *implied* by the next hop), it's nice to be
> explicit.
>
> We need some flag for the terminal node anyway, so it makes sense IMHO
> to expand it.
Sure, but the explicit network byte should be within the main p2p message
header rather than the header for the onion blob itself. When crossing
chains,
nodes will properly set the net magic in the outer message header.
Also we don't need to allocate an additional byte for the terminal node in
any
case. The terminal node can either be identified by the null-MAC, or
null-nexthop (if that isn't being used to dispatch into virtual channels).
> Strawman proposal:
> 1) HTLC-hash and HTLC-preimage? (aha H-hash & H-preimage).
> 2) committx-hash and committx-preimage (C-hash / C-preimage) for the
> commitment transaction revocation?
>
> That avoids R altogether, which is overloaded...
Sounds good to me!
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160812/9368dd41/attachment.html>

2023-06-09 12:46:24

- reply

📅 Original date posted:2016-08-04
📝 Original message:
> Hmm, I think we should combine the "header" and "per-hop payload" into a
> single 40 byte field. They're not meaningfully distinct for lightning,
> AFAICT.
It's not clear to me what we gain by squashing the header (hop's ephemeral
key,
MAC, next hop) and the per-hop payload (amount to forward, possibly an
allowed
CLTV range, etc) into a single blob. I think the extensibility features are
the
same regardless.
> And I think we should add/steal at least one byte for "realm". 0 =
> terminal. 1 = bitcoin lightning. 2 = TBA. etc.
What does "terminal" represent in this context?
I don't think we need an equivalent of Bitcoin's "net magic" bytes within
the
onion blob itself, as I'd imagine that the onion blob would be encapsulated
within a fixed-length field within the "htlcAdd" message. The "htlcAdd"
message
would then have a header similar to Bitcoin's, in which the "net magic"
bytes
would be placed.
> We can't simply deny multiple HTLCs with the same r hash, since that
allows an
> attacker to probe the network to see where an HTLC went (note that in the
> longer run, it's in a node's short-term economic interest to allow this,
which
> is why rhash is troubling).
We wouldn't deny multiple HTLC's with the same r hash. We'd deny a packet
with
a shared secret we've already seen, meaning one that we've processed
before. A
node could still forward multiple HTLC's with identical r-hashes (perhaps
due
to having to fragment a payment due to insufficient link-capacity), these
HTLC's would have distinct (indistinguishable) onion packets.
(as a side note: I think we should establish some better terminology than
r-hash, or H)
> If we switch from hash/preimage to the privkeys with point addition scheme
> (which has other benefits) this is no longer an issue and we can simply
refuse
> to accept two HTLCs with the same pubkey.
The point addition derivation (P2CH style) scheme only applies to
revocations.
It's not clear to me how one can switch to priv/pub key based HTLC's without
modifying Bitcoin Script. At the moment, we're unable to guarantee/force key
disclosure with Script's current capabilities.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160804/34ecad88/attachment-0001.html>

2023-06-09 12:46:15

- reply

📅 Original date posted:2016-05-02
📝 Original message:
>
> Or require a 110k preimage to redeem, drop to the blockchain, then
> redeem it by sending direct to a miner. A node trying to use that
> preimage would create a non-standard transaction, which may not
> propagate. Similarly with an almost 4MB preimage which requires you
> to grind out a tiny signature to redeem in a tx small enough...
>
Segwit's witness program validation logic ensures that each element of the
passed witness stack is less-than-or-equal-to the maximum script element
size (520 bytes). This check is enforced before execution itself.
Therefore, even without the additional OP_SIZE check, Script will enforce a
ceiling on the pre-image size.
We've also recently made such an observation, resulting in a modification
to our scripts similar to the one you've detailed. Thanks for sounding the
alarm with this mailing-list post!
Best,
Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160502/fef7092a/attachment.html>

2023-06-09 12:45:27

- reply

📅 Original date posted:2015-12-17
📝 Original message:
>
>
> >
> > I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I
> used) vs ChaCha20+poly1035.
>
> I'd prefer ChaCha20+poly1305.
>
Welcome aboard the Cha Cha Train! [1]
>
> > 128 bits definitely seems a bit tight for node ids: I assumed a full
> > bitcoin EC pubkey in my current implementation.
>
> I have a pretty good sense of how risky short node ids are, but I
> don't have a good idea of how costly long node ids are in this
> context. I also don't know how many node ids are likely to exist in
> the long-run, successful scenario. 10⁹? 10¹²? Not more than 10¹⁵!
>
> I'd suggest 192-bit nodeids, based on such musings as:
>
> *
> http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html
>
> * http://www.keylength.com/en/compare/
>
> I feel confident that 192-bit nodeids are safe enough. Whether they
> are, practically speaking, more efficient than 256-bit nodeids I'll
> leave up to you to answer.
>
>
Currently, in our code, node ID's take two forms: either the hash160
(Bitcoin style) of a node's current pub-key or the raw serialized pub-key
itself. This is done such that "nodeID at host" locators explicitly provide a
level of backwards (p2pkh) compatibility for end wallets that are unable to
establish a connection in a timely manner.
Within the Sphinx mix-header, I think we should be safely able to truncate
this (the hash160) to 16-bytes. In the case of a collision, the onion-route
propagation across the incorrect node will simply fail, as it won't be able
to properly derive the shared secret.
Otherwise, we'd be forced to ditch chacha20+poly3015 for
AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node
ID's in the routing info.
> > Matts was really interested in sending messages over LN, though, so no
> > doubt he'll be salivating at the idea of extending in this direction :)
>
>
I can't blame him! Utilizing HORNET's rendezvous protocol will allow for a
high level of privacy for both sender *and* receiver.
>
> > Sure, let's discuss that. I want to modify the handshake anyway to
> > include a <len> prefix (like every other message). This lets us upgrade
> > the crypto later, by appending a key for a different system.
> >
>
>
Sure. If we end up going with cha cha, I'd like us to adopt the practice of
encrypting the packet lengths with a separate key (and a new instance of
chacha20) similar to openssh's chacha20-poly3015 specification[2]. With
this construction, packet-length+packet-payload remain confidential.
> > PS. Are we having fun yet?
>
>
Definitely! On my Winter Break atm, so getting a chance to catch up on all
the fun I missed out on during this past quarter :)
1. https://www.youtube.com/watch?v=xGQ5OOyuaxs
2.
https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151217/94f6241d/attachment.html>

2023-06-09 12:45:27

- reply

📅 Original date posted:2015-12-18
📝 Original message:
>
>
> I'm afraid I don't understand how this backwards-compatibility works,
> so if it is important that I understand it please point me to docs or
> explain it more.
>
So we don't have any docs out (yet). But the general ideas arises from
considering the following scenario: an edge wallet wishes to send funds
over lightning to 49hwYWYV26Qgym2n1GnpgxBffhKf at roasbeef.computer. Assuming
we're not use HORNET for payment related messages, the wallet attempts to
connect directly to roasbeef.computer but is unable to. As a fallback, the
wallet simply decodes the ID from base58, appends the checksum, adds a
version byte, and then sends the coins to the resulting address.
Essentially, the idea is to have an easy mechanism for a graceful fallback
to regular on-chain Bitcoin transactions. But, it's really just a
half-baked idea at this point.
Do you mind explaining why you think this is safe? I don't understand
> how it could be safe, in the case that the attacker knows a private
> key that maps to the same 128-bit nodeid as a user's private key does.
>
Sure. Also, I'm referring to colliding public-key hashes. So for a moment
let's view the network as essentially having two namespaces: global vs
local. It's not a requirement that the local namespace be of lower
cardinality than the global namespace. However, in the case of 16-byte
local (mix-net) ID, and 32-byte global ID (LN) it is, therefore collisions
are more frequent. In practice, I think this is safe because in the case a
global node ID conflicts with the local mix-net ID, it doesn't undermine
the propagation of an HTLC, since only one node will be able to
successfully check the MAC, and unwrap the mix-header for the next hop.
Here's an illustration:
Say Alice wishes to send funds to Dave, and her channel sub-graph looks
like this:
Estelle
/
Alice -- Bob
\
Carol - Dave
Alice collects the necessary public keys for the route: Bob -> Carol ->
Dave. She then generates the Sphinx mix-header for the route. As a step in
the process she generates 16-byte local node ID's for the "next-hop" part
of each node's mix-header. She then sends the mix-header to Bob, the first
hop. However, unbeknownst to Alice, the 16-byte ID of Estelle's public-key
collides with Carol's ID. Bob get's the mix-header, and processes it as
normal: checks the MAC, re-blinds group element, and finally peels off
layer from nested mix-header. Bob then realizes there's a collision in the
local namespace. So he first tries to send the mix-header to Estelle first.
Estelle rejects the mix-header because she's unable to check the MAC since
her derived shared secret isn't the one Alice computed for this hop. Bob
gets this error message, so he instead forwards it to Carol, who accepts,
resulting in everything continuing as normal.
To Estelle it just looks like Bob computed the mix-header incorrectly, or
simply forwarded to the wrong node.
I think that's okay (there may be something I'm overlooking)?
> > Otherwise, we'd be forced to ditch chacha20+poly3015 for
> > AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for
> node
> > ID's in the routing info.
>
> I don't understand why the use of entire public keys instead of
> possibly-truncated hashes of public keys would force a decision about
> which cipher and MAC to use.
>
Sphinx requires that the mix-net node ID's be the same size as the MAC
within the mix-header. So if node ID's in the mix-net were 32-bytes, then
we couldn't use poly3015 to generate tags since its tag size is 16-bytes.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151218/1fcd7977/attachment.html>

2023-06-09 12:45:26

- reply

📅 Original date posted:2015-12-15
📝 Original message:
>
> Not sure where these numbers come from? The current header overhead is
> sha256 (32 bytes) + pubkey (33 bytes), or 1300 bytes. (Don't be
> confused by the current test implementation which doesn't serialize the
> pubkey).
>
Hmm, I pulled those numbers from here:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000247.html:
"That's a fixed 3840 bytes; each node decrypts and removed the tail entry,
then prepends padding." Perhaps there's been a newer iteration I've missed,
or the 3.8K bytes isn't the true serialized size.
> If we were to cut to a 16 byte MAC (which seems unwise)
With Poly1035 (which takes 32-byte key and produces a 16-byte tag), forged
messages are rejected with a probability of 1-(n/(2^102)) for a 16n-byte
message[1]. Since the MAC is computed over the 656 byte (20 hops, s=16)
routing-info portion (the onion-wrapped part of the mix header), forged
tags will be rejected with a probability of 1-(656/(2^102)), which seems
okay to me.
> Or, if we're standarizing on ChaCha20, with a 32-byte key:
>
> 33 + (2 * 20 + 2) * 32 = 1377 bytes.
>
Apologies for the ambiguity, but, the "(..)*16" (s) more accurately refers
to the size of the HMAC and node ID's. So if using ChaCha for a stream
cipher, and Poly1035 for MACs rather than AES-CTR + a truncated
SHA-256-HMAC, the size remains the same. Either AES-CTR or ChaCha20 are
valid candidates for the required stream-cipher in the Sphinx construction.
As an side, my current implementation uses AES-CTR as a stream cipher, and
a truncated SHA-256-HMAC for the MAC (s=20). It was written before we
cozied up to ChaCha20-Poly1035. I'll be porting it over to ChaCha-Poly3015
once I tick off some more high-priority items from my TODO list (assuming
we're comfortable with 16-byte node ID's, node ID's are used to map to a
node's current DH-key (id -> key)).
HORNET seems a bit over-the-horizon for now
>
Agreed! Sphinx should be sufficient for now.
Great! Let's argue about protobufs and ChaCha20 vs AES before then :)
>
Perhaps in a new thread :)
Oh, and also, we've come up with a slight variation on the current proposed
p2p crypto handshake. It builds off of the current method (ephemerals
first, etc.). I should get around to posting it to the ML sometime
tomorrow+1 (I'd like to make sure it's sound).
1. https://tools.ietf.org/html/rfc7539 (Section 4)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151215/ac6be70f/attachment.html>

2023-06-09 12:45:25

- reply

📅 Original date posted:2015-12-14
📝 Original message:
Hi y'all!!
So I've been drafting up some schemes for the design of onion routing
within the
Lightning Network myself. Rather than create my own mixing format, and
onion
routing protocol, I've instead turned to some of the existing academic
literature
concerning the subject. I found two schemes, the first building upon the
other, which seem to fit elegantly into our problem domain, directly solving
many problems we've encountered along the way.
The two schemes of interest are first Sphinx[1]: a compact mixing format,
and
HORNET[2][3], which leverages Sphinx to build a low-latency, high-bandwidth
onion routing protocol.
Alright, let's jump into and overview of both schemes!
(heads up, this post is a bit long as it includes a brain dump of ideas
I've
been been floating around in my head for the past two months or so)
First, I'll give a brief overview of Sphinx. I won't delve into the exact
details of the protocol, instead I'll highlight the key insight that allows
for
*extremely* small mix-headers. If we assume a maximum diameter of 20 hops,
and a
16-byte MAC, then a full onion blob weighs in at only 705 bytes! This is
considerably smaller (a 4X size reduction) than the 3840 bytes per
onion-blob in
current proposal. I recommend consulting the paper for the proper
specifics.
Additionally the paper includes a formal proof of security in the Universal
Composability model[4], achieving each of the 4 properties outlined for a
secure
onion routing protocol in [5].
(btw, don't dismiss figures 1 and 2 in the Sphinx paper. They may look
strange,
but finally grokking them resulted in a break through allowing me to finish
my
implementation)
So, at this point, y'all may be wondering how Sphinx achieves such compact
mix-headers. Well, Rather, than including a group element to perform DH
with
for *each* hop in the route, mix-headers in Sphinx only contain a single
group
element. This single group element is then deterministically re-randomized
by
each hop in the route, preparing the group element for the hop directly
following it.
Here's a brief sketch of the mechanism (covering only the DH aspects):
Say Alice wants to route a payment to Bob (Y_b) over Lightning. Alice
consults her
routing/service table, and finds a route via Carol and Dave. Next, to
create the
mix-header, Alice grabs key-pairs for Carol (Y_c) and Dave (Y_d). She then
generates
an ephemeral DH key-pair (a_0 = g^x) then proceeds to derive a shared
secret
for each hop in the route. Using multiplicative notation, the DH derivation
looks something like this (s = shared key, b = blinding factor):
* a_0 = g^x, s_0 = (Y_c)^x, b_0 = hash(a_0, s_0)
* a_1 = (a_0)^b_0, s_1 = (Y_d)^x*b_0, b_1 = hash(a_1, s_1)
* a_2 = (a_1)^b_1, s_2 = (Y_b)^x*b_0*b_1, b_2 = hash(a_2, s_2)
......... continued if more hops were in the route ..........
Alice computes all the blinding factors and shared secrets up front,
allowing
her to create the mix-header for each hop using the derived hop shared
secret
to derive subsequent decryption and MAC keys. Each node receives a_{i}, and
prepares a_{i+1} for the next hop by re-randomizing the group element using
the
blinding factor.
The formula for computing the size of a mix-header for a given hop count,
and
security parameter is (ignoring the final message size):
* p + (2r + 2)s
* p = pub key size (in bytes, for DH each hop)
* r = max number of hops
* s = symmetric key size (in bytes)
So, for 20 hops the size is computed as (with a symmetric key size of 16
bytes):
* 33 + (2*20 + 2) * 16 = 705 bytes!
445% smaller than the 3840 bytes of the current proposal.
The original version of Sphinx was designed with anonymous mailing in mind.
So the final mix-header to the destination node includes a final
destination
email-address (k-bits), and an Identifier (k-bits) used to generate reply
messages back to the sender. If we remove these from the mix-net, we save
2k-bits arriving at a new formula to compute the mix-header size:
* p + (2*r*s)
So with 20 hops the size is reduced to:
* 33 + (2*20*16) = 673 bytes
With this size reduction the, the base64 encoding of a mix-header for two
hops
can fit entirely into a tweet!
* 33 + (2*2*16) = 97 bytes
However, it occurred to me that the final destination address may be useful
in
the context of a more hub-and-spoke-y network. In this scheme the payment
would
be routed to a "shared node", who would then use the destination address to
demultiplexing the payment to one of its connected links in a "host:port"
fashion.
Finally, Sphinx has built-in protection for replay attacks. Meaning an
adversary
is unable to force a node to process a previously processed mix-header. It
achieves this protection by having all nodes remember every derived shard
secret
it has ever come across. However, within the paper, the extent of the past
with
which a node is to recall is unspecified, leading to potentially large
storage
overhead. However, it's worth noting that the paper recommends frequent key
rotation, during which this table may be safely cleared. Additionally,
nodes may
also employ a decaying bloom-filter/hash-set [6] for use in-between key
rotations to create an upper bound on the storage overhead.
With that said, Sphinx is much more compact than the current proposal,
carries
a formal proof of security, and specifies replay protection.
It was recently brought up in [7], that allowing nodes to use onion routing
with
Lightning as an end-to-end messaging interface. This is where HORNET comes
in.
One could use Sphinx's Single-Use-Reply-Blocks to allow the recipient to
communicate with the sender after a dummy onion circuit has been set up.
However, this introduces some performance considerations, due to Sphinx
requiring
each hop to perform 2 asymmetric crypto operations (shared secret
derivation + group element blinding)
before forwarding. HORNET gets around this performance issue by first using
Sphinx
to set up a duplex onion circuit between sender and receiver, which after
set up,
only requires nodes to compute purely symmetric crypto operations before
forwarding.
Continuing, both Sphinx and the current proposal only provide sender
anonymity.
Meaning that only the source maintains unlinkability, therefore it learns
the
destination's location. The addition of HORNET allows both side to retain
full
unlinkability. HORNET has a built-in, an optional rendezvous protocol,
which is
a bit similar to the way Hidden Services in TOR work.
With that said, what follows is a brief high-level overview of the HORNET
onion-routing
protocol (focusing on the initial set up, instead of data transmission).
Unlike Sphinx, which is essentially a "fire-and-forget" onion routing
protocol
from the view of the sender, HORNET requires a cumulative circuit
round-trip
as a set up phase before messaging can begin. Once completed, this set up
phase
creates a duplex onion circuit between the sender and destination, allowing
a
level of throughput approaching 93 Gb/s as reported experimentation section
within
the paper.
The primary addition to Sphinx's mix-header format is something they've
dubbed the
Anonymous Header (AHDR). Instead of requiring each node in the mix-net to
store
per-session state (which would prohibit scale in large networks), all
session-state
is instead stored within the onion-packet itself. Therefore, each node only
needs to
maintain a local secret. A full AHDR contains contains a series of
Forwarding
Segments (FSes) for each hop, allowing them to decrypt the per-hop onion,
revealing the next hop in the path. Each FS contains: the next hop in the
route,
a TTL value, and a derived shared secret. A full AHDR has the following
format:
* (FS, MAC, Onion wrapped FSes)
First, let's go over how a duplex onion circuit is achieved, maintaining
sender
unlinkability (once again, using multiplicative notation):
* Sender Set Up:
* The sender obtains the current keys for each hop in the path,
constructing
a forward, and backwards path (the reverse of the forward path).
* The sender then generates a per-session ephemeral DH key-pair: (x,
g^x)
* Using the Sphinx protocol described above, then sender then generates
two
Sphinx mix-headers: one for the forwards path, and another for the
backwards
path. At this point, the source has derived shared secrets for each
node along
both paths.
* The message payload (SP) of the forward Sphinx mix-header (encrypted
to the
destination), is the backwards Sphinx mix-header which allows the
destination
to reply to the sender.
* The Sphinx mix-header (SHDR) is then extended with two additions:
* A empty list of FSes (P_fs), which each intermediate node can
populate
without learning the total path length, nor their position within
the
route.
* The Sphinx per-hop MAC is also extended over the HORNET Common
Header
(CHDR): (packet type, hops, TTL)
* The sender then sends this set up packet to the first node in the
route:
(CHDR, SHDR, SP, P_fsf)
* Intermediate Node Set Up:
* Upon receipt of the Sphinx packet, each node processes it as normal
(according to Sphinx): deriving the shared secret, recovering the
next hop's
ID, and re-blinding the group element.
* Next, the node verifies the next-hop is correct, and that the packet
hasn't yet expired according to its TTL.
* In order to provide forward secrecy for the messaging phase,
the node then derives a new DH key-pair (y, g^y), and then derives a
new
shared secret to be included within the FS: (a_i)^y
* Using it's local shared secret (SV_i), the node creates a FS that
only it
can decrypt, adding this to the FS payload. This payload entry
additionally
includes the new ephemeral DH-key pair (y, g^y), allowing the source
to derive
the shared secret which will be used for the FS's MAC (and also when
transmitting data).
* Finally the node re-assembles the packet (CHDR', SHDR', SP, P_fsf'),
and
forwards it to the next hop.
* Destination Set Up:
* The destination initially processes the packet identically to the
intermediate
nodes described above.
* It then decrypts the Sphinx payload, uncovering the backwards SHDR.
The node
then creates a new payload each of the completed FSes in the payload.
destined to the source.
* At this point, the destination has no knowledge of any of the derived
shared
secrets, other than the one it has derived with the source.
* Next, it creates a new FS list P_fsb, to collect FSes along the
backwards path.
* Finally, it creates the backwards set up packet (CHDR, SHDR, SP_b,
P_fsb), and
sends it to the first node on the backwards path.
* Each intermediate node then processes the backwards packet just as
before.
* Data Transfer (brief overview, consult the paper for proper details)
* The source node then recovers the Sphinx payload SP_b, recovering the
forwarding segments for the forward (P_fsf) and backwards path (P_fsb)
* At this point, set up has been completed!
* The source node then constructs two initial AHDR's, one so it can
send
messages to the destination via the circuit, and the other which will
allow the destination to reply to the source.
* After the first message from S -> D, D obtains the backwards AHDR,
allowing it to reply without knowing the actual route.
The, the following modifications are necessary to achieve sender-receiver
unlinkability as described earlier. The modification to allow send-receiver
unlinkability is relatively straight forward. It involves nested AHDRs.
Lets
say Alice wants to send a message (or a payment in our case) to Bob while
maintaining
full unlinkability. Bob will first need to select a rendezvous point (RP),
let's call him Rodriguez. Bob then executes the set up protocol detailed
above
between himself and Rodriguez. As a result, Bob obtains a AHDR allowing
Rodriguez
to route messages (via some specified path) to Bob (R -> B). Bob then
publishes
this AHDR_rb to some "public bulletin board", or in the case that Alice has
a
hidden service set up, directly to Alice. Alice then obtains the AHDR_rb,
routing as normal to Rodriguez, but then includes AHDR_rb, nested within
the
regular AHDR_ar (Alice -> Bob). Once this mix-header reaches Bob, he
recovers the
nested AHDR, allowing him to complete the route to Bob. Additionally, its
possible
for Bob to specify several rendezvous points, allowing Alice to select the
closest/cheapest route to her. As a side effect, the usage of this nested
AHDR
doubles the bandwidth required for each node to forward along the path.
With this duplex onion route set up (with or without the RP), Alice can
send a
message to Bob, asking for R (along with other payment details), then
propagate
HTLCs along the full path in order to pay Bob. In order to mitigate the
potential
DoS attacks introduced by adding a message layer for control signals, we
can
either introduce a payment system (as suggested in [8]), or a required
Hashcash
challenge (avoiding SHA-256, using either SHA-3 or BLAKE2). However, seeing
as
we'd like to maintain the responsiveness of the network, I'm personally
leaning
towards payments (if we do in fact deem in network messaging attractive).
Okay, so that concludes my first post on the mailing list! So at this point
y'all may be wondering where the implementation I mentioned above is?
Well, so far I have a working implementation of Sphinx by itself, not yet
integrating the aspects of HORNET, but, it's not yet publicly released.
We (me+Tadge+Joseph) are planning on publicly releasing our in progress
implementation of Lightning, sometime near the end of this month (December)
:).
1. http://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
2. http://arxiv.org/pdf/1507.05724v1.pdf (HORNET w/ forward secrecy)
3. http://www.scion-architecture.net/pdf/2015-HORNET.pdf
4. https://eprint.iacr.org/2000/067.pdf
5. http://cs.brown.edu/~anna/papers/cl05-full.pdf
6. https://moderncrypto.org/mail-archive/messaging/2015/001906.html
7.
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-December/000369.html
8.
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-December/000371.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151214/996b3701/attachment-0001.html>

2023-06-07 23:16:38

- reply

📅 Original date posted:2022-11-04
📝 Original message:Hi Johan,
I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However, by the time
that transaction hits the chain, the UTXO may no longer exist. At that
point, what happens to the asset? Is it burned? Can you retry it again? Does
it go back to the sender?
As a concrete example, imagine I have a channel open, and give you an
address to "teleport" some additional assets to it. You take that addr, then
make a transaction to commit to the transfer. However, the block before you
commit to the transfer, my channel closes for w/e reason. As a result, when
the transaction committing to the UTXO (blinded or not), hits the chain, the
UTXO no longer exists. Alternatively, imagine the things happen in the
expected order, but then a re-org occurs, and my channel close is mined in a
block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
used as a serialization point, the scheme seems to lack a necessary total
ordering to ensure safety.
If we look at Taro's state transition model in contrast, everything is fully
bound to a single synchronization point: a normal Bitcoin transaction with
inputs consumed and outputs created. All transfers, just like Bitcoin
transactions, end up consuming assets from the set of inputs, and
re-creating them with a different distribution with the set of outputs. As a
result, Taro transfers inherit the same re-org safety traits as regular
Bitcoin transactions. It also isn't possible to send to something that won't
ultimately exist, as sends create new outputs just like Bitcoin
transactions.
Taro's state transition model also means anything you can do today with
Bitcoin/LN also apply. As an example, it would be possible for you to
withdrawn from your exchange into a Loop In address (on chain to off chain
swap), and have everything work as expected, with you topping off your
channel. Stuff like splicing, and other interactive transaction construction
schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.
Ignoring the ordering issue I mentioned above, I don't think this is a great
model for anchoring assets in channels either. With Taro, when you make the
channel, you know how many assets are committed since they're all committed
to in the funding output when the channel is created. However, let's say we
do teleporting instead: at which point would we recognize the new asset
"deposits"? What if we close before a pending deposits confirms, how can one
regain those funds? Once again you lose the serialization of events/actions
the blockchain provides. I think you'd also run into similar issues when you
start to think about how these would even be advertised on a hypothetical
gossip network.
I think one other drawback of the teleport model iiuc is that: it either
requires an OP_RETURN, or additional out of band synchronization to complete
the transfer. Since it needs to commit to w/e hash description of the
teleport, it either needs to use an OP_RETURN (so the receiver can see the
on chain action), or the sender needs to contact the receiver to initiate
the resolution of the transfer (details committed to in a change addr or
w/e).
With Taro, sending to an address creates an on-chain taproot output just
like sending to a P2TR address. The creation of the output directly creates
the new asset anchor/output as well, which allows the receiver to look for
that address on chain just like a normal on chain transaction. To 3rd party
observers, it just looks like a normal P2TR transfer. In order to finalize
the receipt of the asset, the receiver needs to obtain the relevant
provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
service keyed by the input outpoint and output index. In short, the send
process is fully async, with the sender and receiver using the blockchain
itself as a synchronization point like a normal Bitcoin wallet.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/354c256b/attachment.html>

2023-06-07 23:07:00

- reply

📅 Original date posted:2022-04-28
📝 Original message:Stating the taproot interaction more plainly: the taproot tweak is defined
as a function of the internal key itself h_tapTeak(internalKey || rootHash),
which means that the full tweak can't be known ahead of time. Instead, one
must aggregate the keys to obtain the internal key _then_ apply the tweaks
as normal.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220427/1e777215/attachment-0001.html>

2023-06-07 23:06:48

- reply

📅 Original date posted:2022-04-05
📝 Original message:Hi y'all,
I'm excited to publicly publish a new protocol I've been working on over the
past few months: Taro. Taro is a Taproot Asset Representation Overlay which
allows the issuance of normal and also collectible assets on the main
Bitcoin
chain. Taro uses the Taproot script tree to commit extra asset structured
meta
data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or
MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
sparse
merkle tree, enabling things like easily verifiable asset supply proofs and
also efficient proofs of non existence (eg: you prove to me you're no longer
committing to the 1-of-1 holographic beefzard card during our swap). Taro
asset
transfers are then embedded in a virtual/overlay transaction graph which
uses a
chain of asset witnesses to provably track the transfer of assets across
taproot outputs. Taro also has a scripting system, which allows for
programmatic unlocking/transfer of assets. In the first version, the
scripting
system is actually a recursive instance of the Bitcoin Script Taproot VM,
meaning anything that can be expressed in the latest version of Script can
be
expressed in the Taro scripting system. Future versions of the scripting
system
can introduce new functionality on the Taro layer, like covenants or other
updates.
The Taro design also supports integration with the Lightning Network
(BOLTs) as
the scripting system can be used to emulate the existing HTLC structure,
which
allows for multi-hop transfers of Taro assets. Rather than modify the
internal
network, the protocol proposes to instead only recognize "assets at the
edges",
which means that only the sender+receiver actually need to know about and
validate the assets. This deployment route means that we don't need to
build up
an entirely new network and liquidity for each asset. Instead, all asset
transfers will utilize the Bitcoin backbone of the Lightning Network, which
means that the internal routers just see Bitcoin transfers as normal, and
don't
even know about assets at the edges. As a result, increased demand for
transfers of these assets as the edges (say like a USD stablecoin), which in
will turn generate increased demand of LN capacity, result in more
transfers, and
also more routing revenue for the Bitcoin backbone nodes.
The set of BIPs are a multi-part suite, with the following breakdown:
* The main Taro protocol:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
* The MS-SMT structure:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
* The Taro VM:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
* The Taro address format:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
* The Taro Universe concept:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
* The Taro flat file proof format:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
Rather than post them all in line (as the text wouldn't fit in the allowed
size
limit), all the BIPs can be found above.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220405/930b239c/attachment.html>

2023-06-07 18:24:25

- reply

📅 Original date posted:2020-05-05
📝 Original message:Hi Antoine,
> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients [0] each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the backbone network. If
> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
> signal BIP 157, that's an increase of 100GB/month for each. Which is
> consequent with regards to the estimated cost of 350GB/month for running
> an actual public node
One really dope thing about BIP 157+158, is that the protocol makes serving
light clients now _stateless_, since the full node doesn't need to perform
any unique work for a given client. As a result, the entire protocol could
be served over something like HTTP, taking advantage of all the established
CDNs and anycast serving infrastructure, which can reduce syncing time
(less latency to
fetch data) and also more widely distributed the load of light clients using
the existing web infrastructure. Going further, with HTTP/2's server-push
capabilities, those serving this data can still push out notifications for
new headers, etc.
> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment
> capabilities to price chain access resources [3]
Piggy backing off the above idea, if the data starts being widely served
over HTTP, then LSATs[1][2] can be used to add a lightweight payment
mechanism by inserting a new proxy server in front of the filter/header
infrastructure. The minted tokens themselves may allow a user to purchase
access to a single header/filter, a range of them in the past, or N headers
past the known chain tip, etc, etc.
-- Laolu
[1]: https://lsat.tech/
[2]: https://lightning.engineering/posts/2020-03-30-lsat/
On Tue, May 5, 2020 at 3:17 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi,
>
> (cross-posting as it's really both layers concerned)
>
> Ongoing advancement of BIP 157 implementation in Core maybe the
> opportunity to reflect on the future of light client protocols and use this
> knowledge to make better-informed decisions about what kind of
> infrastructure is needed to support mobile clients at large scale.
>
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node. Assuming a
> user adoption path where a full-node is required to benefit for LN may
> deprive a lot of users, especially those who are already denied a real
> financial infrastructure access. It doesn't mean we shouldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even a
> first-step to it.
>
> Designing a mobile-first LN experience opens its own gap of challenges
> especially in terms of security and privacy. The problem can be scoped as
> how to build a scalable, secure, private chain access backend for millions
> of LN clients ?
>
> Light client protocols for LN exist (either BIP157 or Electrum are used),
> although their privacy and security guarantees with regards to
> implementation on the client-side may still be an object of concern
> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
> estimation). That said, one of the bottlenecks is likely the number of
> full-nodes being willingly to dedicate resources to serve those clients.
> It's not about _which_ protocol is deployed but more about _incentives_ for
> node operators to dedicate long-term resources to client they have lower
> reasons to care about otherwise.
>
> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients [0] each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the backbone network. If
> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
> signal BIP 157, that's an increase of 100GB/month for each. Which is
> consequent with regards to the estimated cost of 350GB/month for running an
> actual public node. Widening full-node adoption, specially in term of
> geographic distribution means as much as we can to bound its operational
> cost.
>
> Obviously, deployment of more efficient tx-relay protocol like Erlay will
> free up some resources but it maybe wiser to dedicate them to increase
> health and security of the backbone network like deploying more outbound
> connections.
>
> Unless your light client protocol is so ridiculous cheap to rely on
> niceness of a subset of node operators offering free resources, it won't
> scale. And it's likely you will always have a ratio disequilibrium between
> numbers of clients and numbers of full-node, even worst their growth rate
> won't be the same, first ones are so much easier to setup.
>
> It doesn't mean servicing filters for free won't work for now, numbers of
> BIP157 clients is still pretty low, but what is worrying is wallet vendors
> building such chain access backend, hitting a bandwidth scalability wall
> few years from now instead of pursuing better solutions. And if this
> happen, maybe suddenly, isn't the quick fix going to be to rely on
> centralized services, so much easier to deploy ?
>
> Of course, it may be brought that actually current full-node operators
> don't get anything back from servicing blocks, transactions, addresses...
> It may be replied that you have an indirect incentive to participate in
> network relay and therefore guarantee censorship-resistance, instead of
> directly connecting to miners. You do have today ways to select your
> resources exposure like pruning, block-only or being private but the wider
> point is the current (non?)-incentives model seems to work for the base
> layer. For light clients data, are node operators going to be satisfied to
> serve this new *class* of traffic en masse ?
>
> This doesn't mean you won't find BIP157 servers, ready to serve you with
> unlimited credit, but it's more likely their intentions maybe not aligned,
> like spying on your transaction broadcast or block fetched. And you do want
> peer diversity to avoid every BIP157 servers being on few ASNs for
> fault-tolerance. Do people expect a scenario a la Cloudflare, where
> everyone connections is to far or less the same set of entities ?
>
> Moreover, the LN security model diverges hugely from basic on-chain
> transactions. Worst-case attack on-chain a malicious light client server
> showing a longest, invalid, PoW-signed chain to double-spend the user. On
> LN, the *liveliness* requirement means the entity owning your view of the
> chain can lie to you on whether your channel has been spent by a revoked
> commitment, the real tip of the blockchain or even dry-up block
> announcement to trigger unexpected behavior in the client logic. A
> malicious light client server may just drop any filters/utxos spends, what
> your LN client should do in this case ? [1]
>
> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment capabilities
> to price chain access resources [3]. This proposition may suit within the
> watchtower paradigm, where another entity is delegated some part of
> protocol execution, alleviating client onliness requirement. It needs
> further analysis but how your funds may be compromised by a watchtower are
> likely to be the same scenario that how a chain validation provider can
> compromise you. That said, how do you avoid such "chain access" market
> turning as an oligopoly is an open question. You may "bind" them to
> internet topology or ask for fidelity bonds and create some kind of
> scarcity but still...
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
> just rely on few thousands of full-node operators being nice and servicing
> friendly millions of LN mobiles clients. But just in case it may be good to
> consider a reasonable alternative.
>
> Thanks Gleb for many points exposed here but all mistakes are my own.
>
> Cheers,
>
> Antoine
>
> [0] UTXO set size may be a bottleneck, but still if you have 2 channels by
> clients that's 20M utxos, just roughly ~x3 than today.
>
> [1] And committing filters as part of headers may not solve everything as
> an attacker can just delay or slow announcements to you, so you still need
> network access to at least one honest node.
>
> [2] It maybe argue that distinction client-vs-peer doesn't hold because
> you may start as a client and start synchronizing the chain, relaying
> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
> what you want to run in a mobile.
>
> _______________________________________________
> 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/bitcoin-dev/attachments/20200505/f910aa3f/attachment.html>