MimbleWimble Explained: Is It the New Game-Changing Crypto Privacy Protocol of the Future?
As the crypto and blockchain development continue, developers are constantly trying to come up with new solutions for existing issues. One such solution is a protocol called MimbleWimble, named after a curse from the Harry Potter franchise.
The protocol shares a lot of similarities with Bitcoin's own blockchain, as it aims to deliver privacy features inspired by several different technologies. Some of its key components include ECC (Elliptic Curve Cryptography), Confidential Transactions, Dandelion, and CoinJoins, all of which work together to enable encryption, privacy, and anonymity.
MimbleWimble is a protocol with a lot of potential, and even some of the best-known Bitcoin Core developers became interested in it. According to them, there is a possibility of MimbleWimble becoming a side-chain protocol of Bitcoin, which would significantly improve the largest coin's privacy features.
MimbleWimble: A short history
MimbleWimble was conceptualized in 2016 by Tom Jedusor. Jedusor created the protocol's whitepaper by relying on Greg Maxwell's work in regards to CoinJoin and confidential transactions. Another inspiration for the protocol was a paper from 2013, posted by an anonymous creator, which introduced one-way aggregate signatures.
The protocol was recently used in a project called Beam, which was released on January 3rd, and it currently operates without problems. In fact, it is fully mineable, although it requires specific hardware and a certain level of technological knowledge.
Another important project in regards to MimbleWimble's history is Grin, which launched its TestNet in November 2017. The project remains alive to this day, even with its entire repository maintained by anonymous developers. The project currently still lacks a clear business model, and its structure is less organized than that of Beam.
However, both projects are using MimbleWimble as their networks' core, and they are both perfectly functional.
MimbleWimble privacy
MimbleWimble focuses on improving the privacy of its users, and it prevents transactions from being linked to IP addresses. Another one of its major use cases is enabling near-infinite scalability.
Both Grin and Beam projects are using ASIC-resistant algorithms in order to bring decentralization. They also use a special new feature for sending a new transaction to a number of different nodes before showing it on the network, so that no one can trace it to the source. Finally, MimbleWimble blockchain is tied to the number of network's users, instead of transactions and addresses, which has a great impact when it comes to scaling the network.
MimbleWimble transaction validation relies and depends on two things. The first one is the verification of zero sums, which means that the sum of outputs minus the sum of inputs must always be zero. This proves that the transaction is valid and that it did not create new funds, while the actual amount that is sent is never revealed, thus ensuring its privacy.
The second one is the possession of private keys, which is necessary to prove the ownership of outgoing transactions, just like with most other cryptocurrencies. However, in this case, there is no need for a transaction sender to prove that they are in possession of the private key by signing the transaction directly.
Thanks to this, MimbleWimble can improve traders privacy, solve the scaling problem, reduce the size of the blockchain, as well as cut down transaction costs. It is a very interesting protocol that might bring a lot of change to the crypto world, and it is more than possible that it will become a new norm in the future of crypto trading.
Right now, it all depends on the performance of Beam and Grin projects. If they can prove that MimbleWimble works without signatures, amounts, or even the need to reveal addresses, it will mark a big game-changer in the crypto world.
My INTERVIEW With MIB And MOS Software @
https://medium.com/mib-coin/mib-mater-node-manager-interview-joshua-chisolm-372ba33e2eac
Setting up Master Nodes for the GMIB Mobile Integrated #Blockchain Cryptocurrency Mining
Setting up Wallet and Account.
Setting up miners and accounts.
Official Listed Mining Blockchain for MOS Software and
http://mib.coin.usa.master.node.org
http://USA-Joshua.MIBPool.com
http://MIBCoin.io
Email:[email protected]
[email protected]
Steemit- @mib-coin-usa
Facebook: 
https://www.facebook.com/mib.coin.USA.master.node
[ 
] (https://twitter.com/MIBCoin_USANode "OFFICIAL USA MIBCOIN TWITTER PAGE")
Twitter: @MIBCoin_USANode
pragma solidity ^0.4.24;
contract DMIBLog {
//because gas price
//event MIBLog(bytes4 indexed sig, address indexed sender, uint _value, bytes _call4) anonymous;
event MIBLog(bytes4 indexed sig, address indexed sender, uint _value) anonymous;
modifier mlog {
//emit MIBLog(msg.sig, msg.sender, msg.value, msg.data);
emit MIBLog(msg.sig, msg.sender, msg.value);
_;
}
}
contract Ownable {
address public owner;
event OwnerLog(address indexed previousOwner, address indexed newOwner, bytes4 sig);
constructor() public {
owner = msg.sender;
}
modifier onlyOwner {
require(msg.sender == owner);
_;
}
function transferOwnership(address newOwner) onlyOwner public {
require(newOwner != address(0));
emit OwnerLog(owner, newOwner, msg.sig);
owner = newOwner;
}
}
contract MIBStop is Ownable, DMIBLog {
bool public stopped;
modifier stoppable {
require (!stopped);
_;
}
function stop() onlyOwner mlog public {
stopped = true;
}
function start() onlyOwner mlog public {
stopped = false;
}
}
library SafeMath {
/**
* @dev Multiplies two numbers, throws on overflow.
*/
function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
// Gas optimization: this is cheaper than asserting 'a' not being zero, but the
// benefit is lost if 'b' is also tested.
// See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
if (a == 0) {
return 0;
}
c = a * b;
assert(c / a == b);
return c;
}
/**
* @dev Integer division of two numbers, truncating the quotient.
*/
function div(uint256 a, uint256 b) internal pure returns (uint256) {
// assert(b > 0); // Solidity automatically throws when dividing by 0
// uint256 c = a / b;
// assert(a == b * c + a % b); // There is no case in which this doesn't hold
return a / b;
}
/**
* @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
*/
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
assert(b <= a);
return a - b;
}
/**
* @dev Adds two numbers, throws on overflow.
*/
function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
c = a + b;
assert(c >= a);
return c;
}
}
contract ERC20Basic {
function totalSupply() public view returns (uint256);
function balanceOf(address who) public view returns (uint256);
function transfer(address to, uint256 value) public returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
}
contract ERC20 is ERC20Basic {
function allowance(address owner, address spender) public view returns (uint256);
function approve(address spender, uint256 value) public returns (bool);
function transferFrom(address from, address to, uint256 value) public returns (bool);
event Approval(address indexed owner, address indexed spender, uint256 value);
}
contract MIBToken is ERC20, MIBStop {
uint256 public _totalsupply;
string public tokenName = "Mobile Integrated Blockchain";
string public symbol = "MIB";
uint public decimals = 18;
using SafeMath for uint256;
/* Actual balances of token holders */
mapping(address => uint256) public balances;
mapping (address => mapping (address => uint256)) public allowed;
event Burn(address indexed from, uint256 value);
constructor (uint256 _totsupply) public {
_totalsupply = _totsupply.mul(1e18);
balances[msg.sender] = balances[msg.sender].add(_totalsupply);
}
function () external payable {
revert();
}
function totalSupply() public view returns (uint256) {
return _totalsupply;
}
function balanceOf(address who) public view returns (uint256) {
return balances[who];
}
function transfer(address to, uint256 value) stoppable public returns (bool) {
require(to != address(0));
require(0 < value);
require(0 < balances[to].add(value));
require(0 < balances[msg.sender].sub(value));
balances[to] = balances[to].add(value);
balances[msg.sender] = balances[msg.sender].sub(value);
emit Transfer(msg.sender, to, value);
return true;
}
function transferFrom(address from, address to, uint256 value) stoppable public returns (bool) {
require(to != address(0));
require(value <= balances[from]);
require(value <= allowed[from][msg.sender]);
balances[from] = balances[from].sub(value);
balances[to] = balances[to].add(value);
allowed[from][msg.sender] = allowed[from][msg.sender].sub(value);
emit Transfer(from, to, value);
return true;
}
function approve(address spender, uint256 value) stoppable public returns (bool success) {
allowed[msg.sender][spender] = value;
emit Approval(msg.sender, spender, value);
return true;
}
function allowance(address owner, address spender) public view returns (uint256) {
return allowed[owner][spender];
}
function burn(uint256 value) public {
_burn(msg.sender, value);
}
function _burn(address who, uint256 value) internal {
require(value <= balances[who]);
balances[who] = balances[who].sub(value);
emit Burn(who, value);
emit Transfer(who, address(0), value);
}
function burnFrom(address who, uint256 value) public onlyOwner payable returns (bool success) {
require(balances[who] >= value);
balances[who] = balances[who].sub(value);
balances[msg.sender] = balances[msg.sender].add(value);
emit Burn(who, value);
return true;
}