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

2021-12-17 Thread ZmnSCPxj via Lightning-dev
Good morning Ronan, > If there is a payment to go from party A to be split between parties B & C, > is it possible that only one of B or C would need a plugin? > > If all receiving parties need a plugin that is quite limiting. Thanks, Ronan Given N payees, only N - 1 need the plugin. The last

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

2021-12-17 Thread ZmnSCPxj via Lightning-dev
Good morning cdecker, > I was looking into the docs [1] and stumbled over `createinvoice` which does > almost what you need. However it requires the preimage, and stores the > invoice in the database which you don't want. Indeed, that is precisely the issue, we need a `signfakeinvoice`

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

2021-12-16 Thread ZmnSCPxj via Lightning-dev
Good morning William, > Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would > it be, could it be done with a clightning plugin perhaps? Probably not *yet*; it needs each intermediate payee (i.e. the one that is not the last one) to sign an invoice for which it does not know

Re: [Lightning-dev] A blame ascribing protocol towards ensuring time limitation of stuck HTLCs in flight.

2021-12-16 Thread ZmnSCPxj via Lightning-dev
Good morning Bastien, > * it's impossible for a node to prove that it did *not* receive a message: > you can prove knowledge, >   but proving lack of knowledge is much harder (impossible?) Yes, it is impossible. If there could exist a proof-of-lack-of-knowledge, then even if I personally

Re: [Lightning-dev] PTLCs early draft specification

2021-12-07 Thread ZmnSCPxj via Lightning-dev
Good morning t-bast, > I believe these new transactions may require an additional round-trip. > Let's take a very simple example, where we have one pending PTLC in each > direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A. > > Now A makes some unrelated updates and wants

Re: [Lightning-dev] PTLCs early draft specification

2021-12-07 Thread ZmnSCPxj via Lightning-dev
Good morning LL, and t-bast, > > Basically, if my memory and understanding are accurate, in the above, it is > > the *PTLC-offerrer* which provides an adaptor signature. > > That adaptor signature would be included in the `update_add_ptlc` message. > > Isn't it the case that all previous PTLC

Re: [Lightning-dev] PTLCs early draft specification

2021-12-06 Thread ZmnSCPxj via Lightning-dev
Good morning t-bast, Long ago: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html And I quote: >> A potential issue with MuSig is the increased number of communication rounds >> needed to generate signatures. > >I think you can reduce this via an alternative

Re: [Lightning-dev] Half-Delegation & Chaperones for Decker Channels

2021-11-29 Thread ZmnSCPxj via Lightning-dev
Good morning Jeremy, > Just a minor curiosity I figured was worth mentioning on the composition of > delegations and anyprevout... > > DA: Let full delegation be a script S such that I can sign script R and then > R may sign for a transaction T. > DB: Let partial delegation be a script S such

Re: [Lightning-dev] INTEROPERABILITY

2021-11-24 Thread ZmnSCPxj via Lightning-dev
Good morning x raid, > We are talkin interoperability among impl not individual node operators > version management of chosen impl. > > where Pierre of Acinq says > "So we eat our own dog food and will experience force closes before our users > do.." > hahaha made my day ... > > a node operator

Re: [Lightning-dev] INTEROPERABILITY

2021-11-23 Thread ZmnSCPxj via Lightning-dev
Good morning x-raid, > so You propose Acinq / Blockstream / Lightning Labs do not have funds to run > a box or 2 ? Not at all, I am proposing that these people, who have already done the effort to release working Lightning Network Node implementations free of charge to you, are not obligated

Re: [Lightning-dev] INTEROPERABILITY

2021-11-23 Thread ZmnSCPxj via Lightning-dev
Good morning x-raid, > what i can imagine is each team should provide boxes and channel liquidity as > stake on mainnet for tests before announce a public realise as to feel the > pain first hand instead of having several K´s of plebs confused and at worst > have funds in channelclosed etc.

Re: [Lightning-dev] INTEROPERABILITY

2021-11-23 Thread ZmnSCPxj via Lightning-dev
Good morning again x-raid, Are you proposing as well to provide the hardware and Internet connection for these boxes? I know of one person at least who runs a node that tracks the C-Lightning master (I think they do a nightly build?), and I run a node that I update every release of

Re: [Lightning-dev] INTEROPERABILITY

2021-11-23 Thread ZmnSCPxj via Lightning-dev
Good morning x-raid, > I propose a dialog of the below joint effort ... > > thanks > /xraid > > *** > A decentralised integration lab where CL Eclair LDK LND (++ ?) runs each the > latest release on "one box" rBOX and master.rc on "another box" rcBOX. I believe Electrum also has its own bespoke

Re: [Lightning-dev] Route reliability<->fee trade-off control parameter

2021-11-21 Thread ZmnSCPxj via Lightning-dev
Good morning Dave, > If LN software speculatively chooses a series of attempts with a similar > 95%, accounting for things like the probability of a stuck payment (made > worse by longer CLTV timeouts on some paths), it could present users > with the same sort of options: > > ~1 second, x fee >

Re: [Lightning-dev] Route reliability<->fee trade-off control parameter

2021-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > What I did in lnd is to work with so called 'payment attempt cost'. A virtual > satoshi amount that represents the cost of a failed attempt. https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003191.html And I quote: > Introduction > > >

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-11-03 Thread ZmnSCPxj via Lightning-dev
Good morning again list, > > > We could use an identicon, we do that with the lightningnetwork repository. > > An official logo is probably better - give the project a real symbol. > > I attached an SVG file I have been working on for some time, for the > amusement of all. > > It is

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-11-03 Thread ZmnSCPxj via Lightning-dev
Good morning list, > We could use an identicon, we do that with the lightningnetwork repository. > An official logo is probably better - give the project a real symbol. I attached an SVG file I have been working on for some time, for the amusement of all. It is unfortunately not square, and

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-21 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote: > > > Good morning Joost, > > > > > A potential downside of a dedicated probe message is that it could be > > > used for free messaging on lightning by including additional data in the > > > payload for the recipient. Free

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-21 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > A potential downside of a dedicated probe message is that it could be used > for free messaging on lightning by including additional data in the payload > for the recipient. Free messaging is already possible today via htlcs, but a > probe message would lower the cost to

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-19 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > There could be some corners where the incentives may not work out 100%, but I > doubt that any routing node would bother exploiting this. Especially because > there could always be that reputation scheme at the sender side which may > cost the routing node a lot more in

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread ZmnSCPxj via Lightning-dev
Good morning Owen, > C now notes that B is lying, but is faced with the dilemma: > > "I could either say 'no' because I can plainly see that B is lying, or > I could say 'yes' and get some free sats from the failed payment (or > via the hope of a successful payment from a capacity increase in the

Re: [Lightning-dev] Issue assets on lightning

2021-10-15 Thread ZmnSCPxj via Lightning-dev
Good morning Prayank, > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html > > Still trying to understand this problem and possible solutions. Interesting > email though (TIL), thanks for sharing the link. Found related things > explained Suredbits blog as

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread ZmnSCPxj via Lightning-dev
Good morning Owen, > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > > So how would things work out with a combination of both of the > > proposals described in this mail? First we make probing free (free as > > in no liquidity locked up) and then we'll require senders to pay for

Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

2021-10-13 Thread ZmnSCPxj via Lightning-dev
Good morning Matt, > On 10/13/21 02:58, ZmnSCPxj wrote: > > > Good morning Matt, > > > > > The Obvious (tm) solution here is PTLCs - just have the sender > > > always add some random nonce * G to > > > the PTLC they're paying and send the recipient a random nonce in the > > > onion.

Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

2021-10-13 Thread ZmnSCPxj via Lightning-dev
Good morning Matt, > The Obvious (tm) solution here is PTLCs - just have the sender always add > some random nonce * G to > the PTLC they're paying and send the recipient a random nonce in the > onion. I'd generally suggest we > just go ahead and do this for every PTLC payment,

Re: [Lightning-dev] Issue assets on lightning

2021-10-12 Thread ZmnSCPxj via Lightning-dev
Good morning Prayank, > Hello everyone, > > I wanted to know few things related to asset issuance on lightning: > > 1.Is it possible to issue assets on LN right now? If yes, what's the process > and is it as easy as few commands in liquid:  >

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote: > > > ### Scorched earth punishment > > > > Another thing that I'd like to mention is that using revocable signatures > > enables scorched earth punishments [2]. > > I kind-of think it'd be more interesting to

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote: > > > A transaction is required, but I believe it is not necessary to put it > > onchain (at the cost of implementation complexity in the drop-onchain case). > > The trick with that is that if you don't put it on chain,

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > In order to transition from BOLT#3 format to this proposal, an onchain > transaction is required, as the "revocable signatures" arrangement cannot > be mimicked via the existing 2-of-2 CHECKMULTISIG output. A transaction is required, but I believe it is not

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning Pieter, > Indeed - UTXO set size is an externality that unfortunately Bitcoin's > consensus rules fail to account > for. Having a relay policy that avoids at the very least economically > irrational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning shymaa, > The suggested idea I was replying to is to make all dust TXs invalid by some > nodes. Is this supposed to be consensus change or not? Why "some" nodes and not all? I think the important bit is for full nodes. Non-full-nodes already work at reduced security; what is

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-10-06 Thread ZmnSCPxj via Lightning-dev
Good morning e, > mostly thinking out loud > > suppose there is a "lightweight" node: > > 1. ignores utxo's below the dust limit > 2. doesn't validate dust tx > 3. still validates POW, other tx, etc. > > these nodes could possibly get forked - accepting a series of valid, > mined

[Lightning-dev] Fast Forwards By Channel-in-Channel Construction, Or: Spillman-Decker-Wattenhofer-Poon-Dryja-Towns

2021-10-05 Thread ZmnSCPxj via Lightning-dev
Introduction In some direct discussions with me, ajtowns recently came up with a fairly interesting perspective on implementing Fast Forwards, which I thought deserved its own writeup. The idea by aj is basically having two CSV-variant Spillman unidirectional channels hosted by a

[Lightning-dev] Ask First, Shoot (PTLC/HTLC) Later

2021-09-28 Thread ZmnSCPxj via Lightning-dev
Good morning list, While discussing something tangentially related with aj, I wondered this: > Why do we shoot an HTLC first and then ask the question "can you actually > resolve this?" later? Why not something like this instead? * For a payer: * Generate a path. * Ask first hop if it can

[Lightning-dev] Theory: Proofs of Payment are Signatures

2021-09-23 Thread ZmnSCPxj via Lightning-dev
Introduction Lightning provides proof-of-payment for standard forms of payment, but does not provide it for keysend or non-high hash-based AMP. Let us consider, then, what exactly a proof-of-payment even *is*. Lamport Signatures == One of the earliest

Re: [Lightning-dev] Stateless invoices with proof-of-payment

2021-09-21 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > > > preimage = H(node_secret | payment_secret | payment_amount | > > > encoded_order_details) > > > invoice_hash = H(preimage) > > > > > > The sender sends an htlc locked to invoice_hash for payment_amount and > > > passes along payment_secret and encoded_order_details in

Re: [Lightning-dev] Stateless invoices with proof-of-payment

2021-09-21 Thread ZmnSCPxj via Lightning-dev
Good morning again Joost, > However, we can do "pay for signature" protocols using PTLCs, and rather than > requesting for a scalar behind a point as the proof-of-payment, we can > instead ask for a signature of a message that attests "this recipient got > paid `payment_amount` with

Re: [Lightning-dev] Stateless invoices with proof-of-payment

2021-09-21 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > It could be something like this: > > payment_secret = random > preimage = H(node_secret | payment_secret | payment_amount | > encoded_order_details) > invoice_hash = H(preimage) > > The sender sends an htlc locked to invoice_hash for payment_amount and passes > along

Re: [Lightning-dev] Deriving channel keys deterministically from seed, musig, and channel establishment v2

2021-09-20 Thread ZmnSCPxj via Lightning-dev
Good morning SomberNight, > Good morning ZmnSCPxj, > > > > Solutions: > > > > > > 1. Naively, we could just derive a static key to be used as > > > payment_basepoint, reused between all our channels, and watch the > > > single resulting p2wsh script on-chain. > > > Clearly this has

Re: [Lightning-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

2021-09-20 Thread ZmnSCPxj via Lightning-dev
Good morning John Law, > (at the expense of requiring an on-chain transaction to update > the set of channels created by the factory). Hmmm this kind of loses the point of a factory? By my understanding, the point is that the set of channels can be changed *without* an onchain transaction.

Re: [Lightning-dev] Deriving channel keys deterministically from seed, musig, and channel establishment v2

2021-09-20 Thread ZmnSCPxj via Lightning-dev
Good morning SomberNight, > Solutions: > > 1. Naively, we could just derive a static key to be used as > payment_basepoint, reused between all our channels, and watch the > single resulting p2wsh script on-chain. > Clearly this has terrible privacy implications. If the only problem

Re: [Lightning-dev] Bandwidth in Lightning Network.

2021-09-02 Thread ZmnSCPxj via Lightning-dev
Good morning xraid, It helps to consider on-Lightning bitcoins as a substitute good for onchain bitcoins. Converting to or from on-Lightning coins to onchain coins has a cost, either: * Cost of channel open (converting onchain coins to on-Lightning coins) or channel close (converting

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

2021-09-02 Thread ZmnSCPxj via Lightning-dev
Good morning Stefan, > > > For myself, I think a variant of Pickhardt-Richter payments can be > > > created which adapts to the reality of the current network where > > > `base_fee > 0` is common, but is biased against `base_fee > 0`, can be a > > > bridge from the current network with

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

2021-09-01 Thread ZmnSCPxj via Lightning-dev
Good morning Matt and all, > Please be careful accepting the faulty premise that the proposed algorithm is > “optimal”. It is optimal under a specific heuristic used to approximate what > the user wants. In reality, there are a ton of different things to balance, > from CLTV to feed to

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

2021-08-31 Thread ZmnSCPxj via Lightning-dev
Good morning Stefan, > > For myself, I think a variant of Pickhardt-Richter payments can be created > > which adapts to the reality of the current network where `base_fee > 0` is > > common, but is biased against `base_fee > 0`, can be a bridge from the > > current network with `base_fee > 0`

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

2021-08-31 Thread ZmnSCPxj via Lightning-dev
Good morning Orfeas, > Such an approach is much more suitable to debian, since they have > full control and a complete view over their "network" of packages, as opposed > to LN, which is decentralized, nodes come and go at will and they can be > private (even from developers!).

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

2021-08-31 Thread ZmnSCPxj via Lightning-dev
Good morning aj and Rene, > On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev > wrote: > > > As we thought it was obvious that the function is not linear we only > > explained > > in the paper how the jump from f(0)=0 to f(1) = ppm+base_fee breaks > > convexity. > >

Re: [Lightning-dev] Fee Budgets: A Possible Path Towards Unified Cost Functions For Lightning Pathfinding Problems

2021-08-30 Thread ZmnSCPxj via Lightning-dev
Good morning Stefan, > Good Morning Zmn! > > If you'd like to understand  the min-cost flow problem and algorithms better, > I would really recommend the textbook we have been citing throughout the > paper. > > The algorithm you have found has a few shortcomings. It'll only work for the >

[Lightning-dev] Handling nonzerobasefee when using Pickhard-Richter algo variants

2021-08-30 Thread ZmnSCPxj via Lightning-dev
Good morning list, It seems to me that the cost function defined in Pickhard-Richter can in fact include a base fee: -log(success_probability) + fudging_factor * amount * prop_fee + fudging_factor * base_fee (Rant: why do mathists prefer single-symbol var names, in software engineering

Re: [Lightning-dev] Fee Budgets: A Possible Path Towards Unified Cost Functions For Lightning Pathfinding Problems

2021-08-23 Thread ZmnSCPxj via Lightning-dev
Good morning Stefan, > Hi Zmn! That is some amazing lateral thinking you have been applying there. > I'm quite certain I haven't understood everything fully, but it has been > highly entertaining to read. Will have to give it a closer read when I get > some time. > > As a first impression,

Re: [Lightning-dev] Fee Budgets: A Possible Path Towards Unified Cost Functions For Lightning Pathfinding Problems

2021-08-20 Thread ZmnSCPxj via Lightning-dev
> Alternative Pathfinding? > Or to put this section more succinctly: Why should cost be a number? What operations do the minimum cost flow algorithms demand of this thing called "cost", and can we provide those operations using something which is not a

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-08-20 Thread ZmnSCPxj via Lightning-dev
Good morning Jeremy, > one interesting point that came up at the bitdevs in austin today that favors > remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust

[Lightning-dev] Fee Budgets: A Possible Path Towards Unified Cost Functions For Lightning Pathfinding Problems

2021-08-20 Thread ZmnSCPxj via Lightning-dev
Subject: Fee Budgets: A Possible Path Towards Unified Cost Functions For Lightning Pathfinding Problems Introduction What is the cost of a failed LN payment? Presumably, if a user wants to pay in exchange for something, that user values that thing higher than the Bitcoin they

Re: [Lightning-dev] #zerobasefee

2021-08-20 Thread ZmnSCPxj via Lightning-dev
Good morning Stefan, > > A reason why I suggest this is that the cost function in actual > > implementation is *already* IMO overloaded. > > > > In particular, actual implementations will have some kind of conversion > > between cltv-delta and fees-at-node. > > That's an interesting aspect.

Re: [Lightning-dev] #zerobasefee

2021-08-16 Thread ZmnSCPxj via Lightning-dev
Good morning Stefan, > >I propose that the algorithm be modified >as such, that is, it *ignore* the > >fee  scheme. > > We actually started out thinking like this in the event we couldn't find a > proper way to handle fees, and the real world experiments we've done so far > have only involved

Re: [Lightning-dev] #zerobasefee

2021-08-15 Thread ZmnSCPxj via Lightning-dev
Good morning matt and aj, Let me cut in here. >From my reading of the actual paper --- which could be a massive >misunderstanding, as I can barely understand half the notation, I am more a >dabbler in software engineering than a mathist --- it seems to me that it >would be possible to replace

Re: [Lightning-dev] #zerobasefee

2021-08-15 Thread ZmnSCPxj via Lightning-dev
Good morning lisa, aj, et al., > The result is that micropayments have a different payment regime than > “non-micropayments”, (which may still incentive almost irrational behavior) > but at least there’s no *loss* felt by node operators for handling/supporting > low value payments. 10k

Re: [Lightning-dev] #zerobasefee

2021-08-15 Thread ZmnSCPxj via Lightning-dev
Good morning aj, et al. > Hey *, > > There's been discussions on twitter and elsewhere advocating for > setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing > this to summarise my understanding in a place that's able to easily be > referenced later. > > Setting the base fee to

Re: [Lightning-dev] Zero Fee Routing

2021-08-14 Thread ZmnSCPxj via Lightning-dev
Good morning Daki, While certainly a very imaginative approach to the problem, do note that there is a substantive difference between running a Bitcoin fullnode and running a Lightning forwarding node. Namely: * A Bitcoin fullnode does not risk any lockup of its funds just to run. * A

[Lightning-dev] Algorithm For Channel Fee Settings

2021-08-14 Thread ZmnSCPxj via Lightning-dev
Introduction As use of Lightning grows, we should consider delegating more and more tasks to programs. Classically, decisions on *where* to make channels have been given to "autopilot" programs, for example. However, there remain other tasks that would still appreciate delegation

Re: [Lightning-dev] Turbo channels spec?

2021-08-13 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Mostly nitpick on terminology below, but I think text substantially like > > the above should exist in some kind of "rationale" section in the BOLT, so > > --- > > In light of dual-funding we should avoid "funder" and "fundee"

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-08-10 Thread ZmnSCPxj via Lightning-dev
Good morning all, Thinking a little more, if the dust limit is intended to help keep UTXO sets down, then on the LN side, this could be achieved as well by using channel factories (including "one-shot" factories which do not allow changing the topology of the subgraph inside the factory, but

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-08-10 Thread ZmnSCPxj via Lightning-dev
Good morning Billy, et al., > For sure, CT can be done with computational soundness. The advantage of > unhidden amounts (as with current bitcoin) is that you get unconditional > soundness. My understanding is that it should be possible to have unconditional soundness with the use of El-Gamal

Re: [Lightning-dev] Revisiting Link-level payment splitting via intermediary rendezvous nodes

2021-08-09 Thread ZmnSCPxj via Lightning-dev
Good morning Gijs, > To circumvent the saturated channel D-C, C creates the route C->A->D, > where node D supports rendezvous routing. C can create a sub-route > from D to E and treat it as a partial route-to-payee under rendezvous > routing by using the hop payload found when unwrapping the

Re: [Lightning-dev] Impact of eltoo loss of state

2021-07-27 Thread ZmnSCPxj via Lightning-dev
Good morning aj, and list, > > I don't think you can reliably hide that you forgot some state? Thinking a little more --- *why* do we need to hide that we forgot some state? The reason is that if your peer learns you forgot state, the peer can pass off obsolete state onchain, thereby stealing

Re: [Lightning-dev] Impact of eltoo loss of state

2021-07-27 Thread ZmnSCPxj via Lightning-dev
Good morning cdecker, aj, and list, > . In addition we can store the same data with multiple peers, ensuring that > as long as one node is behaving we're good. Depending on size limits of the stored data, it may be possible to use some kind of erasure coding so that at least k of n peers need

Re: [Lightning-dev] Turbo channels spec?

2021-07-04 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty et al, > Matt Corallo lf-li...@mattcorallo.com writes: > > > Thanks! > > On 6/29/21 01:34, Rusty Russell wrote: > > > > > Hi all! > > > > > > John Carvalo recently pointed out that not every implementation > > > > > > > > > accepts zero-conf channels, but they are

Re: [Lightning-dev] Lightning Mints

2021-06-29 Thread ZmnSCPxj via Lightning-dev
Good morning elsirion, > Hi ZmnSCPxj, > > let me chime in here, I've been working on federated mint for quite some time > now but only recently began talking about it more publicly. > > > WabiSabi "simply" replaces blinded signatures with blinded credentials. > > Blinded signatures are fairly

Re: [Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts

2021-06-29 Thread ZmnSCPxj via Lightning-dev
Good morning lisa, > A dedicated attacker could probably figure out your UTXO set, but that's not > much different from the current system; the only difference is the span of > time > it takes them to figure it out. > > ## Things We've Done to Counter This: > I had the pleasure of finally

Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol?

2021-06-28 Thread ZmnSCPxj via Lightning-dev
Good morning VzxPLnHqr, > Dear ZmnSCPxj, > > Thank you for your reply. I see how the vending machine can be mapped into > the Courier role. There are some questions around how to extend this to a > multi-courier situation, but let us solve that problem later and further > discuss the nuances

Re: [Lightning-dev] Lightning Mints

2021-06-28 Thread ZmnSCPxj via Lightning-dev
Good morning again CAsey, > > I believe a major failing of Chaumian mints is that they are, at their core, > inherently custodial. > The mint issues blinded minted coins in exchaange for people handing over > other resources to their custody. > While the mint itself cannot identify who owns how

Re: [Lightning-dev] Lightning Mints

2021-06-27 Thread ZmnSCPxj via Lightning-dev
Good morning Casey, I believe a major failing of Chaumian mints is that they are, at their core, inherently custodial. The mint issues blinded minted coins in exchaange for people handing over other resources to their custody. While the mint itself cannot identify who owns how much, it can

Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol?

2021-06-26 Thread ZmnSCPxj via Lightning-dev
Good morning VzxPLnHqr, This certainly seems workable. I first encountered similar ideas when people were asking about how to implement a vending machine with Lightning, with the vending machine being offline and not having any keys. The idea was to have the vending machine record

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-19 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > Hi Z, > > Thanks again for getting to the bottom of this. I think we are on the same > page except for one clarification: > > On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote: >   > > > Thus, in our model, we have the property that Bob can always recover all > > signatures sent

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-07 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > Hi Z, > > I agree with your analysis. This is how I pictured eltoo fast forwards > working as well. > > Another interesting thing about this idea is that it could allow a new type > of custodial LN provider where the custodian is only in charge of receiving > payments to the

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-01 Thread ZmnSCPxj via Lightning-dev
Good morning again LL, So I started thinking as well, about Decker-Russell-Osuntokun and the Fast Forwards technique, as well as your "desync" idea. And it seems to me that we can also adapt a variant of this idea with Decker-Russell-Osuntokun, with the advantage of **not** requiring the

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-01 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > Hi Z, > > I just went through the presentation which made your thinking very clear. > Thanks. > I will not be able to match this effort so please bear with me as I try and > explain my own thinking. > I don't see why fast forwards (FF) need "symmetrically encumbered outputs"?

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-05-31 Thread ZmnSCPxj via Lightning-dev
Good morning list, > It may be difficult to understand this, so maybe I will make a convenient > presentation of some sort. As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp The presentation is intended to be seen by semi-technical and technical people, particular

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-05-24 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > Hey Z, > > Thanks for your analysis. I agree with your conclusion. I think the most > practical approach is the "ask first" 3 round protocol. > > Another option is to have `remote_penaltyclaimpubkey` owned by the node > instead of the hardware device. > This allows funds to

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-05-23 Thread ZmnSCPxj via Lightning-dev
Good morning list, Note that there is a possible jamming attack here. More specifically, when "failing" an incoming HTLC, the receiver of the HTLC sends its signature for a transaction spending the HTLC and spending it back to the sender revocable contract. The funds cannot be reused until the

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-05-23 Thread ZmnSCPxj via Lightning-dev
Good morning list, I have decided to dabble in necromancy, thus, I revive this long-dead thread from two years ago. Ph34R mE and my leet thread necromancy skillz. A short while ago, LL and Steve Lee were discussing about ways to reduce the privkey onlineness requirement for Lightning. And LL

Re: [Lightning-dev] Questions on lightning chan closure privacy

2021-05-18 Thread ZmnSCPxj via Lightning-dev
Good morning LL and Lee, > Hi Lee, > > You are touching on some very relevant privacy challenges for lightning. To > your questions: > > 1. Is it possible to identify which node funded a lightning channel? (this > tells you who owns the change output) > 2. Is it possible to identify who owns

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-12 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, and list, > > More generally, all Boolean logic can be converted to one of two standard > forms. > > - sum-of-products i.e. `||` over `&&` > - product-of-sums i.e. `&&` over `||` > > For example an XOR can be converted to the sum-of-products form: > > A ^ B = (!A

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-12 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, and list, > > More generally, all Boolean logic can be converted to one of two standard > forms. > > - sum-of-products i.e. `||` over `&&` > - product-of-sums i.e. `&&` over `||` > > For example an XOR can be converted to the sum-of-products form: > > A ^ B = (!A

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-12 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, > Hey ZmnSCPxj, > > Your earlier post about how to accomplish ORing points without verifiable > encryption was super interesting. > > I think this contains a clever general NOT operation where you double the > payment and use the point as a condition for the "cancellation

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-12 Thread ZmnSCPxj via Lightning-dev
Good morning Andres, > > > Is there any disadvantage about using dual-hash HTLCs? > > > Is it supported by the current LN spec? > > > > It is no supported by current LN spec, and PTLCs are overall superior (they > > are equivalent to having any number of hashes, not just 2 that dual-hash > >

Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)

2021-02-12 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > > Not quite up-to-speed back into this, but, I believe an issue with using > > feerates rather than fixed fees is "what happens if a channel is forced > > onchain"? > > > > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is > > forced onchain, and

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-11 Thread ZmnSCPxj via Lightning-dev
Good morning Andres, > Hey ZmnSCPxj, > > On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote: > > > Good morning Andres, > > > > > This looks cool but would hinder UX too much for certain scenarios: e.g. > > > if the escrow in place is part of a bitcoin exchange, then you require > > > the bitcoin

Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)

2021-02-11 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, Not quite up-to-speed back into this, but, I believe an issue with using feerates rather than fixed fees is "what happens if a channel is forced onchain"? Suppose after C offers the HTLC to D, the C-D channel, for any reason, is forced onchain, and the blockchain is

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-10 Thread ZmnSCPxj via Lightning-dev
Good morning Andres, > This looks cool but would hinder UX too much for certain scenarios: e.g. if > the escrow in place is part of a bitcoin exchange, then you require the > bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new > users (which could maybe only have fiat).

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-10 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav and Andres, Thank you for bringing up this topic again. Let me provide a new twist to this old idea. This is the entire logic of the contract to the seller: SELLER && (BUYER || ESCROW) Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||` which is

Re: [Lightning-dev] Escrow Over Lightning?

2021-02-10 Thread ZmnSCPxj via Lightning-dev
Good morning Pedro, > Hi Nadav, > > You are right that the intermediary (i.e., Ingrid) needs to hold a certain > amount of coins to allow the virtual channel between Alice and Bob. Some > comments here: >  - The protocol makes sure that Ingrid will get paid whatever fee she decides > to charge

Re: [Lightning-dev] Lightning dice

2021-02-02 Thread ZmnSCPxj via Lightning-dev
Good morning aj, and list, > Note that Bob could abort the protocol with a winning bet before > requesting the payout from Carol -- he already has enough info to prove > he's won and claim Carol isn't paying him out at this point. > One way of dealing with this is to vet Bob's claim by sending

Re: [Lightning-dev] PoDLEs revisited

2021-01-05 Thread ZmnSCPxj via Lightning-dev
Good morning LL, and happy new year as well, > # Signaling Transactions > > Finally I present a simple but unintuitive protocol that achieves roughly the > same properties as the PoDLE protocol but without lightning gossip messages. > > Whenever the initiator adds an input in the interactive

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-21 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > > > > I suspect part of the proof-of-discrete-log-equivalance can be gated as > > > > well by a ZKCP on payment point+scalar the proof is provided only on > > > > payment. > > > > The selling node operator does not even need to reveal `z`. > > > > > > Actually no -- the fact

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-18 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > > I suspect part of the proof-of-discrete-log-equivalance can be gated as > > well by a ZKCP on payment point+scalar the proof is provided only on > > payment. > > The selling node operator does not even need to reveal `z`. > > Actually no -- the fact that you were able to

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-16 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > > > - What do you do if the channel state has HTLCs in flight? I don't know > > > -- I guess you can just put them onto the settlement tx? That way it's > > > possible the payment could still go through. Alternatively you could just > > > gift the money to the party

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-15 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > - What do you do if the channel state has HTLCs in flight? I don't know -- I > guess you can just put them onto the settlement tx? That way it's possible > the payment could still go through. Alternatively you could just gift the > money to the party offering the recovery

Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates

2020-12-01 Thread ZmnSCPxj via Lightning-dev
Good morning LL, > Back to the general topic. Perhaps a way of refining the proposal is the > following: > > 1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of > design. > 2. The owner (owners?) of leach LN UTXO can go to any node in the network and > request a kind of

Re: [Lightning-dev] Lightning Distributed Routing

2020-12-01 Thread ZmnSCPxj via Lightning-dev
Good morning Joao and Bastien, I believe the `feeadjuster` plugin for C-Lightning, created by Darosior, already does what you want to do, without a specs change. * We already know that nodes prefer low-fee routes over high-fee routes. * `feeadjuster` adjusts our channel feerate according to

  1   2   3   4   5   6   >