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

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

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

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.

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

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

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

: > 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-state equates to loss-of-f

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

[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

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

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 >

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.

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 >>

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: [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

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

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

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

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

[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

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

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

[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

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 >

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

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

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

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

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,

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

[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

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

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

[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

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

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

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

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

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.

[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

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

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

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

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

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

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"

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

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

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

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] 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

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

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

sible 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

, 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, but

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

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

inuxfoundation.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 > proposed

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

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] 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

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

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

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`

[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

Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

ZmnSCPxj via Lightning-dev writes: > Good morning Alejandro, > > I was about to ask Christian this myself. > > There is another technique: > > Use a sequence of `nSequence`d transactions off-chain. For example, > to get an 2-bit counter, you would have:

Re: [Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out

ZmnSCPxj via Lightning-dev writes: > Suppose, rather than implement a splice-in/splice-out ("channel > top-up", etc.) we instead implement a more general "cut-through" for a > channel close transaction. > > Normally a channel close spends a single input

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

ZmnSCPxj writes: >> This also allows domain operators to have one or more public nodes, >> but many private ones with channels open to their public nodes to >> better manage their risk. For example, the private nodes could be >> behind a firewall. > > I am not sure how

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Tyler, thanks for the detailed feedback, I'll try to address some of the issues inline: Tyler H writes: > --Regarding looking up nodes at the time of payments: > > In the future, nodes could negotiate a channel open with a push amount and > provide the TXID or payment hash as

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Hi Tyler, Hi Robert, first of all, welcome to the mailing list, always good to have more people looking and improving the spec. I quickly read through the spec and it is very well written, and it looks good. On a conceptual level, I do however have some issues with the proposal. I don't think

Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

ZmnSCPxj via Lightning-dev writes: > In a retaliation construction, if a party misbehaves, the other party gets > the entire amount they are working on together, as disincentive for any party > to cheat. > > That works for the two-party case A and B. If

Re: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain?

Dear Mahesh, as interesting as the discussion of alternative blockchain storage it, it is probably off-topic for the Lightning mailing list. So I'd suggest taking this discussion to either the bitcoin-dev or bitcoin-core-dev mailing lists. Cheers, Christian Mahesh Govind

Re: [Lightning-dev] Lightning network implementation with ethereum

Dear Mahesh, that's a very interesting question, to be best of my knowledge there is no working implementation for Ethereum and I don't think anybody is working on one currently. There is the Raiden network attempt at porting a Lightning-like network to Ethereum, but I'm not sure what the current

Re: [Lightning-dev] DNS Seed query semantics clarification

Thomas Steenholdt writes: > Thanks for the explanation - This was exactly the the piece of the > puzzle I was missing.  > > I'd be happy to help clarify this in the BOLT10 specification, if that > makes any type of sense? I can make a pull request for

Re: [Lightning-dev] DNS Seed query semantics clarification

Hi Thomas, indeed the spec is a bit vague on the flags. The intent is to use them as subdomains. For example if you want to query for only realm IPv4 nodes then you'd use the following: dig a2.seed.bitcoinstats.com while IPv4 or IPv6 nodes, but only nodes with realm 0, should be returned to

Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?

chain one > could at least use that measure to warn people before opening and funding > another payment channel with a node that is heavily underfunded. Also in > the sense of network topology such a measure would probably make sure that > channels are somewhat equally funded. > >

Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?

Hi René, very good question. I think the simple answer is that this is exactly the reason why not having a participant in the network that can 51% attack over a prolonged period is one of the base assumptions in Lightning. These attacks are deadly to all blockchains, and we are certainly no

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

Jim Posen writes: > If using two hashes to deliver the payment while still getting a proof, I'm > not sure what that provides above just sending regular lightning payments > over multiple routes with one hash. Firstly, if there is a second hash, it > would presumably be the

Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

I'd also like to point out that the way we do state invalidations in Lightning is not really suited for multi-party negotiations beyond 2 parties. The number of potential reactions to a party cheating grows exponentially in the number of parties in the contract, which is the reason the Channel

Re: [Lightning-dev] Manual channel funding

Hi Alex, not sure what the context of your question. It doesn't appear to be protocol related, but rather an issue with the interface that the implementations expose. If that is the case, I'd suggest filing an issue with the respective implementation. Cheers, Christian Alex P

[Lightning-dev] Improving the initial gossip sync

Hi everyone When we started drafting the specification we decided to postpone the topology syncronization mechanism until we have a better picture of the kind of loads that are to be expected in the network, e.g., churn and update rate, and instead implement a trivial gossip protocol to

Re: [Lightning-dev] How to use LN

v e writes: > Will do as you suggested. one another question, when you say customers do > you mean end clients who are buying goods and services? Yes, they'll need to have clients that understand the Lightning protocol just like anyone else in the network. > Also i am

Re: [Lightning-dev] How to use LN

Hi v e, in order to use Lightning Charge you will need the following: - A full bitcoind node sync'd with the network - A c-lightning node - npm + lightgning-charge running to give you access to the REST API We currently do not have (and may never have) bindings for bitcoinj. Re invoices:

Re: [Lightning-dev] negative fees for HTLC relay

Mark Friedenbach writes: > It is not the case that all instances where you might have negative > fees would have loops. If we don't have a cycle we can hardly talk about rebalancing channels. At that point you're paying for someone else's payment to go through your

Re: [Lightning-dev] negative fees for HTLC relay

Benjamin Mord writes: > It isn't obvious to me from the BOLTs if fees can be negative, and I'm > finding uint in the go source code - which suggests not. In scenarios where > the funding of a payment channel has been fully committed in one direction, > why not allow negative fees to

Re: [Lightning-dev] Descriptive annotations visible to intermediate nodes

ed so far by how cleanly and explicitly the BOLTs address > extensibility. I find that reassuring, many thanks to whoever applied their > technical creativity to this aspect. > > Was there a BOLT #6? > > On Thu, Jan 4, 2018 at 12:13 PM, Christian Decker < > decker.christ...@gma

  1   2   >