[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

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

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

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

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

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

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)

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

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

  1   2   3   >