The MimbleWimble model
Epic is a MimbleWimble chain. An Epic transaction contains no addresses, no scripts and no readable amounts. It is a set of blinded commitments plus a compact signature proving that inputs and outputs balance. Because each output commits to a blinding factor only its owner knows, the sender cannot build a complete transaction alone.
What the chain stores
A transparent chain records, for each payment, a sender, a recipient and an amount. Epic records none of those.
An output is a Pedersen commitment, a curve point of the form v·H + r·G where v is the value
and r is a blinding factor. Anyone can verify that a set of commitments balances without learning any
v. A range proof accompanies each output, proving the value is not negative, which is what
prevents inflation.
Commitment arithmetic. Step 1 of 6. Two sides that have to match
A kernel carries the excess signature and, depending on its feature variant, a fee and a lock
height. There are three variants. Plain carries a fee, HeightLocked carries a fee and a lock
height, and Coinbase carries neither
(core/src/core/transaction.rs:39). A Plain kernel serialises to
106 bytes, one feature byte plus an 8-byte fee, a 33-byte excess commitment and a 64-byte signature, and
HeightLocked adds 8 bytes for the lock height
(core/src/core/transaction.rs:113). Kernels are the permanent part of
the chain, so chain growth tracks the number of users rather than the number of transactions ever made.
Spent outputs are removed by cut-through. Once an output has been created and spent, the pair cancels and neither is needed to validate current state. The cut-through horizon is 10,080 blocks, one week at the 60-second target.
The practical consequence is that there is no transaction history to query. You cannot ask the chain what a given party received. Your own records are the only account of who paid you. Crediting deposits from this position is covered in exchange integration.
There are no addresses
Epic has identifiers that look like addresses. An epicbox address such as
esYQ…@epicbox.epiccash.com is real and usable. It is not an address in the sense used on other
chains.
They are routing identifiers for messages between wallets. They tell your wallet where to deliver a partially built transaction so the other party can complete their half. The chain has no knowledge of them. No output is ever "paid to" an epicbox address.
A balance is not a property of an address. No such query exists at any layer. A balance is a private computation your wallet performs by scanning the output set with your own keys.
A send is not unilateral. Delivering a message to a wallet that is not listening accomplishes nothing on its own.
A mistyped address cannot consume value, and it can still pay the wrong party. A corrupted epicbox address fails its base58 checksum and the wallet rejects it before anything is sent. A well-formed address that belongs to a different wallet behaves like any other recipient. If that wallet is listening, the transfer completes and the funds are theirs. If nothing is listening, the transfer never completes and your inputs stay reserved until you cancel it. See what releases them.
Units
One EPIC is 100,000,000 base units. The smallest unit is called a freeman. Every API accepts and
returns amounts as an integer number of freemen, so 0.1 EPIC is 10000000.
Relationship to Grin
Epic began as a Grin fork and shares the MimbleWimble fundamentals. It differs in several areas, so material written for Grin is a poor guide to these:
| Area | Epic |
|---|---|
| Proof of work | Three algorithms run concurrently in a ratio set per era by consensus. See proof of work |
| Emission | Stepped eras, and it terminates. See emission |
| Block reward | A declining foundation levy takes a share |
| Default transport | Epicbox, a store-and-forward relay. See the protocol |
| Tor | The wallet and the node can both bundle a Tor expert bundle at build time |