[Lightning-dev] Açai: a backup protocol for Lightning Network wallets

[Margherita Favaretto]

Hello, lightning dev community,

I’m writing to you to share an update of my Master Thesis project (previous
object e-mail: Recovering protocol for Lightning network 11/12/2018),
regarding a recovery mechanism of false positive in the Lightning network.


First of all, I'd like to thank Conner Fromknecht and Alex Bosworth for the
discussion during this week, and ZmnSCPxj for the feedback to my previous
email: all your suggestions were very important to proceed with my work.

Thanks also to Olaoluwa Osuntokun to notify me of the problem with my
email, I'm trying to use another one now. :-)


To recap, the problem I'm focusing on is the recovery of the unspent
bitcoins stuck inside the Lightning Network after a wallet failure (e.g.
lost or corrupted transaction data put into the wallet storage).

The Lightning Network provides higher speeds and confidentiality for
bitcoin transactions, but the absence of the underlying distributed ledger
makes impossible the recovery of unspent transactions through the
traditional cryptographic seed and the BIP32 address derivation.

My solution, named Açai Protocol, aims to use the watchtowers not just for
monitoring the channels, but also as a backup service in order to solve the
problem.

Compared to the solution proposed in the previous e-mail, I've abandoned
the idea to use a public key to encrypt data in the watchtower, and I've
decided to adopt the concepts of txid, hint and blob, to maintain the
privacy and the security of nodes.

For simplicity, I've created a project on Github:
https://github.com/margheritafav/LightningNetworkProject, where you could
find all the details about the Açai Protocol, and also you are welcome to
add your comments and feedback.

margheritafav/LightningNetworkProject

github.com
Contribute to margheritafav/LightningNetworkProject development by creating
an account on GitHub.


I hope that the explanation of the design is clear, otherwise please do not
hesitate to ask clarification.

Any thoughts/feedback would be really appreciated, to proceed in the wisest
way and find a solution that can also cover all the needs of the community.

If you are interested in this research topic, please do not hesitate to
contact me for a possible collaboration at s170...@student.dtu.dk.

Thank you very much in advance,

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

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

[Rusty Russell]

René Pickhardt  writes:
> Dear Rusty,
>
> I am not getting this proposal (maybe I am lacking some technical basic
> understandings) however I decided to ask more questions in order to
> complete my onboarding process faster and hope this is fine.
>
> My problem starts with the fact that I can't find the term "lightning probe
> message" in the current BOLTs  (actually the term probe only occures two
> times and these seem unrelated to what you are talking about) so I am
> confused what this is.

It would be a new message.  We don't have an equivalent at the moment,
though one was proposed for liveness testing of routes pre-payment:

Use probing with short latency constraints (ex” must reply within 100 
ms) to check that a route is usable before payment is actually sent

https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html

> As far as I understand your proposal from a high level the payer is
> supposed to create an onion package which triggers the offering of HTLCs
> with some additional metadata so that the receipient of the final onion can
> answer with a BOLT11 invoice. What I don't get is the fact that a payment
> hash needs to be known in order to offer HTLCs.

No, there's a new message, which looks like:

1. type: 260 (`fetch_invoice`)
2. data:
   * [`32`:`channel_id`]
   * [`1366`:`onion_routing_packet`]

(The onion doesn't need some of the current fields, TBD).

> In general I was wondering (already during the summit) why we don't include
> a connection oriented communication layer on top of the current protocol
> which would allow payer and payee to communicate more efficiently about
> payment and routing process and to negotiate stuff like spontaneos
> payments.

This is HORNET; I recommend reading the paper.  I admit that this
message is the camel's nose in the tent, but we're building a payment
network, not a generalized communication network.  And until we figure
out how to pay-per-message without haemorrhaging privacy, we shouldn't
build such a thing.

> I see two reasons against this: 1.) more synchronous
> communication makes stuff more complicated to implement and 2.) privacy
> concerns.

3) Lack of incentives.  Nodes forward because they want a functioning
payment network, and they hope to be rewarded for it.  At the moment you
can get spammed quite badly and never get paid; I'd like to make that
more difficult, not bake it into the protocol!

Someone may build such a thing on top of lightning, but lightning nodes
are not generalized bandwidth providers.

> Am I missing something here? (and sorry for splitting the topic but I
> didn't want to start a new one when it actually seems to fit to this
> proposal.

This is a can of worms I don't want to open for 1.1...

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

Re: [Lightning-dev] Wumbological local AND global features

[ZmnSCPxj via Lightning-dev]

Good morning list,

> I realized the other day that the wumbo bit should also likely encompass wumbo
> payments. What good is a wumbo channel that doesn't also allow wumbo payments?
> Naturally if the bit is signalled globally, then this should also signal the
> willingness of the node to forward larger payments up to their max_htlc limit
> within the channel_update for that link.

This certainly is true, but, much of the wumbo payments would be implemented by 
AMP.

If there is no direct path of wumborama nodes from payer to payee, then wumbo 
payments will have to be done by AMP.
It would be nice if we could have AMP merge into intermediate nodes instead of 
always at the destination --- that way, only the suffix of the path needs to be 
wumborama.
Certainly this would be less of an issue as more nodes signal wumborama; we 
know from previous user behavior that they will be #reckless and enable 
wumborama as soon as it is implemented.

Regards,
ZmnSCPxj

> On a similar note, I was reviewing the newer-ish section of the spec 
> concerning
> the optional max_htlc value. I noticed an inconsistency: it states the value
> should be below the max capacity of the channel, but makes no reference to the
> current (pre wumbo) _max HTLC limit_. As a result, as it reads now, one may
> interpret signalling of the optional field as eligibility to route wumbo
> payments in a pre-wumbo channel world.
>
> -- Laolu
>
> On Tue, Nov 13, 2018 at 3:34 PM Rusty Russell  wrote:
>
>> ZmnSCPxj via Lightning-dev  writes:
>>> Thus, I propose:
>>>
>>> * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that 
>>> the node is willing to wumbo with its counterparty in the connection.
>>> * The global feature bit `option_anyone_can_wumbo`, which indicates that 
>>> the node is willing to wumbo with any node.
>>
>> I think we need to name `option_anyone_can_wumbo` to `option_wumborama`?
>>
>> Otherwise, this looks excellent.
>>
>> Thanks,
>> Rusty.
>> ___
>> 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

[Lightning-dev] RBF and dual-fund interactions

[ZmnSCPxj via Lightning-dev]

Good morning list,

After some thinking, I suggest that RBF and dual-fund have some complex 
interactions.

Let us consider some node who wishes to provide liquidity in exchange for a fee.
For simplicity, let us suppose this liquidity provider owns a single UTXO 
containing its entire funding.

A customer appears and purchases some liquidity.
The liquidity being purchased is less than the total money of the liquidity 
provider.
Thus the funding tx has a change output that goes to the liquidity provider.

Suppose, while the funding tx is unconfirmed, that another customer appears and 
purchases liquidity.
The liquidity provider cannot provide liquidity from a confirmed output, but 
can only get liquidity from the change output from the first customer funding 
tx.

Now suppose the first customer gets tired of waiting for a confirmation on its 
funding tx, and RBF its funding tx.
The second customer funding tx is now removed from mempools, since its root was 
replaced.
Now the liquidity provider also has to ask the second customer to sign a new tx.

This is potentially an attack vector (although I suppose we could consider 
simply ignoring edge-case attack vectors).
Since the second customer pays the fees and designates its own inputs, it can 
gather all its dust, then give a very low fee, creating a large tx that has too 
low feerate to be mined, but too large total fee to get over the RBF rule 1 
(The replacement transaction pays an absolute higher fee than the original 
transactions.).
The first customer can then find it very difficult to get its own channel 
confirmed unless it pays an uneconomical onchain fee.

To my mind, channel initiation RBF is more important than dual-fund.
Off-to-onchain services (which can already be built on top of existing LN, 
because proof-of-payment) can provide incoming liquidity by reversing the 
polarity of the satoshi flow, and in addition, can be used to put funds in cold 
storage or pay people onchain.

---

Alternatively, instead of providing change outputs for liquidity providers, 
instead require that liquidity providers cannot have a change output on the 
funding tx.
Thus the liquidity provider will have to create a transaction from its single 
UTXO to two UTXOs, only one of which is actually added to the channel, and the 
other being the liquidity provider change output.
The liquidity provider can provide this with minimum relay fee and deduct it 
from the channel liquidity it is selling, so that the fee for this tx is CPFP 
by the first customer and so initiator-pays remains.
This allows a second output that is not dependent on the funding tx, and which 
allows the two customers to RBF independently of each other.
It has the unfortunate drawback of increasing blockchain usage.

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