/biz/ - Business & Finance

Do these threads get no replies because it's a shitcoin nobody cares about, or do they get no replies because everyone is accumulating for the golden staking period? So hard to know these days.

wheres thr airdrops

>>16822485
China coin
Copy coin
Give us your money
Round eye cunt

>>16822485
You didn't list the single biggest cons:
there's no technical way for them to force the use of their token.
The core technology is the zk-snark circuit with keys generated in a mpc ceremony, but they have to publicize them eventually. At that point it's trivial to copy everything but strip LRC.
They know that, which is why they are hiding proving keys, waiting before their own dex (wedex) launches, but I don't think it's going to be effective.

Fantastic product, worthless funding token. Many such cases.

>>16822736
Everytime I see this coin on biz I literally am a bit frusterated. I thought this would stay silent a bit longer. Luckily no one here has the capability to move the market....rriight?

>>16822485
Cons:
>No one is interested in buying

>>16822736
The former.

>>16823008
This. Token is pointless. Excited for higher performance dexes though

>>16822736
i bought a small bag and staked it

>>16823008
aren't the incentives to stake it real though, why are they negated by the core protocol being forkable? do you mean that those incentives could just be replicated but with staked ETH instead?

>>16822736
Shitcoin that is already made obsolete by better projects (Algorand on the performance front, Stegos on the privacy front). LRC has no future.

>>16823008
>>16823614
particularly the security/reputation stake

>>16823614
the only reason for collateral is to prevent a timelock attack. It's extremely weak and pretty much a made up risk.
>That’s why we also support certain on-chain requests, most notable here, the on-chain withdrawal request. These on-chain withdrawal requests are done directly by users on-chain. If the operator refuses to process them, the Loopring smart contracts know this and take action:

>The smart contracts force the operator to do these on-chain withdrawal requests; it cannot process any other requests (trades, etc) if such a request remains outstanding. [This force happens after ~1 hour]
>If the operator keeps refusing to process them, the exchange goes into withdrawal mode, and the operator is slashed. [Happens after ~1 day]

Consider how absurd the premise is - a dex operator (making money on his dex) disappears for a day. Why is any collateral needed? He already kills the value of his dex (implicit slashing), which means it can't be intentional.
Even if, the worst that happens is that users have to wait 24 hours for their funds.

The funny thing is, to run a dex you need to stake a lot of lrc as a minimum, it's $20k or something. This means that plausibly someone starting a dex couldn't even afford to buy enough lrc, and would be forced to strip it away if only because of this.

>>16823616
>made obsolete by better projects
>(Algorand on the performance front, Stegos on the privacy front)

>>16823643
thanks for the timelock attack explanation
>He already kills the value of his dex
isn't that value harvested by collecting trade fees in LRC? or i suppose it wouldn't be too difficult to write a fork that collects fees in ETH?

>>16823687
>isn't that value harvested by collecting trade fees in LRC?
Fees are collected in traded tokens. I'm not exactly sure how are fees in lrc enforced, but probably the currently deployed contracts pause if the operator doesn't burn lrc equivalent to 0.01% fees? I'm actually reading the contracts right now.
In any case, there's no physical way to enforce the use of lrc. For staking, it's impossible, period. For fees, at best they could encode the public key of the loopring contract in the circuit itself (which I looked at and it appears they don't) and force transfers to be in the on-chain data, but then, the withdrawal itself is handled by the smart contract which is free to ignore it. Users won't care about lrc fees - they only care if smart contract enforces the possibility of their withdrawals.

>>16823687
Interesting. From what I understand, the tokens/eth claimed as the 0.01% are sold on uniswap for lrc. Huh.

>>16822736

It's a dime a dozen vaporware shitcoin that only shills and retarded bagholders care about

>>16823746
>>16823787
based thanks fren

>>16823817
well it's more complicated, there's some dutch auction thingy. But the end result is the same.

To be fair, it's all so complicated I can see a future in which dex creators decide the 0.01% fee is worth paying to not have to tinker manually, and once they start it gets increasingly harder to switch as they would have to pause and redeploy the exchange contract.

>>16823817
there's a design document with all details
https://github.com/Loopring/protocols/blob/master/packages/loopring_v3/DESIGN.md

>>16823878
>>16823860
honestly /biz/ has been fucking shit except for like 3 threads this past week or so, you've completely negated those shit threads my friend

>>16823787
So an exchange could just collect fees in traded tokens by making the sell side on uniswap. Wonder how costly that would be in terms of gas

>>16823794
Vaporware means there is no functional product. Loopring have a useful product, they just have a questionable token utility. Words have meanings. It might be a useless token and a bad investment but that doesn't make it vaporware.

>>16823930
There's no "sell side", there are liquidity pools and what you describe is impossible.
I have a feeling there's a discrepancy between the actual design of the system (seems to be just uniswap?) and some complicated dutch auction design. I guess they decided uniswap is enough.
---
One design problem I noticed is the limit of 253 arbitrary tokens, other than eth, weth and lrc. That's not that much. Unfortunately that's in the zk-snark circuit itself which means changing this would require regenerating the multi-party computation process.
Looking at the complexity of the system, I think it's going to start with relying on lrc as first dexes are going to be done with people already in lrc (or even team members) - like wedex, but eventually others are going to fork the system. If those first dexes catch on the subsequent forks are going to have some problems competing.

In the long run, there are also dangers on the purely technical side. There's EIP 1962 long in the works that's going to allow recursive zk-snarks via the MNT curves - something that would massively decrease the proving costs of this and make it much easier to extend base functionality. There's also the new recursive proving technique without trusted setup that doesn't rely on elliptic curves at all from the zk-sync team - and they promised to release the general-purpose compiler this year.
It's possible in principle to make a dex that also functions as a mixing contract, which I think would be massively popular.

https://eips.ethereum.org/EIPS/eip-1962

The true long-time winner is, of course, eth itself.

>>16823643
>>16823969
Damn so I wasted $200 on this shit?

>>16824037
it's not that bad
>Looking at the complexity of the system, I think it's going to start with relying on lrc as first dexes are going to be done with people already in lrc (or even team members) - like wedex, but eventually others are going to fork the system. If those first dexes catch on the subsequent forks are going to have some problems competing.
basically, think of it as bnb for lrc dexes (at least one is in the works).

>>16824035
>In the long run, there are also dangers on the purely technical side.
Can you elaborate on that? What you wrote afterward doesn't seem dangerous at all?
Thank you for sharing your research

>>16824035
Your last comment about dexes that are mixers makes raised so many questions as to how the development vs regulation process is going to pan out. Such exciting times to be following crypto. Thanks for your insights.

>>16823969
Fren, have you tried to make a trade on Dolomite.io? Utter shit-tier, barely functional as an exchange. And they’ve been mainnet for what, a year? Vaporware is a pretty good description.

One thing I remembered - they are not alone. Starkware along with Deversifi is also launching a zk-based dex.
https://twitter.com/StarkWareLtd/status/1214236179551412232
This means loopring is going to have similar competition right at the start.

>>16824083
Recursive zk-snarks make it likely that competitors with much better functionality (and performance) are going to arrive, making the current loopring design unattractive. Eg. the current design has a hard limit of 4150 trades per one zk-snark proof, and each proof verification costs 225k gas. It would be much more efficient to have one proof for arbitrary number of trades.

For the zk-sync part, it kills the biggest barrier to entry - the need for a multiparty proving key generation. Proving keys in (currently used) zk-snarks rely on "trusted setup" meaning the proof generator can later generate false proofs (which here would allow fund stealing). For this reason, the generation of proving keys is split among N people, with a crucial property: only one person out of N has to be honest (ie. delete all information) to prevent anyone from generating false proofs.
This is hard to organize and is extremely time consuming.
Current loopring circuit used 15 people:
https://loopring.org/#/ceremony (scroll to the bottom if the link doesn't work)
from what I know, it takes one day on a powerful pc for any person to generate their part.
That's a big advantage for them, as you can't modify anything in the core circuit without redoing the whole ceremony, making it more complicated to work around the default setting (lrc token).

Take the need for the mpc ceremony away, and anyone could fully generate something like loopring completely on their own, making it extremely unlikely that any non-loopring affiliated dex continues to pay forced fees. As a bonus, these new schemes are also quantum secure and faster to prove.

If you're interested in more details, read the zk-sync announcement
https://medium.com/matter-labs/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58
especially the part about their new zk-snark scheme.

>>16824201
so until zk-sync launches their recursive proving technique later this year LRC will be an ok hold