Re: [Lightning-dev] Potential vulnerability in Lightning backends: BOLT-11 "payment hash" does not commit to payment!

[Martin Habovštiak]

Yeah, my point was to not have to setup any other instance of LND. I'm just
testing LND <-> app integration - whether the app receives payments from
LND. So another similar flag to do self-payment without going through
network would be ideal.

Dňa ne 16. 7. 2023, 19:32 Olaoluwa Osuntokun  napísal(a):

> lnd supports paying invoices it generates, you just need to set the
> `allow_self_payment` field using this
> API: https://lightning.engineering/api-docs/api/lnd/router/send-payment-v2
> .
>
> This _does_ end up actually finding a circular route through the network
> though, it's most commonly used to implement circular rebalancing.
>
> However if you set up another node, and then fund bi-lateral "trusted
> channels" (so zero conf channel that will never actually confirm as the
> funding point will never exist on chain), then you gain the ability to pay
> invoices without doing the actual network route. This doesn't need any
> other
> external software, and also gives you all the normal payment/invoice
> records
> you'd expect for normal payments.
>
> Another way to accomplish the same thing would be to use the
> `"allow-circular-route` flag, which'll let you double back on the same
> channel (incoming+outgoing channel is the same for the route).
>
> -- Laolu
>
> On Sat, Jul 15, 2023 at 8:22 PM fiatjaf  wrote:
>
>> On Thu, Jul 13, 2023 at 3:47 AM David A. Harding  wrote:
>> > My question is whether you think it would be worthwhile to ask
>> > developers of the underlying LN node implementations you use to support
>> > self-payment of their own invoices (if they don't already).
>>
>> As far as I know no Lightning node has this ability, which is very
>> unfortunate.
>> If possible this should definitely be implemented. It would be the
>> biggest feature for custodial Lightning service providers of all kinds
>> since always.
>> ___
>> 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 mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Potential vulnerability in Lightning backends: BOLT-11 "payment hash" does not commit to payment!

[Martin Habovštiak]

Hi folks,

I would also like to point out this can help testing a lot. I do
integration testing of payment flow by spawning a secondary node, setting
up a channel etc which takes considerable time even automated on regtest.
Also it sometimes fails for silly unrelated reasons.

Dňa so 15. 7. 2023, 20:22 fiatjaf  napísal(a):

> On Thu, Jul 13, 2023 at 3:47 AM David A. Harding  wrote:
> > My question is whether you think it would be worthwhile to ask
> > developers of the underlying LN node implementations you use to support
> > self-payment of their own invoices (if they don't already).
>
> As far as I know no Lightning node has this ability, which is very
> unfortunate.
> If possible this should definitely be implemented. It would be the
> biggest feature for custodial Lightning service providers of all kinds
> since always.
> ___
> 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] Supporting a custodial user who wishes to withdraw all sats from the account...

[Martin Habovštiak]

Hi folks,

I think I've seen wallets supporting "send max" when a zero-amount invoice
was used. So isn't it a problem with the custodial service not supporting
it?
Whatever idea we figure out they can just refuse to implement it so we
can't force them into improving and being custodial they could steal
already, so that shouldn't be an issue.

Have a nice day!
Martin

On Sat, 27 Aug 2022 at 04:06, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Rene,
>
> > Dear fellow Lightning Developers,
> >
> > I was recently on an event where the visitors have been gifted 10k sats
> on a custodial wallet. They could spend those sats via some web interface
> and an NFC card. During the event I was contacted by several plebs who were
> confused about one particular thing:
> > It was impossible for them to withdraw the full amount from the service.
> >
> > Pasting an invoice for 10k sats would not work as the custodial service
> required a fee budget of 1%. However if people submitted an invoice for
> 9900 sats the remaining 100 sats were usually not fully required for the
> fees. Thus the users may have had a leftover of for example 67 sats. Now
> the problem repeated on the residual amount. While some services seem to
> have a drain feature for such a situation I find this frustrating and was
> wondering if we could help directly on a protocol level.
> >
> > Here is my proposal for a simple solution to this specific problem:
> `option_recipient_pays_routing_fees`
> >
> > This would be a new flag in invoices signaling that the recipient is
> willing to pay for the routing fees by releasing the preimage even if the
> full amount has not been arrived in htlcs at the recipient.
> >
> > So the workflow would be the following:
> >
> > 1. Alice creates an invoice for 10k sats setting the
> `option_recipient_pays_routing_fees` flag in the invoice and passes it
> either to custodial user Bob or to her own custodial account.
> > 2. The payer parses the invoice and searches for a payment path or
> payment flow to Alice.
> > 3. Because `option_recipient_pays_routing_fee` is set, the onion is not
> constructed in a way that the final HTLC will be for the amount of 10k sats
> but rather in a way that the first htlc will be for 10k sats and the
> following HTLCs will be of decreasing value so that routing nodes are
> compensated properly.
> > 4. When the HTLC(s) arrive at Alice she will release the preimage if and
> only if not too many sats (e.g. 1% of the amount) are missing. Of course it
> would be good if the 1% was not hard coded in the protocol / software but
> configurable by Alice at the time of invoice creation.
> >
> > I think the main issue with this proposal is that instead of confusing
> users who wish to drain an account we may now have to educate users about
> two different invoice types. On the other hand I think this can probably
> easily be achieved via the current wide spread user interfaces. Of course
> it may be nice to have folks from the Bitcoin Design community to join this
> specific part of the discussion.
>
> In theory, trampoline routes / whatever-the-cool-name-is-now should fix
> this problem as well.
> I am referring to that scheme where the invoice contains an onion and a
> "trampoline" node that is the only node that can decrypt the first layer of
> the onion.
> The sender then has to route to the trampoline node, and the trampoline
> node then receives the rest of the onion.
>
> In this scheme, the receiver provides an encrypted route from some node to
> itself.
> As the receiver provides the route in order to gain privacy from the
> sender, the onus is on the receiver to deduct the fees from its received
> funds.
> i.e. the sender is only responsible for paying for fees up to the entry
> point of the trampoline.
>
> Thus, such a drain requirement simply means that the custodial service has
> to give its node ID.
> Then the receiver finds a route from the custodial service to itself, and
> encodes that in the trampoline onion, with a direct neighbor of the
> custodial service node as the trampoline.
> The custodial service then does not care about any fees as the receiver
> decided the route; the receiver knows exactly how much to expect (since it
> calculated the route).
>
>
> Of course, it is also possible as you propose, but any level-1-selfish
> custodial service will then always keep the remaining fee budget and always
> ensure that the receiver gets 99% of the value (or 100% -
> whatever_setting_they_chose), paying fees, and keeping the remaining 1% for
> itself.
> The receiver in this case cannot audit the route anyway, and thus cannot
> determine how much the true fees are; whereas in the trampoline case the
> route is specifically selected by the receiver.
>
> Regards,
> ZmnSCPxj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> 

Re: [Lightning-dev] Remove Description From Bolt11 Invoices

[Martin Habovštiak]

> Specific items, maybe not, but maybe a use case for keeping description
> hash for this.
>
> You can't keep hash without making it possible to use it for AOPP-style
verification. The exchanges would just ask users to make invoices with that
hash.

> the envisioned scenario is that this AOPP-style regulation gets
> restrictive enough that nobody can use regulated custodians to make
> payments.
>
Not necessarily, it could also be just so frequent people develop muscle
memory and avoid even trying to pay from exchanges.

> Why do we need to comply with extreme node level KYC enforcement to make
> this the case?
>
I don't know if we *need* it maybe better education can replace it but
surely it helps.

> The enforcement won’t stop with the scenario you’ve described if everyone
> is complying and supporting these regulations in the first place.
>
In a way it was too late when KYC came to exist. Note that slippery slope
can be fallacious argument and I think it's the case here. The specific
regulation is only about proving that you aren't paying someone else. The
intention is for exchanges to not have to register as banks. The objective
is NOT to track people.

> They will get worse. They are already talking about how to DOX the sender
> of a payment by signing a message in a TLV field.
>
The only serious discussion I remember seeing about this proposed to make
it unlinkable. The recipient would not know which node it was.

> Also node IDs could be rotated.
>
> How so? Close down all channels, shut down node, coinjoining utxo’s and
> spin up a new one?
>

No, it literally only requires changing the receiver implementation to
accept messages for any known node ID. The only problem is channel id being
static and we need some protocol for private channels to generate new IDs.

> "KYC" of a private node ID is completely meaningless
>
> This will be the realization of the regulators as well.
>
When they get people smart enough to understand it they will also
understand the only solutions are ban Bitcoin completely or give up. We
can't change it anyway.

> This also assumes there are protective mechanisms in place to make sure a
> “private node” is actually private because that’s not the case and there
> are enough gotchas to break down that assumption.
>
That's also what I said. I encourage you to work on these instead of
removing description.

> An operator of popular public node can just connect to self and pretend
> it's some random person routing through him. It's essentially impossible to
> prove it's not the case.
>
> I think this is a good thing to do but if not done correctly, there can be
> enough correlations to break this down.
>
The only way I can see it being done incorrectly is user entering invoice
from the public node where he shouldn't. Can you see any other?

> Ideally, it’s like you’ve said, “popular public node”. What about everyone
> else?
>
Even unpopular public nodes have plausible deniability even though they
might have harder time. Fixing private nodes should be among top priorities.

> There is not a hard & fast rule that no custodian is processing anything
> except to the user’s (assumingly) private nodes.
>
> Not a big deal except for uninformed dissidents. People who break unjust
dictatorship laws should be more careful. This can't be changed anyway.

> Nodes are being KYC’d now. Invoices and payment reasons are being
> aggregated in mass. How do we stop this now except by removing the ability
> for it *to* happen?
>
We don't need to stop it, making it meaningless is a possibility. And
certainly stopping it by screwing up something else is not a good strategy.
Regardless, we need to educate people about this simple rule:

NEVER put invoices from others into any KYC wallet.

Finally, fixing privacy issues like ID reuse is much more important and
productive than removing description.

Cheers
Martin

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

Re: [Lightning-dev] Remove Description From Bolt11 Invoices

[Martin Habovštiak]

(sorry for double message, wrong button)

Hi,

I object to the idea that AOPP-like verification is harmful *to lightning*,
quite contrary, it's beneficial! Also removing description creates another
problem: impossibility to prove payment for goods or services making
arbitration hard or impossible.

Why it's beneficial?

Suppose there's a dissident in a dictatorship country wanting to buy banned
goods. He pays using LN. There are two possibilities:
0. exchange doesn't enforce description
1. exchange does enforce description

Let's look at case 0:
The dissident, who happens to not be that knowledgeable about security buys
sats at an exchange and inputs the destination invoice from whoever he pays
directly into the exchange. The exchange logs this along with the identity.
Some time later the node ID being paid for banned goods leaks (very likely
for public nodes) and the tyrants use this to track down dissidents. The
dissident is screwed.

Case 1:
The dissident withdraws to his non-custodial wallet (can't do anything
else) which he then uses to pay. The exchange can not possibly see where
the payment went from non-custodial wallet or if it was even sent away.
Recipients don't know identities of senders so no matter what information
leaks, it's impossible to link the payment.

The biggest real problem with the enforcement is the fact that invoices
leak txids of private channels even though they shouldn't have to. *This*
needs to be fixed, really. Also node IDs could be rotated.

Assuming it's fixed, "KYC" of a private node ID is completely meaningless.
The exchange can not see where the sats ultimately end up - either LN or
chain. It's essentially equivalent to assigning meaningless random number
to each transaction.

This assumes "private" channels but has a simple workaround for public
nodes too. An operator of popular public node can just connect to self and
pretend it's some random person routing through him. It's essentially
impossible to prove it's not the case.

Note that this whole reasoning doesn't apply to BTC chain as addresses
don't have such strong privacy properties but could be applied to e.g.
Monero (maybe a bit weaker guarantee; not endorsing it).

I'm not saying that we should (not) proactively support these efforts,
since accepting regulations is bad precedent but it could be the case here
that it's a good way to turn regulations against the regulators and it
could outweigh the cons.

Hope I'm clear enough. Cheers!
Martin

On Mon, Jan 31, 2022, 06:07 armdxxi via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> All,
>
> In light of recent AOPP concerns[0] where custodial users have to sign a
> message from an address to prove that it is theirs when withdrawing from
> highly regulated exchanges, I thought it was important to bring up that
> this is happening in the Lightning space as well.
>
> The tagged field d provides both payers and payees with a description of
> what the transaction is for. When a Lightning Node creates a BOLT11 invoice
> with a description, this is signed. The signature verification process
> validates that it came from a specific node and that it is unaltered.
>
> The problem is that this is being exploited by bad actors in the regulated
> space. Unsuspecting users are going along with it not knowing the
> repercussions.
> KYC Node Verification
>
> Companies like Bottlepay[1] are forcing some users to verify their node by
> creating a specialized invoice. They ask the user to put PII in the
> description and give the signed invoice to the service. Afterwards, a
> database of KYC'd users and their nodes may be stored and shared with 3rd
> parties, regulators, and governments.
>
> Given that the Lightning Network is a reputation-based system without an
> easy way to handle rotations, this has lasting effects if this practice
> were to scale out to all providers. At least with AOPP, one may spin up a
> new on-chain address with ease and attempt to mitigate linkage via coinjoin.
>
> This alone is enough to recommend wallet devs to remove the ability for
> users to unknowingly sign statements with their node. Just like with the
> widespread removal of AOPP from hardware/software wallets, exchanges may
> stop expecting that users are capable of handing over this information with
> ease.
> Payment Reason Aggregation
>
> On the payment receiver side, a user may add a description for their
> reference later on. In an ideal world, only the payer and payee are the
> ones that know the reason for the payment. However, given the current
> reliance on custodians today, these 3rd parties can see and store this
> information.
>
> A good thread[2] highlights some of these concerns. If exchanges are
> relaying invoices to chain analytic companies[3], this can be pretty
> revealing in aggregation.
>
> What they'd know solely on processing Bolt11 invoice data:
>
>1. Which internal UserID is paying
>2. Which Lightning Node is receiving a payment
>3. Amount
>   

Re: [Lightning-dev] [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning

[Martin Habovštiak]

I recommend you researching RGB: https://rgb-org.github.io/

On Mon, Dec 6, 2021, 11:21 Karl  wrote:

> Hi,
>
> I'm not a bitcoin developer.
>
> On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
> bitcoin-...@lists.linuxfoundation.org> wrote:
>
>> Hello all,
>>
>> I’ve been thinking about how OP_RETURN is being used to create and trade
>> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
>> if it’s possible to
>>
>
> Do you have a link to any of these protocols?
>
> make transactions with this opcode via Lightning.
>>
>> More specific questions could be:
>>
>>1. Can opcodes like OP_RETURN be inside a channel’s opening or
>>closing transaction?
>>2. If so, could that OP_RETURN change hands within that channel or
>>network of channels?
>>
>> OP_RETURNs do not have ownership according to the bitcoin network.  It is
> not hard to define a protocol that associates an OP_RETURN with ownership,
> and ownership could then be transferred via lightning by sending associated
> currency via lightning.  Robustness improvements seem possible.
>
>
>>1. If possible, could the OP_RETURN be divisible? Could one person
>>send a piece of a OP_RETURN just like one can do right now on the primary
>>ledger or would it need to maintain the OP_RETURN code intact?
>>
>> OP_RETURNs themselves do not have ownership, but you can define a
> protocol that gives them divisible ownership, including via lightning.
>
> I’m assuming that, if possible, this would need a protocol layer parallel
>> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
>> ones which involve the node's channels as well as the ones with the
>> OP_RETURN, just like CounterParty does right now with the primary ledger.
>>
>> Thank in advance.
>> ——
>>
>> *Héctor Cárdenas*@hcarpach
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-...@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> 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] Removing lnd's source code from the Lightning specs repository

[Martin Habovštiak]

I can confirm I moved a repository few months ago and all links kept
working fine.

On Mon, Oct 11, 2021, 20:58 Matt Corallo  wrote:

>
>
> On 10/11/21 05:29, Bryan Bishop wrote:
> > On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses  >
> > wrote:
> >
> > Completely agree with this. How to move this forward? Set up a vote?
> What would be the reasoning
> > for not moving it?
> >
> >
> > One consideration is broken links, which can be solved by a soft note in
> a README somewhere.
> >
> > - Bryan
> > https://twitter.com/kanzure 
>
> I believe the Github "move repository" feature makes all old links
> auto-redirects, so I'd hope this
> wouldn't happen. This information is at least a few years old, however.
>
> Matt
> ___
> 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] Impact of eltoo loss of state

[Martin Habovštiak]

What would happen in 2) if the node has data but the peer returned an
incorrect state?

On Wed, Jul 14, 2021, 20:13 Christian Decker 
wrote:

> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
> impact only funds that are in a PTLC at the time of the loss-of-state.
>
> We have a couple of options here, that don't touch the blockchain, and
> are therefore rather lightweight:
>
>  1) Do nothing and keep the incentive to keep up to date backups. It
>  still is a reduction in risk w.r.t. LN-penalty, since this is just an
>  append only log of secrets, and old secrets don't harm you like
>  attempting to close with an old commitment would.
>  2) Use the peer-storage idea, where we deposit an encrypted bundle with
>  our peers, and which we expect the peers to return. by hiding the fact
>  that we forgot some state, until the data has been exchanged we can
>  ensure that peers always return the latest snapshot of whatever we gave
>  them.
>
> The latter is the encrypted-blob idea that Rusty has been proposing for
> a while now.
>
> Cheers,
> Christian
>
> Anthony Towns  writes:
> > Hello world,
> >
> > Suppose you have some payments going from Alice to Bob to Carol with
> > eltoo channels. Bob's lightning node crashes, and he recovers from an
> > old backup, and Alice and Carol end up dropping newer channel states
> > onto the blockchain.
> >
> > Suppose the timeout for the payments is a few hours away, while the
> > channels have specified a week long CSV delay to rectify any problems
> > on-chain.
> >
> > Then I think that that means that:
> >
> >  1) Carol will reveal the point preimages on-chain via adaptor
> > signatures, but Bob won't be able to decode those adaptor signatures
> > because those signatures will need to change for each state
> >
> >  2) Even if Bob knows the point preimages, he won't be able to
> > claim the PTLC payments on-chain, for the same reason: he needs
> > newer adaptor signatures that he'll have lost with the state update
> >
> >  3) For any payments that timeout, Carol doesn't have any particular
> > incentive to make it easy for Bob to claim the refund, and Bob won't
> > have the adaptor signatures for the latest state to do so
> >
> >  4) But Alice will be able to claim refunds easily. This is working how
> > it's meant to, at least!
> >
> > I think you could fix (3) by giving Carol (who does have all the adaptor
> > signatures for the latest state) the ability to steal funds that are
> > meant to have been refunded, provided she gives Bob the option of
> claiming
> > them first.
> >
> > However fixing (1) and (2) aren't really going against Alice or Carol's
> > interests, so maybe you can just ask: Carol loses nothing by allowing
> > Bob to claim funds from Alice; and Alice has already indicated that
> > knowing P is worth more to her than the PTLC's funds -- otherwise she
> > wouldn't have forwarded the PTLC to Bob in the first place.
> >
> > Likewise, everyone's probably incentivised to negotiate cooperative
> > closes instead of going on-chain -- better privacy, less fees, and less
> > delay before the funds can be used elsewhere.
> >
> > FWIW, I think a similar flaw exists even in the original eltoo spec --
> > Alice could simply decline to publish the settlement transaction until
> > the timeout has been reached, preventing Bob from revealing the HTLC
> > preimage before Alice can claim the refund.
> >
> > So I think that adds up to:
> >
> >  a) Nodes should share state on reconnection; if you find a node that
> > doesn't do this, close the channel and put the node on your enemies
> > list. If you disagree on what the current state is, share your most
> > recent state, and if the other guy's state is more recent, and all
> > the signatures verify, update your state to match theirs.
> >
> >  b) Always negotiate a mutual/cooperative close if possible, to avoid
> > actually using the eltoo protocol on-chain.
> >
> >  c) If you want to allow continuing the channel after restoring an old
> > state from backup, set the channel state index based on the real
> time,
> > eg (real_time-start_time)*(max_updates_per_second). That way your
> > first update after a restore from backup will ensure that any old
> > states that your channel partner may not have told you about are
> > invalidated.
> >
> >  d) Accept that if you lose connectivity to a channel partner, you will
> > have to pay any PTLCs that were going to them, and won't be able
> > to claim the PTLCs that were funding them. Perhaps limit the total
> > value of inbound PTLCs for forwarding that you're willing to accept
> > at any one itme?
> >
> > Also, layered commitments seem like they make channel factories
> > complicated too. Nobody came up with a way to avoid layered commitments
> > while I wasn't watching did they?
> >
> > Cheers,
> > aj
> > 

[Lightning-dev] Turbo channels spec?

[Martin Habovštiak]

Hi guys,

happy to see this being discussed again! When I came up with the idea,
it was originally intended for cases when there's an inherently trusted
exchange,
such as trading fiat for sats using an ATM. In this scenario only the push
amount was spendable.
Receiving more on top of that was disabled.

Since then some implementations have made zero-conf channels fully
operational.
While strictly worse security, I'm not against it. I'd just really, really
like to have these
cases distinguished.

So I think we need one more bit to signal whether it's only push being
zeroconf or the
channel is fully zeroconf.

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