{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-05-27\n🗒️ 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.\n📝 Original message:Hi Burak,\n\nThanks for your response!  I found it very helpful.  I'm going to reply\nto your email a bit out of order.\n\n\u003e 4. Alice places one input to her one-in, three-out transaction to\n\u003e    supply funds to commitment output, connectors output, change\n\u003e    output, and transaction fees.\n\nYou don't mention it in your reply, but was I correct in my earlier\nemail in assuming that Alice can claim any funds paid to a commitment\noutput after four weeks if its commitments haven't been published\nonchain?  E.g., that in the best case this allows a ~50 vbyte commitment\noutput that pays an arbitrary number of users to be spent as a ~100\nvbyte input (P2TR scriptpath for pk(A) \u0026\u0026 older(4 weeks))?\n\n\u003e 1. Mixing coins.\n\u003e 2. Paying lightning invoices\n\u003e 3. Making internal transfers\n\nIf commitment outputs can't normally be spent by Alice for four weeks,\nthen Alice needs to keep enough capital on hand to pay out all amounts\ninvolved in the activities listed above.  I've seen many people make\nthis point, but I wanted to run some rough numbers to estimate the\nextent of that capital load.\n\nLet's say Alice has a million customers who each receive all of their\nincome and pay all of their expenses with her.  In my country, the\nmedian income is a bit less than $36,000 USD, or about $3,000 a month.\nI imagine spending is not evenly distributed over time, so let's say\nAlice needs to hold 3x the average to be prepared for a busy period.\nThat implies Alice's capital requirements are about $9 billion USD (3 *\n3000 * 1e6).\n\nAt a hypothetical risk-free interest rate of 1.5% annual, that's about\n$135 that will need to be recovered from each user per year (9e9 * 0.015\n/ 1e6).\n\nAdditionally, if we assume the cost of an onchain transaction is $100\nand the service creates one transaction per five seconds, that's $630 in\nfee costs that will need to be recovered from each user per year ((60 /\n5) * 60 * 24 * 365 * 100 / 1e6).\n\nI'll come back to this financial analysis later.\n\n\u003e If we want to enable Lightning-style instant settlement assurances for\n\u003e the internal transfers, we need OP_XOR or OP_CAT on the base layer\n\u003e [...] https://eprint.iacr.org/2017/394.pdf\n\nWhat do you mean by \"instant\"?  Do you mean \"settlement as soon as the\nnext onchain pool transaction is published\"?  For example, within 5\nseconds if the coinjoining completes on time?  That's significantly\nslower than LN today, at least in the typical case for a well-connected\nnode.[1]\n\nI think 5 seconds is fine for a lot of purposes (at both point-of-sale\nterminals and on websites, I very often need to wait \u003e5 seconds for a\ncredit card transaction to process), but I think it's worth noting the\nspeed difference in a technical discussion.\n\nAdditionally, I think the idea described significantly predates that\npaper's publication, e.g.:\n\n\"Well while you can't prevent it you could render it insecure enabling\nminers to take funds.  That could work via a one-show signature\n[...]\"[2]\n\nA problem with the idea of using one-show signatures as double-spend\nprotection is that miner-claimable fidelity bonds don't work as well\nagainst adversaries that are not just counterparties but also miners\nthemselves.  This same problem has been described for other ideas[3],\nbut to summarize:\n\nBob has something valuable.  Alice offers him the output of an\nunconfirmed transaction in exchange for that thing.  She also provides a\nbond that will pay its amount to any miner who can prove that Alice\ndouble spent her input to the unconfirmed transaction.\n\nIf Alice is miner, she can privately create candidate blocks that double\nspend the payment to Bob and which also claim the bond.  If she fails to\nfind a PoW solution for those candidate blocks, she lets Bob have his\nmoney.  If she does find a PoW solution, she publishes the block, taking\nBob's money, securing her bond, and also receiving all the regular block\nrewards (sans the fees from whatever space she used for her\ntransaction).\n\nI haven't exactly[4] seen this mentioned before, but I think it's\npossible to weaken Alice's position by putting a timelock on the\nspending of the bond, preventing it from being spent in the same block\nas the double-spend.  For example, a one-block timelock (AKA: 1 CSV)\nwould mean that she would need to mine both the block containing her\nunconfirmed transactions (to double spend them) and the next block (to\npay the fidelity bonds back to herself).\n\nIgnoring fee-sniping (bond-sniping in this case), selfish mining, and\n51% attacks, her chance of success at claiming the fidelity bond is\nequal to her portion of the network hashrate, e.g. if she has 33%, she's\n33% likely to succeed at double spending without paying a penalty.  The\nvalue of the fidelity bond can be scaled to compensate for that, e.g. if\nyou're worried about Alice controlling up to 50% of hashrate, you make\nthe fidelity bond at least 2x the base amount (1 / 50%).  Let's again\nassume that Alice has a million users making $3,000 USD of payments per\nmonth (28 days), or about on average $75,000 per minute (1e6 * 3000 / 28\n/ 24 / 60).  If Alice bonds 2x the payment value and her bonds don't\nexpire for 6 blocks (which might take 3 hours), she needs an additional\n$27 million worth of BTC on hand (75000 * 2 * (3 * 60)), which I admit\nis trivial compared to the other capital requirements mentioned above.\n\n* * *\n\nTaken all together, it seems to me that Alice might need to keep several\nbillion dollars worth of BTC in a hot wallet in order to serve a million\nusers.  The per-user cost in fees and capital service would be around\n$1,000 per year.  If we assume onchain transaction costs are about $100,\nthat would be equal to 10 channels that could be opened or closed by\neach user for the same amount (i.e. an average of 5 channel rotations\nper year).\n\nDid I miss something in my analysis that would indicate the capital\ncosts would be significantly lower or that there wouldn't be other\ntradeoffs (slower settlement than LN and a need to use a timelocked\nfidelity bond)?\n\nThanks!,\n\n-Dave\n\n[1] https://twitter.com/Leishman/status/1661138737009442818\n\n[2] \nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html\n\n[3] \nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018010.html\n\n[4] Years ago, I think I saw a reply by Peter Todd to some idea about\n     paying money to miners in a fair way and he noted that it was\n     critical to pay miners far enough in the future that the current set\n     of miners wouldn't be incentivized to manipulate who got the money\n     by choosing which block to include the transaction in now.  I wasn't\n     able to quickly find that post, but it definitely influenced my\n     thinking here."}