#92 Idea [requesting feedback]: integrating payments using Lightning

Open
opened 11 months ago by angus · 5 comments
angus commented 11 months ago

I'm working on looking at how Lightning could integrate into Cwtch to provide a payments capability on top of the messaging platform. I sent an email to the list on the background. I believe this is possible to be done securely without leaking data, or at least preventing probabilistic analysis.

Challenge:

  1. Lightning establishes channels and routes payments over those channels using a gossip protocol. While onion routing and off chain transactions are used, with the inclusion of fees in the channels, it is possible that a malicious node or series of nodes could essentially force a transaction to be routed through a certain path and consequently derive more information about the route than simply the predecessor and successor in the route.
  2. As we need to assume that the Cwtch server could be malicious, we should not use it for routing Lightning transactions as it would likely know both end points (as it would be the most efficient route to take)

Proposed solution:

  1. Use the public Lightning network, and each client that wishes to use payments opens a channel with a public node with the 'announce_channel' flag unset (as we do not need to route payments)
  2. Establish a function to query the gossip routing tables and define logic which determines the probability that the route taken by certain payments can be probabilistically determined due to misbalanced fee structures
  3. Share the routing table amongst the group and use a flag that is checked when a payment is attempted that flags whether or not there is a risk that the payment could expose metadata based on the possible routes

I believe this is the best solution available and should be able to provide adequate privacy, however please let me know if there's anything I'm missing or not thinking about.

I'm working on looking at how Lightning could integrate into Cwtch to provide a payments capability on top of the messaging platform. I sent an email to the list on the background. I believe this is possible to be done securely without leaking data, or at least preventing probabilistic analysis. Challenge: 1. Lightning establishes channels and routes payments over those channels using a gossip protocol. While onion routing and off chain transactions are used, with the inclusion of fees in the channels, it is possible that a malicious node or series of nodes could essentially force a transaction to be routed through a certain path and consequently derive more information about the route than simply the predecessor and successor in the route. 2. As we need to assume that the Cwtch server could be malicious, we should not use it for routing Lightning transactions as it would likely know both end points (as it would be the most efficient route to take) Proposed solution: 1. Use the public Lightning network, and each client that wishes to use payments opens a channel with a public node with the 'announce_channel' flag unset (as we do not need to route payments) 2. Establish a function to query the gossip routing tables and define logic which determines the probability that the route taken by certain payments can be probabilistically determined due to misbalanced fee structures 3. Share the routing table amongst the group and use a flag that is checked when a payment is attempted that flags whether or not there is a risk that the payment could expose metadata based on the possible routes I believe this is the best solution available and should be able to provide adequate privacy, however please let me know if there's anything I'm missing or not thinking about.

As we need to assume that the Cwtch server could be malicious, we should not use it for routing Lightning transactions

So, one of the foundational assumption in the Cwtch security model is that it is impossible for a Cwtch server to interfere with traffic in a targeted way i.e. it can only ever censor traffic inconsistently (and detectably) - therefore I think this assumption needs to be rethought through. I think we can actually rely on a Cwtch group to route payments in a metadata resistant fashion (if we couldn't, Cwtch would be broken)

> As we need to assume that the Cwtch server could be malicious, we should not use it for routing Lightning transactions So, one of the foundational assumption in the Cwtch security model is that it is impossible for a Cwtch server to interfere with traffic in a targeted way i.e. it can only ever censor traffic inconsistently (and detectably) - therefore I think this assumption needs to be rethought through. I think we can actually rely on a Cwtch group to route payments in a metadata resistant fashion (if we couldn't, Cwtch would be broken)

I think the main metadata issues with this system are not in routing payments (assuming we limit payments between members in a group, for now)

They are mostly around managing the metadata of the bitcoin transactions themselves e.g. funding a Cwtch wallet, ensuring that Cwtch payment channel setups don't leak identifying information to blockchain peers (by tunneling lightning <-> bitcoin stuff over Tor - which I think the lightning daemon supports out of the box?) and to ensure that public blockchain transactions can't be linked back to cwtch peers in other ways (through traditional transaction analysis)

I think the main metadata issues with this system are not in routing payments (assuming we limit payments between members in a group, for now) They are mostly around managing the metadata of the bitcoin transactions themselves e.g. funding a Cwtch wallet, ensuring that Cwtch payment channel setups don't leak identifying information to blockchain peers (by tunneling lightning <-> bitcoin stuff over Tor - which I think the lightning daemon supports out of the box?) and to ensure that public blockchain transactions can't be linked back to cwtch peers in other ways (through traditional transaction analysis)
angus commented 10 months ago
Poster

Agree on the main probably being the metadata around the bitcoin transactions, and that was part of the reason why I felt we shouldn't try to route entirely within a group or the ecosystem: if you're working with a small group (or any sized group, really), the data available on the bitcoin blockchain around which channels were opened at what time with what amounts would make it easy to determine what addresses are part of a Cwtch group. Whereas if you route publicly, I would think in theory with far more connections it would be far harder to analyze.

Lightning does support Tor out of the box I believe, the bit I'm unsure about is at what layer. I don't understand how you could tunnel through nodes and also do the lightning operations needed without being able to see and potentially interfere with the raw transactions as a node in that series of nodes.

Point taken with the assumption around the Cwtch server, I'll need to think through more how that would work. I'm not sure if considering the above if it's as important?

Agree on the main probably being the metadata around the bitcoin transactions, and that was part of the reason why I felt we shouldn't try to route entirely within a group or the ecosystem: if you're working with a small group (or any sized group, really), the data available on the bitcoin blockchain around which channels were opened at what time with what amounts would make it easy to determine what addresses are part of a Cwtch group. Whereas if you route publicly, I would think in theory with far more connections it would be far harder to analyze. Lightning does support Tor out of the box I believe, the bit I'm unsure about is at what layer. I don't understand how you could tunnel through nodes and also do the lightning operations needed without being able to see and potentially interfere with the raw transactions as a node in that series of nodes. Point taken with the assumption around the Cwtch server, I'll need to think through more how that would work. I'm not sure if considering the above if it's as important?

I would say that the main point of routing payments inside a Cwtch group is that it keeps those transactions outside the public network, therefore there is nothing to analyze.

The only times then that metadata would appear on the Blockchain would be when committing/opening the channel, and closing the channel. Those commitments could be posted to the blockchain (or more accurately, served to neighboring peers) over Tor, and thus the only metadata would be the addresses themselves.

Proper anonymous public channels would have to be done with something like Bolt, and is outside the scope of this I think.

Disconnecting the addresses from the Cwtch peers themselves is a more open problem, and probably involves introducing some kind of mixing function which for now I'm happy to leave out of scope and just focus on "assuming we have a Cwtch wallet, and a group setup, establishing a channel within the group backed by the blockchain"

People watching the blockchain transactions would be able to see that a contract was funded from certain addresses (and thus the time and length of the contract) - but none of those things are hideable directly in bitcoin anyway. As long as the transactions themselves were published via an onion bitcoin peer it should not be possible for an adversary to determine which if any Cwtch groups started the contract.

I would say that the main point of routing payments inside a Cwtch group is that it keeps those transactions outside the public network, therefore there is nothing to analyze. The only times then that metadata would appear on the Blockchain would be when committing/opening the channel, and closing the channel. Those commitments could be posted to the blockchain (or more accurately, served to neighboring peers) over Tor, and thus the only metadata would be the addresses themselves. Proper anonymous public channels would have to be done with something like Bolt, and is outside the scope of this I think. Disconnecting the addresses from the Cwtch peers themselves is a more open problem, and probably involves introducing some kind of mixing function which for now I'm happy to leave out of scope and just focus on "assuming we have a Cwtch wallet, and a group setup, establishing a channel within the group backed by the blockchain" People watching the blockchain transactions would be able to see that a contract was funded from certain addresses (and thus the time and length of the contract) - but none of those things are hideable directly in bitcoin anyway. As long as the transactions themselves were published via an onion bitcoin peer it should not be possible for an adversary to determine which if any Cwtch groups started the contract.
angus commented 9 months ago
Poster

Apologies that it has taken me so long to respond to this: having left my job it's been a rather hectic few weeks getting sorted.

The reason I was thinking that it would need to be routed publicly is because if we have a small ecosystem - say, 10-15 members - then what you will be able to see on the blockchain is the funding transactions that show a closed ecosystem of addresses that do not interact with the public lightning network, and I was concerned about that metadata. I was also concerned about the information on payments being visible in the routing process: in a group of that size it's likely that there would be nodes routing payments that have the sender on one side and the recipient on the other, and thus would be able to see the payment details. My thinking was that if the channels are opened with entities on the public network then the transaction behavior is indistinguishable from regular lightning behavior, and by being forced to follow a longer route then it would be sufficiently obscured. But perhaps I'm thinking about this wrong.

I'm looking into the roadmap of Taproot and Schnorr signatures being integrated into Bitcoin, which would make the above analysis moot as all transactions would look the same. From a timing perspective therefore, is it worth creating the interface for payments and using raw bitcoin transactions for now, which may have higher fees and not have the same speed, but may have adequate anonymity assuming no address reuse?

Apologies that it has taken me so long to respond to this: having left my job it's been a rather hectic few weeks getting sorted. The reason I was thinking that it would need to be routed publicly is because if we have a small ecosystem - say, 10-15 members - then what you will be able to see on the blockchain is the funding transactions that show a closed ecosystem of addresses that do not interact with the public lightning network, and I was concerned about that metadata. I was also concerned about the information on payments being visible in the routing process: in a group of that size it's likely that there would be nodes routing payments that have the sender on one side and the recipient on the other, and thus would be able to see the payment details. My thinking was that if the channels are opened with entities on the public network then the transaction behavior is indistinguishable from regular lightning behavior, and by being forced to follow a longer route then it would be sufficiently obscured. But perhaps I'm thinking about this wrong. I'm looking into the roadmap of Taproot and Schnorr signatures being integrated into Bitcoin, which would make the above analysis moot as all transactions would look the same. From a timing perspective therefore, is it worth creating the interface for payments and using raw bitcoin transactions for now, which may have higher fees and not have the same speed, but may have adequate anonymity assuming no address reuse?
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.