All posts tagged "Monero"

This is Part 2 of this series. For Part 1, click here. New Coins on the Block Grin and Beam are two of the newest privacy coins to come to market. They are both implementations of a proposed design for a new blockchain called MimbleWimble, which has generated significant buzz in the blockchain community due to a) its elegant proposal for a privacy blockchain and b) its bitcoin-esque origin. UTXOs and Transaction Kernels MimbleWimble’s integration of privacy into the core code makes its implementation of Confidential Transactions and Coinjoining different from that of Monero’s. One of the unique characteristics of MimbleWimble’s core protocol is that it does not use public addresses or keys. It is a scriptless blockchain. Instead, the identifiers in MimbleWimble are based on the tokens themselves, technically known as Unspent Transaction Outputs (UTXOs). Unlike Bitcoin, Monero and even ZCash, the scriptless nature of MimbleWimble allows for transactions to remain visually untraceable. The data posted to blocks in the MimbleWimble blockchain doesn’t reveal any information on both the sender and receiver’s identification and transaction amounts. In fact, for an observer the information contained within a block looks like randomized data. You may ask — if there are no addresses for senders and receivers, how can we track the flow of these tokens and be sure the sender is the owner of / has the right to send the tokens they are sending? An appropriate answer, for now, is that the tokens essentially have special trackers on them, called a transaction kernel, that allow us to verify ownership (more on this in later paragraphs). Let’s dive into an example of a transaction between a sender and receiver to more concretely understand how a MimbleWimble transaction works, the way in which the transaction posts to a block, and how observing nodes verify the transaction. Since they are quite similar mechanically, please review RingCT in Monero as a refresher. Let’s say a sender holds 3 tokens or Unspent Transaction Outputs (UTXOs) in his or her wallet. The sender wants to send 2 tokens to a receiver, leaving 1 (change) in his wallet. As a part of Confidential Transactions, when the sender sends 2 tokens to the receiver, he or she has to choose a blinding factor in order to produce a Pedersen Commitment. Without this, and a response Pedersen Commitment from the receiver, the involved parties could not produce a rangeproof for their posted transaction and observing nodes would be unable to validate the transaction in a block. Therefore, like in Monero these UTXO values are multiplied by the blinding factors of the sender and receiver, obfuscating the values. Unlike in the current version of Monero, the difference in the sender’s blinding factor and receiver’s blinding factor means something — it produces the transaction kernel we introduced above. The transaction kernel is included in every transaction published to the MimbleWimble blockchain and essentially represents a digital signature (multi-sig) signed by the parties confirming the transaction. The sender and receiver both know their side of the signature, aka the blinding factor they chose, but do not know the other. Hence, the kernel is proof the exchange happened between both parties, represented on the blockchain in the form of a public key. It’s important that the sender and receiver can not figure out the other’s blinding factor, because if a party knows the blinding factor for a given UTXO, he or she can spend it. So if the sender knew the blinding factor of the receiver, they could steal back the value after the transfer is completed. (Remember, these tokens don’t physically reside anywhere — ownership is determined by having access to certain digits that prove authority). Thankfully, because cryptographic hashing is essentially a random yet deterministic process, by knowing the outputted blinding factor and only 1 input, the sender and receiver cannot figure out the other input as one may think. This isn’t like boxing and solving for the missing variable in high school algebra! For each transaction what’s included in that block on the blockchain, similar to Monero, is the following: The UTXOs, which are represented by: a pedersen commitment from the receiver (33 bytes) and a range proof (over 5KB) Transaction inputs, which is the pedersen commitment of the sender (32 bytes) Transaction fees, in clear text The excess kernels (33 bytes) A signature generated with all the excess kernels (71 bytes average) A block header (about 250 bytes) A side point but a very important concept to address — when parties interact on the MimbleWimble blockchain, because the protocol is a scriptless language all communication between transaction participants is conducted off-chain between those two parties directly, like via a chat session. Therefore, the transfer of control process involves active participation from both parties, unlike in scripted blockchains like Bitcoin where you can send tokens to a recipient without them being online. On one hand, members of the community have claimed that this point of friction negatively impacts the user experience. On the other hand, members appreciate this active process, because active participation from both parties prevents spamming from unknown participants.

Blockchain Beach

All posts tagged "Monero"

Research

Going Deep on Privacy: MimbleWimble (Part 2)

Research

Going Deep on Privacy: MimbleWimble (Part 1)

Crypto

Going Deep on Blockchain Scalability & Privacy: Zcash

Crypto

Going Deep on Blockchain Scalability & Privacy: Monero

Crypto

What the Crypto? A Visual Guide to Top Digital Currencies

Financial Regulation

What to Know from Latest CFTC Blockchain Technology Committee Meetings