Re: [Lightning-dev] Splicing Proposal: Feedback please!
> Mainly limitations of our descriptor language, TBH. I don't follow...so it's a size issue? Or wanting to avoid "repeated" fields? > I thought about restarting the revocation sequence, but it seems like that > only saves a tiny amount since we only store log(N) entries Yeah that makes sense, forgetting the HTLC state is a big enough win in and of itself. >>> Splice Signing >> >> It seems that we're missing some fields here if we're to allow the splicing >> of inputs to be done in a non-blocking manner. We'll need to send two >> revocation points for the new commitment: one to allow it to be created, and >> another to allow updates to proceed right after the signing is completed. In >> this case we'll also need to update both commitments in tandem until the >> splicing transaction has been sufficiently confirmed. > >I think we can use the existing revocation points for both. Yep, if we retain the existing shachain trees, then we just continue to extend the leaves! > We're basically co-generating a tx here, just like shutdown, except it's > funding a new replacement channel. Do we want to CPFP this one too? It'd be nice to be able to also anchor down this splicing transaction given that we may only allow a single outstanding splicing operation to begin with. Being able to CPFP it (and later on provide arbitrary fee inputs) allows be to speed up the process if I want to queue another operation up right afterwards. -- Laolu On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell wrote: > 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 for allowing multiple channels. Multiple > > channels allow nodes to: > > > > * create distinct channels with distinct acceptance policies. > > * create a mix of public and non-advertised channels with a node. > > * be able to send more than the (current) max HTLC amount > > using various flavors of AMP. > > * get past the (current) max channel size value > > * allow a link to carry more HTLCs (due to the current super low max > HTLC > > values) given the additional HTLC pressure that > > AMP may produce (alternative is a commitment fan out) > > These all seem marginal to me. I think if we start hitting max values, > we should discuss increasing them. > > > Is there a fundamental reason that CL will never allow nodes to create > > multiple channels? It seems unnecessarily limiting. > > Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1 > channel. My own fault: I was the one who insisted we mux multiple > connections over the same transport; if we'd gone for independent > connections our implementation would have been trivial. > > >> Splice Negotiation: > > > > Any reason to now make the splicing_add_* messages allow one to add > several > > inputs in a single message? Given "acceptable" constraints for how large > the > > witness and pkScripts can be, we can easily enforce an upper limit on the > > number of inputs/outputs to add. > > Mainly limitations of our descriptor language, TBH. > > > I like that the intro messages have already been designed with the > > concurrent case in mind beyond a simpler propose/accept flow. However is > > there any reason why it doesn't also allow either side to fully > re-negotiate > > _all_ the funding details? Splicing is a good opportunity to garbage > collect > > the prior revocation state, and also free up obsolete space in watch > towers. > > I thought about restarting the revocation sequence, but it seems like > that only saves a tiny amount since we only store log(N) entries. We > can drop old HTLC info post-splice though, and (after some delay for > obscurity) tell watchtowers to drop old entries I think. > > > Additionally, as the size of the channel is either expanding or > contracting, > > both sides should be allowed to modify things like the CSV param, > reserve, > > max accepted htlc's, max htlc size, etc. Many of these parameters like > the > > CSV value should scale with the size of the channel, not allowing these > > parameters to be re-negotiated could result in odd scenarios like still > > maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k > > satoshis. > > Yep, good idea! I missed that. > > Brings up a side point about these values, which deserves its own > post... > > >> 1. type: 40 (`splice_add_input`) (`option_splice`) > > > > In order to add nested p2sh inputs, we'll need to also expose the redeem > > script here, or add additional fields to allow sides to set a sig script > as > > well as witness during the signing phase. > > > >> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> > EQUAL' > > > > So no P2SH? :( > > Another omission, yeah, we'd want that too I think. >
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
Hi tomokio, This is so dope! We've long discussed creating canned protocol transcripts for other implementations to assert their responses again, and I think this is a great first step towards that. > Our proposal: > Every implementation has compile option which enable output key information > file. So is this request to add an option which will write out the _plaintext_ messages to disk, or an option that writes out the final derived read/write secrets to disk? For the latter path, it the tools that read these transcripts would need to be aware of key rotations, so they'd be able to continue to decrypt the transact pt post rotation. -- Laolu On Sat, Oct 27, 2018 at 2:37 AM wrote: > Hello lightning network developers. > Nayuta team is developing Wireshark plug-in for Lightning Network(BOLT) > protocol. > https://github.com/nayutaco/lightning-dissector > > It’s alpha version, but it can decode some BOLT message. > Currently, this software works for Nayuta’s implementation(ptarmigan) and > Éclair. > When ptarmigan is compiled with some option, it write out key information > file. This Wireshark plug-in decode packet using that file. > When you use Éclair, this software parse log file. > > Through our development experience, interoperability test is time > consuming task. > If people can see communication log of BOLT message on same format > (.pcap), it will be useful for interoperability test. > > Our proposal: > Every implementation has compile option which enable output key > information file. > > We are glad if this project is useful for lightning network eco-system. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Splicing Proposal: Feedback please!
> However personally I do not really see the need to create multiple channels > to a single peer, or increase the capacity with a specific peer (via splice > or dual-funding). As Christian says in the other mail, this consideration, > is that it becomes less a network and more of some channels to specific big > businesses you transact with regularly. I made no reference to any "big businesses", only the utility that arises when one has multiple channels to a given peer. Consider an easier example: given the max channel size, I can only ever send 0.16 or so BTC to that peer. If I have two channels, then I can send 0.32 and so on. Consider the case post AMP where we maintain the current limit of the number of in flight HTLCs. If AMP causes most HTLCs to generally be in flight within the network, then all of a sudden, this "queue" size (outstanding HTLCS in a commitment) becomes more scarce (assume a global MTU of say 100k sat for simplicity). This may then promote nodes to open additional channels to other nodes (1+) in order to accommodate the increased HTLC bandwidth load due to the sharded multi-path payments. Independent on bolstering the bandwidth capabilities of your links to other nodes, you would still want to maintain a diverse set of channels for fault tolerance, path diversity, and redundancy reasons. In the splicing case, if only a single in flight splice is permitted, and me as users wants to keep all their funds in channels, the more channels I have, the more concurrent on-chain withdraws/deposits I'll be able to service. > I worry about doing away with initiator distinction Can you re-phrase this sentence? I'm having trouble parsing it, thanks. > which puzzles me, and I wonder if I am incorrect in my prioritization. Consider that not all work items are created equal, and they have varying levels of implementation and network wide synchronization. For example, I think we all consider multi-hop decor to be a high priority. However, it has the longest and hardest road to deployment as it effectively forces us to perform a "slow motion hard-fork" within the network. On the other hand, if lnd wanted to deploy a flavor of non-interactive (no invoice) payments *today*, we could do that without *any* synchronization at the implementation of network level, as it's purely an end-to-end change. > I am uncertain what this means in particular, but let me try to restate > what you are talking about in other terms: Thought about it a bit more (like way ago) and this is really no different than having a donation page where people use public derivation to derive addresses to deposit directly to your channel. All the Lightning node needs to do, is recognize that any coins send to these derived addresses should be immediately spliced into an available channel (doesn't have any other outstanding splices). > It seems to me naively that the above can be done by the client software > without any modifications to the Lightning Network BOLT protocol Sticking with that prior version yes, this would be able to be seamlessly included in the async splce proposal. The one requirement is a link-level protocol that allows both sides to collaboratively create and recognize these outputs. > Or is my above restatement different from what you are talking about? You're missing the CLTV timeout clause. It isn't a plain p2wkh, it's a p2wsh script. Either they splice this in before the timeout, or it times out and it goes back to one party. In this case, it's no different than the async concurrent commitment splice in double spend case. -- Laolu On Tue, Oct 16, 2018 at 10:16 PM ZmnSCPxj wrote: > Good morning Laolu, > > Is there a fundamental reason that CL will never allow nodes to create > multiple channels? It seems unnecessarily limiting. > > > The architecture of c-lightning assigns a separate process to each peer. > For simplicity this peer process handles only a single channel. Some of > the channel initiation and shutdown protocols are written "directly", i.e. > if the BOLT spec says this must happen before that, we literally write in > the C code this_function(); that_function();. It would be possible to > change this architecture with significant difficulty. > > However personally I do not really see the need to create multiple > channels to a single peer, or increase the capacity with a specific peer > (via splice or dual-funding). As Christian says in the other mail, this > consideration, is that it becomes less a network and more of some channels > to specific big businesses you transact with regularly. But I suppose, > that we will have to see how the network evolves eventually; perhaps the > goal of decentralization is simply doomed regardless, and Lightning will > indeed evolve into a set of channels you maintain to specific big > businesses you regularly work with. > > > >* [`4`:`feerate_per_kw`] > > What fee rate is this? IMO we should do commitmentv2 before splicing as > then > we can
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
> This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data" Scratch that: the static back ups just need to include this CSV value! -- Laolu On Tue, Nov 6, 2018 at 3:29 PM Olaoluwa Osuntokun wrote: > 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. > > > - HTLC-timeout and HTLC-success txs sigs are > > SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. > > Would this mean that we no longer extend fees to the second-level > transactions as well? If so, then a dusty HTLC would be determined solely > by > looking at the direct output, rather than the resulting output in the > second > layer. > > > - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, > `remote_htlcpubkey`, > > `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a > > two-stage unhardened BIP-32 derivation based on the commitment number. > > It seems enough to _only_ modify the derivation for local+remote pubkey (so > the direct "settle" keys). This constrains the change to only what's > necessary to simplify the backup+recovery workflow with the current > commitment design. By restricting the change to these two keys, we minimize > the code impact to the existing implementations, and avoid unnecessary > changes that don't make strides towards the immediate goal. > > > - `to_remote` is now a P2WSH of: > >`to_self_delay` OP_CSV OP_DROP OP_CHECKSIG > > This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data". If it was just a plain p2wkh, then during a routine seed import and > rescan (assuming ample look ahead as we know this is a "special" key), I > would pick up outputs of channels that were force closed while I was down > due to my dog eating my hard drive. > > Alternatively, since the range of CSV values can be known ahead of time, I > can brute force a set of scripts to look for in the chain. However, this > results in potentially a very large number of scripts (depending on how > many > channels one has, and bounds on the acceptable CSV) I need to scan for. > > -- Laolu > > > On Fri, Oct 12, 2018 at 3:57 PM Rusty Russell > wrote: > >> 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 >>option_data_loss_protect "please tell me your current >>per_commitment_point" problem[1] >> 3. The CLTV timeout should be symmetrical to avoid trying to game the >>peer into closing. (Connor IIRC?). >> >> It makes sense to combine these into a single `commitment_style2` >> feature, rather than having a testing matrix of all these disabled and >> enabled. >> >> BOLT #2: >> >> - If `commitment_style2` negotiated, update_fee is a protocol error. >> >> This mainly changes BOLT #3: >> >> - The feerate for commitment transactions is always 253 satoshi/Sipa. >> - Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi. >> - Fees, OP_TRUE are always paid by the initial funder, because it's >> simple, >> unless they don't have funds (eg. push_msat can do this, unless we >> remove it?) >> - HTLC-timeout and HTLC-success txs sigs are >> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. >> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, >> `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` >> derivation now uses a two-stage unhardened BIP-32 derivation based on >> the commitment number. Two-stage because we can have 2^48 txs and >> BIP-32 only supports 2^31: the first 17 bits are used to derive the >> parent for the next 31 bits? >> - `to_self_delay` for both sides is the maximum of either the >> `open_channel` or `accept_channel`. >> - `to_remote` is now a P2WSH of: >> `to_self_delay` OP_CSV OP_DROP OP_CHECKSIG >> >> Cheers, >> Rusty. >> >> [1] I recently removed checking this field from c-lightning, as I >> couldn't get it to reliably work under stress-test. I may just have >> a bug, but we could just fix the spec instead, then we can get our >> funds back even if we never talk to the peer. >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
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! >> - HTLC-timeout and HTLC-success txs sigs are >> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. > > Would this mean that we no longer extend fees to the second-level > transactions as well? If so, then a dusty HTLC would be determined solely by > looking at the direct output, rather than the resulting output in the second > layer. Good point, yes. >> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, >> `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a >> two-stage unhardened BIP-32 derivation based on the commitment number. > > It seems enough to _only_ modify the derivation for local+remote pubkey (so > the direct "settle" keys). This constrains the change to only what's > necessary to simplify the backup+recovery workflow with the current > commitment design. By restricting the change to these two keys, we minimize > the code impact to the existing implementations, and avoid unnecessary > changes that don't make strides towards the immediate goal. I was thinking in the long term when we drop backwards compat, then we only have one derivation scheme? >> - `to_remote` is now a P2WSH of: >>`to_self_delay` OP_CSV OP_DROP OP_CHECKSIG > > This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data". If it was just a plain p2wkh, then during a routine seed import and > rescan (assuming ample look ahead as we know this is a "special" key), I > would pick up outputs of channels that were force closed while I was down > due to my dog eating my hard drive. Good point; we need to weigh the benefits of symmetry (which seems to require this) against this additional complication. > Alternatively, since the range of CSV values can be known ahead of time, I > can brute force a set of scripts to look for in the chain. However, this > results in potentially a very large number of scripts (depending on how many > channels one has, and bounds on the acceptable CSV) I need to scan for. I don't suppose we could get everyone to agree on the same CSV values? :) Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
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. > - HTLC-timeout and HTLC-success txs sigs are > SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. Would this mean that we no longer extend fees to the second-level transactions as well? If so, then a dusty HTLC would be determined solely by looking at the direct output, rather than the resulting output in the second layer. > - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, > `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a > two-stage unhardened BIP-32 derivation based on the commitment number. It seems enough to _only_ modify the derivation for local+remote pubkey (so the direct "settle" keys). This constrains the change to only what's necessary to simplify the backup+recovery workflow with the current commitment design. By restricting the change to these two keys, we minimize the code impact to the existing implementations, and avoid unnecessary changes that don't make strides towards the immediate goal. > - `to_remote` is now a P2WSH of: >`to_self_delay` OP_CSV OP_DROP OP_CHECKSIG This seems at odds with the goal of "if the remote party force closes, then I get my funds back immediately without requiring knowledge of any secret data". If it was just a plain p2wkh, then during a routine seed import and rescan (assuming ample look ahead as we know this is a "special" key), I would pick up outputs of channels that were force closed while I was down due to my dog eating my hard drive. Alternatively, since the range of CSV values can be known ahead of time, I can brute force a set of scripts to look for in the chain. However, this results in potentially a very large number of scripts (depending on how many channels one has, and bounds on the acceptable CSV) I need to scan for. -- Laolu On Fri, Oct 12, 2018 at 3:57 PM Rusty Russell wrote: > 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 >option_data_loss_protect "please tell me your current >per_commitment_point" problem[1] > 3. The CLTV timeout should be symmetrical to avoid trying to game the >peer into closing. (Connor IIRC?). > > It makes sense to combine these into a single `commitment_style2` > feature, rather than having a testing matrix of all these disabled and > enabled. > > BOLT #2: > > - If `commitment_style2` negotiated, update_fee is a protocol error. > > This mainly changes BOLT #3: > > - The feerate for commitment transactions is always 253 satoshi/Sipa. > - Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi. > - Fees, OP_TRUE are always paid by the initial funder, because it's simple, > unless they don't have funds (eg. push_msat can do this, unless we > remove it?) > - HTLC-timeout and HTLC-success txs sigs are > SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. > - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, > `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` > derivation now uses a two-stage unhardened BIP-32 derivation based on > the commitment number. Two-stage because we can have 2^48 txs and > BIP-32 only supports 2^31: the first 17 bits are used to derive the > parent for the next 31 bits? > - `to_self_delay` for both sides is the maximum of either the > `open_channel` or `accept_channel`. > - `to_remote` is now a P2WSH of: > `to_self_delay` OP_CSV OP_DROP OP_CHECKSIG > > Cheers, > Rusty. > > [1] I recently removed checking this field from c-lightning, as I > couldn't get it to reliably work under stress-test. I may just have > a bug, but we could just fix the spec instead, then we can get our > funds back even if we never talk to the peer. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin maximalist in me thinks that's unwise :) I can see how not wanting to use millisatoshis makes you less compatible with other people that do prefer using that unit of account. But in this case I think it's important to allow the freedom to choose. I essentially feel we should be allowed to respect the confines of the layer we're building upon. There's already a lot of benefits to achieve from second layer scaling whilst still respecting the limits of the base layer. Staying within those limits means optimally benefit form the security it offers. Essentially by allowing to keep satoshi as the smallest fraction, you ensure that everything you do off-chain is also valid and enforced by the chain when you need it to. It comes at trade offs though: it would mean that if someone routes your payment, you can only pay fees in whole satoshis - essentially meaning if someone wants to charge a (small) fee, you will be overpaying to stay within your chosen security parameters. Which is a consequence of your choice. I would be happy to make a further analysis on what consequences allowing this choice would have for the specification, and come up with a proposal on how to add support for this. But I guess this discussion is meant to "test the waters" to see how much potential such a proposal would have to eventually be included. I guess what I'm searching for is a way to achieve the freedom of choice, without negatively impacting other clients or users that decide to accept some level of trust. In my view, this would be possible - but I think working it out in a concrete proposal/RFC to the spec would be a logical next step. Gert-Jaap ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for updateable / revokable proofs of payment
I think it's true that most of my proposal can be achieved by writing such things in human-readable form in the description field. Mostly, the only thing my proposal does is to put things into a machine- readable form; this may aid in automated processing and maybe a better UI experience. Maybe the least trivial thing is the inclusion of a payer pubkey in the original invoice; this is the least trivial both in protocol complexity and in potential benefits. One benefit is that it turns a "proof-that- someone-paid" into a "proof-that-I-paid"; another benefit is that it becomes clear who is authorized to issue another invoice that says "this original invoice is nullified". Now that I think of it: my proposal has something important that yours doesn't: the requirement to have *two* signatures (both payer and payee) on each update. Without that requirement, there is one party who can nullify the old contract by making a unilaterally signed invoice and a self-generated payment preimage. Not even a need to do a payment to self to "fake" a sort of a refund payment or so. This may be OK as long as there is only one party who has obligations: then the other party may partially or completely nullify those obligations, optionally dependent on a payment. Requiring two signatures (and thereby consensus) on each update is more generic though: it allows for obligations on both parties. Even more generic could be to allow more than two parties. I'm sure there are complex business arrangements that have a need for this, but I think we can always develop that later. Let's first tackle this relatively simple case. CJP ZmnSCPxj schreef op ma 05-11-2018 om 01:20 [+]: > Good morning CJP, > > It seems to me, naively, that we can encode the description "the > obligation in the invoice whose hash is is nullified", whose > meaning then is promoted to "if payment happens, payee has an > obligation to ensure that the obligation in the invoice whose hash is > is nullified", then we have revokable payments already. Such a > payment may itself be revoked, ad infinitum. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Monday, November 5, 2018 5:08 AM, CJP > wrote: > > > Right now, the only defined semantics of the description field in > > BOLT11 is that it SHOULD be "a complete description of the purpose > > of > > the payment". I think this is a bit vague; maybe this is > > deliberate? > > > > Anyway, you may also think of a BOLT11 payment request as an option > > contract. If the payment is performed (which can be proven by > > showing > > the preimage), then payee is bound to the terms and conditions in > > the > > description. So, then the meaning of a description "one cup of > > coffee" > > becomes "if payment happens, payee has an obligation to deliver one > > cup > > of coffee". > > > > A known issue is that payer is not identified in the contract, so > > it is > > not clear to who the payee has this obligation. As far as I can > > see, > > the only way to fix this is to have two-way communication, where > > first > > the payer sends some data to payee (e.g. public key), and then > > payee > > makes the payment request, including this data. With this > > established, > > we turn the preimage + payment request from a "proof that someone > > paid" > > into a "proof that I paid", and therefore also a "proof that payee > > has > > this obligation to me". > > > > I'm a bit afraid that such proofs are a bit too inflexible for > > real- > > life applications. I think in real-life there are many cases where > > you > > need to update / revoke agreements, even after payment. > > > > One example is a full refund: if goods/services cannot be delivered > > somehow, payer+payee might agree to a full refund instead of > > delivery > > of goods/services. The refund is another payment, with a payment > > request made by the original payer; its contract should state that > > the > > original payee is no longer bound by the obligations in the > > original > > contract. > > > > Another example is a partial refund, for instance if only a lower > > quantity or a lower quality of goods/services is delivered. This is > > another payment, but now the new contract replaces the old contract > > and > > specifies a new, lower set of obligations for the original payee. > > > > Another example is a change of conditions without change of > > payment, > > for instance when a white/gold dress was ordered, but turned out to > > be > > unavailable, and payer finds a black/blue dress acceptable as well, > > at > > equal price. Then you'd just want to replace white/gold in the > > contract > > by black/blue, without any payment. > > > > I think nearly all cases (including ones not mentioned here) are > > covered by a "contract update" format which includes: > > > > - the new obligations of the two parties to each other > > - a secure hash of the previous contract version that
Re: [Lightning-dev] Proposal for rendez-vous routing
Good morning CJP, On Monday, November 5, 2018 4:04 PM, CJP wrote: > Rusty, > > In your proposal, I guess it is more or less widely known that Bob is > providing this forwarding service. Wouldn't Bob risk being excluded > from the side of the network with the more harsh regulatory conditions, > based on this knowledge? Bob might actually face even worse penalties > for providing such a service. > > The nice thing about rendez-vous routing is that any forwarding node > can be a rendez-vous point, and even the node itself wouldn't know > about it. The case where a payment is routed from and to the same > channel could be a hint though: normally that makes no sense, but if > payer and payee make their part of the route independently, the > combined route can often end up like that. TODO: check if forwarding > nodes are currently cool with such weird forwarding requests. This is allowed within the protocol and to my knowledge existing node software do not particularly care. However, it is indeed a concern as it allows somebody to notice such use of rendezvous routing. A use of this (forwarding to the same channel as receiving) is to give donations to a node without actually requiring an invoice to that node. You simply route a circle to yourself to an invoice you generated yourself, and hide the donation to some node as fees paid for forwarding through that node. Nodes will accept as fee any amount higher than the feerate they indicate in gossip. Regards, ZmnSCPxj > > CJP > > Rusty Russell schreef op ma 05-11-2018 om 10:56 [+1030]: > > > CJP c...@ultimatestunts.nl 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 the destination half of the route). > > > > > > Sounds like it makes sense; I need to look into it. > > > > Here's my attempt to design a "merchant forward" service using stuff > > we > > have today. > > Alice wants to remain anonymous, even from the lightning > > network. Bob's > > node offers a forwarding service. Alice pays Bob (base + > > percentage?), > > gives a path Bob->Alice, and Bob gives Alice a short-channel-id > > (BobAliceSCID) and privkey to use (BobAliceSecretKey). Anything sent > > from Bob to this short channel id and pubkey is in fact forwarded via > > a > > new HTLC to Alice. > > Alice identity BobAliceKey to create an invoice, with a route-hint to > > say pubkey=Bob, short_channel_id=BobAliceSCID. Alice can sign > > that invoice, and Bob can decode the incoming payment, from which it > > creates a new HTLC to pay Alice. The payer doesn't even know this > > arrangement exists: it looks exactly like Alice has a private channel > > with Bob. > > The minor downside: because we conflate invoice keys (Alice needs) > > and > > onion keys (Bob needs), Bob can now issue invoices as Alice. It's > > not > > very useful, since Alice won't honor them, but it is an argument for > > a separate invoice key in future. > > Cheers, > > Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
