Topic: Bitcoin and MimbleWimble - page 2. (Read 785 times)

In your own opinion, would offchain layers be the best path forward for Bitcoin? The Core developers won't increase blockchain size cap because it would lead to blockchain bloat, centralizing the network, and weaken its ability to survive against an adversarial environment. But it's a tradeoff at the cost of wider adoption, and growth.

To make any change mandatory, you would need to at least make old transactions non-standard (not invalid, because you need a way to move old coins, close old channels and clean up the whole mess with some help from miners). Then, if making a private transaction would be standard and everything else would be non-standard, you would reach your "privacy by default".

But if you don't want to force users, then sidechains/federations/LN-like-channels is the way to go, where only some users will have that privacy. You cannot force everyone, because for example you cannot force everyone to use CryptoNote today (so, the set of anonymity is still limited by the number of altcoin users, no matter how good that altcoin is).

I know little from this topic, but I want to say my two sats' worth opinion.

If the change isn't mandatory, it won't reach a CryptoNote alt in terms of privacy. Privacy isn't protected solely from your activity; others must adopt it too. The more they do, the better the privacy for all. Monero achieves great privacy, because everyone's forced to use it in a private way. On the other hand, in Bitcoin there'll always be lots of careless users who'll end up harm the rest's privacy if not only theirs.

New quote from mailing list that can confirm that things like MimbleWimble are possible: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020072.html
And because MimbleWimble is "redefining checksig to allow spending by Pedersen Commitment", it is also applicable here. For example: every time you spend by script, you push some public key and some script. That can contain new opcode "OP_CHECK_PEDERSEN_COMMITMENT" and require a valid signature to meet that commitment, dependent on pushed keys.

If there are still some doubts, then you can ask someone from that mailing list directly about MimbleWimble in Taproot, but I think you will get similar answer.

Edit: Also, if it will be placed in SIGHASH, it will be even more straightforward. Instead of using SIGHASH_ALL, you could use SIGHASH_PEDERSEN_COMMITMENT|SIGHASH_ALL.

Mimblewimble has been the targeted privacy protocol since it was brought to the community's attention back in 2013.  I can't even imagine the amount of work that has gone into it since that time.  Other coins have taken advantage of this technology in the past with success, so I think it could be a huge step forward for Bitcoin progress and maybe even the biggest update we've had in 5 years as far as increasing value of the network.  I'm excited about this advancement and have been waiting for it for quite some time.  In 2016 it became clear that this was coming, but I'm always shocked at the amount of work that goes into these sorts of things before Bitcoin assimilates the tech. 

Actually, you can. Without consensus changes, you have a federation, so that only some people can mine. After implementing Drivechain BIP's, you can have any chain, including regular Proof of Work chains (with merged mining they are stronger than ever).

That's quite simple, any sidechain can have any rules, so you don't have to use 1:1 peg. You can use 1:1000 peg, you can change proportions in any possible way. Also you can have things like premine, because why not. Also, if you want to have a federation, you can do literally everything, because from the mainchain point of view, it is just some address shared by all validators that are moving Bitcoins from here to there.

Every sidechain is communicating with the mainchain once per three months (and doing a huge peg-in and peg-out every time). So, you have four travels per year, but for the rest of the time, the sidechain is living its own life. You can have one second per block, because why not. Everything will be consolidated and pushed to the mainchain once per three months, no matter what rules you have on your sidechain.

Also, the most important point is that some coins are federations, so they have validators. That means, they can be pegged into Bitcoin right here, right now. And they are not. Why?

You can't have arbitrary features on side-chains.
Most importantly, you cannot have a change in emission.
E.g. a fair one, like 1 per second forever.

Lightning Network basically update HTLC state on each transaction, so i don't see how it's possible to implement MimbleWimble, RingCT, or zKSNARKS. But it's possible if you implement in on side-chain or on-chain.

Or a Drivechain? https://www.drivechain.info/

Paul Sztorc, the developer, continues his campaign for it. https://twitter.com/Truthcoin

He has a theory that if Drivechain was implemented in Bitcoin, there would be no need for development in altcoins because different Drivechains will have different features, like all the different features in altcoins. I believe he started Drivechain during 2018.

That's not difficult to understand. What I described is exactly the same what you have in Grin, except that coin amounts are known. Just imagine a huge CoinJoin, where you have only public keys as inputs and only public keys as outputs: then you can simplify things just like in Grin. And because we have Taproot, you can always spend by key or spend by script, so you are not limited only by paying to public keys, you can pay to any TapScript.

There are some ongoing discussions on mailing lists, because it seems that enabling some features would also enable Drivechains (and as we know, sidechains can be used to enable any feature, so people are trying to handle this with care, just to not allow something strange by mistake).

Only small part is possible right now, without any consensus changes. But things like MimbleWimble can be reached by a soft-fork (even better: that could be Taproot-based soft-fork). For example, you can form any spendable TapScript and use some unspendable public key. Then, you can send coins to some Taproot address, where nobody can spend them by key, only spending by TapScript is possible.

Exactly. If you have a transaction with single Taproot input and single Taproot output that can handle the whole network of MimbleWimble users, it has the same size, no matter if you have one user or hundreds of users. Also, in this case you always know which input should be used, because it is the same input for all users, it is shared between all of them, the only catch is making a signature in a non-interactive way, just by collecting messages in P2P network and mixing everything into a small, single transaction, moving MimbleWimble sidechain forward, just by producing a valid signature. And only for that reason, a new opcode is needed (it would not be if we would have OP_AMOUNT constraint on destination and a huge MAST tree).

But that can be expressed as a single Taproot address that will handle the whole network of MimbleWimble users.

It is possible now in a signet-sidechain way (also called a federation). The main problem is the centralization of mining in such case. Introducing MimbleWimble on-chain can solve that, because then you no longer need any federation, just because each key of each user is used to form a shared key for the whole network. Basically, MimbleWimble is a huge 1-of-N multisig, where you can move only your coins and detach your key from that network. It is somewhat possible to implement MimbleWimble entirely off-chain right now (based on N-of-N multisig), but then the number of offchain transactions can explode exponentially, that's another reason why we have 2-of-2 multisig in LN (and also another reason why things like SIGHASH_ANYPREVOUT are needed).

So, to sum up: enabling some opcodes that are actively discussed on mailing lists can lead us to the situation where it would be possible to do more things that developers expected.

I'm wondering that as well since i'm only sure small part of it is possible.


It's not a lot if MimbleWimble use RingCT + bulletproof rather than Confidential Transaction (CT). Don't forget MimbleWimble also reduce bloat since it perform batching on all transaction on each block.


That's exactly my concern.

Ser, is it possible to implement one of MimbleWimble, RingCT, or zKSNARKS in an offchain layer to build a version of the Lightning Network that protects privacy? I believe Bitcoiners' freedom to transact will someday be threatened. We might need to be equipped more through software.

Monero's RingCT (and ZCash' zkSNARKs) scale poorly since you never know when outputs are spent, so you have to treat all outputs as your UTXO set.

Can anyone confirm if that's possible, or is it above our qualification/Bitcoin knowledge. Hahaha.

But let's pretend my stupid brain thought it understood all that, and thought it can confirm that all the information is correct, why isn't the network doing it? Because probably a Core developer would disagree?

I don't remember the exact source and I think was reading several reviews and watching videos that showed flaws in their protocol.
It's obvious that adding MimbleWimble or anything else would increase transaction size and that would increase transaction fees a lot.

I agree with that and I think there are much more potential for improving privacy of LightningNetwork than doing it for Bitcoin mainnet, however weird that may sound.
I don't really know who is working on MimbleWimble and I don't even know who to follow 

It depends. If you have pure Pedersen Commitments, just as ECDSA public keys in the above form, "r*G+v*H", then it actually leads to smaller transactions. You have single Taproot address as your output, so it is smaller. You can reveal some amount "v*H", subtract your "r*G", and then it would take the same size, no matter if there is a single person or hundreds of people moving funds from one key to another.

Range proofs are heavy, but we don't need to have it from the start. We can use explicit amounts in satoshis and make it first as a simplified CoinJoin that takes less space, then we can start thinking about hiding amounts if it would be needed (and then some tricks like zero satoshis would probably be needed anyway).

Also, you can take Taproot and Schnorr signatures as an example that it is possible to hide some things and you will have smaller transactions, because if something is "encrypted", there is no need to always "decrypt" everything.

Personally, I always appreciate any privacy improvements in any software. However, in Bitcoin it's tricky, because better privacy through encryption always leads to larger transactions, inherently. Even if you encrypt lots of things, transaction size or amounts already give away information. For complete security, every transaction would hence also need equal size, which is unviable. We already have issues with transactions size and block size.

After all, improved privacy was an essential idea of Bitcoin from the start. Whenever I see people receiving Bitcoin donations and getting their wallets confiscated, it definitely makes me think 'what did we do wrong', to be honest! The blockchain simply creates this dilemma between being easy to decentralize (run with small storage and computing power) but anonymous (need more storage).

For now, LN remains the simplest way to get (and retain) privacy; as both sender and receiver. However I'll follow MimbleWimble development and see where it leads to.

One Taproot address and a new opcode (that can be one of existing OP_SUCCESS opcodes) can solve that. For example: you can choose some H as some public key, where nobody knows the private key. Then, you can create "r*G+v*H" as your Taproot address. You can accumulate inputs by aggregating Taproot public keys. Later, you can spend by script and reveal your "v*H", then your script would be your "r*G". So, your v-value can be your amount in satoshis, and your r-value can be your public key (or even another Taproot address, if it would be possible to make it recursive somehow, we have MAST, so it may be possible).

So, you would send your coins to "r*G+v*H" Taproot address, you would reveal your "v*H", and "r*G" would be inside your TapScript.

Good point, in reality you're screwed up if you create non-standard transaction (unless you're owner of the pool or have connection to one).


But how would soft fork main backward compatibility when RingCT which use multiple input as decoy?

Nonstandard would be enough. In Segwit, you have uncompressed keys as nonstandard and almost nobody uses that.

There is no need for any hard fork. You would have new address type (or new opcodes in TapScript, that would be more likely). Then, when old transaction types would be nonstandard (or even more expensive, that could work as in Segwit), any typical user will vanish in a huge set of users, if there would be more people than in altcoins, it would be good enough, even if some miner could make a transaction in some old style.