Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM

Very interesting proposal, though as Will points out we could implement the same using runes: have the rune be managed by the hardware wallet, and commit the rune used to authenticate the RPC call commit to the call's payload. That way a potentially compromised client cannot authenticate arbitrary

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

> > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an inf

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi Antoine, this is an intrinsic issue with reputation systems, and the main reason I'm sceptical w.r.t. their usefulness in lightning. Fundamentally any reputation system bases their expectations for the future on experiences they made in the past, and they are thus always susceptible to sudden b

Re: [Lightning-dev] Highly Available Lightning Channels

Hi Matt, Hi Joost, let me chime in here, since we seem to be slowly reinventing all the research on reputation systems that is already out there. First of all let me say that I am personally not a fan of reputation systems in general, just to get my own biases out of the way, now on to the why :-)

Re: [Lightning-dev] Onion messages rate-limiting

Thanks Bastien for writing up the proposal, it is simple but effective I think. >> One issue I see w/ the first category is that a single party can flood the >> network and cause nodes to trigger their rate limits, which then affects >> the >> usability of the onion messages for all other well-beh

Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

Matt Corallo writes: > On 6/28/22 9:05 AM, Christian Decker wrote: >> It is worth mentioning here that the LN protocol is generally not very >> latency sensitive, and from my experience can easily handle very slow >> signers (3-5 seconds delay) without causing too ma

Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

Olaoluwa Osuntokun writes: >> 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

Re: [Lightning-dev] Lightning RPC

Hi Will, > I noticed you are doing RPC stuff... I'm looking to do RPC over > lightning itself. I started a C library called lnsocket[1], scrounged > from clightning parts, so that I can send messages from iOS to control > my lightning node. Sounds interesting, and similar to commando's goals. Rus

Re: [Lightning-dev] Split payments within one LN invoice

I was looking into the docs [1] and stumbled over `createinvoice` which does almost what you need. However it requires the preimage, and stores the invoice in the database which you don't want. However if you have access to the `hsm_secret` you could sign in the plugin itself, completely sidestepp

Re: [Lightning-dev] Split payments within one LN invoice

This is quite a common request, and we've used a solution I like to call the "Poor man's rendez-vous". It basically routes a payment through all the parties that are to be paid, with the last one accepting the payment for all participants. The payment is atomic, once the circuit is set up no parti

Re: [Lightning-dev] INTEROPERABILITY

ZmnSCPxj via Lightning-dev writes: > Are you proposing as well to provide the hardware and Internet > connection for these boxes? Having implemented and operated the lightning integration testing framework [1,2] in the past this is something near and dear to my heart. However I have since become

Re: [Lightning-dev] Impact of eltoo loss of state

Martin Habovštiak wrote: > What would happen in 2) if the node has data but the peer returned an > incorrect state? > > On Wed, Jul 14, 2021, 20:13 Christian Decker > wrote: > >> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty >> loss-of-stat

Re: [Lightning-dev] Impact of eltoo loss of state

Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty loss-of-state equates to loss-of-funds, in eltoo this is reduced to impact only funds that are in a PTLC at the time of the loss-of-state. We have a couple of options here, that don't touch the blockchain, and are therefore r

[Lightning-dev] Funding Timeout Recovery proposal

Hi All, I just finished writing a (very) rough draft of the Funding Timeout Recovery proposal (a.k.a. "So long, and thanks for all the sigs"). You can find the full proposal here [1]. The proposal details how the fundee can assist the funder quickly recover a botched funding. This is an alternati

Re: [Lightning-dev] Escrow Over Lightning?

> The `!(a && b && ...)` can be converted to a reversal of the payment. > The individual `!BUYER` is just the buyer choosing not to claim the > seller->buyer direction, and the individual `!ESCROW` is just the > escrow choosing not to reveal its temporary scalar for this payment. > And any products

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

Rusty Russell writes: >> This is in stark contrast to the leader-based approach, where both >> parties can just keep queuing updates without silent times to >> transferring the token from one end to the other. > > You've swayed me, but it needs new wire msgs to indicate "these are > your proposals

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

> And you don't get the benefit of the turn-taking approach, which is that > you can have a known state for fee changes. Even if you change it to > have opener always the leader, it still has to handle the case where > incoming changes are not allowed under the new fee regime (and similar > issu

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

Joost Jager writes: >> The LOW-REP node being out of pocket is the clue here: if one party >> loses funds, even a tiny bit, another party gains some funds. In this >> case the HIGH-REP node collaborating with the ATTACKER can extract some >> funds from the intermediate node, allowing them to dime

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

I wonder if we should just go the tried-and-tested leader-based mechanism: 1. The node with the lexicographically lower node_id is determined to be the leader. 2. The leader receives proposals for changes from itself and the peer and orders them into a logical sequence of changes 3. The

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

I think the mechanism can indeed create interesting dynamics, but not in a good sense :-) >> I can still establish channels to various low-reputation nodes, and >> then use them to grief a high-reputation node. Not only do I get to >> jam up the high-reputation channels, as a bonus I get the >> l

Re: [Lightning-dev] Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo)

ZmnSCPxj writes: > I am almost certain that a Smart Contract Unchained Escrowed > Decker-Russell-Osuntokun channel factory can merge the watchtower and > escrow functionality as well, using the above basic sketch, with > additional overlay network to allow for federated escrows. The issue > is re

Re: [Lightning-dev] Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo)

Hi Nadav, thanks for writing up this proposal. I think I can add a bit of details, which might simplify the proposal. ## Ordering of updates The way we ensure that an update tx (as the commitment txs are called in the paper) can be attached only to prior updates is done by comparing the state-nu

Re: [Lightning-dev] Collaborated stealing. What happens when the final recipient discloses the pre-image

It might be worth mentioning here that the wormhole attack can also just be considered a more efficient way of routing a payment over fewer hops, freeing funds in channels that have been skipped by failing them even though the overall payment has not been completed. This is why I hesitate to even

[Lightning-dev] Speciication Meeting 2020/05/25

Dear Fellow Bolters, the next Lightning Network specification meeting will be this Monday at 20:00 UTC [1]. The current agenda [2] is still a bit light on issues and PRs, which gives us some time to spend on longer term goals, and extended discussions. If there are issues that need to be discussed

Re: [Lightning-dev] Sphinx Rendezvous Update

Hi Bastien, thanks for verifying my proposal, and I do share your concerns regarding privacy leaks (how many hops are encoded in the onion) and success ratio if a payment is based on a fixed (partial) path. > I believe this makes it quite usable in Bolt 11 invoices, without blowing up > the size

[Lightning-dev] Lightning Spec Meeting 2020/03/02

Dear Protocol Devs, start you text-editors, the next meeting is this Monday (2020/03/02), and to facilitate review and meeting preparations we have prepared a short agenda [1], this time brought to you by @t-bast, because I almost forgot :-) Below is a snapshot of the current agenda. Should there

Re: [Lightning-dev] Sphinx Rendezvous Update

Hi Bastien, seems you were a bit quicker than I was with my writeup of my proposal. I came up with a scheme that allows us to drop a large part of the partial onion, so that it can indeed fit into an outer onion, and the rendez-vous node RV can re-construct the original packet from the included da

Re: [Lightning-dev] Direct Message draft

Rusty Russell writes: >> Would it not be better to create a circular path? By this I mean, >> Alice constructs an onion that overall creates a path from herself to >> Bob and back, ensuring different nodes on the forward and return >> directions. The onion hop at Bob reveals that Bob is the cho

[Lightning-dev] Lightning Spec Meeting 2020/02/17

Dear Fellow Protocol Devs, the next meeting is this Monday (2020/02/17), and to facilitate review and meeting preparations we have prepared a short agenda [1]. The open topic discussions during the last two iterations have been very interesting, albeit a bit long, so this time we decided to limit

Re: [Lightning-dev] Sphinx and Push Notifications

darosior via Lightning-dev writes: > Hi Pavol, > >> 1) Is c-lightning going to support Sphinx or other form of >> spontaneous payments? > > I think cdecker is working on integrating keysend to his noise plugin > (https://github.com/lightningd/plugins/pull/68). The keysend functionality is impleme

[Lightning-dev] Lightning Spec Meeting 2020/02/03

Dear Fellow Protocol Devs, the next meeting is this Monday (2020/02/03), and to facilitate review and meeting preparations we have prepared a short agenda [1]. We switched over to a Github issue to prepare the agenda, since we already heavily rely on the infrastructure for all of our other task

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

Matt Corallo writes: > Right, but there are approaches that are not as susceptible - an > obvious, albeit somewhat naive, approach would be to define a fixed and > proportional max fee, and pick a random (with some privacy properties eg > biasing towards old or good-reputation nodes, routing acros

[Lightning-dev] Lightning Spec Meeting 2020/01/20

Dear Fellow Protocol Devs, our next meeting is this Monday (2020/01/20) and I thought I'd try to follow up on my new years resolution to add some more structure to the spec meetings. I drafted an agenda for Monday [1], hoping to give everybody a couple of days before the meeting to get up to speed

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

That is correct, the chain of noinput/anyprevout transactions is broken as soon as the signers are online and can interactively bind and sign without noinput/anyprevout. Conner Fromknecht writes: > Good evening, > >> I didn't think this was the design. The update transaction can spend any > pri

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

ZmnSCPxj via Lightning-dev writes: > Good morning Rusty, > >> ZmnSCPxj zmnsc...@protonmail.com writes: >> >> > Good morning Rusty, >> > >> > > > Hi all, >> > > > I recently revisited the eltoo paper and noticed some things related >> > > > watchtowers that might affect channel construction. >> > >

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

(I wrote this a couple of days ago but forgot to send it, sorry for that) Hi Conner, thanks for looking into this. I hadn't really thought too much about watchtowers while writing the paper, so there might definitely be things I hadn't considered. I fail to see where the watchtower needs to gener

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

Anthony Towns writes: > On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev > wrote: >> With the recently renewed interest in eltoo, a proof-of-concept >> implementation >> [1], and the discussions regarding clean abstractions for off-chain proto

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

ZmnSCPxj via bitcoin-dev writes: > Good morning lists, > > Let me summarize concerns brought up: > > * Chris concern, is that an ordinary UTXO that is not allocated for > `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`. > * My concern, is that unless a UTXO allocated for `S

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

ZmnSCPxj writes: >> That is very much how I was planning to implement it anyway, using a >> trigger transaction to separate timeout start and the actual >> update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo >> there shouldn't be an issue here :-) > > My understanding is that a tr

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

Chris Stewart writes: > I do have some concerns about SIGHASH_NOINPUT, mainly that it does > introduce another footgun into the bitcoin protocol with address reuse. > It's common practice for bitcoin businesses to re-use addresses. Many > exchanges [1] reuse addresses for cold storage with very l

Re: [Lightning-dev] Continuing the discussion about noinput / anyprevout

Chris Stewart writes: >> I don't find too compelling the potential problem of a 'bad wallet > designer', whether lazy or dogmatic, misusing noinput. I think there are > simpler ways to cut corners and there will always be plenty of good wallet > options people can choose. > > In my original post,

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

ZmnSCPxj writes: > To elucidate further --- > > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > `OP_CHECKSIG_WITHOUT_INPUT`. > > This new opcode ignores any `SIGHASH` flags, if present, on a > signature, but instead hashes the current transaction without the > input references, t

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

ZmnSCPxj writes: > I rather strongly oppose output tagging. > > The entire point of for example Taproot was to reduce the variability > of how outputs look like, so that unspent Taproot outputs look exactly > like other unspent Taproot outputs regardless of the SCRIPT (or lack > of SCRIPT) used to

[Lightning-dev] Continuing the discussion about noinput / anyprevout

With the recently renewed interest in eltoo, a proof-of-concept implementation [1], and the discussions regarding clean abstractions for off-chain protocols [2,3], I thought it might be time to revisit the `sighash_noinput` proposal (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5]. (sorry for

Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

ZmnSCPxj writes: >> Not necessarily. If we have an escape hatch in the scripts that allows >> to spend any output attached to the settlement transaction by n-1 >> participants we could reclaim these into a new open right away. > > This would have to be very very carefully designed. > The entire po

Re: [Lightning-dev] Revocations and Watchtowers

I don't think this paints an accurate picture, both when it comes to watchtowers for LN-penalty as well as for eltoo: Technically the storage requirement for the shachain is also O(log(n)) and not O(1) due to the fact that we effectively have a cut through the height of the tree, along which we ha

Re: [Lightning-dev] Avoiding gossip spam: how many updates do you need?

ZmnSCPxj via Lightning-dev writes: >> But it is perfectly fine to use ***zero*** routing fees, I think. > > Briefly: if a channel has too much liquidity on your side, passively > rebalance by broadcasting a `channel_update` with 0 routing fees. > This helps JIT-Routing of nearby nodes as it allows

Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

ZmnSCPxj writes: >> cooperative close: >> * when all parties mutually agree to close the channel >> * close the channel with a layer one transaction which finalizes the outputs >> from the most recent channel output state >> * should be optimized for privacy and low on-chain fees > > Of note is t

[Lightning-dev] Reconciling the off-chain and on-chain models with eltoo

With the recently published proof-of-concept of eltoo on signet by Richard, I thought it might a good time to share some thoughts on ho I think we can build this system. I think there are a few properties of eltoo that allow us to build a nicely layered protocol stack, which improves flexibility an

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

ZmnSCPxj via Lightning-dev writes: > Good morning Atoine, > > Thank you for your proposal. > >> Eltoo has been criticized to lower the cost for a malicious party to >> test your monitoring of the chain. If we're able to reintroduce some >> form of punishment without breaking transaction symmetry

Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions

Hi Ugam, I just wanted to quickly note that the current proposal [1] (implemented here [2]) is to give up on the fixed 65 byte frames altogether and allow variable payloads (reclaiming what previously was padding in the hop payloads). Given the low diameter of the network, this gives us a lot of f

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

ZmnSCPxj via Lightning-dev writes: >> Can you expand on that? Why do we need to "make use of the >> collaborative path" (maybe it's unclear to me what you mean by >> collaborative path here)? > > The collaborative path is the use of the taproot-tweaked public key to > sign, without revealing any

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

Hi Bastien, thanks for investigating. > I have been digging into Anthony Towns' anyprevout BIP > > proposal > to verify that it has everything we need for Eltoo > . > > The separation

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

Hi ZmnSCPzj, I think we should not try to recover from a node not finding the next hop in the trampoline, and rather expect trampolines to have reasonable uptime (required anyway) and have an up to date routing table (that's what we're paying them for after all). So I'd rather propose reusing the

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

On Wed, 3 Apr 2019, 05:42 ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Pierre and list, > > > There is another unrelated issue: because trampoline nodes don't know > > anything about what happened before they received the onion, they may > >

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

Thanks Pierre for this awesome proposal, I think we're onto something here. I'll add a bit more color to the proposal, since I've been thinking about it all weekend :-) There are two ways we can use this: - A simple variant in which we just tell a single trampoline what the intended recipient

Re: [Lightning-dev] More thoughts on NOINPUT safety

Anthony Towns writes: > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput), > so if you used a tagged output, you could do everything normal taproot > address could, but also do noinput sigs for them. > > So you might have: > >funding tx -> cooperative claim > >funding tx

Re: [Lightning-dev] Multi-frame sphinx onion format

ZmnSCPxj writes: > Good morning Christian, Rusty, and list, > You can take this a step further and make the realm 0 byte into a > special type "0" which has a fixed length of 1299 bytes, with the > length never encoded for this special type. It would then define the > next 1299 bytes as the "V",

Re: [Lightning-dev] Multi-frame sphinx onion format

Rusty Russell writes: > There are two ways to add TLV to the onion: > 1. Leave the existing fields and put TLV in the padding: >* [`8`:`short_channel_id`] >* [`8`:`amt_to_forward`] >* [`4`:`outgoing_cltv_value`] >* [`12`:`padding`] > 2. Replace existing fields with TLV (eg. 2=short

[Lightning-dev] Multi-frame sphinx onion format

Heya everybody, during the spec meeting in Adelaide we decided that we'd like to extend our current onion-routing capabilities with a couple of new features, such as rendez-vous routing, spontaneous payments, multi-part payments, etc. These features rely on two changes to the current onion format:

Re: [Lightning-dev] Extending Associated Data in the Sphinx Packet to Cover All Payment Details

Hi Laolu, thanks for bringing this up. I think committing to more data might be nice, but I have some reservations re signaling in the onion packet version. But let's start at the top: > However, since the CLTV isn't also authenticated, then it's possible > to attempt to inject a new HTLC with a

Re: [Lightning-dev] Quick analysis of channel_update data

Fabrice Drouin writes: > I think there may even be a simpler case where not replacing updates > will result in nodes not knowing that a channel has been re-enabled: > suppose you got 3 updates U1, U2, U3 for the same channel, U2 disables > it, U3 enables it again and is the same as U1. If you dis

Re: [Lightning-dev] Quick analysis of channel_update data

Rusty Russell writes: >> But only 18 000 pairs of channel updates carry actual fee and/or HTLC >> value change. 85% of the time, we just queried information that we >> already had! > > Note that this can happen in two legitimate cases: > 1. The weekly refresh of channel_update. > 2. A node updated

Re: [Lightning-dev] Quick analysis of channel_update data

Hi Fabrice, happy new year to you too :-) Thanks for taking the time to collect that information. It's very much in line with what we were expecting in that most of the updates come from flapping channels. Your second observation that some updates only change the timestamp is likely due to the st

Re: [Lightning-dev] Reason for having HMACs in Sphinx

Corné Plooy writes: >> The total_decorrelation_secrets serves as the payer-generated shared >> secret between payer and payee. B cannot learn this, and thus cannot >> fake its own secret. Even if it instead offers ((I + K[A]) + k[z] * >> G) for a new secret k[z], it cannot know how to change >>

Re: [Lightning-dev] Reason for having HMACs in Sphinx

Rusty Russell writes: >> The shared secret doesn't need to be very large: the number of attempts >> per second (to guess the shared secret) is limited by network latency, >> bandwidth and maybe some artificial rate limiting. If an attacker can do >> 100 attempts per second, then a 32-bit shared se

Re: [Lightning-dev] Base AMP

Which brings us back to the initial proposal that just signals the awareness of a temporary underpayment with the single "more is coming"-bit. On Sun, Dec 2, 2018 at 11:49 PM Rusty Russell wrote: > ZmnSCPxj writes: > > But what if 2 of those paths fail? > > It would be better to merge them into

Re: [Lightning-dev] Reason for having HMACs in Sphinx

Hi Corne, the HMACs are necessary in order to make sure that a hop cannot modify the packet before forwarding, and the next node not detecting that modification. One potential attack that could facilitate is that an attacker could learn the path length by messing with different per-hop payloads:

[Lightning-dev] Rendez-vous proposal with ephemeral key switch

I finally got around to amending my initial (broken) proposal for the rendez-vous protocol using the ephemeral key switch at the rendez-vous point. I'd like to try and keep a live document that describes the entire proposal in the Wiki to make it easier for people to get an overall view of the prop

Re: [Lightning-dev] type,len,value standard

Conner Fromknecht writes: >> For a sequence of `type,len,value`, the `type`s must be in ascending order >> -- not explicitly accepted or rejected. It would be easier to check >> uniqueness > (the previous rule we accepted) here for a naive parser (keep >> track of some "minimum allowed type" that

Re: [Lightning-dev] Base AMP

I'm not sure this is an improvement at all over just allowing a single merge-point, i.e., the destination. You see as long as we don't attempt intermediate merges the routes are independent and failures of one HTLC do not impact any other parts. Take for example the network below: /

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

ZmnSCPxj writes: > The construction we came up with allows multiple rendezvous nodes, > unlike the HORNET construction that is inherently only a single > rendezvous node. Perhaps the extra flexibility comes with some > security degradation? I don't think this is the case. If I remember correctly

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

naive here, as I am not a mathist and I did not understand > half what you wrote, sorry) > > > > Then at C, we have the onion from D->E, we also know the next ephemeral > key to use (we can derive it since we would pass it to D anyway). > > It rightshifts th

Re: [Lightning-dev] Packet switching via intermediary rendezvous node

Hi ZmnSCPxj, like I mentioned in the other mailing thread we have a minor complication in order get rendez-vous working. If I'm not mistaken it'll not be possible for us to have spontaneous ephemeral key switches while forwarding a payment. Specifically either the sender or the recipient have to

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

Great proposal ZmnSCPxj, but I think I need to raise a small issue with it. While writing up the proposal for rendez-vous I came across a problem with the mechanism I described during the spec meeting: the padding at the rendez-vous point would usually zero-padded and then encrypted in one go with

Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol

Would it be possible to query a command line program or a JSON-RPC call to get the secret? In that case we could add it to the `listpeers` output. On Wed, Nov 7, 2018 at 6:43 AM tock203 wrote: > We implemented the latter scheme. lightning-dissector already supports key > rotation. > FYI, here's

Re: [Lightning-dev] Splicing Proposal: Feedback please!

Olaoluwa Osuntokun writes: >> However personally I do not really see the need to create multiple > channels >> to a single peer, or increase the capacity with a specific peer (via > splice >> or dual-funding). As Christian says in the other mail, this > consideration, >> is that it becomes less

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

Gert-Jaap Glasbergen writes: > Op 1 nov. 2018 om 03:38 heeft Rusty Russell > mailto:ru...@rustcorp.com.au>> het volgende geschreven: >> I believe this would render you inoperable in practice; fees are >> frequently sub-satoshi, so you would fail everything. The entire >> network would have to dr

Re: [Lightning-dev] Splicing Proposal: Feedback please!

ZmnSCPxj via Lightning-dev writes: >> 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 cha

Re: [Lightning-dev] Splicing Proposal: Feedback please!

Olaoluwa Osuntokun writes: > 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

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

8 possible updates, which > should be enough for a while even without reanchoring. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Friday, October 12, 2018 1:37 AM, Christian Decker

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

ct 10, 2018 at 10:25 AM Anthony Towns wrote: > On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote: > > eltoo is a drop-in replacement for the penalty based invalidation > > mechanism that is used today in the Lightning specification. [...] > > Maybe this is obvious

Re: [Lightning-dev] Splicing Proposal: Feedback please!

On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell wrote: > > * Once we have enough confirmations we merge the channels (either > > automatically or with the next channel update). A new commitment tx is > > being created which now spends each output of each of the two funding tx > > and assigns the ch

Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity

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.

Re: [Lightning-dev] W3C Web Payments Working Group / Payment Request API

://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March.txt > Christian Decker is a member. Which I think would be awesome! > > They have just released their candidate recommendation for a payment API > at: https://www.w3.org/TR/payment-request/ According to their site the > pr

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

Corné Plooy via Lightning-dev writes: >> Aside from that, spontaneous payments is amongst the most request feature >> request I get from users and developers. > > A while ago I realized that spontaneous payments (without proof of > payment, mostly for donations only) can be realized quite easily i

Re: [Lightning-dev] Arbitrary Bitcoin Contracts over LN

Thanks for the excellent writeup ZmnSCPxj, I just have a minor issue with your characterization that LN-penalty is to be preferred. My issue is with the fact that CLTV-branches and nLocktimed spending transactions also need to be guarded with a further `OP_CSV` condition, since they may leak on-ch

Re: [Lightning-dev] Measuring Lightning Nodes

Hi Alex, could you elaborate what you mean by measuring lightning nodes? For example are you interested in the network topology, or monitoring a single node? Or maybe you are interested in the successrate of payments performed on the network? There are a lot of things one can monitor/measure :-)

Re: [Lightning-dev] Lack of capacity field in channel_announcement makes life difficult. Why is it not there?

or successful routing, i think the channel_update-approach is > much more of a boost. > > Regards, > Robert > > > On Sun, Jul 29, 2018 at 4:59 PM, Christian Decker > wrote: >> >> Robert Olsson writes: >> > I think however it would be much better

Re: [Lightning-dev] Lack of capacity field in channel_announcement makes life difficult. Why is it not there?

Robert Olsson writes: > I think however it would be much better and flexible to append a max to > channel_update. We already have htlc_minimum_msat there and could add > htlc_maximum_msat to show capacity (minus fees) > Like this: > > >1. type: 258 (channel_update) >2. data: > - [64:

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

ZmnSCPxj via Lightning-dev writes: > For myself, I think, for old nodes, it should just appear as a > "normal" close followed by a "normal" open. That's exactly what they should look like, since the channel is being closed with the existing protocol and opened (possibly with a slightly different

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Gregory Maxwell writes: > I know it seems kind of silly, but I think it's somewhat important > that the formal name of this flag is something like > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially > insecure for traditional app

Re: [Lightning-dev] [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

"David A. Harding" writes: > I finished a re-read of y'alls excellent paper describing Eltoo, and > there was something that confused me: > >> If the update transaction represents the last agreed upon state it can >> use relatively low fees being certain that it will not be replaced. > > I don't

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Anthony Towns writes: > On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote: >> > The big concern I have with _NOINPUT is that it has a huge failure >> > case: if you use the same key for multiple inputs and sign one of them >> > with _NOINPUT, you've spent all of them. The current prop

Re: [Lightning-dev] BIP sighash_noinput

Given the general enthusiasm, and lack of major criticism, for the `SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent BIP editors) to be assigned a BIP number. I have hacked together a simple implementation of the hashing implementation in Bitcoin Core [1] though I think it's

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Carsten Otto writes: > the paper is a bit confusing regarding the setup transaction, as it is > not described formally. There also seems to be a mixup of "setup > transaction" and "funding transaction", also named T_{u,0} without > showing it in the diagrams. The setup transaction is simply a tra

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

ZmnSCPxj writes: > Ha, no, looking at the detailed `SIGHASH_NOINPUT` spec, `hashPrevouts`, which > normally commits to the other inputs, is blanked, so we do not commit to them > either. This means that `SIGHASH_NOINPUT` implicitly has a > `SIGHASH_ANYONECANPAY`. > > (the BIP `SIGHASH_NOINPUT`

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Excellent summary ZmnSCPxj, I'll try to address the points inline (if there is anything to add that is): ZmnSCPxj writes: > Hi Christian, > > Let me know if I have summarized the paper accurately below: > > 1. SIGHASH_NOINPUT removes all inputs of the transaction copy before > signing/verify

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

ZmnSCPxj writes: > Good morning Christian, > > This is very interesting indeed! > > I have started skimming through the paper. > > I am uncertain if the below text is correct? > >> Throughout this paper we will use the terms *input script* to refer to >> `witnessProgram` and `scriptPubKey`, and *

[Lightning-dev] BIP sighash_noinput

Hi all, I'd like to pick up the discussion from a few months ago, and propose a new sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous output. This was previously mentioned on the list by Joseph Poon [1], but was never formally proposed, so I wrote a proposal [2]. We hav

  1   2   >