[Lightning-dev] Lightning Developers Biweekly Meeting Announce

2017-07-12 Thread Rusty Russell
Hi all! Every two weeks we've been running an informal Google Hangout for implementers of the Lightning spec; as the spec is starting to freeze, we've decided to formalize it a bit which means opening access to a wider audience. The call is at 20:00 UTC every two weeks on Monday:

[Lightning-dev] [MINUTES] Dev Meeting 2017-07-10

2017-08-07 Thread Rusty Russell
Nothing groundbreaking, but some PRs finally got merged :) https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] BOLT 11, real time micro payments, and route redundancy

2017-09-03 Thread Rusty Russell
Andy Schroder writes: > Hello, > > Yes, it seems as though high frequency payments are not a reality. For > high value products that are delivered quickly, "micro" payments are not > even possible. With my fuel delivery system, the smallest volume of > product that could

[Lightning-dev] [MINUTES] Dev Meeting 2017-11-13

2017-11-14 Thread Rusty Russell
Hi! Sorry I've been slack posting previous minutes, but the good news is we've put them all in one place: https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco/edit#heading=h.8iu8f3dcmgj2 Highlights from 2017-11-13: - Integration tests looking

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

2017-11-29 Thread Rusty Russell
Olaoluwa Osuntokun writes: > (re-sending as doesn't look like my original mail went through to the list?) I increased the limit to 80k now. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] BOLT3: Commitment Transaction Outputs is weak to malleability

2017-11-30 Thread Rusty Russell
Nicolas Dorier writes: > I noticed the Commitment Transaction Output script is weak to malleability, > this can be used to delay confirmation of the revocation. > Luckily, fixing the situation does not require lots of development. Oh, wow! FWIW I'm a bit mindblown by

Re: [Lightning-dev] Section 7 Query: Timestamps & Pruning

2017-12-04 Thread Rusty Russell
Shannon Appelcline writes: > Section 7 says "nodes MAY prune channels should the timestamp of the > latest `channel_update` be older than 2 weeks (1209600 seconds)" > > Yet timestamps are only required to be sequential, not an actual > timestamp ("The creating node MUST set

Re: [Lightning-dev] Comments on BOLT#11

2017-12-15 Thread Rusty Russell
Jonathan Underwood writes: > Additional comment: we should make a requirement to hide text in the > description under certain conditions. > > ie. "A reader MUST hide information surrounded by curly brackets {} > including > the brackets themselves from the UI, and

Re: [Lightning-dev] Bi-directional or uni-directional?

2017-11-20 Thread Rusty Russell
Alan Carbery via Lightning-dev writes: > Hi, > > All the tutorials that I've read about Lightning describe bi-directional > channels. However, reading through the draft RFC I'm wondering if it's > uni-directional only. Can anyone clarify if this is the

Re: [Lightning-dev] Questions on SIGHASH_NOINPUT

2017-11-12 Thread Rusty Russell
Tomas writes: > HI, > > I have some questions regarding the proposal to use SIGHASH_NOINPUT on > the bitcoin-dev mailing list. [1] > > 1. If I understand correctly, the problem of malleated transactions for > LN is limited to the punishment transaction which is the only one

Re: [Lightning-dev] Question: Invoice

2017-11-02 Thread Rusty Russell
Hi Cezary, This is indeed the right place for such questions at the moment. Cezary Dziemian writes: > 1. After LN starts, some group of users will use it, other not. If for > example, I would like to receive payment for coffee from some user, I don't > know if

Re: [Lightning-dev] Directionality of the transaction fees

2017-12-10 Thread Rusty Russell
Johan Torås Halseth writes: > Hi, Edward! Welcome to the mailing list :) > The fees can indeed be set for each direction of the channel, check out > https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message > >

Re: [Lightning-dev] Directionality of the transaction fees

2017-12-11 Thread Rusty Russell
Edward Marynarz <edziumaryn...@gmail.com> writes: > On Mon, Dec 11, 2017 at 12:15 AM, Rusty Russell <ru...@rustcorp.com.au> > wrote: > >> >> In particular, fees are charged on entry to the channel, so if there's >> an A->B channel, A charges the fee.

Re: [Lightning-dev] Comments on BOLT#11

2017-12-11 Thread Rusty Russell
Jonathan Underwood writes: > Hello all, > > Recently I have implemented BOLT11 in node JS. You can find it on github at > bitcoinjs/bolt11 (check the wip branch, I am still working on tests and > looking at maybe splitting encode up into two functions, encode and

[Lightning-dev] [MINUTES] Dev Meeting 2017-12-12 ***TWO BREAKING CHANGES***

2017-12-11 Thread Rusty Russell
https://docs.google.com/document/d/1WaZDvCX7FsfZbrEMepLdchmDQyyRhY9MTBMF4NeZlOc/edit# Unusually, we had two minor breaking changes, despite the freeze: 1. `r` fee field is now base+millionths like channel_update. * Fixes case where there's no amount ('donation address'). * Nobody

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-14 Thread Rusty Russell
Jim Posen writes: > Thanks for the thoughtful responses. > >> You missed the vital detail: that you must prove channel closure if you >> can't unpeel the onion further. That *will* hit an unresponsive party >> with a penalty. > > Ah, that is a good point. I still find the

Re: [Lightning-dev] Why do we need fee estimation in the protocol?

2018-05-14 Thread Rusty Russell
CJP writes: > Hi, > > Maybe this is a stupid question, and it is late so maybe I'm > overlooking something, but I don't want to lose a potentially good > idea, so here it goes: > > Right now, BOLT#3 imposes a certain algorithm for fee estimation. This > algorithm is likely

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-09 Thread Rusty Russell
Jim Posen writes: > There are two directions of solutions I have heard: 1) protocol support for > decrypting the onion route if the HTLC is kept in-flight for too long 2) > requiring fees even if the payment fails as a cost to the attacker 3) some > sort of reputation system

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

2018-05-09 Thread Rusty Russell
Anthony Towns via bitcoin-dev writes: > On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev > wrote: >> Given the general enthusiasm, and lack of major criticism, for the >> `SIGHASH_NOINPUT` proposal, [...] > > So first, I'm not sure

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-18 Thread Rusty Russell
ZmnSCPxj writes: >>> Please describe the below: >>> >>> 1. Behavior if payment succeeds after T time. >>> 2. Behavior if payment fails after T time. >>> >>> It seems you only described "Behavior if payment succeeds after T time". >> >> Ah, sorry if I didn't make that

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

2018-07-01 Thread Rusty Russell
I'm delighted someone is fleshing this out! Splice-out is easy, splice-in is harder. Note that there are two ways: 1. Broadcast a spend which joins with one or more random outputs and then maintain both the old and new channels (ie. both sets of signatures) until it confirms deeply

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

2018-07-02 Thread Rusty Russell
Gregory Maxwell via bitcoin-dev writes: > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > wrote: >> 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 > > I

Re: [Lightning-dev] Invoice without amount

2018-01-09 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: > Good morning Cezary, > > Currently, c-lightning can PAY amountless invoices via the "pay" command, but > cannot CREATE them via the c-lightning "invoice" command. Good point, I've filed an issue for this, so we don't

[Lightning-dev] Fee disentanglement for 1.1 spec?

2018-01-15 Thread Rusty Russell
Hi all, Wanted to post some thinking on this for everyone to mull over, though I know we're all busy. Your consideration and feedback gratefully accepted! Problem #1 == For simplicity, one side (funder) sets fees, but other side needs to check they're sufficient, and not

Re: [Lightning-dev] BOLTs and meaning of "MUST" in potentially adversarial contexts

2018-01-15 Thread Rusty Russell
Benjamin Mord writes: > One thing I find useful in RFCs is a brief discussion about the meaning of > terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol > definition. Hi Benjamin! Weird, I always find them kinda useless. RFC2119 pretty much covers it.

Re: [Lightning-dev] Pay payment_request with an openchannel+push_sat

2018-01-11 Thread Rusty Russell
Jonathan Underwood writes: > Hi all, > > I have mentioned this to roasbeef re: lnd implementing it... but I am > wondering if this idea has propagated through the LN community and whether > other wallets are going to implement it? > > Feature: > > If the recipient of

Re: [Lightning-dev] Suggestion: Add optional IP address field to invoice format

2018-02-02 Thread Rusty Russell
Ignatius Rivaldi writes: > Hi, > > I think that there is a potential problem for sellers to accept > lightning network. They need someone to open a channel with them that is > filled with bitcoins so that they can start receiving bitcoins from > other LN users. But

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

2018-02-07 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Protocol Overview > == > This design can be seen as a generalization of the single, non-interactive > payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode > extra data for the receiver. In that design, the extra

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

2018-02-07 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Y'all, > > A common question I've seen concerning Lightning is: "I have five $2 > channels, is it possible for me to *atomically* send $6 to fulfill a > payment?". The answer to this question is "yes", provided that the receiver This is awesome!

Re: [Lightning-dev] Improving the initial gossip sync

2018-02-11 Thread Rusty Russell
Christian Decker <decker.christ...@gmail.com> writes: > Rusty Russell <ru...@rustcorp.com.au> writes: >> Finally catching up. I prefer the simplicity of the timestamp >> mechanism, with a more ambitious mechanism TBA. > > Fabrice and I had a shor

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

2018-02-13 Thread Rusty Russell
Conner Fromknecht writes: > IMHO, the current signed invoice + preimage is a very weak proof of payment. > It's the hash equivalent to proving you own a public key by publishing the > secret key. There is an assumption that the only way someone could get that >

Re: [Lightning-dev] Improving the initial gossip sync

2018-02-19 Thread Rusty Russell
Hi all, This consumed much of our lightning dev interop call today! But I think we have a way forward, which is in three parts, gated by a new feature bitpair: 1. A query message for a particular shortid. 2. A query message for shortids in a range of blocks. 3. A gossip_timestamp field

Re: [Lightning-dev] Privacy issues with proof of payment

2018-02-22 Thread Rusty Russell
Hi Corné! Indeed, the privacy focus has generally been the payer, rather than the recipient of funds. So there are several things we can do to address this, the main obvious one the ability to provide a "pre-cooked" onion. This would allow either a payment to an anonymous

Re: [Lightning-dev] Improving the initial gossip sync

2018-02-25 Thread Rusty Russell
Fabrice Drouin <fabrice.dro...@acinq.fr> writes: > On 20 February 2018 at 02:08, Rusty Russell <ru...@rustcorp.com.au> wrote: >> Hi all, >> >> This consumed much of our lightning dev interop call today! But >> I think we have a way forward,

Re: [Lightning-dev] General questions about channels

2018-01-01 Thread Rusty Russell
Mark Friedenbach writes: > I had always assumed the protocol limits were training wheels, and would be > shocked and dismayed if that were not the case (and would immediately begin > work on an alternative fork because such limits would make lightning useless > for my

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

2018-06-21 Thread Rusty Russell
"David A. Harding" writes: > On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote: >> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual >> transaction containing the settlement is expected to have (at least) two >> inputs, with the second one originating the fees.

Re: [Lightning-dev] Virtual channels

2018-07-27 Thread Rusty Russell
Dmytro Piatkivskyi writes: > Dear list, pardon me that I haven't investigated the Lightning > implementations in depth yet, but one discussion has made me wonder how you > approach the below described situation. > > Rene was talking about virtual channels in his article [1]. His motivation >

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

2018-07-29 Thread Rusty Russell
Christian Decker writes: > They are orthogonal, I agree, but we should judge their merits > independently, and not batch the discussions out of convenience. > In the case of the htlc_maximum_msat I think it will not be > controversial, but it should get its own proposal and discussion. BTW, my

[Lightning-dev] 2018 Lightning Developer Summit: Invitation Applications

2018-07-16 Thread Rusty Russell
. Note that this is a highly technical event focused solely on protocol design; there will be many other opportunities for people looking to build applications or contribute to Lightning-related projects. The Lightning Summit Disorganization Committee: Elizabeth Stark, Pierre-Marie Padiou, Rusty

Re: [Lightning-dev] Lightning-dev Digest, Vol 35, Issue 13 (sighash_noinput & watchtowers)

2018-07-13 Thread Rusty Russell
James Chiang writes: > Hello everyone, > I understand sighash_noinput allows us to reduce the number of stored > signatures, as it can spend any uxto with the respective one-use pub key > script. > In the case of watchtowers, are we not trading off privacy, as we are > revealing which states are

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

2018-07-04 Thread Rusty Russell
lesser evil is. And yeah, I called it Schnorr-Eltoonicorn not only because it's so pretty, but because actually capturing it will be a saga. Cheers, Rusty. > On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote: > >> Christian Decker writes: >> >> > ZmnSCPxj via Lightning-de

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

2018-07-04 Thread Rusty Russell
Christian Decker writes: > ZmnSCPxj via Lightning-dev writes: >> For myself, I think splice is less priority than AMP. But I prefer an >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer >> implies receipt of payment at payee, to facilitate trustless >> on-to-offchain and

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

2018-07-08 Thread Rusty Russell
Olaoluwa Osuntokun writes: >> Was referring to losing proof-of-payment; that's vital in a system without >> intermediaries. We have to decide what the lesser evil is. > > As is now, we don't have a proper proof of payment. We have a "proof that > someone paid". A proper proof of payment would

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

2018-07-12 Thread Rusty Russell
DING FENG writes: > Hi, > > I'm a junior developer and a bitcoin user. > And I have read this thread carefully. > > I'm very worried about "SIGHASH_NOINPUT". > > Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse > address more dangerous. No. A wallet should *never* create

Re: [Lightning-dev] Commitment delay asymmetry

2018-04-12 Thread Rusty Russell
Jim Posen writes: > I find it easier to analyze the game theory of these situations if the > to_remote output is also time-locked by the to_remote_delay. Making the > consequence of an on-chain settlement symmetric changes the game from > chicken [1] to a tragedy of the

[Lightning-dev] Lightning Developer Summit #2: Adelaide, Australia 2018-10-08 and 2018-10-09

2018-04-11 Thread Rusty Russell
Hi all, Note the date change; it's now November. Same location, same discussions, and we'll be finalizing the agenda closer to the date. I'm scouting exact locations for 15-30 people at the moment; I'll post here once it's finalized, and ask for RSVPs. Thanks, Rusty.

Re: [Lightning-dev] QR of node information

2018-04-11 Thread Rusty Russell
Robert Olsson writes: > Hello all, > > I seem to not find a bolt regarding the QR code of node@ip:port > > It seems eclair only supports the format hex@ip:port format, and i haven't > tried any other mobile wallets. I anticipate a move away from "manually connect to node" and

Re: [Lightning-dev] Lightning Developer Summit #2: Adelaide, Australia 2018-11-08 and 2018-11-09

2018-04-11 Thread Rusty Russell
Subject correction: 2018-11-08 and 2018-11-09. November, not October. Thanks AJ... Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Pinging a route for capacity

2018-03-04 Thread Rusty Russell
Jim Posen writes: > My understanding is that the best strategy for choosing a route to send > funds over is to determine all possible routes, rank them by estimated fees > based on channel announcements and number of hops, then try them > successively until one works. > > It

Re: [Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy

2018-03-05 Thread Rusty Russell
Andy Schroder <i...@andyschroder.com> writes: > On 09/14/2017 11:49 PM, Rusty Russell wrote: >> So, we really need to be able to include a (smaller) return onion to >> fix this properly. I've added that to: >> >> >> https://github.com/lightningn

Re: [Lightning-dev] Another Implementation

2018-03-05 Thread Rusty Russell
栗元憲一 writes: > I'm Kenichi Kurimoto from Japan. Greetings Kenichi, I've been wondering what you've been doing, since we've seen so many of your intelligent questions on the lightning-rfc github! We have a Google Hangout every two weeks; you're welcome to join if you

[Lightning-dev] Improving the initial gossip sync: DRAFT

2018-03-05 Thread Rusty Russell
https://github.com/lightningnetwork/lightning-rfc/pull/392 I'll append to this as suggestions come in. I'm trying to find some cycles to implement it too. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org

[Lightning-dev] Lightning Protocol Summit September 10/11 2018?

2018-03-05 Thread Rusty Russell
Hi all, We had a kickoff summit for the Lightning Protocol in October 2016 in Milan. I think we're due for another one, so I'm proposing a date and location which works for me: September 10th and 11th Adelaide, Australia. This would be a meeting for development, update and

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

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

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

[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

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

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

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

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

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

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

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 >

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

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

[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

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

2018-10-09 Thread Rusty Russell
Pierre writes: >> But there's no reason to believe that the invoicer has more knowledge about >> all but the last hop. > > I disagree: there is a good chance that the receiver is a 24/7 running > merchant/website, with a full up-to-date view of the network, whereas > the payer is most likely a

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

2018-09-28 Thread Rusty Russell
: SLICKERMASTER- addresses: 165.227.30.200, 2604:a880:2:d0::2065:5001 You can autogenerate an invoice for testnet with: http://165.227.30.200:8000/cgi-bin/payreq.sh If there's insufficient incoming capacity, this *won't* produce an 'r' hint, but will issue a warning. Cheers, Rusty. Rusty Russell

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

2018-09-28 Thread Rusty Russell
Olaoluwa Osuntokun writes: >> This is orothogonal. There's no point probing your own channel, you're >> presumably probing someone else's. > > In my scenario, you're receiving a new HTLC, from some remote party > unbeknownst to you. You have incoming and outgoing channels, and no other

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

2018-09-19 Thread Rusty Russell
Hi all, I'm considering a change to c-lightning, where `invoice` would automatically append an 'r' field for a channel which has sufficient *incoming* capacity for the amount (using a weighted probability across our peers). This isn't quite what 'r' was for, but it would be a

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

2018-09-26 Thread Rusty Russell
Olaoluwa Osuntokun writes: >> That might not be so desirable, since it leaks the current channel >> capacity to the user > >>From my PoV, the only way a node can protect the _instantaneous_ available > bandwidth in their channel is to randomly reject packets, even if they have > the bandwidth to

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

[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

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

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

  1   2   >