Yes- it is a proposal which, as I understand it, is intended to clarify the questions asked, initiate dialogue, raise awareness, and move forward if there is consensus/ support. So far, people have raised some great questions. It would be great to get answers if this is to move forward from a proposal status - no?
@Talyght, could you and your colleagues please clarify some of the questions that have been raised in the coming days…? That would be very welcome.
Small comment, but “capture” might not be the best word to use here. Brings to mind a “hunter/hunted” vibe. I suggest something like “engage” or “recruit” instead.
In our opinion, Sovryn can still run its “uniswap-style DEX” on RSK with a pegging mechanism for BTC, while building a DEX ecosystem on Mintlayer with direct swaps (atomic swaps/lightning swaps). Both are valuable and have specific use-cases. There is no such a thing as a unique reference platform for Mintlayer DEX transactions, since the order book is a distributed hash table (imagine your p2p shared library on torrent) and any entity - first and foremost Sovryn itself - is welcome to build platforms to facilitate DEX trades as book aggregator or liquidity provider, also providing their own web platform and tools.
As said above, the purpose is not to collapse the platform at all. There is not an alternative platform built from Mintlayer team that can replace Sovryn. As Sovryn currently allows users to connect their wallets to the platform and exchange tokens, it can build a similar mechanism for Mintlayer, with the difference that you will be able to connect directly your BTC wallet (and also use Lightning Network). This doesn’t imply that RSK should be left behind. The two ecosystem can run peacefully together, on Sovryn, and users will choose one chain or the other as it is more convenient in that particular situation.
To answer your questions:
- the private sale price was 0,0952$
- “a week after the token sale” means that “All addresses belonging to Bitocracy users that have received MLT tokens during the public sale or the week after the public sale are eligible to receive the airdrop”. The rationale is that if the public sale allocation is finished before you can buy MLT, you still have incentives in buying later because you are still eligible for the airdrop. Anyway, thank you for pointing out that it wasn’t clear enough. In case, we’ll reformulate that sentence for the actual SIP.
- regarding the vesting, the idea is that a Bitocracy user buying 1000 MLT (locked or unlocked doesn’t matter) remains eligible for the airdrop as long as at least 1000MLT tokens are still in the indicated address for the entire 12 months. The 1000MLT tokens airdropped are unlocked progressively month by month.
- to answer your question about how can the maximum be applied (if for example 400 SOV stakers qualify rather than just 300: among those that asked for the airdrop, we will pick up only those that bought the tokens first (independently from the moment they asked for the airdrop). So if you bought tokens on public sale, it’s more likely that you will receive the airdrop, if compared to those who bought tokens during the week immediately after the public sale
- finally, regarding the liquidity mining: to calculate the quota to each one, only the rMLT amount is considered
Thank you dseroy for your thoughtful questions. I try to answer all of them here:
- What makes Mintlayer “built on Bitcoin”: the two blockchain are strictly linked together, since every Mintlayer block has a reference to a Bitcoin block, so if Bitcoin reorganizes its chain (or a block is orphaned) then also Mintlayer does roeorg. This allows better reliability of atomic swaps (a reorg would result in a transaction cancelled in both the chains). Also, the Mintlayer rounds, determining the participants in the governance as blocksigners, committee and block creators, are determined through an algorithm taking as a random variable the hash of Bitcoin blocks. Finally, the status of Mintlayer blockchain is consolidated in the Bitcoin blockchain as snapshots through a sophisticated system that is built-in the protocol (check the DSA Consensus paper). Besides that, it’s worth to note thata other features of Mintlayer directly inherited from Bitcoin allows for direct interoperability between the two chains: for example UTXO structure and Lightning Network.
- Of course, we’d appreciate the chance to do an AMA session with all Sovryn users
- MTL token value & use cases: once mainnet is live, MTL tokens can be used to pay network fees, issue new tokens/tokenized assets on the chain, create and update Access Control List for security tokens, stablecoins, stock tokens etc. and of course, to collect for network fees in case you have been selected as participant in a round.
- regarding the 300,000 MLT airdrp at 0.20$, you might be right, thanks to your feedback we are re-considering these metrics. We published the draft just because we wanted feedbacks like this, so we really appreciate it!
- the initial market cap is far below the 400mln due to the vesting mechanism. Only around 20 MLN are circulating at TGE (this amount might slightly vary, depending on how much tokens will be allocated in the public sale here on Sovryn)
- for your final questions “does this platform add value to sovryn?”, I must specify that Mintlayer is not a platform, but a protocol. And yes, if Sovryn integrates Mintlayer, this might be a great added value, at least in my opinion.
thank you, I agree! We’ll rephrase!
I really appreciate you taking the time to respond thoughtfully. As I shared on the forum, I felt this project aligned with our mandate as a community and was hoping more experienced folks could help with the “tokenomics” as that seemed like the weakest part of the proposal.
I’d argue that it’s technically a draft SIP. Saying its a proposal and not a SIP is confusing since sip stands for Sovryn Improvement Proposal.
What a well written draft SIP. Informative and detailed. Good job Guillermo (@Talyght)
I agree on most noted points of the proposal however my only concern is that as long as MintLayer is complementing the Sovryn ecosystem and is a value add then we can mutually benefit from this; but if the intention is to compete/decommit Sovryn DEX/ protocols to be replaced by MintLayer then I’d be hesitant to vote yes on the actual SIP.
Thank you for putting this for forward and good luck!
My general thoughts after looking through all the materials:
I don’t necessarily see Mintlayer as competing with Sovryn. It may be an alternative blockchain to deploy some of Sovryn’s tools to, and there is likely a way for SOV holders to capture value from any Sovryn tools deployed to Mintlayer just as they are able to capture value from Sovryn’s RSK deployment.
I am neutral right now on many of the architectural decisions Mintlayer is making (although you can see below I have a bunch of questions that might change my mind one way or another) and I think it’s probably an experiment worth running. Although I’m not thrilled about the idea of Sovryn having another blockchain to have to build against, as Sovryn dev resources are already spread quite thin.
If Mintlayer is going to happen anyways, with or without Sovryn’s help, SOV holders might as well get a piece of the upside. So I don’t see a problem with Mintlayer launching on Origins, from that perspective.
My main concern is that there is no testnet yet, the project is far from a working product. This implies a high likelihood that the MLT sold would be considered a security in certain jurisdictions including the U.S. This could be a legal issue for the Mintlayer project and hurt the value of the token, it could also create legal issues for Sovryn if Sovryn team members are seen as promoting or brokering the token sale (note: I am not a lawyer). Also, this lack of a working product creates a situation of high trust required between the token buyers and the token sellers, and if the sellers betray that trust then this could reflect poorly on Sovryn. This fact alone has me leaning toward opposing this proposal.
Now for my questions about Mintlayer:
- Why should bitcoin holders use a DEX based on a sidechain that drives value to holders of a new token (MLT) rather than a DEX based on a sidechain that drives value to BTC miners and by extension, BTC holders (RSK)?
- In your opening post you say:
Does Mintlayer actually implement on-chain blockchain governance i.e. tokenholders vote on the consensus rules and full nodes automatically update according to the results of tokenholder votes, as is the case with Decred, EOS, Polkadot, Tezos, etc? If not, what exactly is referred to here by “governance”? This issue of “governance” is imo orthogonal to the question of how a two-way BTC peg would be deployed.
The DSA paper says that the Mintlayer consensus algorithm uses a bitcoin block hash as its source of randomness for selecting participants in a round. Using a block hash has long been considered to be an insecure source of randomness. How important is it that the selection of participants is truly random? And/or what are your general thoughts on past critiques of using block hashes as a source of randomness?
The DSA paper says that block time is 1-2 mins. There are many PoS algorithms now that are much faster. Why was 1-2 mins chosen for the Mintlayer DSA block time?
The DSA paper says that the block size limit is 1MB. At a 1 min block time that is max 10MB per 10 mins, approximate 5x the amount of data of bitcoin blocks. This brings to mind bitcoin block size limit debates where even 4MB was considered close to or at the threshold where decentralization would be irreparably harmed (based on “immediately excluded nodes” in Table 2 here). How do you think about Mintlayer scaling, the cost for users and validators to run Mintlayer full nodes, and how Mintlayer’s block size limit and other design decisions fit into all that?
The DSA paper says:
Everyone may include a marker on the Bitcoin blockchain with the hash of a Mintlayer block at any height (let’s say height X)… When the proposer generates the Mintlayer block at height X+n where n is a positive integer, it can include a reference to Tx0.
So checkpoints are optional? Could this turn into a “tragedy of the commons” problem where since no one has to do it, and it costs money to do, no one will ever do it? Why not make the checkpoints part of the consensus rules e.g. “there must be a checkpoint every x number of blocks”?
- You say:
However the Mintlayer DSA paper says:
A node cannot validate checkpoints on two different chains and once reconstructed the respective trees, it will start validating what appears to be the longest chain in terms of signature power, which in this caseis the attacker’s one.Therefore, to avoid a long range attack against new nodes synching from the genesis block, the new software releases need to include the updated checkpoints made on the canonical chain.
So it seems that even with the checkpoints, new nodes in Mintlayer rely on subjectivity to decide which chain to follow, is that right? Which seems to contradict what you wrote in your first post?
- You say:
However one of the main benefits you cite for the Mintlayer DEX is:
Why do you consider tokenization “pollution” of bitcoin’s block space, but not cross-chain atomic swaps which require multiple bitcoin txs to execute? And why do you seem to make out RSK and Liquid federations to be a downside, while Mintlayer’s documentation suggests using a federation to create MLS-01 and MLS-02 tokens?
One of the techniques used by the Mintlayer DEX is cross-chain atomic swaps. In cases where two different assets are being exchanged e.g. BTC and USDT, how, if at all, does Mintlayer prevent users from exploiting the free option problem?
Have you considered using OpenDEX for order propagation and matching? What are your general thoughts about OpenDEX?
- The Mintlayer documentation Section 3.3 says:
A token can be issued on the network by implementing Bullet-proof Confidential transactions with ring signatures
So is this using RingCT as implemented in Monero? If so, what ring size is Mintlayer using? Why use RingCT (which only encrypts transaction amounts) rather than zk-SNARKs such as implemented in Zcash (which encrypt transaction amounts as well as the sender and recipient of a transaction)?
- In the Mintlayer documentation Section 3.4 it says:
It is possible to use the Mintlayer blockchain as a second layer for other blockchains like Bitcoin or Ethereum. Central entities can wrap tokens on Mintlayer: they lock-in funds on the main blockchain, which creates a corresponding amount of MLS-01 or MLS-02 tokens.
Rather than relying on centralized entities or federations with nothing at stake to secure the BTC peg, have you considered implementing a protocol such as the Nomic BTC peg?
- The Mintlayer docs in Section 4 have a lot of negative things to say about Turing-complete smart contract languages. What do you think about the object-oriented approach taken by Agoric?
Regardless of the legal uncertainty regarding securities offerings, i am opposed to launching any project on the Origins platform that does not have an MVP / codebase, and is looking for funding to implement such work.
imho, Origins token launches should only be for products / projects that are looking for Scale-up funding, and not Seed-Round funding.
The more appropriate track for the type of proposal Mintlayer is making would be to
- Participate in one of the Sovrython bounty tracks, or submit to the research grant bounty.
- Win a bounty award for an MVP, or a research bounty
- Participate in the follow-up grant round to further develop the protocol, and show progress
- Introduce a SIP for a token launch for Scale-Up funding.
Thank you Light for your research, you are one of the reasons why I love humanity : )
I’ll try to answer every single point here. Luckily, a few other Mintlayer contributors helped me with some of the most technical questions. You really did a good job in exploring Mintlayer and you deserve good answers! I hope there is everything you were looking for here, but please, any other feedback is absolutely welcome!
MLT has been audited by a law firm and classified as “utility token” so that San Marino authorities (issuance will be made from San Marino) can classify it as “utility”.
Because in the first case, the blockchain governance is in the hands of holders who have directly invested in the blockchain, in the latter, BTC miners have no direct stake in the chain.
Here an example of what I mean:
F2Pool hashrate amounts to 12.50 exahash/s (which is 12,500,000 Terahash/s)
With that hashrate, it can get 0.416 BTC monthly mining RSK blocks (https://mining.rsk.co/).
Also, with that hashrate, F2Pool mines about 630 Bitcoin blocks (obviously these numbers change a lot in time, you can check the current status here Pool Stats - BTC.com)
Average reward fees per block: 0.532, multiplied per 630 blocks = 335 BTC
Coinbase reward of 6.25 x 630 = 3937,5 bitcoins. So total revenue of that pool: 4,272 bitcoin
0.416 BTC of revenues on RSK equals 0.000097% of the revenue of that mining pool.
The 0.000097% of the miners revenues are the opportunity cost a Bitcoin pool renounces if it attacks the RSK chain.
It’s not strictly a voting mechanism like Decred, EOS etc., but more like Bitcoin. POS stakers are like Bitcoin miners, so they can “vote” on improvement proposals (BIP-like) using the block version field or even the coinbase (i.e. where miners wrote NYA during the blocksize wars to show support to the New York Agreement proposals)
A bitcoin miner can manipulate a Bitcoin block renouncing to 1/2 of the block reward forging the block with a “favourable hash” within a timeframe of 1-2 minute. In this case, the only thing that the miner achieves is to reduce entropy from 68 to 67, which is the minimum entropy of a block that is composed of 32 bits of nonce representation and the rest is the merkle root of txes (from 32 to 68).
What does it mean? If the Mintlayer Consensus algorithm only takes the block hash % 1008 to get a number X, the staking user with index X will be selected, then the index (X+hash^2)% and so on. For the cost of 1/2 Bitcoin block reward the attacker could select index X by manipulating one of the 32 bits (moving it to left or right by using powers of 2). In that case one of the blocksigners with high signature power can wait for this manipulation on the Bitcoin blockchain and attack the Mintlayer chain.
The attack is very unlikely and has negligible impact (you can slightly affect the order of the blocksigners/slot owners and slightly increase the chance to win a slot), because you need to have a huge stake in Mintlayer (which is one good way to disincentivize such an attack) and you have to be a Bitcoin miner renouncing to part of the reward.
Anyway, with bitcoin mining difficulty increasing, the leading zeros in block hash are hurting the entropy of the block hash (more leading zeros → less entropy) and indeed, we have no control over this. What if at some point millions of dollars transitioning into the Mintlayer transactions will cause some nice interest for some parties to throw away some millions only to manipulate the miners?
To increase the entropy and further reduce the possibility of such an attack, we decided to sum to the bitcoin hash the root of the merkle tree generated by the UTXO, which is part of the block too (utreexo).
Larger time spans means less possibility of orphaned blocks and make it unlikely that other blocksigners try to replace the slot leader which has the higher chances of being the actual block creator. From a mere technical standpoint, block frequency could be higher, but we don’t see reasons to increase it by spamming more blocks (more blocks with the same amount of transactions adds a fixed cost to the blockchain in terms of weight and validation time). From a “human” perspective, 2 minutes block frequency is a fairly acceptable time: it means that - on average - when you make a payment it will be included in the first block within the next minute. If we consider 1 minute block frequency, it’s on average in the next 30 seconds.
Speaking of storage, Mintlayer shouldn’t be problematic given the fact that Dryja’s utreexo shrinks a lot the size of UTXO set, while the checkpoints allow you to safely prune the chain up to the last checkpoint.
Speaking of validation, 10mb per 10mins (while BTC is about 2mb) is quite high considering the current hardware technology and I would say it can be considered an upper limit. But also consider the following:
- Block frequency can’t be exactly 1minutes, it will always be greater than 1 minute, because blocks proposed need to collect counter-signatures from the other blocksigners. It will be pushed towards the limit of 1 minute only if block proposers think that it is a convenient strategy in terms of block reward (they may have incentives in waiting 2 minutes before to propose the block, in order to collect more transaction fees)
- Those 10mb are the very upper limit in case the blockchain is fully congested at maximum block frequency. Even if all current stablecoins transactions moved to Mintlayer, it would be far from being congested. If your concern is that Mintlayer DEX will lead soon to a congested chain, you have to consider that it’s likely that users will move to LN DEX even when onchain fees are still low, because LN swaps have higher speed and therefore an advantage in terms of arbitrage. Note that Ethereum is currently congested because of Uniswap onchain DEX (a very different kind of DEX if compared to the atomic swaps) and because of onchain arbitrage transactions between Uniswap and other DEXs.
- Mintlayer fullnodes are dedicated to financial activity, not just common users holding money, so it might also be reasonable that nodes will be heavier than Bitcoin fullnodes and probably they will be run by a specialized niche of the bitcoin holders
By the way, to be completely honest, there is an ongoing internal discussion about reducing the blocksize to 500kbs. We’d like to have feedback about this from the entire community.
Yes, checkpoints are optional. In general, you will need a checkpoint in 2 cases:
- You want to safely prune the blockchain (which means savings, in terms of disk storage)
- You want to protect the chain against a long-range attack from an entity who got the majority of signature power in the past. If this never happened, you probably won’t need a checkpoint.
The cost of a checkpoint is minimal (1 transaction on the Bitcoin blockchain), so we think there are many reasons and really tiny costs for doing that.
We were actually more concerned about a “malicious use” of the checkpoint system rather than the possibility that no one actually creates checkpoints. So, making it mandatory would mean really huge risks and unexpected outcomes, especially because it needs a Bitcoin transaction, which is not something you can control directly in the Mintlayer protocol.
Not exactly. All synching nodes that are up-to-date don’t rely on subjectivity, since all checkpoints are created locally on those nodes, according to the protocol rules, and are not hardcoded. But if you run a new node from the beginning, there is the very unlikely case in which a malicious node having the majority of signature power (at some point in the past) forks the chain and makes you think the forked branch is the correct one, because block frequency in that branch is higher. The chain broadcasted by that malicious node won’t be relayed by honest nodes, so this attack may be successful only if you have a direct connection with the attacker, which means basically that your node is directly under attack. A similar attack on Bitcoin is the sybil attack, where your node receives wrong information from the network (e.g. if you are isolated). In the case of sybil attack on Bitcoin, once you know that there is a longer chain (the honest, correct one), you immediately reorg, but in the case of Mintlayer, you may have already locally validated a checkpoint on the fake branch, so you won’t reorg on the correct chain and you need to bootstrap the node from the beginning. Basically, the problem here is not the absence of checkpoints, but rather the fact that you will create locally a “wrong” checkpoint when you are induced to sync a fake chain. By the way, to avoid this, the user bootstrapping a new node could look for a software release with updated checkpoints and cross-check those checkpoints with other sources. I think you would do the same in the Bitcoin network if you suspect you are under a Sybil attack.
Everything on the Bitcoin blockchain and Bitcoin transactions that has a different purpose than the mere transfer of bitcoins is, in my opinion, pollution. An atomic swap means that you want to spend your bitcoins, so you are transferring them. A Bitcoin transaction created to timestamp a document, to create other tokens and to move them has nothing to do with transferring bitcoins. Today, if you want to spend your bitcoins to buy whatever token/altcoin, you need to first transfer them (towards a centralized exchange, or a federation), so you still need to make a Bitcoin transaction. At this point, why not exchange bitcoin directly?
Federations, themselves, are not bad. They are just another use case. Mintlayer focus is on direct swap so that users can DEX bitcoins for other tokenized assets without any other passage or intermediary, which is something currently missing in the ecosystem, but that doesn’t mean all users are interested in the same things and we are glad if developers freely build their projects on Mintlayer, including peg-in federations.
We are building a blockchain ex-novo which is focused on these DEX swaps, so we can implement whatever strategy to mitigate the free option problem. The most likely one is simply to introduce a timeout system: if Alices has Bob signatures to sign and broadcast the atomic swap to the network, she needs to broadcast it within n blocks, otherwise it’s invalidated.
Actually yes, we are studying different solutions from 0x to OpenDEX and it’s likely we will partner with other entities (why not, maybe OpenDEX too) to accelerate the development. Most of the work required for Mintlayer is in some way already “done”, the matter here is to collect all the “pieces” from the ecosystem and make them fit into the puzzle.
As it stands a final decision on confidential transactions is yet to be made. The MLS-02 standard isn’t expected until Q2 2023 so we are currently focused on ensuring the testnet is released ontime.
We have looked at a variety of options so far including zk-SNARKS, zk-STARKS and bulletproofs. We have looked at a variety of things including difficulty to implement, security of the method, ease of batching transactions, proof sizes and times for both proving and verification. So far the trusted setup required by vanilla zk-SNARKS has been off putting but Microsoft’s work on Spartan has shown that’s not necessarily an unsolvable issue. It’s fair to say this is still a somewhat open issue and something we welcome community input on as we start to tackle this following the testnet launch later this year.
I never heard about that, we’ll take a look. By the way, devs will be free to build their own peg-in mechanism, so we would be glad if there are more options on the table. Thank you for mentioning this. If it will be necessary to make some adjustments to the Mintlayer protocol in order to make it compatible with a better peg-in mechanism, why not?
i am opposed to launching any project on the Origins platform that does not have an MVP / codebase, and is looking for funding to implement such work.
in fact, we agree with this, and after some consideration we have decide to push back the public sale until at least a time when we have a testnet ready to launch, which should mean at least another couple of months down the road.
We will revise the draft SIP accordingly or post a new one, but for sure, we would like to take part in the Sovrynthon or provide other types of bounties.
Since the Mintlayer team has been exposed to the Sovryn community, we’ve fallen in love - We see here a group of people who clearly share many of the same values which drive Mintlayer, and know what the current “DeFi on Bitcoin” experience is lacking better than anyone else.
As a new project fresh out of stealth mode, we don’t have much of a community of our own except for the extended friends and family who have been following us since the beginning of our journey. Yet we aim to be a fully distributed open source project that is built out by a community of believers.
So you can see the potential value we can bring to each other; The Sovryn community can be our guiding light in the development of Mintlayer, and we hope that Sovryns will take ownership of the project, make it truly theirs and turn Mintlayer into the best possible protocol by and for Sovryns.
That’s why we won’t take down the draft SIP completely, despite a sale not being imminent, it is eventually coming and we would like to involve the Sovryn community in the process of building Mintlayer up to the stage where we’re ready for this sale.
@Talyght I am very positive over your level of response and your dedication towards Sovryn. Much appreciation and respect your way
I am impressed by both the level of knowledge and the level-of-headedness the mintlayer team exhibits.
What i envision, is not that Mintlayer offers bounties, but that it competes for one or more of the appropriate categories, and then upon “winning” a category, that grants would also be available, for which mintlayer could write bounties for, and offer on, gitcoin.
Doing it this way keeps everything in the spirit of open-source, and transparency, and gives the Mintlayer project / team a trail of provable provenance, as well as a codebase to work from which then justifies / markets an Origins Token launch.
My goal here is not in any way to discourage, but to engage for success of the project / protocol, in such a way that it can stand on it’s own two feet (or fins, in the case of babelfish lol), and be an independent member of a growing, decentralised ecosystem with no single point of failure, and which can continue if any key members get hit by a bus.
Reach out to me for any assistance you need in submitting to the hackathon, Andreas!
First of all, we would like to express our utmost gratitude to all the members of the Sovryn community who in the past few days have interacted with our draft SIP. We at Mintlayer feel honored and amazed to have had this amount of interaction, support, and legitimate curiosity about Mintlayer, we really appreciate the thoughtfulness and deep “DYOR” done by the Sovryn community on this draft SIP.
After a long analysis of the current stage of Mintlayer, we have decided to postpone the Origins sale, we think that in order to have a more successful Origins launch we need better conditions, a fundamental one being the readiness of an MVP. We have come to the conclusion that it would be best to hold the origins sale at a time that is closer to the Mintlayer testnet launch.
We will coordinate closely with the Sovryn community in order to pick the best timing, and we will post a new SIP for the sale when the time comes. Until then, you can expect to hear a lot more about Mintlayer as we continue to collaborate closely with the Sovryn team on hackathons, bounties, and other ways to engage the Sovryn community in the development of Mintlayer.
To initiate this community collaboration, there’s a new Mintlayer Subcategory in the Adoption Hive, where everything mint can be discussed. In the about post are links to Mintlayer’s github repo, and their new Discord Server
Will close this topic now for comment, and switch the category of the post over to Mintlayer, and wish y’all good luck on this initiative!