Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-10-13 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > I think this change may be a bit misguided, and we should be careful about > making sweeping changes to default values like this such as fees. I'm > worried that this post (and the subsequent LGTMs by some developers) > promotes the notion that somehow

[Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-10-10 Thread Rusty Russell
Hi all, I've been looking at the current lightning network fees, and it shows that 2/3 are sitting on the default (1000 msat + 1 ppm). This has two problems: 1. Low fees are now a negative signal: defaults actually indicate lower reliability, and routing gets tarpitted trying them

Re: [Lightning-dev] Quotes for Article on LN Bug Fix

2019-09-28 Thread Rusty Russell
Hi Ed, Sorry for the delay. There's always a tension between safety and disclosure. In this case, the three implementations agreed that it was best to make sure everyone had done a release and ensure there were no problem with upgrades and that the majority of people had upgraded before

[Lightning-dev] Full Disclosure: CVE-2019-12998 / CVE-2019-12999 / CVE-2019-13000

2019-09-27 Thread Rusty Russell
ibes the requirement to wait for confirmations[5]. It did NOT, however, require the receiver to actually check that the transaction is the one promised by the funder: both the amount and the actual scriptpubkey. Discovery - Rusty Russell (Blockstream) discovered this while working on protocol

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

2019-09-05 Thread Rusty Russell
Hi all, The next release of c-lightning will start suppressing gossip which comes too fast. I have implemented a simple filter which allows each message (node_announcement or channel_update) ONCE PER DAY on average, with a burst up to 4 times per day. We will also discard identical

[Lightning-dev] CVEs assigned for lightning projects: please upgrade!

2019-08-30 Thread Rusty Russell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Security issues have been found in various lightning projects which could cause loss of funds. Full details will be released in 4 weeks (2019-09-27), please uprade well before then. Effected releases: CVE-2019-12998 c-lightning < 0.7.1

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-13 Thread Rusty Russell
Ecurrencyhodler Blockchains writes: >1. Bob wants to send me 100,000 sats. >2. My node just came online and has 0 inbound liquidity. >3. I create an invoice for 100,000 sats. My LN node recognizes I have 0 >inbound liquidity so my wallet also embeds my URI in the invoice. >4.

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-08 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: >> > Typical quotes suggested that commodity hardware would take 2 seconds to >> > find a route >>   >> Can you provide a reproducible benchmark or further qualify this number (2 >> seconds)? > > No reproducible benchmark. OK, on my digital ocean 2-cpu 4GB ram

Re: [Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric

2019-07-24 Thread Rusty Russell
Pierre writes: >> > How would bruteforcing on the CSV delay be different from a BIP32 >> > wallet with look ahead keys? Especially given that we could try with >> > most probable values first. >> >> It's a big multiplier, given that CSV can be specified by the >> counterparty. If you accept up

Re: [Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric

2019-07-20 Thread Rusty Russell
Pierre writes: > Hi Rusty, > > How would bruteforcing on the CSV delay be different from a BIP32 > wallet with look ahead keys? Especially given that we could try with > most probable values first. It's a big multiplier, given that CSV can be specified by the counterparty. If you accept up to

[Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric

2019-07-17 Thread Rusty Russell
Hi all, In Adelaide we proposed that CSV delays be symmetric; that the to-self output would be delayed to avoid weird "no, you close!" games. Unfortunately, Roasbeef points out that this undermines the great strength of the option_static_remotekey, which allows a

[Lightning-dev] [PROPOSAL] Gossip protocol v2

2019-07-13 Thread Rusty Russell
Hi all, At the last Summit we discussed using Schnorr sigs for gossip; we'll also need to change things for taproot-based channels, so I think it makes sense to combine the two changes. channel_announcement drops from 430 to 140 (plus feature bitmap). channel_update drops from to 136 to

[Lightning-dev] [RELEASE] c-lightning v0.7.1: The Unfailing Twitter Consensus Algorithm

2019-07-04 Thread Rusty Russell
This is a recommended upgrade! https://github.com/ElementsProject/lightning/releases/tag/v0.7.1 We're pleased to announce c-lightning 0.7.1, named by new C-Lightning Core Team member Lisa Neigut. Highlights for Users o Gossip (both serving to others and

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

2019-03-19 Thread Rusty Russell
es. Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse scenario (as well as the second), I'd be content with that proposal. Future segwit versions may choose to relax it.[1] Cheers, Rusty. [1] Must be consensus, not standardness; my prev suggestion was bogus. Rusty Russel

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

2019-03-19 Thread Rusty Russell
Anthony Towns writes: > If you publish to the blockchain: ... > 4 can be dropped, state 5 and finish can be altered). Since the CSV delay > is chosen by the participants, the above is still a possible scenario > in eltoo, though, and it means there's some risk for someone accepting > bitcoins

Re: [Lightning-dev] [META] Mailing list move

2019-03-18 Thread Rusty Russell
nSCPxj > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, March 16, 2019 12:45 PM, Rusty Russell > wrote: > > > Hi all, > > > > Linux Foundation (who graciously host this list for us) is > > deprecating their mailing list

[Lightning-dev] [META] Mailing list move

2019-03-15 Thread Rusty Russell
Hi all, Linux Foundation (who graciously host this list for us) is deprecating their mailing list infrastructure (mailman2 is unmaintained, apparently v3 is a mess), and migrating lists to groups.io. Apparently this is the direction that bitcoin-dev is heading. Unless people raise

[Lightning-dev] [RFC] option_static_remotekey

2019-03-14 Thread Rusty Russell
e for HTLC outputs). This is a much simpler stepping stone, and resolves one immediate problem. Suggested-by: @roasbeef Signed-off-by: Rusty Russell diff --git a/.aspell.en.pws b/.aspell.en.pws index b1a1ad3..20664f2 100644 --- a/.aspell.en.pws +++ b/.aspell.en.pws @@ -33

[Lightning-dev] [RELEASE] c-lightning v0.7.0: "Actually an Altcoin"

2019-03-01 Thread Rusty Russell
We're pleased to announce c-lightning 0.7, named by Mark Beckwith. https://github.com/ElementsProject/lightning/releases/tag/v0.7.0 Highlights for Users * Plugins are here, with frameworks for C, Python and Go! Write your own cool extensions! * Much better pay

Re: [Lightning-dev] Payee pay fee

2019-02-25 Thread Rusty Russell
ZmnSCPxj writes: > Might it be possible to use SURBs as in the other thread? It's possible, but you still don't want it for all the same reasons: you have a nicely anonymized path you know works, so why use something else? Cheers, Rusty. ___

Re: [Lightning-dev] Payee pay fee

2019-02-24 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > >> So we need a web way of asking a client to send an invoice or offer over >> HTTPS. Is this a new URI scheme? How would this work? > > I thought that offers would work over LN alone? > > When you first proposed the offers, I thought it was this way: > >

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

2019-02-21 Thread Rusty Russell
Subnote on this, there's a query on TLV format (1 byte type, 1 byte+ len). 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.

Re: [Lightning-dev] Payee pay fee

2019-02-21 Thread Rusty Russell
Cezary Dziemian writes: > Thanks for answer ZMNSCPxj, > > Sad to hear that you have anything non LN-related to do that has higher > priority. > > What, can't this this be done in easier way? For example: I've been thinking about this as 'the yalls problem'. But it is has similarities to

Re: [Lightning-dev] SURBs as a Solution for Protocol-Level Payment ACKs

2019-02-18 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi y'all, > > Recently we've started to do more design work related to the Sphinx packet > (EOB format, rendezvous protocol). This prompted me to re-visit the original > Sphinx paper to refresh my memory w.r.t some of the finer details of the > protocol. While I was

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

2019-02-18 Thread Rusty Russell
ning inventory messages for channel_update messages. > > Cheers, > > Fabrice > > > > On Wed, 9 Jan 2019 at 00:44, Rusty Russell wrote: >> >> Fabrice Drouin writes: >> > I think there may even be a simpler case where not replacing updates >> >

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

2019-02-12 Thread Rusty Russell
Matt Corallo writes: >>> Thus, even if you imagine a steady-state mempool growth, unless the >>> "near the top of the mempool" criteria is "near the top of the next >>> block" (which is obviously *not* incentive-compatible) >> >> I was defining "top of mempool" as "in the first 4 MSipa", ie.

[Lightning-dev] WIP pull requests for feature bit unification and TLV bits

2019-02-12 Thread Rusty Russell
Hi all, Finally tried to write up the feature bit changes: https://github.com/lightningnetwork/lightning-rfc/pull/571 And also start on TLV definition for the onion: https://github.com/lightningnetwork/lightning-rfc/pull/572 Feature bits: - 1. Rename

Re: [Lightning-dev] Unification of feature bits?

2019-01-26 Thread Rusty Russell
Fabrice Drouin writes: > On Mon, 21 Jan 2019 at 08:05, Rusty Russell wrote: >> >> Hi all, >> >> I have a concrete proposal for feature bits. >> >> 1. Rename 'local features' to 'peer features'. >> 2. Rename 'global features' to 'routing featur

Re: [Lightning-dev] Mandatory "d" or "h" UX issues

2019-01-20 Thread Rusty Russell
Francis Pouliot writes: > Here is how I picture the ux issues taking place. > >1. User goes on my app to buy Bitcoin with fiat, and opts to be paid out >via LN rather than on-chain BTC. >2. My app will tell him: "make an invoice with the following: msatoshi, >description. >3.

[Lightning-dev] Unification of feature bits?

2019-01-20 Thread Rusty Russell
Hi all, I have a concrete proposal for feature bits. 1. Rename 'local features' to 'peer features'. 2. Rename 'global features' to 'routing features'. 3. Have them share a number space (ie. peer and routing features don't overlap). 4. Put both in `features` in node announcements, but

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

2019-01-08 Thread Rusty Russell
Christian Decker writes: > Assume that we have a network in which a node D receives the updates > from a node A through two or more separate paths: > > A --- B --- D > \--- C ---/ > > And let's assume that some channel of A (c_A) is flapping (not the ones > to B and C). A will send out two

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

2019-01-08 Thread Rusty Russell
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] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

2019-01-07 Thread Rusty Russell
Matt Corallo writes: > Ultimately, defining a "near the top of the mempool" criteria is fraught > with issues. While it's probably OK for the original problem (large > batched transactions where you don't want a single counterparty to > prevent confirmation), lightning's requirements are very

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-07 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: > HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across > Assets, or, An Argument For Single-Asset Lightning Network Interesting. FWIW, I believe that multi-asset LN will fail for a related, but different reason: to prevent long-lived

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

2019-01-07 Thread Rusty Russell
Fabrice Drouin writes: > Follow-up: here's more detailed info on the data I collected and > potential savings we could achieve: > > I made hourly routing table backups for 12 days, and collected routing > information for 17 000 channel ids. > > There are 130 000 different channel updates :on

[Lightning-dev] Minisketch and lightning gossip

2018-12-12 Thread Rusty Russell
Hi all, In case you're bored with the limited range of improvements going into the 1.1 spec, you might like to ruminate on: https://github.com/sipa/minisketch/blob/master/README.md It's a library for efficient summaries of data, such as bitcoin transaction gossip. It has an

Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort

2018-12-11 Thread Rusty Russell
Matt Corallo writes: > Any update on this? It seems like the people who bothered to respond > were pretty in favor of not using calls (and, at least based on the > latest call doc, which is the only one I've seen, they seem to be only > somewhat sparsely attended). We always have a

[Lightning-dev] Spec Meeting: Tuesday, January 8, 2019 at 19:00:00 UTC (~1hr)

2018-12-10 Thread Rusty Russell
Hi all, As agreed at last spec meeting, the next will be held on IRC: freenode, #lightning-dev. Since that would be Christmas Eve[1], I deferred it to January[2]. All are welcome! The rough ground rules are as follows: 1. I post the agenda to the index about 12 hours prior:

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

2018-12-05 Thread Rusty Russell
Christian Decker writes: > 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 at

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

2018-12-04 Thread Rusty Russell
Corné Plooy via Lightning-dev writes: > For instance, the attacking intermediate node might guess that the next > node in the route is the final node; it can test this by completely > replacing the onion packet it sends to the next node with a self-written > onion packet that has the next hop as

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

2018-12-03 Thread Rusty Russell
Matt Corallo writes: > As an alternative proposal, at various points there have been > discussions around solving the "RBF-pinning" problem by allowing > transactors to mark their transactions as "likely-to-be-RBF'ed", which > could enable a relay policy where children of such transactions

Re: [Lightning-dev] Dual Funding Proposal

2018-12-03 Thread Rusty Russell
lisa neigut writes: >> The receiving node MUST fail the channel if: >>... >>- `option_dual_fund` has been negotiated. >> > > Does v2 of channel open necessarily deprecate the original between two > upgraded nodes? > > This seems more sane than having both as an option...will update. Yes.

Re: [Lightning-dev] Base AMP

2018-12-02 Thread Rusty Russell
ZmnSCPxj writes: > But what if 2 of those paths fail? > It would be better to merge them into a single payment along the expensive > 4th path. > However, the remaining succeeding path has already given `numpaths`=3. > > Using `numpaths` overcommits to what you will do in the future, and is >

Re: [Lightning-dev] Funds locked in channel and MAX_HTLC

2018-12-02 Thread Rusty Russell
Cezary Dziemian writes: > Hello guys, > > I red BOLT. Do I understand correctly, that max_accepted_htlcs means that > for single channel there is possibility to have such amount of transactions > pending at the same time? Yes. - if result would be offering more than the remote's

Re: [Lightning-dev] Dual Funding Proposal

2018-12-02 Thread Rusty Russell
ZmnSCPxj writes: >> 128-bit seed in >> open_channel2 could be added, with sorting by SHA(seed | > input> | ) and SHA(seed | )? > > `open_channel2` contains a good amount of entropy --- temporary channel ID, > various basepoints. > Would not hashing `open_channel2` to get this `seed` be

Re: [Lightning-dev] Dual Funding Proposal

2018-11-29 Thread Rusty Russell
lisa neigut writes: > Hello fellow Lightning devs! > > What follows is a draft for the new dual funding flow. Note that the > `option_will_fund_for_food` specification has been omitted for this draft. Hi! Wow, my mailer really mangled this! I've liberally demangled below as I quote. The

Re: [Lightning-dev] Dual Funding Proposal

2018-11-29 Thread Rusty Russell
lisa neigut writes: >> * [`2`:`scriptlen`] >> >> * [`scriptlen`:`script`] >> >> * [`2`:`max_extra_witness_len`] >> >> * [`2`:`wscriptlen`] >> >> * [`wscriptlen`:`wscript`] >> >> >> `script` here is the `scriptPubKey`? This is needed for `hashPrevouts` in >> BIP143 I believe. >> >> What is

Re: [Lightning-dev] Base AMP

2018-11-29 Thread Rusty Russell
ZmnSCPxj writes: > Good morning all, > >> I initially suggested we could just have a 2-byte "number of total >> pieces", but it turns out there's a use-case where that doesn't work >> well: splitting the bill. There each payer is unrelated, so doesn't >> know how the others are paying. > > This

Re: [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment)

2018-11-28 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > >> There's a kinda-neat intersection between the "use TLV" proposal and the >> "multi-cell-onion" idea, so I want to make a concrete proposal (wording >> needs formalization): >> >> Multi-cell structure: >> >> 1. `realm` (or `per_hop_type` if you prefer)

Re: [Lightning-dev] Approximate assignment of option names: please fix!

2018-11-27 Thread Rusty Russell
Corné Plooy via Lightning-dev writes: > The only reasons I see for keeping the global/local distinction is that > you might not want to gossip everything, either to keep the gossip data > small, or for some privacy reasons. Apparently, that's all very > theoretical so far, as current features

[Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment)

2018-11-27 Thread Rusty Russell
There's a kinda-neat intersection between the "use TLV" proposal and the "multi-cell-onion" idea, so I want to make a concrete proposal (wording needs formalization): Multi-cell structure: 1. `realm` (or `per_hop_type` if you prefer) meaning expanded. 2. Lower 4 bits is `num_extra_cells` to use

Re: [Lightning-dev] Base AMP

2018-11-27 Thread Rusty Russell
Johan Torås Halseth writes: > (excuse me for not yet understanding what this extra complexity gives us) > > To summarize: My suggestion was to only add an optional field to the > invoice, and let the recepient wait until all funds have received before > pulling the payment. No changes to the

[Lightning-dev] [META] Organization of 1.1 Spec Effort

2018-11-26 Thread Rusty Russell
Hi all, As you may know, for 1.0 spec we had a biweekly Google Hangout, at 5:30am Adelaide time (Monday 19:00 UTC, or 20:00 UTC Q3/4). You can see the minutes of all meetings here: https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco The current

Re: [Lightning-dev] lookupinvoice

2018-11-25 Thread Rusty Russell
Sarat G writes: > Hi, > > I'm been working on the LN repo for a while now. I would like to know if > there is any way that a payee can lookup the invoice it gets paid, i.e > similar to the 'lookupinvoice' command as provided by the lnd(Golang). Hi Sarat, I'm confused; "the LN repo" is

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-25 Thread Rusty Russell
Matt Corallo writes: > Hmm, are we willing to consider CLTV sufficient? In case you have two > HTLCs, one of medium-small value that has a low CLTV and one of high > value that has a higher CLTV, you could potentially use the soon-CLTV to > delay the commitment transaction somewhat further if

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-22 Thread Rusty Russell
Matt Corallo writes: > Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(. OK, let's walk through this: Locally offered HTLC: - Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay. Remote offered HTLC: - Local HTLC-Success tx can be done without

Re: [Lightning-dev] Base AMP

2018-11-22 Thread Rusty Russell
Conner Fromknecht writes: > Hi all, > >> But it's unnecessary for the recipient to know the total amount I meant >> to pay; they just need to return the receipt once it exceeds the amount >> they want. > > I think it’s true that the recipient doesn’t need to know necessarily, but > sending the

Re: [Lightning-dev] Splicing Proposal: Now with RBF

2018-11-22 Thread Rusty Russell
lisa neigut writes: > Hello Rusty. Exciting stuff! A few observations: > > On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell > wrote: > >> ### Confirming a splice: `splice_confirm` >> >> 1. type: 43 (`splice_confirm`) (`option_splice`) >> 2. data: &

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-21 Thread Rusty Russell
otherwise those transactions could >> count as the carve-out tx). >> >> Matt >> >> On 11/21/18 2:17 AM, Rusty Russell wrote: >>> I'm also starting to implement this, to see what I missed! >>> >>> Original at https://github.com/lightningnetwor

Re: [Lightning-dev] Base AMP

2018-11-21 Thread Rusty Russell
Johan Torås Halseth writes: > Seems like we can restrict the changes to BOLT11 by having the receiver > assume NAMP for incoming payments < invoice_amount. (with some timeout of > course, but that would need to be the case even when the sender is > signalling NAMP). This would effectively become

Re: [Lightning-dev] Base AMP

2018-11-21 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > >> And do not play with `amount_to_forward`, as it's an important >> signal to the final node that the previous node did not offer less value >> for the HTLC than it was supposed to. (You could steal the top bit to >> signal partial payment if you really

[Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-20 Thread Rusty Russell
output; you may sweep for others. Signed-off-by: Rusty Russell diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 7cf9ebf..6ec1155 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -133,7 +133,9 @@ node can offer. (i.e. 1/4 the more normally-used 'satoshi per 1000 vbytes

Re: [Lightning-dev] Base AMP

2018-11-20 Thread Rusty Russell
René Pickhardt via Lightning-dev writes: > Hey List, > > as this base AMP proposal seems pretty small I just started to write this > up to make a PR for BOLT04 and BOLT11. While doing my write up I realize > that there are smaller things that I would want to verify / double check > and propose

Re: [Lightning-dev] Invoice Address Format

2018-11-20 Thread Rusty Russell
Varunram Ganesh writes: > Now, I am no expert on error encoding formats, but I think that bech32 is > under optimised for invoices (whose lengths are greater than 71). Related to > this, is there a reason why we use hex encoded pubkeys in lightning? Unless > I'm missing something, I think

Re: [Lightning-dev] Forwarding hints in channel update messages

2018-11-19 Thread Rusty Russell
Joost Jager writes: > On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell wrote: > >> The decision was made to allow additional channel_update in the error >> reply: >> >> DECISION: document that scid is not binding, allow extra >> channel_updates i

Re: [Lightning-dev] RBF and dual-fund interactions

2018-11-19 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: > This is potentially an attack vector (although I suppose we could consider > simply ignoring edge-case attack vectors). > Since the second customer pays the fees and designates its own inputs, it can > gather all its dust, then give a very low fee, creating

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-17 Thread Rusty Russell
René Pickhardt writes: > Dear Rusty, > > I am not getting this proposal (maybe I am lacking some technical basic > understandings) however I decided to ask more questions in order to > complete my onboarding process faster and hope this is fine. > > My problem starts with the fact that I can't

[Lightning-dev] Splicing Proposal: Now with RBF

2018-11-16 Thread Rusty Russell
Hi all, I tried to simplify RBF as much as possible; it adds a *lot* of complexity :( In particular, below we have one side pay the fees (and thus responsible for RBF), in violation of the summit agreement, and simplified the fee amount as much as reasonable. RBF it implicitly requires multiple

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

2018-11-15 Thread Rusty Russell
Conner Fromknecht writes: > Hi ZmnSCPxj, > > Thanks for writing this up! I had started an email, but you beat me to it :) > >> 1. For a sequence of `type,len,value`, each `type` must be unique. -- >> accepted. > > To add to this, it seemed that there was some agreement that repeated fields >

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-15 Thread Rusty Russell
ZmnSCPxj writes: >> I apologize that this wasn't fleshed out before the summit, but I >> overestimated the power of Scriptless Scripts so had mentally deferred >> this. > > My understanding is that SS *is* as powerful as we thought, at least for some > of the applications we were hoping to use

[Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-14 Thread Rusty Russell
Hi all, I want to propose a method of having reusable BOLT11 "offers" which provide almost-spontaneous payments as well as not requiring generating a BOLT11 invoice for each potential sale. An "offer" has a `p` field of 26 bytes (128 bits assuming top two are 0) (which is ignored by existing

Re: [Lightning-dev] Forwarding hints in channel update messages

2018-11-14 Thread Rusty Russell
Joost Jager writes: > Hello all, > > I'd like to bring up an idea that builds on top of "non-strict" forwarding. > I commented about this on conner's non-strict forwarding lightning-rfc pr, > but it is probably better to discuss it on its own in this list. The decision was made to allow

Re: [Lightning-dev] Approximate assignment of option names: please fix!

2018-11-13 Thread Rusty Russell
Pierre writes: > Hi Rusty, > >>The feature masks are split into local features (which only >>affect the protocol between these two nodes) and global features >>(which can affect HTLCs and are thus also advertised to other >>nodes). > > I don't think that definition

Re: [Lightning-dev] Wumbological local AND global features

2018-11-13 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: > Thus, I propose: > > * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the > node is willing to wumbo with its counterparty in the connection. > * The global feature bit `option_anyone_can_wumbo`, which indicates that the > node is

[Lightning-dev] Approximate assignment of option names: please fix!

2018-11-12 Thread Rusty Russell
Hi all, I went through the wiki and made up option names (not yet numbers, that comes next). I re-read our description of global vs local bits: The feature masks are split into local features (which only affect the protocol between these two nodes) and global features

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

2018-11-06 Thread Rusty Russell
Olaoluwa Osuntokun writes: >> Mainly limitations of our descriptor language, TBH. > > I don't follow...so it's a size issue? Or wanting to avoid "repeated" > fields? Not that smart: tools/extract-formats.py extracts descriptions from the spec for each message. It currently requires constants in

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-11-05 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > I'm a big fan in general of most of this! Amongst many other things, it'll: > simplify the whole static channel backup + recovery workflow, and avoid all > the fee related headaches we've run into over the past few months. I certainly hope so! >> -

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Rusty Russell
Anthony Towns writes: > FWIW, I don't see reddit as a particularly viable "court"; there's > no way for reddit to tell who's actually right in a dispute, eg if I > say blockstream didn't send stickers I paid for, and blockstream says > they did; ie there's no need for a sock puppet in the above

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty and aj and list, > >> >> > > In the payer-supplied data case, I think 'm' should include a signature >> > > for a key only the payer knows: this lets them prove they made the >> > > payment. >> > >> > I don't object to that, but I think it's unnecessary; as

Re: [Lightning-dev] Proposal for rendez-vous routing

2018-11-04 Thread Rusty Russell
CJP writes: >> Looking through BOLT 4, the text assumes inherently that source >> routing is done, and even has a shared secret between hop and >> source.  However, it may be possible in rendezvous routing to simply >> provide the blinding key (while hiding everything beyond the first >> hop on

Re: [Lightning-dev] Proposal for "local" channel announcements.

2018-11-03 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > > To clarify, it seems the below: > > 1. There is a "private" node, one whose channels are all non-published. > 2. There is a public node who knows that everything that passes through the > channel with the "private" node comes only from the "private"

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-03 Thread Rusty Russell
Anthony Towns writes: >> > - channel announcements: do you support secp256k1 for hashes or just >> >sha256? >> Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support >> secp256k1 with Schnorr". You need a continuous path of channels with >> the same feature. > > I don't

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-02 Thread Rusty Russell
Anthony Towns writes: > On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote: >> There's been some discussion of what the lightning payment flow >> might look like in the future, and I thought I'd try to look forwards so >> we can avoid painting ourselves

[Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-02 Thread Rusty Russell
Hi all, There's been some discussion of what the lightning payment flow might look like in the future, and I thought I'd try to look forwards so we can avoid painting ourselves into a corner now. I haven't spent time on concrete design and implementation to be sure this is correct,

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

2018-11-01 Thread Rusty Russell
Gert-Jaap Glasbergen writes: > As for htlc_minimum_msat I would not feel good about it being dropped. > It is the only protection measure I saw in the standard against > producing trimmed HTLCs. In my view the safe default is to set it above > the dust limit to avoid it to get trimmed, and

[Lightning-dev] Proposal for "local" channel announcements.

2018-11-01 Thread Rusty Russell
I'm not sure if this is too large a hammer for a small problem, but I thought it worth writing up. Currently, a node with only private channels loses deniability of payments; if you have an unannounced channel with me, I can be fairly sure any payment I see coming from that channel is from you

[Lightning-dev] [RELEASE] c-lightning 0.6.2: The Consensus Loving Nasal Daemon

2018-10-27 Thread Rusty Russell
We're pleased to announce c-lightning 0.6.2, named by @practicalswift. https://github.com/ElementsProject/lightning/releases/tag/v0.6.2 OR https://launchpad.net/~cdecker/+archive/ubuntu/clightning (SOON) We HIGHLY RECOMMEND you upgrade to this release NOW; it will improve overall network health!

Re: [Lightning-dev] [RELEASE] c-lightning 0.6.2: The Consensus Loving Nasal Daemon

2018-10-27 Thread Rusty Russell
Rusty Russell writes: > We're pleased to announce c-lightning 0.6.2, named by @practicalswift. > > https://github.com/ElementsProject/lightning/releases/tag/v0.6.2 > OR https://launchpad.net/~cdecker/+archive/ubuntu/clightning (SOON) Sorry, https://launchpad.net/~lightningnetwork/+ar

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

2018-10-24 Thread Rusty Russell
Conner Fromknecht writes: > In light of this, and if I'm following along, it seems our hand is forced in > splicing via a single on-chain transaction. In my book, this is preferable > anyway. I'd much rather push complexity off-chain than having to do a > mutli-stage splicing pipeline. Agreed.

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-23 Thread Rusty Russell
Jim Posen writes: > Instead of leaving an extra output for CPFP, is it not sufficient to just > sign all inputs with ANYONECANPAY and expect the sender to make an exact > output for the fees input? It would require an extra tx assuming they don't > already have a properly sized UTXO handy (which

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-19 Thread Rusty Russell
Fabrice Drouin writes: > Hello, > >> 1. Rather than trying to agree on what fees will be in the future, we > > should use an OP_TRUE-style output to allow CPFP (Roasbeef) > > We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without > adding the "OP_TRUE" output to the

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

2018-10-16 Thread Rusty Russell
Hi all, Everywhere in the protocol where we negotiate, we've had problems: what do you do if you can't agree? In most cases, we've settled on defacto generally-accepted values which aren't mentioned anywhere in the spec (I've skimmed codebases below, looked at defaults). I'd like to

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

2018-10-16 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > Happy to get the splicing train rolling! > >> We've had increasing numbers of c-lightning users get upset they can't >> open multiple channels, so I guess we're most motivated to allow splicing > of >> existing channels > > Splicing isn't a substitute

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

2018-10-16 Thread Rusty Russell
Rusty Russell writes: > If we're going to do side splice-in like this, I would use a very > different protocol: the reason for this protocol was to treat splice-in > and splice-out the same, and inline splice-in requires wait time. Since > splice-out doesn't, we don't need

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-12 Thread Rusty Russell
ZmnSCPxj writes: > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Friday, October 12, 2018 2:36 PM, Rusty Russell > wrote: > >> ZmnSCPxj zmnsc...@protonmail.com writes: >> >> > Good morning Rusty and list, >> > >

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-12 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty and list, > >> >> 1. Rather than trying to agree on what fees will be in the future, we >> should use an OP_TRUE-style output to allow CPFP (Roasbeef) >> > > My understanding is that this would require some base-layer changes at > Bitcoin level first?

[Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-11 Thread Rusty Russell
Hi all, There have been a number of suggested changes to the commitment transaction format: 1. Rather than trying to agree on what fees will be in the future, we should use an OP_TRUE-style output to allow CPFP (Roasbeef) 2. The `remotepubkey` should be a BIP-32-style, to avoid the

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

2018-10-11 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > > In BOLT #2 we currently impose a 2^24 satoshi limit on total channel > capacity. Is splicing intended to allow violation of this limit? I do not > see it mentioned in the proposal. Can I splice 21 million bitcoins on a > 1-satoshi channel? Good

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

2018-10-11 Thread Rusty Russell
Christian Decker writes: > 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 spen

[Lightning-dev] Splicing Proposal: Feedback please!

2018-10-09 Thread Rusty Russell
Hi all! We've had increasing numbers of c-lightning users get upset they can't open multiple channels, so I guess we're most motivated to allow splicing of existing channels. Hence this rough proposal. For simplicity, I've chosen to only allow a single splice at a time. It's still

  1   2   >