Published on: 2020-10-06T04:10:52+00:00
ZmnSCPxj, a contributor to the Lightning Network, argues against the proposal of always publishing all channels due to concerns about employee privacy. He warns that revealing the size of a channel between a company and an employee could disclose the employee's bi-weekly salary. To obscure this information, proposals suggest obscuring short-channel-ids in routehints for both published and unpublished channels. ZmnSCPxj also explains how feerate settings in invoices can still be identifiable, but suggests using a small random increase in feerate to obscure the channel referenced in the invoice.ZmnSCPxj further discusses the issue of funding inbound balance on the Lightning Network. He responds to a comment about not being able to front up funds for inbound balance without consuming all of the treasury. He emphasizes the importance of having enough funds available to pay employee salaries to avoid business failure. He explains how even with just one employee, it is possible to make the Lightning Network work by using offchain-to-onchain swap services to put money on-chain and create a new channel for paying the promised salary. He emphasizes that it is unnecessary to lock up all funds and suggests keeping enough in channels to cover continuous operational expenses, including salaries. This method can work regardless of the number of employees.In another discussion, ZmnSCPxj addresses the possibility of a company having only one big to-network channel for Lightning usage. He argues against the assumption that a company cannot front up funds for inbound balance. He explains that even with just one new hire, the company can use offchain-to-onchain swaps to create a new channel and pay the promised salary. The company's funds are not locked up, only the employee's funds. As the company operates and receives money in its big to-network channel, it can cover expenses and salaries. ZmnSCPxj emphasizes the need to keep some funds for other expenses and states that this scenario can work regardless of the number of employees.The author of the text addresses the concern of locking up funds to pay employees via Lightning Network. They argue that it is a necessary step and not an unreasonable assumption. They explain how even with a single big channel and one employee, the system can still work as long as the company earns enough money to cover expenses and salaries. The author concludes by stating that this system will work regardless of the number of employees.In an email exchange, ZmnSCPxj discusses the issue of inbound liquidity on the Lightning Network. They suggest that companies can open channels with employees who have insufficient inbound liquidity to receive their salaries. If an employee's node does not have enough capacity, the company can use offchain-to-onchain swaps to create a new channel for the employee. The size of the channel can be increased or alternative methods can be used to free up capacity for occasional bonuses or permanent raises. The author also notes that even if an employee leaves the company, the channel need not be closed as the company can earn forwarding fees from their new employer or income source. This solution is seen as better than the onchain situation.Lastly, the text mentions Cut Throat Industries, a company that pays its 120 employees biweekly using a single transaction with the company's treasury as input and each employee payroll as output. However, this exposes sensitive information about the company's worth, treasury amount, number of employees, and average payroll. To address these concerns, the company considers using Bitcoin with privacy, but currently believes that paying on-chain is the only solution. However, fronting up funds for inbound balance would consume all of the company's treasury, making it an impractical option.
Updated on: 2023-08-02T02:45:18.131449+00:00