Comments on MimbleWimble Extension Blocks proposals #10
Comments
|
How does this affect Script mining. Also, what type of increase if any could we see with transaction fees? |
|
Litecoin miners will keep mining Scrypt. As for transaction fees, it will depend on the fee market in the canonical chain and the EB. |
|
What's the reason why peg-out outputs require locking? My understanding is that since both chains are tightly coupled 1:1 with each other, when one reorgs, the other reorgs as well. There is no possibility for them to be out of sync. So I don't understand why would they require preventing measures like typical federation-based side-chains etc. |
|
Referring to the Rationale Section of Proposal. Was Elliptic-Curve Diffie–Hellman or the Signal Protocol considered? Does something like ENIGMA off-chain mixing to allow fully private and untraceable monetary transactions make sense for Litecoin? Why can't Lightning Network encrypt sender-receiver data? BOLT #8: Encrypted and Authenticated Transport All communications between Lightning nodes is encrypted in order to provide confidentiality for all transcripts between nodes and is authenticated in order to avoid malicious interference. Each node has a known long-term identifier that is a public key on Bitcoin's secp256k1 curve. This long-term public key is used within the protocol to establish an encrypted and authenticated connection with peers, and also to authenticate any information advertised on behalf of a node. |
The reason why is that with a reorg, the hash of the peg out transaction (on the canonical side) will be changed. So any transaction chains (i.e. transactions spending those outputs) will be invalid. Those transactions cannot be replayed like they would be with normal transactions in a reorg. So for example, if you pegged-out 10 LTC and use that to pay a merchant and they gave you your purchases after 6 confirmation, and there's a 7-block reorg after that. You have effectively double spent that transaction. You would have to resend another 10 LTC to the merchant. With normal transactions, after reorgs, your transaction will just be replayed and everything is good assuming no malicious intent. With peg-outs, you will double spend those transactions if you didn't know about the reorg even without malicious intent. So this is similar to coinbase block reward transactions, which is locked for 100 blocks. Coinbase transactions are worse w.r.t. this because the new coinbase transaction is likely mined by a different miner. At least with EB peg-outs, the same owner controls the new peg-out coins. So we need to lock it enough such that a reorg of that length practically never happens, but don't necessarily need a lock up of 100 blocks. |
|
The only thing this comes down to is Economic Viability! If exchanges & on/off ramps de-list Litecoin because of its new privacy features, then MimbleWimble should NOT be implemented. The effect of this goes against "litecoin is money", and mass user adoption (you can't get mass adoption, if you can't easily buy it). LTC will become illiquid, and we all know what happens to chains that become illiquid. I'm all for privacy features, but not if it jeopardizes economic viability. There needs to be absolute clarification from the large exchanges on what they'll do. The other concern is, exchanges may receive guidance from .Gov to de-list all privacy coins in the future. |
|
The LIPs state:
Does this mean even if signalling after 1yr since commencing only reaches, say, 60% over any of the epochs, that the activation will still occur, rather than timing out and being abandoned? |
|
Although a soft fork this is kind if a big risk since it will rely on large mining pools and exchanges going along. |
|
I do not agree with this proposal. All evidence and reasoning suggests to me that this will not help to provide fungibility in a meaningful way, so it would not be not worth all the drawbacks. Up to 98-99% of Zcash transactions are not shielded because it is opt-in, and there are only reasons to think that this metric would be worse for LTC. LTC’s userbase is more mainstream and less interested in privacy than Zcash’s userbase. Users will have less incentive to use it because it is weaker in terms of privacy guarantees. Services will have less incentive to make the effort to implement it because it is interactive, risks regulatory issues and there will be little user demand. This massive majority of transparent transactions will undermine the effectiveness of the rare opt-in MW transactions. To compare to Beam, all Beam transactions occur with MW and can have forms of decoys to help deal with linkability, which goes beyond this LIP. With these improvements their project still notes that "Linkability is the Achilles' heel of MW" and that they see the need to research further significant cutting-edge changes like Lelantus. Conversely, this LIP ignores the “Achilles’ heel”, proposes nothing to mitigate it, and does not begin to discuss the consequences when interlinked with a massive majority of transparent transactions. There is not even any mention of Dandelion but I have to assume that would be used at the least. Therefore it is not apparent that this would be worth years of development, increased technical complexity, risks of bugs, risks of delistings and the risks of diverging from Bitcoin. Many people see LTC’s value as coming from it having a low risk by sticking to BTC’s code instead of making experimental changes with less experienced developers. People will always worry about problems like inflation bugs that could kill LTC. It may be even worse from a regulatory perspective than Monero due to the possibility of deleted history. This plan could even make fungibility worse since there will be a small percentage of transactions that have an obviously suspicious history. Exchanges and merchants will 100% certainly treat history of opting into MW as a red flag. Anyone can unintentionally end up with those coins. LTC desperately needs fungibility to begin becoming usable as money, but this plan does not take a coherent step toward that. |
|
I agree with @nulldog22, there are too many potential issues. |
|
Hey @nulldog22. Thanks for your feedback.
I'd like to push back on this. One big reason why shielded transactions haven't been widely adopted is because creating them are intensive and take a long time. This is a poor UX and people don't want to wait. If it was easier, it most certainly would be higher. And it's always a possibility that Litecoin users end up using MW a lot, especially if there's a platform of some sort for them to spend it on.
There was discussion internally about using dandelion. Since this LIP is a draft, we could definitely incorporate that into the finalized proposal. I admit there is room to better improve privacy in this LIP. If you have any suggestions and can help us write the code, that would be greatly appreciated.
The canonical chain can still remain close to Bitcoin's codebase. The only difference is the extra work to maintain the extension block.
Supply inflation bugs are a concern for any privacy coin. But one of the benefits of being opt-in (which fully private coins don't have) is that the canonical chain will never exceed 84 million. This helps mitigate this risk. We could even organize an "audit" day where everyone pegs out of the EB (unlikely I know but still theoretically possible).
Would it be fair to ask that we don't make jump to conclusions and engage exchanges and regulators first? The only prominent exchanges I know of that have delisted privacy focused/marketed coins are Coinbase Europe and OKEX. Others haven't made the same move.
Same could be said about coinjoins. Are you opposed to that as well? It's a bit extreme to claim that this will make Litecoin's fungibility worse. And FWIW, we aren't saying that opt-in privacy is better than full privacy. Grin and Beam have us beat on that hands down. But it is a step in the right direction. |
This LIP doesn't discuss the P2P layer at all. It's all about consensus, not implementation. |
Nothing beats mandatory privacy, but as a Grin dev, I can say that LTC has one big privacy advantage over Grin and Beam: a much larger userbase. Right now, LTC has about 5-15x as many daily transactions as Grin. If only 10% of LTC's transactions are moved to the EB, it will have an equivalent anonymity set. |
That has no effect on preventing an inflation bug. Unless you disagree that as soon as the MW chain exists you will forever have to accept people pegging out. In that case you are truly damaging fungibility: MW LTC coins will not have the same value as coins on the transparent chain since there is reason to think MW coins could cease to be accepted if there were an inflation bug.
Regardless of what they say now, the risk is always there.
Yes coinjoins have the same problem and are not a solution. I do not think it is extreme at all, rather it is undeniable that red-flagging MW coins will occur with automated chain analysis risk systems. Fungibility is not the same thing as privacy. Perhaps sometimes it will not be known where some coins came from, but those coins may be seen as different and less valuable because of that.
This is not true, although more transactions is of course a benefit. You seem to be imagining two separate chains that do not interact. Every time someone pegs in with KYC'd coins or pegs out to spend coins at a merchant/exchange that gets the user's identity etc, or just reveal the value of their coins, they will bring in dirty data to the MW chain. If the number of transactions were huge you would still be left with the issue that a large fraction of coins are bringing in data that assists with analysis. From the spend-time distributions of privacy coins and how people naively try to 'clean' their coins it is likely that people will quickly peg-in and peg-out, despite how this easily leads to deanonymisation through timing analysis. I wouldn't want to stay on the MW chain for long-term holding either because of the earlier statement about inflation bugs. |
I never said it prevents it. I said it mitigates it. I suppose you are opposed to all private coins then?
If that were true, all CJ's would be tagged as highly suspicious by chain analysis companies by now. They're not. That is why I believe it is rather an extreme point of view. But we can agree to disagree here.
You're making an assumption here. We know nothing about how people will peg in and out of the EB. Lots can be done about educating people, which we can do since it will take a while for this to roll out. |
It does not mitigate it, I mean. Rather your suggestion to cease accepting MW coins in case of a bug is absurd - LTC would have to be completely centralised to be able to make a decision like that and burn all the users whom would lose their funds. Risks are necessary but you should get something in return. I consider it a non-issue for Monero since it gains reasonable fungibility in return, has a dramatically stronger developer community, still has transparent coinbase transactions for a sense of auditability, does not delete history, uses well-proven primitives, etc.
Source? My understanding is that they are, after anecdotes from several people who say they have had their funds frozen pending KYC on exchanges including Bitfinex and Binance. Additionally, CoinJoins can be difficult to distinguish from normal transactions in some cases unlike pegging in/out of MW.
Considering how users tend to transact is crucial for privacy coins. You have to try, and there is valuable data out there. It is too complicated for everyone to be educated so it needs to be considered in the design. It seems very intuitive to me that people will e.g. do a "private" MW transaction by pegging in with 2.34567 LTC and peg out with 2.3456 LTC after a few minutes, achieving nothing but believing they are safe. You can't quantify exactly how often it will happen but you have to think about how to deal with it and what consequences it will have. |
It does mitigate the risk. The canonical chain will never exceed the set supply of its inflation schedule. People will always be able to peg out. Yes that means some people will be stuck in the EB if there is a supply bug. But at least you have the certainty that the total supply can be audited in the canonical chain, something full privacy coins can not do. And I'm not sure where you got the impression of the need for a centralized entity to peg out, but I recommend you re-read the LIP for a more thorough understanding of our proposal.
But according to your previous logic, you still have the risk of supply inflation so what's the point of even using Monero? I realize now that you're just trolling and have no genuine interest in helping to improve the proposal. Thanks for your feedback but I will no longer engage in further discussion with you. |
Use of the MW sidechain can be further incentivized by lowering minimum MW transaction fees and raising mainchain ones. |
|
Extension blocks are effectively a block size increase. Right now the LIPS stands:
It is very important what is the block size on extension blocks in relationship to main chain. This will determine the fees on both chains, and their popularity etc. If you can pay 10 times less for txes on MW side, then it will naturally be more appealing, than if the fee is roughly the same as on the normal chain. |
Until the blocks are full, the fees are determined by developers. And currently, they are pretty low, so they aren't really going to affect usage much at all. That said, what do people think the blocksize of the EB should be? |
Charlie, wouldn't the extension blocks technically double Litecoin's throughput if the MC and EB were the same block size? (as long as the transactions are split 50/50) Being as the current MC blocks are nowhere near capacity, I'd think keeping the same block size, or slightly larger would be adequate. Unless you think gigameg blocks would be best. |
Perhaps it might be helpful to clearly lay out for a moment how this blocksize increase can affect Litecoin. MW doesn't greatly increase the size of IBD, but it does increase transaction throughput. It also can potentially slow down block propagation depending on the size of both the canonical block and the extension block. This isn't ideal because longer block propagation leads to higher chances of orphaned blocks.
There are several factors that determine fees: blocksize, users, and volume of transactions. Therefore it's difficult to predict how implementing diff. feerates would pan out. For example even if there was a lower feerate for MW txn's in the code, it would be meaningless if the demand for MW txn's were greater than public LTC txns.
@coblee My initial thought is to match LTC's current blockweight on the EB side as long as it doesn't significantly hinder LTC's block propagation. |
It's not easy to keep the same blocksize. If miners had to make sure that the canonical block size plus the extension block size is the same as the current size, it would have to do a lot of complicated calculations to figure out which transactions to include. It's probably best to keep the block weight/size separate for them. But it is possible to maybe cut the blockweight in half in the canonical blocks and add do something equivalent for the extensions blocks so effective total size is not changed. |
|
I’m just wondering as I’m not very knowledgable of Extension blocks... if
they have the same drawbacks as a block size increase, then why was it ever
considered as an alternative to a block size increase?
…On Fri, 1 Nov 2019 at 18:04, Charlie Lee ***@***.***> wrote:
Being as the current MC blocks are nowhere near capacity, I'd think
keeping the same block size, or slightly larger would be adequate. Unless
you think gigameg blocks would be best.
It's not easy to keep the same blocksize. If miners had to make sure that
the canonical block size plus the extension block size is the same as the
current size, it would have to do a lot of complicated calculations to
figure out which transactions to include. It's probably best to keep the
block weight/size separate for them.
But it is possible to maybe cut the blockweight in half in the canonical
blocks and add do something equivalent for the extensions blocks so
effective total size is not changed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10?email_source=notifications&email_token=AAT43OUILGQUIAHOJPXBFS3QRTGYBA5CNFSM4JDJRMJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4QB3I#issuecomment-548995309>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAT43OS3L5BAVA5BKYNWD53QRTGYBANCNFSM4JDJRMJA>
.
|
It was considered because it allowed doing a block size increase with a soft fork. But the solution is so hacky to do just a blocksize increase, as you have same kind of transactions on both EB and main chain. And you have to move coins between the 2 chains. The proposal to do this was pretty quickly shot down by the bitcoin developers. |
|
In light of the recent culmination of 18 months of research around MW with examples showing the protections aren't all they are cracked up to be, are EBs / MW still planned? Or will LTC simply implement a Coinjoin protocol to save most of the hassle / development time (and skip MW / EB)? https://github.com/bogatyy/grin-linkability Other options I suppose would include proceeding as planned regardless, or, looking in to alternative privacy improving methods. |
Great questions. Mimblewimble is exactly as it has always been "cracked up to be" by those of us who work with mw daily. Mimblewimble alone does not provide much unlinkability, and that has been documented in numerous places. However, with just small tweaks to how transactions are propagated, we can really improve the situation. And if we find that it's still not enough, we can at any time go with the "nuclear option" of adding decoys or using coinjoin servers. I will personally volunteer to run a CJ server if necessary. 🙂 |
|
@ChillingSilence as David mentioned, this issue has been known for a while now. But I appreciate this person's research and work because he took the time to execute it while bringing more awareness to MW. There are ways to beat it that we've been discussing such as doing a CJ of txns prior to broadcasting, but of course more research would be great on how to break linkability. As a side note, MW already has CJ and is a lot easier to implement because of hidden amounts. I recommend you read up on Grin for a deeper understanding of how it works here: |
|
Thanks David, appreciate you taking the time to respond. Just to clarify further:
Am I understanding that correctly? If that's the case it seems to still achieve those goals then, correct? :) |
|
Yes, and ideally we would also make the tweaks necessary to help obfuscate sender-receiver link as best we can under the limitations of mimblewimble. |
Please comment here on the MW/EB proposals
The text was updated successfully, but these errors were encountered: