Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers
On 14/11/2019 03:59, Rusty Russell wrote: > Yaacov Akiba Slama writes: >> So we can integrate between them without intermixing the semantics of >> the protocols but we need only to define the interaction points between >> them. >> >> In the previous worflow, the seller can for instance add in the LN >> invoice H(Quotation (UBL)||Order(UBL)||Prepayment Invoice(UBL)), and use >> H(Receipt(UBL)) as preimage. With such a workflow, the UBL documents are >> cryptographically tied to the LN payment. >> >> So the property of UBL of not being machine *handlable* is not altered >> but the LN cryptographic properties are still used to tie the workflow. >> >> Am I missing something? > Sure, people can do this today: simply set your `d` field to "UBL: > ". Exactly. But we can add a BOLT which contains 1) references to UBL as a way to exchange the business information needed in the payer<->payee interactions and 2) describe the process of tying the document(s) to the payment(s). > But it provide what we want from offers: > 1. Does not provide a "static invoice" flow. What do you mean by "static invoice" flow? Perhaps: * Seller -> Buyer: Invoice (UBL) * Seller -> Buyer: Invoice (LN) * Buyer & Seller: Payment + Ack (LN) * Seller -> Buyer: Receipt (UBL) > 2. Does not provide a donation flow. * Payer -> Payee: Order (UBL) * Payee ->Payer: Invoice (LN) * Payer & Payee: Payment + Ack (LN) * Payer -> Payer: Receipt (UBL) > 3. Does not provide a method for wallets to do recurrence. A simplified workflow can be: * Seller -> Buyer: Quotation (UBL) containing recurring information * Buyer -> Seller: Order (UBL) containing recurring information Then at every beginning/end of period (depending on the info in the quotation/order) * Seller -> Buyer: Invoice (UBL) * Seller -> Buyer: Invoice (LN) (d contain the hash of the invoice + f(previous docs)) * Buyer & Seller: Payment & Ack (LN) * Seller -> Buyer: Receipt (UBL) > 4. Does not provide end-to-end over LN (i.e. no HTTP(s) requests). Yes as soon as LN support messaging (using [1] or [2] for instance) --yas [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html [2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
> > > So then because unilateral close is the only way to resolve atm, it is > > correct also in theory that there will never be a commitment tx where the > > non-initiator pays fees? But the point is clear, channels can get stuck. > > Yeah. Generally, it doesn't happen because we insist on a reasonable > balance in the channel, but it's theoretically possible. > Ok, summarizing just for clarity: - there will never be a commitment tx where the non-initiator pays fees - generally a unilateral close doesn't happen because we insist on a reasonable balance in the channel > >> > If we hard-code a constant, we won't be able to adapt to changes of > >> > `dustRelayFee` in the bitcoin network. And we'd also need to deal > with a > >> > peer picking a value higher than that constant for its regular funding > >> flow > >> > dust limit parameter. > >> > >> Note that we can't adapt to dustRelayFee *today*, since we can't change > >> it after funding (another thing we probably need to fix). > >> > > > > You can't for an existing channel, but at least for a new channel you can > > pick a different value. Which wouldn't be possible if we'd put a fixed > > (anchor) amount in the spec. > > That's not really much consolation though for the existing network. > > Still Matt assures me that the relay dust limit is not going to change, > so I think we're best off cutting down our test matrix by choosing a > value and putting it directly into the spec. > > By my calculations, at minfee it will cost you ~94 satoshis to spend. > Dust limit is 294 for Segwit outputs (basically assuming 3x minfee). > > So I'm actually happy to say "anchor outputs are 294 satoshi". These > are simply spendable, and still only $3 each if BTC is $1M. Lower is > better (as long as we stick with funder-pays), as long as they do > eventually get spent. > Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is `dustRelayFee` really never going to change? It even is a (hidden) cmd line parameter that can be set easily. If the fee market would rise and stay high for an extended period of time, why wouldn't people use this flag to raise the dust relay fee? If we then have our hard coded 294 sat anchors, no force close transactions can be broadcast anymore. It would be risky to open new channels at that point, because they can only be coop closed. Maybe Lightning is relevant enough by that time to keep people from touching `dustRelayFee`, but what if not? The fix at that point would be to introduce a new commitment format, which given our process takes a long time. I'd think that having at least an option to adapt to `dustRelayFee` changes for new channels makes Lightning more robust. The two options that I know of are: - Reuse `dust_limit_satoshis` on the `open_channel`/`accept_channel` messages as the anchor size. This ignores that an anchor does not need to be net positive after sweeping (because it's purpose is to get the commit tx confirmed), while we generally do want htlcs to be net positive. It may however be not such a big deal in practice. Suppose we'd just set this to 294 sat to get the desired anchor output value (and make it a soft requirement for channel acceptance). The worst that can happen is that there is a force close with one or more pending htlcs that aren't economical to sweep. Which can happen anyway because this is a channel open parameter and it is impossible to know what is economical for the lifetime of the channel. Instead of burning to fees, the htlc output will sit there waiting for fees to go down. It may have expired by then and either party can claim it. Not perfect, but could it be good enough? - Add a new `anchor_msat` field to the opening messages. We could add to the spec "nodes MAY reject the channel if `anchor_sat` isn't 294". At least then we are not hard-coding the value in the spec. We *could* tweak both anchors by the same amount, but then you'd still > need to see one of them to spend the other. I don't think the tweak adds anything, because there is already enough tweak on the other outputs? Only in the case of just a tweakless (`option_static_remote_key`) `to_remote` output, there will also be a tweakless anchor. But the same reasoning applies there as before: you won't send this tx to a watchtower? Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Doubt regarding payment channel capacity
Hello everyone, My doubt might be silly and apologies for the same. Suppose in a payment channel network say 2 parties B and C are malicious, controlled by same adversary. They had initially opened a channel of 1 BTC. But suppose they get 3 transaction request will flow value of 0.4 BTC each. After 1st 2 transaction, B and C has capacity of 0.2 BTC. But what if BC reports an incorrect residual balance thereby accepting the 3rd transaction. Who will keep track of this capacity violation since no one is keeping track of this residual value ? If this case is true, then parties might resort to such a strategy opening a low value channel but still accepting multiple transactions where the total payment value of all transaction exceeds channel capacity. Please correct me if I am wrong. -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Doubt regarding payment channel capacity
Hello, What happens between two peers is no business of others. They can do what you said if they're cooperating, and many other dirty tricks. And that's not a problem at all for other nodes. The only thing they can't do for not is advertise a channel without telling others where it was funded on the chain, but that's just for antispam reasons (as other nodes must keep track of all announced channels) as far as I know. On Thursday, November 14, 2019, Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > Hello everyone, >My doubt might be silly and apologies for the same. Suppose in a payment channel network say 2 parties B and C are malicious, controlled by same adversary. They had initially opened a channel of 1 BTC. But suppose they get 3 transaction request will flow value of 0.4 BTC each. After 1st 2 transaction, B and C has capacity of 0.2 BTC. But what if BC reports an incorrect residual balance thereby accepting the 3rd transaction. Who will keep track of this capacity violation since no one is keeping track of this residual value ? If this case is true, then parties might resort to such a strategy opening a low value channel but still accepting multiple transactions where the total payment value of all transaction exceeds channel capacity. Please correct me if I am wrong. > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
