-
br-m
<redsh4de:matrix.org> Would
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
-
br-m
<redsh4de:matrix.org> The difficult question is how would FCMP++ proofs be managed for dummy inputs? I see there is a issue about dummy inputs already:
monero-project/research-lab #96
-
br-m
<redsh4de:matrix.org> 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
mrelay.p2pool.observer/e/r77JvdkKVE9nTGtv ]
-
br-m
<articmine> > <@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
-
br-m
<articmine> 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
-
br-m
<elongated:matrix.org> @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
-
br-m
<ofrnxmr:xmr.mx> Remote or local nodes (the downloaded data) isnt the slow part, its the wallet verifying the info that is download
-
br-m
<elongated:matrix.org> @ofrnxmr:xmr.mx: Downloading 200x block size isn’t slow ? You are ruling out most of the current xmr users.
-
br-m
<elongated:matrix.org> Also with 20min wait time, to spend change output really slows down money flow.
-
br-m
<elongated:matrix.org> I don’t expect more than 2x growth year on year.
-
br-m
<ofrnxmr:xmr.mx> You said 10x :P
-
br-m
<ofrnxmr:xmr.mx> 10x txs in fcmp is about 1mb blocks
-
br-m
<elongated:matrix.org> @ofrnxmr:xmr.mx: Good catch 😅
-
br-m
<elongated:matrix.org> @ofrnxmr:xmr.mx: 720mb/day , imagine synchrosing a wallet which was not opened for a month or more
-
br-m
<elongated:matrix.org> Mobile users will pull their hairs out
-
br-m
<elongated:matrix.org> Hopefully lws goes mainstream
-
br-m
<ofrnxmr:xmr.mx> 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
-
br-m
<ofrnxmr:xmr.mx> @elongated:matrix.org: The death of mymonero and birth of skylight seems promising
-
br-m
<ofrnxmr:xmr.mx> As well as lwcli (a cli wallet for lws)
-
br-m
<elongated:matrix.org> @ofrnxmr:xmr.mx: Cake is coming to eat the pie
-
br-m
<ofrnxmr:xmr.mx> Cake doesnt support lws, at least not yet. But yeah. Lws is easy to run (especially if its private / not shared)
-
br-m
<ofrnxmr:xmr.mx> 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
-
br-m
<ofrnxmr:xmr.mx> If private, you can use auto-accept restore(import) and creation
-
br-m
<elongated:matrix.org> I am positive of lws being fully integrated in most wallets before fcmp++ hits mainnet.
-
br-m
<elongated:matrix.org> @ofrnxmr:xmr.mx: I haven’t used lws yet, does it require some kind of api key or user/pass to keep it private ?
-
br-m
<ofrnxmr:xmr.mx> no, the server op can see your txs
-
br-m
<elongated:matrix.org> @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
-
br-m
<ofrnxmr:xmr.mx> You can disable registration / manual only
-
br-m
<ofrnxmr:xmr.mx> Auto-accept is opt-in. You also have option to approve requests
-
br-m
<elongated:matrix.org> @ofrnxmr:xmr.mx: So how can someone share it with a friend ? Keep it at auto accept or go manually make it opt-in
-
br-m
<elongated:matrix.org> Like a onetime/limited key via qr maybe, would be nice to share it with someone