rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2023-05-27 🗒️ Summary of this message: Financial analysis of Alice's capital requirements for various activities, including lightning payments and internal transfers. Instant settlement requires OP_XOR or OP_CAT on the base layer. 📝 Original message:Hi Burak, Thanks for your response! I found it very helpful. I'm going to reply to your email a bit out of order. > 4. Alice places one input to her one-in, three-out transaction to > supply funds to commitment output, connectors output, change > output, and transaction fees. You don't mention it in your reply, but was I correct in my earlier email in assuming that Alice can claim any funds paid to a commitment output after four weeks if its commitments haven't been published onchain? E.g., that in the best case this allows a ~50 vbyte commitment output that pays an arbitrary number of users to be spent as a ~100 vbyte input (P2TR scriptpath for pk(A) && older(4 weeks))? > 1. Mixing coins. > 2. Paying lightning invoices > 3. Making internal transfers If commitment outputs can't normally be spent by Alice for four weeks, then Alice needs to keep enough capital on hand to pay out all amounts involved in the activities listed above. I've seen many people make this point, but I wanted to run some rough numbers to estimate the extent of that capital load. Let's say Alice has a million customers who each receive all of their income and pay all of their expenses with her. In my country, the median income is a bit less than $36,000 USD, or about $3,000 a month. I imagine spending is not evenly distributed over time, so let's say Alice needs to hold 3x the average to be prepared for a busy period. That implies Alice's capital requirements are about $9 billion USD (3 * 3000 * 1e6). At a hypothetical risk-free interest rate of 1.5% annual, that's about $135 that will need to be recovered from each user per year (9e9 * 0.015 / 1e6). Additionally, if we assume the cost of an onchain transaction is $100 and the service creates one transaction per five seconds, that's $630 in fee costs that will need to be recovered from each user per year ((60 / 5) * 60 * 24 * 365 * 100 / 1e6). I'll come back to this financial analysis later. > If we want to enable Lightning-style instant settlement assurances for > the internal transfers, we need OP_XOR or OP_CAT on the base layer > [...] https://eprint.iacr.org/2017/394.pdf What do you mean by "instant"? Do you mean "settlement as soon as the next onchain pool transaction is published"? For example, within 5 seconds if the coinjoining completes on time? That's significantly slower than LN today, at least in the typical case for a well-connected node.[1] I think 5 seconds is fine for a lot of purposes (at both point-of-sale terminals and on websites, I very often need to wait >5 seconds for a credit card transaction to process), but I think it's worth noting the speed difference in a technical discussion. Additionally, I think the idea described significantly predates that paper's publication, e.g.: "Well while you can't prevent it you could render it insecure enabling miners to take funds. That could work via a one-show signature [...]"[2] A problem with the idea of using one-show signatures as double-spend protection is that miner-claimable fidelity bonds don't work as well against adversaries that are not just counterparties but also miners themselves. This same problem has been described for other ideas[3], but to summarize: Bob has something valuable. Alice offers him the output of an unconfirmed transaction in exchange for that thing. She also provides a bond that will pay its amount to any miner who can prove that Alice double spent her input to the unconfirmed transaction. If Alice is miner, she can privately create candidate blocks that double spend the payment to Bob and which also claim the bond. If she fails to find a PoW solution for those candidate blocks, she lets Bob have his money. If she does find a PoW solution, she publishes the block, taking Bob's money, securing her bond, and also receiving all the regular block rewards (sans the fees from whatever space she used for her transaction). I haven't exactly[4] seen this mentioned before, but I think it's possible to weaken Alice's position by putting a timelock on the spending of the bond, preventing it from being spent in the same block as the double-spend. For example, a one-block timelock (AKA: 1 CSV) would mean that she would need to mine both the block containing her unconfirmed transactions (to double spend them) and the next block (to pay the fidelity bonds back to herself). Ignoring fee-sniping (bond-sniping in this case), selfish mining, and 51% attacks, her chance of success at claiming the fidelity bond is equal to her portion of the network hashrate, e.g. if she has 33%, she's 33% likely to succeed at double spending without paying a penalty. The value of the fidelity bond can be scaled to compensate for that, e.g. if you're worried about Alice controlling up to 50% of hashrate, you make the fidelity bond at least 2x the base amount (1 / 50%). Let's again assume that Alice has a million users making $3,000 USD of payments per month (28 days), or about on average $75,000 per minute (1e6 * 3000 / 28 / 24 / 60). If Alice bonds 2x the payment value and her bonds don't expire for 6 blocks (which might take 3 hours), she needs an additional $27 million worth of BTC on hand (75000 * 2 * (3 * 60)), which I admit is trivial compared to the other capital requirements mentioned above. * * * Taken all together, it seems to me that Alice might need to keep several billion dollars worth of BTC in a hot wallet in order to serve a million users. The per-user cost in fees and capital service would be around $1,000 per year. If we assume onchain transaction costs are about $100, that would be equal to 10 channels that could be opened or closed by each user for the same amount (i.e. an average of 5 channel rotations per year). Did I miss something in my analysis that would indicate the capital costs would be significantly lower or that there wouldn't be other tradeoffs (slower settlement than LN and a need to use a timelocked fidelity bond)? Thanks!, -Dave [1] https://twitter.com/Leishman/status/1661138737009442818 [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018010.html [4] Years ago, I think I saw a reply by Peter Todd to some idea about paying money to miners in a fair way and he noted that it was critical to pay miners far enough in the future that the current set of miners wouldn't be incentivized to manipulate who got the money by choosing which block to include the transaction in now. I wasn't able to quickly find that post, but it definitely influenced my thinking here.