Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

[Ross Dyson]

Hi Rusty,

We spoke in detail about this after your presentation at LNconf. I'm one of
the contributors to LNURL so I am a little familiar with what you're trying
to achieve and am very grateful you're considering implementing something
similar to the mainnet protocol.

I can only see delivery address being a nightmare for the network or wallet
providers. If you take a quick look at any Shopify website right now and
try to buy something to be delivered you will see validation of address
inputs before accepting payment.

This is the 'expected' UX of consumer applications in 2019. If offers were
to not validate address inputs correctly the user will not receive the
product, lose money, and have a [very] negative review of both the
wallet-providing and the offer-providing businesses.

Handling these UX expectations will require either the wallet provider or
the offer provider to validate the inputs before proceeding with the sale.

   1. If the offer provider handles validation then the network will have
   to accommodate potentially infinite validation attempts (big no no I assume)
   2. If the wallet provider were to provide the UX for input validation
   they are taking on significant workload to develop a robust address input
   UI, but more importantly the responsibility to correctly validate. There is
   plenty of room to screw up and create a catastrophic user experience.

So I think address validation input is only possible via 2. but I think it
is too much workload and responsibility to expect from wallet providers.
>From what I can see, it would not be impossible to bring delivery address
functionality into offers retroactively after offers was already in prod.
Perhaps icebox it?

I am very excited for LNOs and LNIs. If we want to get offers in prod and
being facilitated by wallet providers I think it would be best if it was
streamlined a little first.

Thanks for reading,

Ross

On Fri, Nov 8, 2019 at 3:40 PM Yaacov Akiba Slama  wrote:

> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
> > Hi Yaacov,
> >  I've been pondering this since reading your comment on the PR!
> >
> >  As a fan of standards, I am attracted to UBL (I've chaired an
> > OASIS TC in the past and have great respect for them); as a fan of
> > simplicity I am not.  Forcing UBL implementation on wallet providers is
> > simply not going to happen, whatever I were to propose.
>
> In fact, using UBL in LN specification is simpler than trying to
> understand the semantic of each field needed by businesses. You are
> right that using such a standard put the burden into wallet providers
> instead of LN developers, but as a wallet (breez) provider, I can say that:
>
> 1) Most money transactions (currently in fiat) are between users and
> companies and not between two users. If we want to replace FIAT by
> bitcoin, we need to create an infrastructure which can be used by
> businesses. That means that LN needs to be able to be integrated easily
> into POS systems. So, as a wallet provider who want to help the
> transition from fiat to bitcoin, I need to be able to support standards
> even if that means that I have to implement using/parsing big and
> complicated standards.
>
> For simple user to user transaction, the wallet can decide to use only a
> subset of the fields defined by the standard.
>
> 2) From a technical point of view, it seems that there are already UBL
> libraries in java and c#. I don't think such library is hard to write in
> go, rust.., so every wallet implementation can use them.
>
> >
> >   We also don't want duplication; what if the "UBL field" were to
> > say I were selling you a bridge for $1 and the description and amount
> > fields actually said I was selling you a coffee for $3?
> >
> >   However, since invoices/offers and UBL are both structures, we
> > should have an explicit mapping between the two.  What fields should
> > have their own existence in the invoice/offer and what should be in a
> > general UBL field is a question we have to think on further.
> I agree that we don't want duplication. This is the reason, I propose to
> use only ubl structure and add in the ln standard invoice an ubl
> "opaque" field which will be self-contained and only add in the
> invoice/offer/.. the fields specific to ln.
> >  Anyway, you'll have to bear with me as I read this 172 page
> > standard...
>
> Sure :-)
>
> BTW, Thanks a lot for your all your work. LN would not have been where
> it is without your push.
>
> ___
> 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] [VERY ROUGH DRAFT] BOLT 12: Offers

[Yaacov Akiba Slama]

Hi Rusty.

On 08/11/2019 05:09, Rusty Russell wrote:

Hi Yaacov,
 I've been pondering this since reading your comment on the PR!

 As a fan of standards, I am attracted to UBL (I've chaired an
OASIS TC in the past and have great respect for them); as a fan of
simplicity I am not.  Forcing UBL implementation on wallet providers is
simply not going to happen, whatever I were to propose.


In fact, using UBL in LN specification is simpler than trying to 
understand the semantic of each field needed by businesses. You are 
right that using such a standard put the burden into wallet providers 
instead of LN developers, but as a wallet (breez) provider, I can say that:


1) Most money transactions (currently in fiat) are between users and 
companies and not between two users. If we want to replace FIAT by 
bitcoin, we need to create an infrastructure which can be used by 
businesses. That means that LN needs to be able to be integrated easily 
into POS systems. So, as a wallet provider who want to help the 
transition from fiat to bitcoin, I need to be able to support standards 
even if that means that I have to implement using/parsing big and 
complicated standards.


For simple user to user transaction, the wallet can decide to use only a 
subset of the fields defined by the standard.


2) From a technical point of view, it seems that there are already UBL 
libraries in java and c#. I don't think such library is hard to write in 
go, rust.., so every wallet implementation can use them.




We also don't want duplication; what if the "UBL field" were to
say I were selling you a bridge for $1 and the description and amount
fields actually said I was selling you a coffee for $3?

However, since invoices/offers and UBL are both structures, we
should have an explicit mapping between the two.  What fields should
have their own existence in the invoice/offer and what should be in a
general UBL field is a question we have to think on further.
I agree that we don't want duplication. This is the reason, I propose to 
use only ubl structure and add in the ln standard invoice an ubl 
"opaque" field which will be self-contained and only add in the 
invoice/offer/.. the fields specific to ln.

 Anyway, you'll have to bear with me as I read this 172 page
standard...


Sure :-)

BTW, Thanks a lot for your all your work. LN would not have been where 
it is without your push.


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

[Rusty Russell]

Yaacov Akiba Slama  writes:
> Hi Rusty,
>
> It seems that there are two kind of TLV fields in your proposition:
> 1) LN specific fields like `num_paths` and `payment_preimage`.
> 2) "Business" fields like `address1` and `currency`.
> I understand the need to define and include the first category, but I 
> don't think that we need or can define the second category. These fields 
> already exists in software like crm, erp, etc.. and are well defined by 
> standard body.
> My suggestion is to have a generic field containing well defined 
> structured and standardized data. See for instance 
> https://en.wikipedia.org/wiki/EDIFACT and/or 
> https://en.wikipedia.org/wiki/Universal_Business_Language.

Hi Yaacov,

I've been pondering this since reading your comment on the PR!

As a fan of standards, I am attracted to UBL (I've chaired an
OASIS TC in the past and have great respect for them); as a fan of
simplicity I am not.  Forcing UBL implementation on wallet providers is
simply not going to happen, whatever I were to propose.

We also don't want duplication; what if the "UBL field" were to
say I were selling you a bridge for $1 and the description and amount
fields actually said I was selling you a coffee for $3?

However, since invoices/offers and UBL are both structures, we
should have an explicit mapping between the two.  What fields should
have their own existence in the invoice/offer and what should be in a
general UBL field is a question we have to think on further.

Anyway, you'll have to bear with me as I read this 172 page
standard...

Cheers,
Rusty.

> What do you think?
> PS: Sorry for crossposting here and in 
> https://github.com/lightningnetwork/lightning-rfc/pull/694
> --yas
>
> On 05/11/2019 06:23, Rusty Russell wrote:
>> Hi all,
>>
>>  This took longer than I'd indicated; for that I'm sorry.
>> However, this should give us all something to chew on.  I've started
>> with a draft "BOLT 12" (it might be BOLT 13 by the time it's finalized
>> though!).
>>
>> I've also appended indications where we touch other BOLTs:
>> 1. BOLT 7 gains a message/reply system, encoded like htlc onions and
>> failure messages.
>> 2. BOLT 11 gains a `q` field for quantity; this avoids changing the
>> description when the user requests an invoice for more than one of 
>> something
>> (since changing the description between offer and invoice requires user
>> interaction: it's the *invoice* which you are committing to).
>>
>> There's definite handwaving in here; let's see if you can find it!
>>
>> Cheers,
>> Rusty.
>>
>> # BOLT #12: Offer Protocols for Lightning Payments
>>
>> An higher-level, QR-code-ready protocol for dealing with invoices over
>> Lightning.  There are two simple flows supported: in one, a user gets
>> an offer (`lno...`) and requests an invoice over the lightning
>> network, obtaining one (or an error) in reply.  In the other, a user
>> gets an invoice request (`lni...`), and sends the invoice over the
>> lightning network, retreiving an empty reply.
>>
>> # Table of Contents
>>
>>* [Offers](#offers)
>>  * [Encoding](#encoding)
>>  * [TLV Fields](#tlv-fields)
>>* [Invrequests](#invrequests)
>>  * [Encoding](#encoding)
>>  * [TLV Fields](#tlv-fields)
>>
>> # Offers
>>
>> Offers supply a reader with enough information to request one or more
>> invoices via the lightning network itself.
>>
>> ## Encoding
>>
>> The human-readable part of a Lightning offer is `lno`.  The data part
>> consists of three parts:
>>
>> 1. 0 or more [TLV](01-messaging.md#type-length-value-format) encoded fields.
>> 2. A 32-byte nodeid[1]
>> 3. 64-byte signature of SHA256(hrp-as-utf8 | tlv | nodeid).
>>
>> ## TLV Fields
>>
>> The TLV fields define how to get the invoice, and what it's for.
>> Each offer has a unique `offer_idenfitier` so the offering node can
>> distinguish different invoice requests.
>>
>> Offers can request recurring payments of various kinds, and specify
>> what base currency they are calculated in (the actual amount will be
>> in the invoice).
>>
>> `additional_data` is a bitfield which indicates what information the
>> invoice requester should (odd) or must (even) supply:
>> 1. Bits `0/1`: include `delivery_address`
>> 2. Bits `2/3`: include `delivery_telephone_number`
>> 3. Bits `4/5`: include `voucher_code`
>> 4. Bits `6/7`: include `refund_proof`
>>
>> `refund_for` indicates an offer for a (whole or part) refund for a
>> previous invoice, as indicated by the `payment_hash`.
>>
>> 1. tlvs: `offer`
>> 2. types:
>>  1. type: 1 (`paths`)
>>  2. data:
>>  * [`u16`:`num_paths`]
>>  * [`num_paths*path`:`path`]
>>  1. type: 2 (`description`)
>>  2. data:
>>  * [`...*byte`:`description`]
>>  1. type: 3 (`expiry`)
>>  2. data:
>>  * [`tu64`:`seconds_from_epoch`]
>>  1. type: 4 (`offer_identifier`)
>>  2. data:
>>  * [`...*byte`:`id`]
>>  1. type: 5 

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

[Rusty Russell]

ZmnSCPxj  writes:
> First, please confirm my understanding of the message flow.
> Suppose I have a donation offer on my website and Rusty wants to donate to me.
> Then:
>
>  ZmnSCPxj  Rusty
> ||
> +-- `lno` -->+ (via non-Lightning communication 
> channel e.g. https)
> ||
> +< `invoice_request` + (via a normal Rusty->ZmnSCPxj 
> payment)
> ||
> + `invoice_or_error` --->| (by failing the above payment and 
> embedding in the failure blob)
> ||
> +<--- `sendpay` -+ (via a normal Rusty->ZmnSCPxj 
> payment)
>
> Is it approximately correct?

Sorry for delayed response; yes, this is correct.

>> gets an invoice request (`lni...`), and sends the invoice over the
>> lightning network, retreiving an empty reply.
>
> Here are completely pointless counterproposals for the offer and 
> invoice-request HRPs:
>
> * Offers:
>   * `lnpayme`
>   * `lnbuyit`
>   * `lnforsale`
> * Invoice Requests:
>   * `lnpaying`
>   * `lnbuying`
>   * `lnshutupandtakemymoney`
>
> `lno` and `lni` feel wrong to me.
> Their juxtaposition implies `lno` == output and `lni` == input to me, due to 
> the use of `o` and `i`, though `lno` is where you get money in exchange for 
> product and `lni` is the request-for-service.

lnx and lny?  Nobody can interpret them at all, that way :)
>> 3.  type: 2 (`description`)
>> 4.  data:
>> -   [`...*byte`:`description`]
>
> UTF-8?
> Null-terminated?

I was thinking UTF-8 like current field.

>> -   MUST include `amount` if it includes `recurrence`.
>> -   if it includes `amount`:
>> -   MUST specify `currency` as the ISO 4712 or BIP-0173, padded with 
>> zero bytes if required
>
> I cannot find ISO 4712, but could find ISO 4217.

Oops, I fixed my typo wrong.  Thanks.

> BIP-173 does not have a list of currencies, but refers to SLIP-0173.
> Some of the listed currencies there seem to have more than 4 characters.

Oh, I'd never seen SLIP-0173.  Cool, I increased it to 5; SLIP-0173 has
no limit but I find it hard to care about any of them anyway.

> Should I assume encoding is ASCII?
> We will "never" see a non-ASCII currency code?

Not really, but if you don't understand it you can't do much, ASCII or
no.

>> The "default offer" of a node is a nominal offer used to send
>> unsolicited payments. It is generally not actually sent, but can be
>> used by any other node as if it has been. It has the following
>> fields:
>>
>> -   `offer_idenfitier`: zero-length
>> -   `d`: any
>> -   `n`: the node id of the recipient.
>
> In essence, this is an implicitly-existing offer that never expires, and 
> which can be used by any node at any time to construct an invoice request?

Yep!

>> The `refund_proof` refers to a previous invoice paid by the sender for
>> the specific case of a `refund_for` offer. It provides proof of
>> payment (the `payment_preimage` and also a signature of the
>> `payment_hash` from the `key` which requested the being-refunded
>> invoice (which does not have to be the same as this `key`!).
>
> An earlier requirement mentions that writers of offers or invoice request 
> MUST have `paths` in some condition.
> The below does not have `paths`, but there is a "human-readable" alternate 
> encoding which *does* have `paths`.
> It might be better to clarify this point.

The in-wire one doesn't have paths, since you respond by reply; you
don't need (and should not be able to) find the sender.

The non-wire one needs a path, since you need to initiate a reply.

>> The `directed` and `directed_reply` Messages
>>
>> -
>>
>> 1.  type: 384 (`directed`) (`option_directed_messages`)
>> 2.  data:
>> -   [`chain_hash`:`chain_hash`]
>> -   [`u64`:`id`]
>> -   [`1366*byte`:`onion_routing_packet`]
>> 3.  type: 384 (`directed_reply`) (`option_directed_messages`)
>> 4.  data:
>> -   [`chain_hash`:`chain_hash`]
>> -   [`u64`:`id`]
>> -   [`u16`:`len`]
>> -   [`len*byte`:`reply`]
>
> This new `directed` message will be the mechanism for sending invoice 
> requests and receiving invoice request responses?

Yes.

> What incentive is there for a forwarding node to actually forward a 
> `directed` message?

It's a strong liveness indicator to the sender, so they're likely to use
the same path for the actual payment.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[Rusty Russell]

Anthony Towns  writes:
> On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
>> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
>> > field: it says 14, ." but Alice doesn't know anything other than
>> >  so can't put  in the onion?
>> Alice created the onion.  Alice knows all the preimages, since she
>> created the chain AZ.
>
> In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating
> the chain ... -- so I was lost as to what you were proposing...

Oops.  Don't trust that Rusty guy, let's stick with Alice.

[ Snip summary, which is correct ]

> As far as the "fair price" goes, the spitballed formula is "16 - X/4"
> where X is number of zero bits in some PoW-y thing. The proposal is
> the thing is SHA256(blockhash|revealedonion) which works, and (I think)
> means each step is individually grindable.
>
> I think an alternative would be to use the prepayment hashes themselves,
> so you generate the nonce  as the value you'll send to Dave then
> hash it repeatedly to get .., then check if pow(,) has
> 60 leading zero bits or pow(,) has 56 leading zero bits etc.
> If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd
> preserve privacy, but also mean you can't meaningfully grind unfairly
> cheap routing except for very short paths?
>
> If you don't grind and just go by luck, the average number of hashes
> per hop is ~15.93 (if I got my maths right), so you should be able to
> estimate path length pretty accurate by dividing claimed prepaid funds by
> 15.93*25msat or whatever. If everyone grinds at each level independently,
> I think you'd just subtract maybe 6 hops from that, but the maths would
> mostly stay the same?
>
> Though I think you could obfusticate that pretty well by moving
> some of the value from the HTLC into the prepayment -- you'd risk losing
> that extra value if the payment made it all the way to the recipient but
> they declined the HTLC that way though.

Yeah, and doesn't help obscure in the in-the-middle failure case unf.
Which is really bad with current payment_hash since you can spot
multiple attempts so easily.  Hence my attempt to roll in some PoW to
obscure the amounts.

The ideal prepay range would be wider, so you can believably have
payments between 16 and 4 per hop, say.  But if I can grind it I'll
naturally restrict the range to the lower end, and if it's ungrindable
(eg. based on nodeid and payment_hash or recent block hash) then
everyone on the path knows what it so too.

So, hashcash here is better than nothing, but still not very good.

>> >> Does Alice lose everything on any routing failure?
>> > That was my thought yeah; it seems weird to pay upfront but expect a
>> > refund on failure -- the HTLC funds are already committed upfront and
>> > refunded on failure.
>> AFAICT you have to overpay, since anything else is very revealing of
>> path length.  Which kind of implies a refund, I think.
>
> I guess you'd want to pay for a path length of about 20 whether the
> path is actually 17, 2, 10 or 5. But a path length of 20 is just paying
> for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of
> 1 cent, which doesn't seem that worth refunding (except for really tiny
> micropayments, where paying for payment bandwidth might not be feasible
> at all).
>
> If you're buying a $2 coffee and paying 500ppm in regular fees per hop
> with 5 hops, then each routing attempt increases your fees by 4%, which
> seems pretty easy to ignore to me.

True, but ideally we'd have lots of noise even if people are trying to
minimize fees (which, if they're sending messages rather than payments,
they might).

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[Rusty Russell]

Joost Jager  writes:
>>
>> > Isn't spam something that can also be addressed by using rate limits for
>> > failures? If all relevant nodes on the network employ rate limits, they
>> can
>> > isolate the spammer and diminish their disruptive abilities.
>>
>> Sure, once the spammer has jammed up the network, he'll be stopped.  So
>> will everyone else.  Conner had a proposal like this which didn't work,
>> IIRC.
>
> Do you have ref to this proposal?
>
> Imagine the following setup: a network of nodes that trust each other (as
> far as spam is concerned) applies a 100 htlc/sec rate limit to the channels
> between themselves. Channels to untrusted nodes get a rate of only 1
> htlc/sec. Assuming the spammer isn't a trusted node, they can only spam at
> 1 htlc/s and won't jam up the network?

Damn, I searched for it but all the obvious keywords turned up blank.
Conner CC'd in case he remembers the discussion and I'm not imagining it?

Anyway, if there are 100 nodes in the network I can still open a channel
to each one and jam it up immediately.  And that's not even assuming I
play nice until you trust me, then attack or get taken over.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[Yaacov Akiba Slama]

On 07/11/2019 16:43, Joost Jager wrote:
On Thu, Nov 7, 2019 at 3:36 PM lisa neigut > wrote:


> Imagine the following setup: a network of nodes that trust each
other

The goal of this pre-payment proposal is to remove the need for
trusted parties


Trust isn't the right word. It is a level of service that you provide 
to your peers. If nodes are cognizant of the fact that the level of 
service they receive goes down if they forward spam, they will be 
careful on the incoming side. Require peers to build up a reputation 
before increasing the inbound limits that apply to the channels with them.
We can learn from the current situation in emails, that a system based 
on reputation tends to concentrate the power in the hands of few big and 
strong actors (gmail and co). If we have from the beginning a mechanism 
to fight against spam by paying to send message, we can perhaps have a 
really distributed system which cannot be censured.

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[Joost Jager]

On Thu, Nov 7, 2019 at 3:36 PM lisa neigut  wrote:

> > Imagine the following setup: a network of nodes that trust each other
>
> The goal of this pre-payment proposal is to remove the need for trusted
> parties
>

Trust isn't the right word. It is a level of service that you provide to
your peers. If nodes are cognizant of the fact that the level of service
they receive goes down if they forward spam, they will be careful on the
incoming side. Require peers to build up a reputation before increasing the
inbound limits that apply to the channels with them.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[lisa neigut]

> Imagine the following setup: a network of nodes that trust each other

The goal of this pre-payment proposal is to remove the need for trusted
parties.

On Thu, Nov 7, 2019 at 07:38 Joost Jager  wrote:

> > Isn't spam something that can also be addressed by using rate limits for
>> > failures? If all relevant nodes on the network employ rate limits, they
>> can
>> > isolate the spammer and diminish their disruptive abilities.
>>
>> Sure, once the spammer has jammed up the network, he'll be stopped.  So
>> will everyone else.  Conner had a proposal like this which didn't work,
>> IIRC.
>>
>
> Do you have ref to this proposal?
>
> Imagine the following setup: a network of nodes that trust each other (as
> far as spam is concerned) applies a 100 htlc/sec rate limit to the channels
> between themselves. Channels to untrusted nodes get a rate of only 1
> htlc/sec. Assuming the spammer isn't a trusted node, they can only spam at
> 1 htlc/s and won't jam up the network?
> ___
> 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] [PATCH] First draft of option_simplfied_commitment

[Joost Jager]

>
> > We could
> > simplify this to a single to_self_delay that is proposed by the
> initiator,
> > but what was the original reason to allow distinct values?
>
> Because I didn't fight hard enough for simplicity :(
>

But the people you were fighting with, what reason did they have? Just
flexibility in general, or was there an actual use case? Maybe these people
are reading this email and can comment?

There is no "negotiation" on opening; it's accept or error.  That leads
> to a situation where every implementation MUST accept what every
> implementation offers.
>

Agreed that the verb negotiate is a bit misleading. Although the
open/accept sequence could be repeated several times to make it more of a
negotiation.


> The unification proposal was to use the max of the two settings.  That's
> fair; if you want me to suffer a 2 week delay, you should too.
>

Yes, we could do that as part of this new commitment format. Make that an
implicit consequence of `option_anchor_outputs` (or whatever its name will
be). The semantics need to change anyway, because we want that CSV lock on
every output.


> >> * Within each version of the commitment transaction, both anchors always
> >> > have equal values and are paid for by the initiator.
> >>
> >> Who pays if they can't afford it?  What if they push_msat everything to
> >> the other side?
> >
> > Similar to how it currently works. There should never be a commitment
> > transaction in which the initiator cannot pay the fee.
>
> Unfortunately, this is not correct (in theory).
>
> We can always get into a case where fees are insufficient (simultanous
> HTLC adds), but it's unusual.  We used to specify that the non-funder
> would pay the remaining fee, but we dropped this in favor of allow
> unilateral close if this ever happened.
>

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.


> > With anchor outputs
> > there should never be a commitment tx in which the initiator cannot pay
> the
> > fee and the anchors.
>
> There can be, but I think we can simply modify this so you have to pay
> the anchors *first* before fees.
>

That way it seems that adding the anchors doesn't make the stuck channel
problem that you described above worse?


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


> If we really want to make it adjustable, could we make each side pay for
> its own; if you can't afford it, you don't get one?  There's no point
> the funder paying for a fundee-anchor if the fundee has no skin in the
> game.
>
> That reduces the pressure somewhat, I think?
>

If you can't afford you don't get one, not sure about that. I could open a
channel, send out the total capacity an in htlc to myself via some other
hops, force close with a very low commit fee, then pull in the htlc (one
time the money). The victim then needs to get the commit confirmed to claim
the money, but there is no anchor unfortunately. I wait for the htlc to
expire, then anchor down the commit tx and time out the htlc (twice the
money).


> > In the light of this forgotten insight, is there a reason why the anchor
> > output would need key rotation? Having no rotation makes it easier to let
> > those anchors go straight into the wallet, which may mitigate the dust
> utxo
> > problem a bit. At least then they can be easily coin-selected for any
> > on-chain spent, if the market fees are low enough.
>
> Or what about we rotate the anchors and nothing else, which (assuming we
> make it anyone-can-spend-after-N-blocks) reduces the amount of onchain
> spam if someone completely loses their keys?
>
> That's a bigger change, but maybe it's worth it?
>

We now have David's great proposal to reuse the funding keys for the anchor
output. That allows us to always let anyone spend after confirmation,
because they can reconstruct the spend script. But I think this also means
that we cannot do rotation on the anchor keys. We need to use the funding
pubkey as is.

Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[Joost Jager]

>
> > Isn't spam something that can also be addressed by using rate limits for
> > failures? If all relevant nodes on the network employ rate limits, they
> can
> > isolate the spammer and diminish their disruptive abilities.
>
> Sure, once the spammer has jammed up the network, he'll be stopped.  So
> will everyone else.  Conner had a proposal like this which didn't work,
> IIRC.
>

Do you have ref to this proposal?

Imagine the following setup: a network of nodes that trust each other (as
far as spam is concerned) applies a 100 htlc/sec rate limit to the channels
between themselves. Channels to untrusted nodes get a rate of only 1
htlc/sec. Assuming the spammer isn't a trusted node, they can only spam at
1 htlc/s and won't jam up the network?
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A proposal for up-front payments.

[Anthony Towns]

On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
> > field: it says 14, ." but Alice doesn't know anything other than
> >  so can't put  in the onion?
> Alice created the onion.  Alice knows all the preimages, since she
> created the chain AZ.

In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating
the chain ... -- so I was lost as to what you were proposing...

Here's what I now think you're saying, which I think mostly hangs
together:

Alice sends a HTLC with hash X and value V to Dave via Bob then Carol

Alice generates a nonce , and calculates H^25() = .

Alice creates an onion, and sends the HTLC to Bob, revealing  and
6, to Bob, along with 2500 msat (25 for the hashing ops between
 and , and *100 for round numbers). Bob calculates "6" is a
fair price.

Bob checks H^6()=. If not, Bob refunds the 2500 msat, and fails
the HTLC immediately. Otherwise, Bob passes the onion on to Carol, with
1900 msat and ; Carol unwraps the onion revealing 15,. Carol
calcualtes "15" is a fair price.

Carol checks H^15()=, and fails the route if not, refunding
1900msat to Bob. Otherwise, Carol passes the onion on to Dave, with 400
msat and .  Dave unwraps the onion, revealing 2,, so can claim
200 msat as well as the HTLC amount, etc.

After the successful route, Dave passes 2, and 200msat back to Carol,
who validates and continues passing things back.

If Carol instead passes, say, 3, back, then she also has to refund
300msat to avoid Bob closing the channel, which would be fine, because
Bob can just pass that back too -- Carol's the only one losing money in
that case.

If Carol wants to close the channel anyway and collect the HTLC on
chain, then Bob's situation is:

   channel with Alice: +2500 msat
   channel with Carol: -1900 msat , -fees , -HTLC funds

If Carol isn't cooperative, Bob only definitely knows , so to keep
the channel open with Alice, has to refund 1900msat, so:

   channel with Alice:  +600 msat , +HTLC funds
   channel with Carol: -1900 msat , -fees , -HTLC funds

(or Bob could keep the 2500 msat at the cost of Alice closing the channel
too:

   channel with Alice: +2500 msat , -fees , +HTLC funds
   channel with Carol: -1900 msat , -fees , -HTLC funds
)

So Bob and either keep the channel open but is out 1300 msat because of
Carol, or can gain 600 msat at the cost of closing the channel with
Alice?

As far as the "fair price" goes, the spitballed formula is "16 - X/4"
where X is number of zero bits in some PoW-y thing. The proposal is
the thing is SHA256(blockhash|revealedonion) which works, and (I think)
means each step is individually grindable.

I think an alternative would be to use the prepayment hashes themselves,
so you generate the nonce  as the value you'll send to Dave then
hash it repeatedly to get .., then check if pow(,) has
60 leading zero bits or pow(,) has 56 leading zero bits etc.
If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd
preserve privacy, but also mean you can't meaningfully grind unfairly
cheap routing except for very short paths?

If you don't grind and just go by luck, the average number of hashes
per hop is ~15.93 (if I got my maths right), so you should be able to
estimate path length pretty accurate by dividing claimed prepaid funds by
15.93*25msat or whatever. If everyone grinds at each level independently,
I think you'd just subtract maybe 6 hops from that, but the maths would
mostly stay the same?

Though I think you could obfusticate that pretty well by moving
some of the value from the HTLC into the prepayment -- you'd risk losing
that extra value if the payment made it all the way to the recipient but
they declined the HTLC that way though.

> >> Does Alice lose everything on any routing failure?
> > That was my thought yeah; it seems weird to pay upfront but expect a
> > refund on failure -- the HTLC funds are already committed upfront and
> > refunded on failure.
> AFAICT you have to overpay, since anything else is very revealing of
> path length.  Which kind of implies a refund, I think.

I guess you'd want to pay for a path length of about 20 whether the
path is actually 17, 2, 10 or 5. But a path length of 20 is just paying
for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of
1 cent, which doesn't seem that worth refunding (except for really tiny
micropayments, where paying for payment bandwidth might not be feasible
at all).

If you're buying a $2 coffee and paying 500ppm in regular fees per hop
with 5 hops, then each routing attempt increases your fees by 4%, which
seems pretty easy to ignore to me.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] HORNET via Circular Self-payment Routing in a Decorrelation Payment Points+Scalar Lightning Network

[ZmnSCPxj via Lightning-dev]

Introduction


[HORNET](https://www.scion-architecture.net/pdf/2015-HORNET.pdf) is a mix 
network that uses a very secure (and computationally expensive) onion routing 
to establish sessions.
Then, once the session is established, it uses a simpler onion routing system, 
whose security is then dependent on the session-establishment security, but 
which is computationally simpler on all forwarding nodes.

There are vague plans to implement some form of HORNET on Lightning, in order 
to allow e.g. an on-Lightning return path for Stuckless ACK, or communications 
method for Lightning Offers.

The Sphinx construction is an onion-routing construction used by HORNET in its 
session-establishment phase.
Incidentally, Lightning itself uses the Sphinx construction as the basis for 
its [payment forwarding 
specifications](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md).

[Payment Decorrelation](https://eprint.iacr.org/2018/472.pdf) prevents two 
cooperating, but distant, intermediate nodes from correlating that forwards 
going through them are actually the same single payment.
This prevents both the "wormhole" attack (where they "shortcut" the intervening 
nodes and steal the fees from them) as well as preventing easy monitoring of 
payments.
Payment decorrelation requires payment points and scalars to be implemented on 
the network.

HORNET Session Establishment and Operation
==

* WARNING: I do not understand the HORNET paper.
  Thus, mistakes may appear below.
  The below is not the complete HORNET paper as well, thus a simplification.

In HORNET, communications between participants must first be packaged into 
abstractions called "sessions".
Thus there are two major phases:

* Setup Phase (Session establishment)
* Data Transmission Phase

HORNET allows the "sender" (the one who initiates the session) maximum privacy.
The "receiver" (the one contacted in establishing the session) is generally 
known by the sender as a particular node on the network.
With some additional construction, the receiver itself could be hidden from the 
sender behind another node.
For now, I will focus on the HORNET variant with sender anonymity, and leave 
the sender-receiver anonymity variant as an exercise to the reader.

Setup Phase
---

During setup, the sender creates two paths, the "forward" path and the "return" 
path.
The forward path is from the sender to the receiver, and the receiver path is 
from the receiver to the sender.
Ideally, the two paths will have little or no shared nodes between them.

The sender onion-encrpyts the return path, then puts it into a packet for the 
receiver.
Then the packet is onion-encrypted via the forward path.

On establishment, the sender sends to the first hop of the forward path, which 
unwraps the onion until it reaches the receiver.
Each hop also provides a "forwarding segment", which is encrypted and forwarded 
as the onion route is unwrapped.
(Basically, onion routing means that we "shift" the data by one hop; instead of 
loading zeros into the shifted data, the forwarding node shifts in its 
forwarding segment)
The forwarding segment is a secret that is then used to derive a shared secret 
with the sender later.

When it reaches the receiver, the receiver remembers the existence of the 
session, then starts unwrapping the return-path onion.
Again, it just "shifts in" all the forward-path forwarding segments, shifts in 
its own forwarding segment, and then the nodes along the return path also shift 
in their own forwarding segments.

When the return-path onion arrives at the sender, the sender can decrypt the 
onion-routed forwarding segments.
Then, it generates shared secrets with each forwarding node along the path.

The forward path allows the sender to send messages to the receiver, while the 
return path allows the receiver to reply to the sender.

Data Phase
--

The data phase uses a similar onion-like construction, where each node in the 
forwarding / return path performs some operation on the packet, then forwards 
it to the next node until it reaches the receiver / sender.

Using the shared keys, there are two operations:

* Add layer
* Remove layer

Both operations take a key (shared between the sender and the intermediate 
node), an initialization vector (a nonce), and a packet of data.
The operation returns a modified initialization vector

When the sender wants to send a message to the receiver:

* The sender starts with the receiver shared secret, and performs "add layer" 
operations in reverse along the forward path from destination to source.
* It sends out the encrypted packet and the initialization vector to the first 
intermediate node.
* Each intermediate node performs "remove layer" and forwards the packet and 
the initialization vector to the next intermediate node.
* On reaching the receiver, it performs a final "remove layer" and extracts the 
plaintext.

When