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

2021-12-17 Thread Christian Decker
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

2021-12-16 Thread Christian Decker
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

2021-11-23 Thread Christian Decker
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

2021-07-20 Thread Christian Decker
: > 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

2021-07-14 Thread Christian Decker
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

2021-03-15 Thread Christian Decker
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?

2021-02-27 Thread Christian Decker
> 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

2020-10-26 Thread Christian Decker
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

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

2020-10-15 Thread Christian Decker
> 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

2020-10-13 Thread Christian Decker
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

2020-10-13 Thread Christian Decker
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

2020-10-13 Thread Christian Decker
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)

2020-09-22 Thread Christian Decker
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)

2020-09-01 Thread Christian Decker
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

2020-07-29 Thread Christian Decker
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

2020-05-23 Thread Christian Decker
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

2020-03-02 Thread Christian Decker
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

2020-02-24 Thread Christian Decker
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

2020-02-21 Thread Christian Decker
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

2020-02-14 Thread Christian Decker
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

2020-02-04 Thread Christian Decker
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

2020-01-29 Thread Christian Decker
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

2020-01-17 Thread Christian Decker
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

2019-12-04 Thread Christian Decker
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

2019-12-04 Thread Christian Decker
(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

2019-10-03 Thread Christian Decker
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

2019-10-03 Thread Christian Decker
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

2019-10-03 Thread Christian Decker
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

2019-10-01 Thread Christian Decker
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

2019-10-01 Thread Christian Decker
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

2019-09-30 Thread Christian Decker
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

2019-09-19 Thread Christian Decker
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

2019-09-18 Thread Christian Decker
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

2019-09-06 Thread Christian Decker
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

2019-07-14 Thread Christian Decker
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

2019-06-28 Thread Christian Decker
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

2019-05-15 Thread Christian Decker
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

2019-04-04 Thread Christian Decker
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

2019-04-03 Thread Christian Decker
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

2019-04-01 Thread Christian Decker
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

2019-03-14 Thread Christian Decker
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

2019-02-24 Thread Christian Decker
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

2019-02-22 Thread Christian Decker
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

2019-02-18 Thread Christian Decker
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] Extending Associated Data in the Sphinx Packet to Cover All Payment Details

2019-02-08 Thread Christian Decker
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

2019-01-08 Thread Christian Decker
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

2019-01-08 Thread Christian Decker
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

2019-01-02 Thread Christian Decker
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

2018-12-06 Thread Christian Decker
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

2018-12-05 Thread Christian Decker
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

2018-11-29 Thread Christian Decker
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

2018-11-18 Thread Christian Decker
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

2018-11-16 Thread Christian Decker
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

2018-11-15 Thread Christian Decker
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

2018-11-14 Thread Christian Decker
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

2018-11-14 Thread Christian Decker
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

2018-11-12 Thread Christian Decker
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

2018-11-07 Thread Christian Decker
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!

2018-11-06 Thread Christian Decker
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.

2018-11-06 Thread Christian Decker
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!

2018-10-16 Thread Christian Decker
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

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

2018-10-15 Thread Christian Decker
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

2018-10-13 Thread Christian Decker
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-10-11 Thread Christian Decker
, 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!

2018-10-11 Thread Christian Decker
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

2018-08-30 Thread Christian Decker
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

2018-08-27 Thread Christian Decker
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?

2018-07-29 Thread Christian Decker
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

2018-07-03 Thread Christian Decker
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

2018-07-03 Thread Christian Decker
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

2018-05-15 Thread Christian Decker
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

2018-05-03 Thread Christian Decker
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

2018-05-01 Thread Christian Decker
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

2018-04-30 Thread Christian Decker
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

2018-04-11 Thread Christian Decker
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

2018-04-11 Thread Christian Decker
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.

2018-04-11 Thread Christian Decker
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.

2018-04-09 Thread Christian Decker
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.

2018-04-08 Thread Christian Decker
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

2018-04-06 Thread Christian Decker
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?

2018-03-30 Thread Christian Decker
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

2018-03-30 Thread Christian Decker
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

2018-03-19 Thread Christian Decker
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

2018-03-16 Thread Christian Decker
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?

2018-03-13 Thread Christian Decker
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?

2018-03-13 Thread Christian Decker
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] Pinging a route for capacity

2018-03-04 Thread Christian Decker
Rusty Russell writes: > Jim Posen writes: > If failure is common this would be true, but I think it's too early to > design for it. > > This kind of signalling is what fees are for: when capacity gets low you > increase fees, and when it gets high, you

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

2018-02-12 Thread Christian Decker
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

2018-02-05 Thread Christian Decker
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

2018-02-05 Thread Christian Decker
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

2018-02-05 Thread Christian Decker
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

2018-01-20 Thread Christian Decker
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

2018-01-19 Thread Christian Decker
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

2018-01-18 Thread Christian Decker
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

2018-01-17 Thread Christian Decker
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

2018-01-11 Thread Christian Decker
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

Re: [Lightning-dev] General questions about channels

2018-01-01 Thread Christian Decker
Andy Schroder writes: > I understand that you have to be in agreement with your direct peers. So > you don't really care about what agreements others in your route may > have in place? I would think that you would choose not to route through > hops that violate your

Re: [Lightning-dev] Every node must be aware of all other nodes - scalability problem?

2017-12-15 Thread Christian Decker
Welcome to the mailing list Oliver :-) > It seems to me by reading BOLT #7 that every node in the lightning network > must be aware of every other. That is necessary to choose a complete route > to send a transaction for example. Yes, Bolt 7 is a purposefully simplistic gossiping protocol that

Re: [Lightning-dev] Peer Selection

2017-12-15 Thread Christian Decker
Let me add some more color to the discussion. If you do not announce the existence of the channel to the wider network you can still receive incoming payments, by simply telling the payment sender about the channel. This is what is being done in the payment request by adding the `r` parameter to

Re: [Lightning-dev] General question on routing difficulties

2017-11-23 Thread Christian Decker
Thanks Pedro for the paper, I'll read through it as soon as possible and add more feedback :-) I just have some minor points to add regarding your last mail. > The onion-like packets used for *payments* in the current LN > implementations inevitably assume that the sender knows the complete >

  1   2   >