## Introduction to flowcoin

Flowcoin (abbreviated as: FLW) is a fully open-source and fully open distributed main network developed on the basis of IPFS. Everyone can develop related plug-ins to achieve more applications, and have a decentralized, deduplicated, fragmented, faster transmission speed and more secure blockchain public chain, which is used as an incentive layer to reward the contribution traffic. digital wave.

## Flowcoin algorithm

Proof of reproduction" (PoRep) is a new type of storage certificate. It allows the server (certifier P) to convince the user
(verifier V) that some data D has been copied to its only dedicated physical storage. Our solution is an interactive
protocol. Proofer P: (a) promise to store n different copies of data D (independent physical copies), and then (b) convince
the verifier V through a challenge / response protocol that P has indeed stored each copy. As far as we know, PoRep improves
the PDP and PoR schemes, preventing witch attacks, outsourcing attacks, and generation attacks.

Please note that for the formal definition of the proof of copy and the description of its attributes and its in-depth
research, we recommend readers to read another academic report of the protocol laboratory.

The spatio- temporal certificateThe PoRep scheme enables an effective prover P to convince the verifier
V that an independent physical copy R of the data D that is exclusive to P has been stored on P. PoRep protocol is characterized
by a tuple of polynomial time algorithms: (Setup, Prove, Verify).

PoRep.Setup (1λ, D)→R, Sp, Sv, where Sp and Sv are the setting variables of the characteristic schemes of P and
V, and λ is a safety parameter. PoRep.Setup is used to generate replica R, and give P and V the necessary information
to run PoRep.Prove and PoRep.Verify. Some solutions may require a prover or an interactive third party to calculate PoRep.Setup.

PoRep.Verify (Sp,R, C)→πc, where C is the verification issued certifier V, πc prove access to a copy of the particular
prover generated for the data D R. PoRep.Prove by the P (prover) to V (verifier) run generated πc.

PoRep.Verify (Sv,c, πc) →{0,1}, used to check whether the proof is correct. PoRep.Verify run B by the V and to
convince V: P has stored R.

The spatio-temporal certificate scheme allows users to detect
whether the storage vendor has stored outsourced data
during the challenge. How can we use the PoS scheme to
prove that the data is stored in a short time? A natural answer
to this question is to ask the user to repeatedly (as per minute)
issued a challenge to the storage vendor. However, the communication complexity required for each interaction will
become a bottleneck for systems like Flowcoin, because
storage providers will also be required to submit their proof to
the blockchain network.

To answer this question, we introduce a new proof, the
spatio-temporal cetificate, in which the verifier can check
whe ther the prover has stored his / her outsourced data over a
period of time. Thus the requirements for the prover is (1)
generating a proof storage order (here copy proof) to as (2)
performs a recursive method to detemine the time to
generate short demonstrable.

Definition 3.2 (proof of spatio-temporal) PoSt scheme enables
the effective prover P to convince the verifier V: within a
period of time t P has stored some data D. PoSt protocol is
characterized by a tuple of polynomial time algorithms (Setup,
Prove, Verify)

PoSt.Setup (1λ, D)→Sp, Sv, where Sp and Sv are the setting
variables of the characteristic schemes ofP and V, and λ is a
safety parameter. PoSt.Setup is used to give P and V the
necessary information to run PoStProve. Some solutions mayrequire a prover or an interactive third party to calculate
PoSt.Setup.

PoStProve (Sp, D, c, t)→πc, where C is the random
verification issued by the verifier V, and πc is the proof that the
prover has access to the data D for a period of time.
PoStProve is run by P (certifier) for V (verifier) to generate πc.

PoStVenify (Sv, c,t, πc) →{0,1}, used to check whether the
proof is correct. PoSt.Verify is run by V and convinces V that P
has stored t for a period of time.

We are interested in the application construction of PoRep and PoSt online systems, rather than relying on hardware or parties.
We give a PoRep system architecture (see "Seal-based replication proof" in the copy proof academic report for details),
which requires a very slow sequential calculation to seal during the Setup process to generate a copy. PoRep and PoSt protocol
sketch given in Figure 4, and the proof of PoSt's underlying mechanism is shown in Figure 3.

Building encrypted blocks

Anti-collision hash: We use an anti-collision hash function: CRH: {0,1} *→{0,1}0(N). We also use an anti-collision
hash function MerkleCRH, which splits the string into multiple part construct a binary tree and apply CRH recursively,
and then output the root.

zk- SNARKS: The actual facts of our PoRep and Post depend on the concise non-interactive knowledge theory (zk -SNARKs)
with zero-knowledge proofs [6, 7, 8]. Because zk-SNARKs are concise, the proof is short and easy to verify. More formally,
let L be the NP language and C is the decision circuit of L The trusted party performs the secondary setup phase and generates
two public keys: the proof key pk and the verification key wk. Prove key pk make any (untrusted) of the prover can produce
proof that π for examples of her choice x，x∈L. The non-interactive proof π is zero knowledge and knowledge proof. Anyone
can verify the proof π using the verification key V. In particular zk-SNARK publicdy verifiable proof: Anyone can verify
π，without interacting with the prover generates π. Prove that π has a constant size in linear time in |x|.

For the process of zk-SNARKs tuple satisfies polynomial time algorithm: (KeyGen, Prove, Verify)

KeyGen (1λ,C) - →(pk, vk), input safety parameter λ and circuit C, KeyGen generates probability samples pk and wk. These
two keys are issued as public keys and can be used to prove / verify membership in Lc.

Prove (pk, x, w)→π, input the witness w declared by pk, x and NP, the prover Prove output a non-interactive proof for
the statementx∈Lc.

Verify (vk,xπ)→{0,1}, inputvk, x and proof π, ifx∈Lc, the verifier verifies 1.

We recommend that interested readers refer to [6] [7] [8] for the official introduction and examples of the zk- SNARK
system. In generally, these systems require a trusted party to run KeyGen operations. Innovative scalable computing system
integrity and privacy (SCIP) [9] shows a promising direction under the premise of the above assumptions of trust to avoid
this first step.

Sealing operation

The role of the sealing operation is (1) by requiring the prover
to store a pseudo-random arrangement D unique to their
public key, forcing the replica to become a physically
independent copy, so that promising to store n replicas will
result in n dedicated space for independent copies (hence the
storage size of replicas is n times), and (2) Forced generation
of copies during PoRep.Setup will actually take more time
than expected to respond to challenges. A more formal
definition of sealing operations. The above operations can be
implemented with SealAES- 256, and τ makes SealAES- 256
take 10-100 times longer than the honest challenge
verification proof sequence. Please note that choosing τ is extremely important because running Seal BC τ
will
undoubtedly take more time than running Prove with random
access ℛ.

Sealing operation

This chapter describes the architecture of the PoRep protocol
and includes a simple protocol sketch in Figure 4.
Implementation and optimization details are omitted.

Create a copy. The Setup algorithm generates a copy through
the sealing operation and provides proof. The prover
generates a copy and output it (excluding ℛ) to the verifier.

Proof storage: The Prove algorithm generates a proof of
storage for copies. The prover receives a random challenge C
from the verifier, and asks to confirm a specific leaf in the
Merkle tree with rt as the root ℛ; the prover generates a
knowledge proof about ℛ, Merkle path to rt proof.

Proof of verification: The Verify algorithm checks the validity
of the stored proof of the Merkle tree root and the original
data hash that copy given. Proofs can be verified publicly: the
nodes that maintain the decentralized system ledger and
customers interested in specific data can verify these proofs.

## Massive amounts of storage sit unused in data centers and hard drives around the world.

### Earn Flowcoin for hosting files

Put your unused storage to work by becoming a Flowcoin miner. Use the Flowcoin mining software to get paid for fulfilling storage requests and hosting files on the global Flowcoin market.

### Exchange Flowcoin for USD, BTC, ETH and more

Flowcoin will be traded on a number of exchanges and supported by multiple cryptocurrency wallets, allowing you to easily exchange Flowcoin for other currencies like US Dollars, Bitcoin and Ether.

## New Blockchain, New Breakthroughs

## A Decentralized Market for Storage

### The Flowcoin network achieves staggering economies of scale by allowing anyone worldwide to participate as storage providers.

It also makes storage resemble a commodity or utility by decoupling hard-drive space from additional services. On this robust global market the price of storage will be driven by supply and demand, not corporate pricing departments, and miners will compete on factors like reputation for reliability as well as price.

## Ready, get set, mine Flowcoin

Flowcoin is under active development and Flowcoin node software is free and and open source. Anyone can choose to run Flowcoin nodes and Testnet and Mainnet will be open to the public for anyone to join and mine.

If you’re a miner and would like to help our team with some testing after our Testnet launch, please sign up for our Miner Mailing List.