pull down to refresh
21 sats \ 1 reply \ @03479d0ee6 22 Jan \ parent \ on: How is Fedimint better than MercuryLayer? ecash
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.
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