[Lightning-dev] Integration testing between implementations

2017-08-10 Thread Christian Decker
I think it's safe to say that the protocol is now in feature freeze for version v1.0 and we are limiting changes to bug fixes and clarifications. In order to locate things that we might have interpreted differently and show how far we are when it comes to interoperability I've been testing the

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 >

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

2017-12-15 Thread Christian Decker
t need to > monitor the blockchain for anything. I will just believe that > Blockstream will do no bad to me. > > Why do I need to drink unnamed cola if there is Pepsi?)) People used > to run emails servers, it is all Gmail now, much more secure and > reliable! > &g

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] General question on routing difficulties

2017-11-17 Thread Christian Decker
On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord wrote: > Ivan, > > That is mostly false, but with bits of truth sprinkled in. Contact me at > b...@mord.io for further discussion so we tread lightly on the lists' > email inboxes. > I think this is exactly the right venue to discuss

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

2017-11-17 Thread Christian Decker
f interest to lightning. It is hard to > imagine it would be a new idea, although I have not yet found the precedent: > http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html > > Thanks, > Ben > > > On Nov 17, 2017 8:04 AM, "Christian Decker&quo

Re: [Lightning-dev] BIP sighash_noinput

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

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] [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

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] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

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] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-04-30 Thread Christian Decker
(cross-posting to bitcoin-dev since this serves as motivation behind the sighash_noinput proposal) > TL;DR: we announce a new, simple, update mechanism for off-chain protocols, > see the announcement [1] and the paper [2] :-) A little over a year ago, the three Lightning Network implementation

[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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Lack of capacity field in channel_announcement makes life difficult. Why is it not there?

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

Re: [Lightning-dev] Measuring Lightning Nodes

2018-07-29 Thread Christian Decker
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] Arbitrary Bitcoin Contracts over LN

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

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] 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] 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] 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] 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] 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-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] 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] 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] Decker-Wattenhofer channels (was: An Idea to Improve Connectivity of the Graph)

2018-04-13 Thread Christian Decker
ZmnSCPxj writes: > Good morning Christian, > > I wonder suddenly, about how HTLCs are offered under > Decker-Wattenhofer Duplex Micropayment Channels. > > Under the Decker-Wattenhofer construction, I believe the transaction > sequence is the below: > > funding -> trigger

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] 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] 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] 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] 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] 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] 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] 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] 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] 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-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] 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] 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] Link-level payment splitting via intermediary rendezvous nodes

2018-11-12 Thread Christian Decker
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] 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] 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] 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] 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] 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] 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] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity

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

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

Re: [Lightning-dev] Base AMP

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

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

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

[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] 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] Eltoo, anyprevout and chaperone signatures

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