pull down to refresh
418 sats \ 10 replies \ @03479d0ee6 21 Jan \ on: How is Fedimint better than MercuryLayer? ecash
AFAIK mercury you can only send swap fixed amounts of bitcoin like 0.1, 0.05 btc etc. It's like virtual open dimes you have an utxo and you can send that to another mercury user. Fedi you are thrusting a group of guardians and you get ecash that you can send to anyone even offline, pay LN invoices etc. I would say in mercury you have less changes of being rugged but more limitations of what you can do. Fedi will be more interoptable with everything and probably more adopted as well. Fedi VS Liquid-Fedi allows you to choose your federation, who you thrust, liquid does not. If you have L-BTC to make a payment you have to swap to LN, in Fedi I think it will be seemless, your Fedi will pay the LN invoice from your balance. It will be probably easier to on-board new users to Fedi that will give them a lot of services, a whole package than just Liquid. This is my 2 sats.
Good post! One correction, Fedi is an app for Fedimint
reply
reply
Just to add to my previous reply. I think adoption will have a big role in this, and Fedimints will have a good user experience, its a whole package, btc custodial, onchain, LN, ecash, Nostr integration and direct messaging, account recovery, probably inheritance, in the future some may offer stablecoins, and maybe fiat on/off ramps. I think Mercury does not compete on this and if almost no one goes to mercury the advantage is gone because low fees are between mercury layer, while even if 2 users are on different Fedimints with ecash you will claim the sats with lightning just like cashu now.
reply
Again - what would stop someone acting as an LN gateway?
Let’s take it one step further - what is stopping someone from making an app that has all the features that Fedimint will have but uses Mercury? The answer is nothing. There can be many Mercury state chains that have apps that all support LN for exiting/interoperability between chains :)
There really is no point to Fedimint. From a payment perspective it doesn’t improve things much over something like WoS
reply
Fedimint and Mercury aim to tackle different problems. Fedimints were built to replace exchanges custody mostly, and as it is more centralized it is easier to manage things and offer more things to the user's. Mercury aimed at offchain txs with more privacy. There are already Fedimint apps working, there is none like Fedimint using Mercury. But let's see some use cases: Funds(account) recovery, Mercury cannot do it because only the user and the SE have the keys. LN txs, in a Fedimint the user can receive funds immediately without any balance in the fedimint. With Mercury the user would need funds already in the statechain to have some inbound liquidity. Ecash - mercury only allows direct tx with full utxos, using something like ecash would probably not be possible because ecash requires an entity to keep track of the tokens to redeem, while the SE could do this it would remove the the advantage of the SE not having never full control of funds. Onchain-Mercury cannot send just a fraction of the utxo to an onchain address, its always a full utxo. In a Fedimint it's just a normal onchain tx. I might be wrong here about some aspects, but the point is, even if some are possible to implement, because it wasn't the main purpose of Mercury the complexity involved would be to big. They are tools with diferent purposes.
reply
Fedimint and Mercury aim to tackle different problems.
I do not agree with you that they tackle different problems overall. They are in practice very very similar. How would it be better for an exchange to be a fedimint? What problem does it solve?
Mercury aimed at offchain txs with more privacy.
So is Fedimint.
There are already Fedimint apps working, there is none like Fedimint using Mercury.
There are multiple clients and a server implementation for Mercury: https://github.com/commerceblock/mercurylayer
Yes, those are not as polished and not "apps", but you can probably see how that's not the hard part here.
Funds(account) recovery, Mercury cannot do it because only the user and the SE have the keys.
I consider this to be a good thing. It's custodial unlike Fedimint.
LN txs, in a Fedimint the user can receive funds immediately without any balance in the fedimint. With Mercury the user would need funds already in the statechain to have some inbound liquidity.
This is not a feature of a Fedimint. This is a feature of Fedi. They are different. Nothing is stopping someone from building a "Fedi" but on top of Mercury that lets users deposit straight into the statechain. They do need to lock up a but of money up-front, but overall it's not a big problem to solve.
Ecash - mercury only allows direct tx with full utxos, using something like ecash would probably not be possible because ecash requires an entity to keep track of the tokens to redeem, while the SE could do this it would remove the the advantage of the SE not having never full control of funds.
Yes, this is probably the one downside, but I think you can work around this. You could for example imagine a situation where a user runs up a credit to one or several LSPs.
For example, let's say a user wants to pay 80000 sats and they only have a 100 000 sats UTXO. When paying the user sends the UTXO to the LSP and the LSP pays the invoice. The LSP can then credit the user internally with the 20 000 sat remainder. Next time the user wants to pay something using LN they will draw from this credit (or again, send a larger UTXO if needed). It's a trade-off but I sure as hell prefer having some small amount of sats non-custodially rather than all of my sats.
Onchain-Mercury cannot send just a fraction of the utxo to an onchain address, its always a full utxo. In a Fedimint it's just a normal onchain tx.
You would do payments via LSPs not on-chain.
I might be wrong here about some aspects, but the point is, even if some are possible to implement, because it wasn't the main purpose of Mercury the complexity involved would be to big.
I don't think the complexity in building something like this is too big. If it was, then building the same thing for a Fedimint protocol would also be too complex and evidently it is not :)
reply
True, but I think Fedimint allows the tx of ecash/onchain btc and LN of any amounts, mercury you have a mercury address I don't think you can send directly to a btc onchain address out of the box. So what I meant is it will probably be easier to jump around all this in a Fedimint, it will be more user friendly than in Mercury where I feel you will need to go through a few extra steps.
reply
This is a good response, however you're missing the elephant in the room regarding Liquid vs Fedimints.
Liquid there is an audit-able supply of tokens. The blinded transactions hide the amount being transacted (and who holds what). However you still have visibility of total supply of said token.
reply
I think Cashu had something like proof of reserves, don't know if that can or will be used in fedimints. But yes it can be a problem i guess, at the end of the day your are always thrusting the guardians. Liquid is more transparent in that regard.
reply
There are 3 main problems with Liquid:
- They rug all users pegged Bitcoin (unlikely)
- Possibility of them censoring your transactions
- Possibility of refusing Peg-Out
In practice I think 2 & 3 are the same problem....meaning if you could prevent them from censoring transactions, they couldn't stop you from pegging out (specifically, they wouldn't know who was pegging out therefore they wouldn't try to stop it).
Liquid, like BTC has no real concept if addresses are owned by same person or not. So a mitigation strategy to this is to immediately move funds from Peg-In to another address you control.
So (a) Peg-In Address --> (b) Initial L-BTC address --> (c) New L-BTC address
In theory, at that point, Federation members can no longer "know" that Address (c) is owned by same person that pegged in or not. Further, Federation members will no longer know what amounts are where.....
reply