Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-14 Thread Ariel Lorenzo-Luaces
I don't think it's so clear that any party refusing to go go first can be 
assumed to have lost data.

If the rule is that the party receiving the connection is the one that must 
send the oblivious signatures then a party that has both lost data and is 
receiving a connection can just ignore the connection request.

There is plausible denyability because knowingly not answering a request can't 
be distinguished from just having connection issues or distinguished from a 
machine is just turned off.

This reasoning should work well into the future because as long as machine 
failures are common, the node with data loss can hide in that anonymity set. 
And if human kind resolves all machine failures then by definition there 
shouldn't be lightning channel data loss.

Cheers
Ariel Lorenzo-Luaces

On Dec 13, 2020, 10:12 AM, at 10:12 AM, "David A. Harding"  
wrote:
>On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
>> If c = 1 (i.e. the node is fine and it wants to continue the channel)
>then
>> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it
>passes
>> it sends the commitment blinding y back to prove that it doesn't have
>the
>> signature (i.e. prove c = 1). If verification fails then the node is
>> malicious and it fails the channel.
>
>This is really cool!  However, I don't understand why it's needed.
>Your
>goal seems to be for the sender to provide the commitment transaction
>and signatures before he learns whether the receiver actually needs
>them.  That's just as easily accomplished by sending the data upfront
>in
>plain text.  For example, it seems to me that both of the following
>protocols provide identical utility:
>
>1. On every reconnection, request the plain text unsigned commitment
>   transaction, send a pedersen commitment, and receive the encrypted
>   signature(s).  If c=1, verify the encrypted signature(s) and (on
>   success) send the blinding factor or (on failure) fail the channel
>   and ban the peer.  If c=0, decrypt the signature(s), apply them to
>   the commitment transaction, and broadcast.
>
>2. On every reconnection, request the plain text unsigned commitment
>   transaction with all of its signatures, also in plain text.  If our
>   database is intact, verify the commitment transaction and its
>   signatures are valid and (on success) continue or (on failure) fail
>   and ban.  If we lost data, broadcast the commitment transaction.
>
>Unless I'm forgetting something, there's no reason a node shouldn't
>send
>its latest commitment transaction to its counterparty in plain text
>(over the regular BOLT8 P2P encrypted and authenticated link).
>
>I think the challenge in either protocol above is deciding which peer
>goes first, because whoever sends the commitment transaction reveals
>what they think the current state is.  Any node that refuses to go
>first
>can then be suspected of having lost data.  BOLT2
>option_static_remotekey has this same problem, which is reasonably
>mitigated IMO by LN's penalty mechanism forcing any would-be thief to
>risk their own funds; this doesn't work for basic eltoo, though.
>
>-Dave
>
>
>
>
>___
>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] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread Ariel Lorenzo-Luaces
> I am forking this thread as my reply is not at all related to the JIT-Routing.

Sorry I think my last reply was also getting off subject as well.
Thank you for forking the thread

> Nonexistent channels (i.e. channels that do not have some backing UTXO in the 
> Bitcoin blockchain) are not safe to propagate on the network since they are 
> trivially spammable (i.e. can generate a large number of fake channels to 
> waste network bandwidth).

I hadn't considered the effect this gossip would have on the network.
Definitely nodes should not trust one another to tell the truth about
nonexistent channels.

The source node could blindly allow intermediate nodes to create
sub-routes to the next hop.
But I wouldn't favor this blind routing idea because fee calculations
would be a complete guesses.

> A good pruning heuristic is "channel capacity", which can be checked onchain 
> (the value of the UTXO backing the channel is the channel capacity).
> It is good to keep channels with large capacity in the routemap, because such 
> large channels are more likely to successfully route a payment than smaller 
> channels.
> So it is reasonable to delete channels with low capacity when the routemap 
> memory is becoming close to full.

I'm generally concerned about these heuristics because any time nodes
can game a heuristic they will be expected to do so.
Gaming a heuristic can be good or bad depending on the side-effects.
One side effect of the "channel capacity" heuristic is more reliable
payments but another side effect is that low capacity (but possibly
reliable) channels are neglected.

> It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea 
> would still work.
> In effect, the high-capacity channel is very likely to successfully route in 
> either direction.
> But if by chance it falls into a state where it is unable to route in one 
> direction or other, the intermediate node has other, lower-capacity channels 
> that it can use JIT-Routing with to improve the directionality of the 
> high-capacity channel.
> Nothing in the JIT-Routing idea requires that the rebalancing loop is small, 
> only that a loop exists.
>
> Nodes still need to track their direct channels (so they are implicitly 
> always in the routemap).
> But payee nodes making BOLT1 invoices could also provide `r` routes in the 
> invoice, with the given routes being from nodes with high-capacity channels, 
> so that even if the intermediate channels are pruned due to low capacity, it 
> is possible to get paid.

Without low capacity channels spontaneous payments would not work. Or
they would depend on asking for an invoice under the hood.
It feels to me that at some point, someone with complete knowledge of
the network needs to be employed.

Cheers
Ariel Lorenzo-Luaces

On Mar 28, 2019, 9:51 PM, at 9:51 PM, ZmnSCPxj  wrote:
>Good morning Ariel,
>
>I am forking this thread as my reply is not at all related to the
>JIT-Routing.
>
>
>Sent with ProtonMail Secure Email.
>
>> Public nodes could advertise channels which don't actually exist
>directly but are instead hidden paths that the source node doesn't need
>to know or care about. The fees advertised for these aggregate-channels
>would be the aggregate fees expected from the sub-route.
>
>Nonexistent channels (i.e. channels that do not have some backing UTXO
>in the Bitcoin blockchain) are not safe to propagate on the network
>since they are trivially spammable (i.e. can generate a large number of
>fake channels to waste network bandwidth).
>
>> I think the biggest gain from this system is that the network can be
>more abstract. This abstraction allows all possible subsets of public
>nodes to be a clique since all subsets of nodes can be maximally
>connected with aggregate-channels as long as the entire network is well
>connected.
>> This new property of the network could allow a source node to select
>a random privacy-clique and rely on payments to be routed along
>aggregate-channels without the source node needing to compute or even
>know the exact sub-routes. Futhermore, the source node could
>exclusively download and listen to the privacy-clique and ignore the
>rest of the network structure thus reducing the burden of keeping up to
>date network information.
>
>Let me suggest something else.
>
>As the LN grows, the public routemap becomes larger and larger, until
>keeping them in a fast in-memory data structure becomes infeasible on
>cheap hardware.
>In all likelihood, at some point in the future, users will want to be
>able to limit the memory consumed by implementations for routemaps.
>
>So, some pruning heuristic is needed, to reduce the resource usage of
>large routemaps.
>
>A good pruning heuristic is "channel capacity&

Re: [Lightning-dev] Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0

2019-03-25 Thread Ariel Lorenzo-Luaces
Good morning list

I have been thinking about how JIT-Routing can allow the network to be more 
private and scalable than it currently is today. Rene has mentioned that 
JIT-Routing allows channel balance information to affect pathing decisions 
without the source node being aware. I would take this further and suggest that 
JIT-Routing can allow routing over sub-paths that are only visible to neighbour 
nodes and are entirely hidden from the source node or plublic view.

An intermediate route node could decide for any reason to re-route a payment 
through any subset of nodes to arrive at the next hop. This is similar to 
Rene's local AMP idea where friend-of-a-friend nodes are used. But instead this 
system could allow arbitraryly long paths to the next hop by finding a new 
sub-route and re-layering the onion packet with the new sub-route prepended.

The same pre-image would be used and this process would be completely invisible 
to the next hop (original next hop, not the new next hop in the sub-route, I 
would instead call those the sub-hops).

It's unfortunate that the intermediate nodes along the sub-route would be aware 
that a sub-route is being attempted because they could observe extra hop 
packets prepended to the minimum twenty and I don't see of a way to fix this. 
But maybe it doesn't need fixing since the original twenty encryption layers 
are arguably private enough.

The sub-route could also employ base AMP since the same pre-image is used. The 
next hop node would still never even know that a subroute was attempted if no 
"wait for more payments" flag is added to the per_hop field and we implement 
the "wait for timeout if HTLC is less than amt_to_forward" rule.

Public nodes could advertise channels which don't actually exist directly but 
are instead hidden paths that the source node doesn't need to know or care 
about. The fees advertised for these aggregate-channels would be the aggregate 
fees expected from the sub-route.

I think the biggest gain from this system is that the network can be more 
abstract. This abstraction allows all possible subsets of public nodes to be a 
clique since all subsets of nodes can be maximally connected with 
aggregate-channels as long as the entire network is well connected.

This new property of the network could allow a source node to select a random 
privacy-clique and rely on payments to be routed along aggregate-channels 
without the source node needing to compute or even know the exact sub-routes. 
Futhermore, the source node could exclusively download and listen to the 
privacy-clique and ignore the rest of the network structure thus reducing the 
burden of keeping up to date network information.

Cheers
Ariel Lorenzo-Luaces


On Mar 22, 2019, 4:44 AM, at 4:44 AM, ZmnSCPxj via Lightning-dev 
 wrote:
>Good morning list,
>
>I have been thinking of JIT-Routing in the context of unidirectional
>channels, as for example in Eclair Mobile.
>Now of course unidirectional-only nodes as in Eclair Mobile cannot
>forward and cannot be intermediate nodes.
>However, as I pointed out in previous email, the same JIT-Routing can
>be used also when the node is the ultimate source of the payment.
>
>The original formulation, which requires a separate, completed
>rebalance, before performing a payment, cannot be used in
>unidirectional mode.
>It requires that the channel to be boosted by the rebalance, must first
>receive the value, which is disallowed in unidirectional mode.
>
>However, the Luaces-Pickhardt JIT-Routing, which has a conditional
>rebalance, does not require that the channel receive.
>So it seems to me, that the Luaces-Pickhardt JIT-Routing can work with
>Eclair.
>
>Let us consider the following history:
>
>1.  An Eclair Mobile client creates a 1mBTC channel.
>2.  The client successfully pays an unrelated payment of 0.5 mBTC.
>3.  The client has to make another payment of 0.6 mBTC, to be passed by
>this channel.
>The client has another channel which can pay out the needed 0.15mBTC
>(additional 0.05mBTC needed for the channel reserve).
>4.  The second payment passes.
>
>In the below sequence of states, A is the Eclair Mobile client node,
>while B is the counterparty.
>
>1.  A = 1.0, B = 0.0 ; starting state.
>2.  A = 0.5, B = 0.0, A->HTLC->B = 0.5 ; client offers payment in #2
>above.
>3.  A = 0.5, B = 0.5 ; payee accepts payment.
>4.  A = 0.5, B = 0.35, B->HTLC->A = 0.15 ; the rebalance from another
>channel of A, initiated by #3 above.
>5.  A = 0.05, B = 0.5, A->HTLC->B = 0.45 ; HTLC polarity reversed by A
>offering an HTLC of 0.6 BTC (the new mechanism proposed by Rene).
>6.  A = 0.05, B = 0.95 ; payee accepts payment.
>
>As can be seen from above, A will never have an increase in its money.
>
>Thus, the new Luaces-Pickhardt formulation of JIT-Routing, which
>require

Re: [Lightning-dev] Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0

2019-03-14 Thread Ariel Lorenzo-Luaces
Hello Rene, ZmnSCPxj, and list 


I really like the proposal and I'm sure it's the correct way forward for 
reducing payment failures and increasing privacy (through mitigating probing 
based network analysis) 


However I am concerned that this proposal could introduce a vulnerability to a 
spoofed-payment attack. 


An adversary could create a malicious payment that's guaranteed to fail, for 
free. Any intermediary nodes on the path of the payment before it fails could 
lose fees due to rebalancing if the rebalancing path's success is not dependent 
on the original payment's success. 


Could anyone speak to this and confirm whether it would be possible for the 
rebalancing step to reuse the original payment hash? If this is possible then 
it should explicitly be included in this proposal. 


If reusing the payment hash is not possible on the routing path then JIT 
routing would need some other mitigation for the spoofed-payment attack. 


Cheers 


Ariel Lorenzo-Luaces 




On Mar 14, 2019, 7:45 AM, at 7:45 AM, ZmnSCPxj via Lightning-dev 
 wrote:
>Good morning Rene and list,
>
>Let us consider then the rule *when* a rebalancing would be beneficial
>to the node.
>
>The node is offered a fee amount (`offered_fee_amount`) for the
>forwarding.
>It knows that, under current channel states, it will definitely have to
>fail and earn 0 fees.
>
>If it engages in JIT-routing, it must pay some fee
>(`rebalancing_fee_amount`) for the rebalancing operation.
>But even if it successfully forwards its hop, it is still possible that
>the route will fail anyway and it will earn 0 fees.
>
>So let us consider the probability of success (`success_rate`), a value
>between 0 to 1.0.
>This is the estimated probability that we will succeed the route after
>we forward it.
>
>We should only engage in JIT-routing if:
>
>offered_fee_amount * success_rate - rebalancing_fee_amount > 0
>
>The LHS of the subtraction is the expected earning, while the RHS of
>the subtraction is the expected cost.
>The above is trivial accounting for determining net earnings.
>
>The fee amounts are trivially computable.
>Presumably the rebalancing code can compute the fee given a particular
>rebalance path, and thus can provide `rebalancing_fee_amount`.
>
>The `success_rate` can be computed statically from some node data.
>Better, is for the node to start with this precomputed static
>information, but augment this over time with its own experienced
>`success_rate` for all forwards.
>
>Regards,
>ZmnSCPxj
>___
>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 delay asymmetry

2018-04-15 Thread Ariel Lorenzo-Luaces
Letting the attacker have immediate access to their funds is a null point 
because the attacker always has the preparation time to unbalance the channel 
to the honest node's favor. The attacker's 'funds' in this case is trivially 
reduced to 'reserve balance'. It's hard to argue that forcing the malicious 
node to wait for the delay before having access to their reserve balance is 
disincentive enough to not perform the attack.

Cheers
Ariel Lorenzo-Luaces


On Apr 15, 2018, 11:37 AM, at 11:37 AM, Jim Posen <jim.po...@gmail.com> wrote:
>I believe that anyone attempting a DOS by forcing on-chain settlement
>can
>do it just as easily with asymmetric delays than with symmetric delays.
>
>If my goal is to waste the time-value of your money in a channel, in a
>world with symmetric delays, I could just publish the commitment
>transaction and you would have to wait the full delay for access to
>your
>funds. True. But with delays asymmetric as they are now, I can just as
>easily refuse to participate in a mutual close, forcing you to close
>on-chain. This is just as bad. In fact, I'd argue that it is worse,
>because
>I lose less by doing this (in the sense that I as the attacker get
>immediate access to my funds). So in my assessment, it is a very active
>attack and symmetric delays are something of a mitigation. You are
>right
>that the balance of funds in the channel becomes a factor too, but note
>that there is the reserve balance, so I'm always losing access to some
>funds for some time.
>
>-jimpo
>
>On Sun, Apr 15, 2018 at 6:35 AM, ZmnSCPxj <zmnsc...@protonmail.com>
>wrote:
>
>> Good morning Daniel,
>>
>>
>> This makes a lot of sense to me as a way to correct the incentives
>for
>> closing channels. I figure that honest nodes that have truly gone
>offline
>> will not require (or be able to take advantage of) immediate access
>to
>> their balance, such that this change shouldn't cause too much
>inconvenience.
>>
>> I was trying to think if this could open up a DOS vector - dishonest
>nodes
>> performing unilateral closes even when mutual closes are possible
>just to
>> lock up the other side's coins - but it seems like not much of a
>concern. I
>> figure it's hard to pull off on a large scale.
>>
>>
>>
>> Now that you bring this up, I think, it is indeed a concern, and one
>we
>> should not take lightly.
>>
>> As a purely selfish rational being, it matters not to me whether my
>> commitment transaction will delay your output or not; all that
>matters is
>> that it delays mine, and that is enough for me to prefer a bilateral
>close
>> if possible.  I think we do not need to change commitment
>transactions to
>> be symmetrical then --- it is enough that the one holding the
>commitment
>> transaction has its own outputs delayed.
>>
>> If I had a goal to disrupt rather than cooperate with the Lightning
>> Network, and commitment transactions would also delay the side not
>holding
>> the commitment transaction (i.e. "symmetrical delay" commitments), I
>would
>> find it easier to disrupt cheaply if I could wait for a channel to be
>> unbalanced in your favor (i.e. you own more money on it than I do),
>then
>> lock up both our funds by doing a unilateral transaction.  Since it
>is
>> unbalanced in your favor, you end up losing more utility than I do.
>> Indeed, in the situation where you are funding a new channel to me, I
>have
>> 0 satoshi on the channel and can perform this attack costlessly.
>>
>> Now perhaps one may argue, in the case of asymmetric delays, that if
>I
>> were evil, I could still disrupt the network by misbehaving and
>forcing the
>> other side to push its commitment transaction.  Indeed I could even
>just
>> accept a channel and then always fail to forward any payment you try
>to
>> make over it, performing a disruption costlessly too (as I have no
>money in
>> this).  But this attack is somewhat more passive than the above
>attack
>> under a symmetrical delay commitment transaction scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
>
>
>
>___
>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