12:47:51 Would https://ccs.getmonero.org/proposals/emsczkp-research-folding-gbp.html enable cheap transaction padding so that all transactions have a balanced input/output count for reduced metadata? i.e a 2-to-4 or a 4-to-2 transaction gets padded to a 4-to-4, padded with two dummy inputs/outputs on each side, or a 1-to-3 becomes a 3-to-3, with 2 dummy inputs 12:47:51 The difficult question is how would FCMP++ proofs be managed for dummy inputs? I see there is a issue about dummy inputs already: https://github.com/monero-project/research-lab/issues/96 12:47:51 If im not wrong, we cannot really provide a membership proof for dummies because they should refer to something from the real output set. Or FCMP++ construction and verification has to be extended to follow something like: "For each input: either this is a real spend with valid membership + spend auth, or it's a dummy i[... more lines follow, see https://mrelay.p2pool.observer/e/r77JvdkKVE9nTGtv ] 17:34:34 > <@elongated:matrix.org> 2c x 40k txs is cheap imho for these actors , won’t be surprised if half of the current txs are originating from them 17:34:34 Sure. Now increase this by a factor of say 200x, by increasing adoption, and the economics change. This is a reason but not even the primary reason why the blockchain surveillance companies need to stymie any kind of peer to peer cash growth in order to retain a semblance of relevance 22:02:30 @articmine: 200x adoption is not realistic for xmr considering how our wallets work, even with 10x on fcmp will be pain to sync over remote nodes 23:01:39 Remote or local nodes (the downloaded data) isnt the slow part, its the wallet verifying the info that is download 23:39:02 @ofrnxmr:xmr.mx: Downloading 200x block size isn’t slow ? You are ruling out most of the current xmr users. 23:39:02 Also with 20min wait time, to spend change output really slows down money flow. 23:39:02 I don’t expect more than 2x growth year on year. 23:39:37 You said 10x :P 23:39:59 10x txs in fcmp is about 1mb blocks 23:40:23 @ofrnxmr:xmr.mx: Good catch 😅 23:42:39 @ofrnxmr:xmr.mx: 720mb/day , imagine synchrosing a wallet which was not opened for a month or more 23:42:39 Mobile users will pull their hairs out 23:42:39 Hopefully lws goes mainstream 23:42:46 100x should be about 10mb blocks and is relatively slow even on localhost, but the bulk of the time is taken up by scanning the thousand+ txs per block. If using onion nodes at loke 500kb/s, then yeah, its going to be a pita 23:43:15 @elongated:matrix.org: The death of mymonero and birth of skylight seems promising 23:43:26 As well as lwcli (a cli wallet for lws) 23:43:40 @ofrnxmr:xmr.mx: Cake is coming to eat the pie 23:45:00 Cake doesnt support lws, at least not yet. But yeah. Lws is easy to run (especially if its private / not shared) 23:45:47 If it's shared, you have to deal with approvals or who can restore etc. Since its resource intensive if somebody decides add a ton of wallets 23:46:07 If private, you can use auto-accept restore(import) and creation 23:47:43 I am positive of lws being fully integrated in most wallets before fcmp++ hits mainnet. 23:48:51 @ofrnxmr:xmr.mx: I haven’t used lws yet, does it require some kind of api key or user/pass to keep it private ? 23:49:21 no, the server op can see your txs 23:50:46 @ofrnxmr:xmr.mx: Yah they have view keys, I meant like how to keep lws server private and not get flooded by some spam bot sending view keys to create millions of wallets and overloading it 23:51:50 You can disable registration / manual only 23:52:26 Auto-accept is opt-in. You also have option to approve requests 23:54:34 @ofrnxmr:xmr.mx: So how can someone share it with a friend ? Keep it at auto accept or go manually make it opt-in 23:54:34 Like a onetime/limited key via qr maybe, would be nice to share it with someone