Generic Blockchain on Generic Human Behavior

ementine Gritti

1 a

, Fr

eric A. Hayek

2 b

and Pascal Lafourcade

2 c

University of Canterbury, New Zealand

Universit

e Clermont Auvergne, CNRS, Mines de Saint-

Etienne, LIMOS, Clermont-Ferrand, France

Keywords:

Blockchain, Consensus, Cryptocurrency.

Abstract:

Blockchain is a type of distributed ledger. A wide range of consensus algorithms exists to reach consen-

sus in a decentralized manner. However, most of them trade energy consumption for a degree of openness.

Blockchains are primarily used for tokens and cryptocurrencies. Often the process of minting new tokens

depends on actionable real world behaviors. A difﬁculty persists in securely translating said behavior into a

decentralized blockchain. We formalize the generic concept of Proof of Behavior (PoB), and use it to create a

consensus mechanism for generic permissionless blockchains.

1 INTRODUCTION

Blockchain technologies have attracted a lot of atten-

tion, with many possible applications (e.g., cryptocur-

rency, healthcare, identity veriﬁcation, etc.). How-

ever, they are not environmental-friendly. With cli-

mate change, it becomes urgent to develop and deploy

technologies that act responsibly towards our planet.

A blockchain is a distributed ledger taking the

form of a set of blocks “chained” together by hash

functions. We call miner an entity who can and tries

to create new blocks in a given blockchain. For

creating valid blocks in Bitcoin (Nakamoto, 2008)

(which introduced the world to blockchain in 2008 by

Nakamoto), miners have to partially inverse a cryp-

tographic hash function – i.e., ﬁnd a nonce to em-

bed in the current block such that the hash of said

block is less than a given target. This process is called

Proof of Work (PoW). Miners are then rewarded with

freshly created bitcoins, the cryptocurrency whose

transactions are written in the blocks. Mining has

become so proﬁtable that a lot of resources have

been allocated to solve these inversion problems. To-

day Bitcoin mining’s energy consumption scales to

that of nations (O’Dwyer and Malone, 2014). Many

blockchains, such as Bitcoin Cash (BTC, ), Mon-

ero (based on Cryptonote (Van Saberhagen, 2013))

as well as Ethereum (Buterin et al., 2014) before the

Merge, have also used PoW for blocks creation.

https://orcid.org/0000-0002-0835-8678

https://orcid.org/0000-0003-1083-0625

https://orcid.org/0000-0002-4459-511X

Nevertheless, blockchains by and large are shy-

ing away from PoW. Even blockchains that did im-

plement PoW are trying to change their consensus

mechanism. The best example is Ethereum’s Merge

(i.e., Ethereum 2.0) that replaced PoW with a ver-

sion of Proof of Stake (PoS). PoS is a family of

consensus mechanisms relying on miners’ stake (i.e.,

wealth). All PoS claim to be energy efﬁcient. It was

ﬁrst introduced by Peercoin’s Proof of Stake-Time

(PoST) (King and Nadal, 2012). PoST is basically a

PoW with an adjustable target such that the target de-

pends on the coins held by the miner (amount and du-

ration). In ﬁne it does not vary signiﬁcantly from PoW

such as to create a paradigm change. All PoS mech-

anisms, by deﬁnition, restrict mining to those who

have a stake in the system. Apart from the fact that

this could be seen as an infringement on the openness

of the system, PoS is generally thought of as either

(a) an extra security layer: giving bigger stakehold-

ers more responsibility in ensuring the safety of the

system; or (b) allowing less decentralization: wealthy

people are more powerful and arguably, very wealthy

individuals who do not care about the underlying as-

sets could make very dangerous attackers. Therefore,

even if PoS has been introduced as an alterntive to

energy-intensive PoW, it brings limitations that could

question the existence of decentralized ledgers.

PoW, PoST, along with Proof of Authority (PoA)

and Proof of Space (PoSp), are considered Nakamoto-

style consensus mechanisms, meaning that one miner

gets the right to mine a block by doing something, and

other miners can accept that block or reject it by sim-

206

Gritti, C., Hayek, F. and Lafourcade, P.

Generic Blockchain on Generic Human Behavior.

DOI: 10.5220/0012091700003555

In Proceedings of the 20th International Conference on Security and Cryptography (SECRYPT 2023), pages 206-217

ISBN: 978-989-758-666-8; ISSN: 2184-7711

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

ply mining atop it or not. Contrary to Nakamoto-style

consensus, some blockchains use Byzantine Fault

Tolerant (BFT) consensus mechanisms. One good ex-

ample of such a blockchain is Algorand (Gilad et al.,

2017). However BFT consensus mechanisms cannot

operate when the set of miners is unspeciﬁed, because

their algorithms depend on the total number of min-

ers which must be well deﬁned. This constraint could

restrict the variety of blockchain types.

With the recent growing trend in design-

ing and releasing cryptocurrencies, different

blockchain types have been presented, namely

permissioned/permissionless and private/public

blockchains. We deﬁne common blockchain types

inspired by (Bernabe et al., 2019) as follows:

• Public blockchains where any entity can emit op-

erations that can potentially be incorporated into

the blockchain.

• Private blockchains where only a set of autho-

rized entities can emit operations that can poten-

tially be incorporated into the blockchain.

• Permissionless blockchains where any entity can

participate in the mining process.

• Permissioned blockchains where only a set of

authorized entities can participate in mining.

Note that through this deﬁnition, PoS blockchains

are regarded as permissioned since only those who

have a stake in the system can actually participate

in the mining process. Others deﬁne blockchains

as permissioned when the current set of miners se-

lects their successors; and in PoS blockchains when

somebody sells a stake to another person, the seller

is also selling the right to mine; so in a way it is

also the set of current miners who selects their suc-

cessors. This deﬁnition enables us to identify public

permissionless blockchains (e.g., Bitcoin (Nakamoto,

2008), Ethereum (Buterin et al., 2014)), public per-

missioned blockchains (e.g., Ethereum 2.0), private

permissioned blockchains (such as the ones built with

the Hyperledger Fabric framework (Androulaki et al.,

2018)) and private permissionless (with no examples,

as this scenario has almost no use cases). As such,

most non-energy consuming blockchains are indeed

permissioned (though it may be public).

A cryptocurrency is a currency that not only re-

lies on cryptographic primitives, but must also have a

certain degree of decentralization and privacy as de-

scribed in (Lansky, 2018). Hence there is a distinc-

tion between regular digital currencies and cryptocur-

rences.

Recent years have seen a rise of tokens rewarded

to people for speciﬁc day-to-day actions such as creat-

ing solar-based energy using photovoltaics (e.g., So-

larcoin (Johnson et al., 2015), walking and running

(e.g., Sweatcoin (Fomenko, 2022; Derlyatka et al.,

2019; Elliott et al., 2019), car-pooling (e.g. and Eco-

coin (Van Mensvoort et al., 2015). Most of such

tokens claim to be cyptocurrencies, yet lack the de-

centralization required to effectively be a cryptocur-

rency (Lansky, 2018).

Our aim in this paper is to propose a solution to

overcome the aforementioned challenges: we propose

a generic blockchain mined by using Proof of Behav-

ior (PoB) (Grollemund et al., 2020). PoB aims to

replace PoW by a speciﬁc human behavior – prefer-

ably an ecological one – to avoid consuming energy in

hash computations on the one hand, and to further the

development of eco-responsible habits on the other.

1.1 Contributions

In (Grollemund et al., 2020) the authors just deﬁne

the concept of PoB, here we go above and beyond.

We formally deﬁne a generic Proof of Behavior along

with all information necessary to verify it and to ex-

tract its impact.

We construct a consensus mechanism for

blockchains using the PoB along with well deﬁned

cryptographic primitives. This blockchain is energy

efﬁcient while it promotes the speciﬁc type of be-

havior that the PoB relies upon. We use a Veriﬁable

Delay Function (VDF) (Boneh et al., 2018a) and then

reduce the energy consumption to at most a couple

of CPUs per miner which is negligeable compared to

unlimited parallelization in PoW-based consensuses.

Furthermore by simply rewarding tokens to the

blockchain miners, we are able to reward a speciﬁc

behavior with the blockchain associated cryptocur-

rency. Optionally, we could choose to allow miners

to also incorporate into the blockchain the PoBs of

non-miners and reward them for it. This entails the

creation of an ecosystem were all people who make a

speciﬁc behavior are rewarded with cryptocurrency.

We construct the transaction fees in such a way

that the miner is not biased towards bigger trans-

actions nor smaller transactions: certain conditions

must be met for this to be non-exploitable by the

miner, but the underlying idea is that senders “pay”

(in fact destroy) a fee rate in concordance with the

size of the transaction, while the miner is rewarded

the same ﬁxed amount of coins for whatever transac-

tion. We also propose to add a temporal demurrage

(highly praised by many economists such as Silvio

Gesell (Gesell, 1958)) on coins such that they lose

value with time. We show how to incorporate this

with the non-biased transaction construction.

There are many applications to such a cryptocur-

rency, and many pre-existing projects can beneﬁt

Generic Blockchain on Generic Human Behavior

207

from such a structure. We also detail an application to

this “behavior chain” in EcoMobiCoin, a cryptocur-

rency mined by ecological mobility. To our knowl-

edge, this is the ﬁrst framework for using generic be-

haviors in a blockchain consensus mechanism and for

rewarding generic behaviors with cryptocurrency.

1.2 Related Work

We are seeing the rise of projects aiming at creat-

ing cryptocurrency as a result of human action. Most

of them target human mobility, perceived through the

lens of ecology or through the lens of health.

Ecocoin. is a currency that aims to reward ecolog-

ical behaviors (Van Mensvoort et al., 2015). These

behaviors are deﬁned by the Ecocoin foundation and

include green commuting (such as car-pooling or bik-

ing), low home energy expenditure, low carbon foot-

print foods, etc. Interestingly, ecocoins are backed by

trees: to each ecocoin in circulation corresponds a tree

put in escrow. In the whitepaper and in public talks,

conceivers of Ecocoin claim it as a cryptocurrency,

and claim that people shall be rewarded for their ac-

tions according to the difﬁculty of said actions. For

example, someone biking in Portugal earns more eco-

coins than someone biking in the Netherlands because

bikes are used much less often in Portugal. For the

moment, Ecocoin is implemented in seperate events

and organizations indepedently. Furhermore, Eco-

coin relies on inspectors to verify users’ behaviors.

Inspectors can be people that personally attest of a

certain behavior (as done with L’Or

eal Paris in the

Netherlands) or can be certiﬁed vendors such as on-

line Marketplaces that could attest that you ordered

low speed shipping. However, neither the whitepa-

per nor any online resource explicits its underlying

distributed ledger. Hence, there are no security guar-

entees whatsoever. Furthermore, the project seems

abandoned since 2019.

Sweat. is a cryptocurrency aiming at complement-

ing Sweatcoin (Fomenko, 2022; Derlyatka et al.,

2019; Elliott et al., 2019). Sweatcoin is a digital to-

ken (not a cryptocurrency) that is awarded to people

who do physical efforts, such as walk, bike, swim,

etc. Users can then use sweatcoins in afﬁliated mar-

kets. Sweat on the other hand is a cryptocurrency

also rewarded to users for their physical activity, how-

ever only the person’s ﬁrst 5’000 steps can earn them

Sweat. After that, they can only get sweatcoins. Fur-

thermore, Sweat implements demurrage as a non-

activity fee. The Decentralized Autonomous Orga-

nization (governed by all holders of Sweat) sets the

activity threshold and the corresponding fees. Sweat

is built on the Near blockchain (Polosukhin and Ski-

danov, 2022). Sweat relies on Movement Validators

to validate a person’s physical activity. SweatCo Ltd

is the only Movement Validator as of launch. Veriﬁ-

cation is done through the analysis of raw data sent by

the recording device. It is intended that in the future,

third parties such as activity trackers, ﬁtness equip-

ment makers, and ﬁtness app developers can operate

as Movement Validators. However veriﬁcation of raw

data sent by recording devices is prone to attacks, for

example by manually manufacturing the data. We de-

ﬁne a Proof of Behavior in such a way to require the

impossibility of synthesize the data.

Clinicoin. is a cryptocurrency on Clinicoin’s public

permissioned blockchain

. Clinicoin connects three

types of people: (i) users who are regular people who

log healthy activities; (ii) validators who validate

(through what is called a Proof-of-Engagement) a

person’s activity, they can be developers of health

apps or in-person validators such as exercise instruc-

tors or personal trainers; and (iii) healthcare and

research providers who are interested in people’s

health data. Users can choose whether to share their

data with providers or not.

Examples above use (entirely or partially) GPS

traces to determine users’ behaviors, which is not nec-

essarily tamper-proof, nor privacy-preserving. Never-

theless, we notice that projects that aim at creating

cryptocurrencies as a reward for human behavior tend

to restrict mining. This may be for security purposes

or for efﬁciency. Some projects, such as Weward

used to have a blockchain before completely aban-

doning it in favor of a digital token architecture.

Solarcoin. is a cryptocurrency created to reward

people for solar energy produced. It is minted at the

rate of 1 solarcoin per 1 MWh of solar energy pro-

duced. To get solarcoins, one must send proof of

one’s solar energy production to the Solarcoin Foun-

dation, which in turn rewards the energy producer

with coins on the blockchain. The Solarcoin Foun-

dation used to use its own blockchain, but have now

migrated onto the Energy Web Chain (Hartnett et al.,

2019) which uses a Proof of Authority type of con-

sensus. Cleary Solarcoin lacks decentralization since

it relies on a single authority to verify solar energy

production, not to mention the Proof of Authority

blockchain.

https://clinicoin.io/en (accessed on 2023-03-07).

https://en.weward.fr/ (accessed on 2023-03-07).

SECRYPT 2023 - 20th International Conference on Security and Cryptography

208

Primecoin. (King, 2013a; King, 2013b) is a cryp-

tocurrency that instead of wasting computing power

to do a regular PoW which serves no purpose ex-

cept chosing the next miner, miners do “computa-

tional work” that actually is useful. Primecoin’s min-

ers are chosen based on who creates new speciﬁc

prime-number related sequences. The goal is to re-

place PoW’s by a useful energy consumption. This

takes the form of “working” on ﬁnding Cunningham

and bi-twin chains, which are interesting to mathe-

maticians.

Elapsed Time Consensus Protocols. encompass

Proof of Elapsed Time (Chen et al., 2017) and Proof

of Luck (Milutinovic et al., 2016), since they share

many similarities. Basically, these consensus mecha-

nism rely on Trusted Execution Environments (TEEs)

to wait a certain period of time before emitting a proof

that they did so. This proof is what gives a miner min-

ing rights. The miner will thus incorporate it into the

block, making it a valid block. In (Bowman et al.,

2021), they also propose a way to not rely on TEEs.

This relies on a function z-test which they modify into

a “time-based” z-test to suit their proof. This function

allows them to calculate if a given miner has mined

too many blocks, in which case it will restrict them

from mining for a period of time. It is easy to see that

this only works in permissioned blockchains (which

they do specify as “private”) since in permissionless

blockchains miners can create new identities on the

ﬂy, and are thus immune to restrictions from the z-

test.

Many blockchains claim to be energy efﬁcient

and permissionless. However, all PoS blockchain, by

deﬁnition, are not permissionless, be it regular PoS,

PoST, liquid PoS (used in Tezos (Goodman, 2014)).

Few consensus mechanisms can claim to be non en-

ergy consuming and permissionless. One such ex-

ample is PoSp (Park et al., 2018). PoSp can be im-

plemented in many forms, most interesting of which

are Proof of Retrievability (PoR) (Miller et al., 2014)

(also known as Proof of Storage) consisting of prov-

ing that a certain data is being correctly stored at the

time of the proof. However, PoSp constructions re-

quire evergrowing memory, and apart from their di-

rect application (storing ﬁles in a distributed manner)

show no further development.

1.3 Road Map

In the following section, we present the cryptographic

tools that we need to design a PoB blockchain. In

Section 3, we deﬁne our eco-friendly Proof of Behav-

ior (PoB). In Section 4, we propose a blockchain us-

ing consensus mechanism based on PoB. In Section

5, we focus on the security of such PoB blockchain.

In Section 6, we explain the process of blockchain-

based demurrage. In Section 7, we suggest our main

application, called EcoMobiCoin, based on our PoB

blockchain, along with other possible examples. Fi-

nally, we conclude our paper in the last section.

2 CRYPTOGRAPHIC TOOLS

2.1 Hash Functions

Hash functions are an important building block of

blockchain technologies. Hash functions take as in-

put data of arbitrary length and output a string of ﬁxed

length. Hash values in such context are used to iden-

tify blockchain transactions and to generate PoWs.

We require the hash function to be computation-

ally efﬁcient and deterministic. Given an input x,

computing H(x) = y is efﬁcient and always gives the

same output y. Moreover, we need the hash function

to be collision-resistant: it must be infeasible to ﬁnd

two different inputs x and x

′

such that they both yield

the same output y = H(x) = H(x

′

2.2 Digital Signatures

Blockchains require the use of digital signatures in

order to authenticate users’ transactions. When a user

submits a transaction to the network, it must prove

that it has enough funds to spend while protecting

iself from getting those funds spent by other users.

Then the submitted transaction is veriﬁed and the new

blockchain state is agreed upon by the network.

Let Alice plan to send 1 coin to Bob. Using her

private key, Alice signs a transaction spending 1 coin

and submits both the transaction and its signature to

the network. The miners check the contents of the

submitted transaction as well as the validity of the as-

sociated signature using the public key of Alice. If the

signature is valid, then the transaction is conﬁrmed

and included in the upcoming block.

Deﬁnition 1. A digital signature scheme consists of

three probabilistic polynomial time algorithms, de-

noted as KeyGen, Sign and Verify

sign

, such that:

KeyGen(λ) → (pk,sk) is a randomized algorithm

that takes a security parameter λ, and outputs the

pair of public key pk and private key sk.

Sign(sk, m) → σ is a deterministic algorithm taking

the private key sk and the to-be-signed message m

and outputs a signature σ.

Generic Blockchain on Generic Human Behavior

209

Verify

sign

(pk,m, σ) → {Accept,Re ject} is a deter-

ministic algorithm taking the message m, its sig-

nature σ along with the supposed signing public

key pk and either outputs Accept if σ is a valid

signature for m with pk or Re ject otherwise.

Correctness. If (pk, sk) ← KeyGen(λ) and

σ ← Sign(m, sk) for a given message m, then

Verify

sign

(m,σ, pk) → Accept.

Unforgeability. We are interested in digital signa-

ture schemes that are existentially unforgeable under

a chosen-message attack (Goldwasser et al., 1988).

Informally, let an adversary get access to signatures

for messages that he chooses. This adversary must

not be able to create a valid signature for a new mes-

sage.

2.3 Veriﬁable Delay Functions

For our consensus mechanism, we rely on Veriﬁable

Delay Functions (VDFs) (Boneh et al., 2018a). A ver-

iﬁable delay function is a function that cannot be com-

puted in less than a pre-deﬁned number of sequential

computations, and it must be “quickly” veriﬁable.

Deﬁnition 2. A VDF scheme consists of three algo-

rithms, Setup, Eval and Verify

V DF

, such that:

Setup(λ,t) → pp = (ek, vk) is a randomized algo-

rithm that takes a security parameter λ and a de-

sired puzzle difﬁculty t and produces public pa-

rameters pp that consist of an evaluation key ek

and a veriﬁcation key vk. We require Setup to

be polynomial time in λ. By convention, the pub-

lic parameters specify an input space X and an

output space Y . We assume that X is efﬁciently

sampleable. Setup might need secret randomness,

leading to a scheme requiring a trusted setup. For

meaningful security, the puzzle difﬁculty t is re-

stricted to be sub-exponentially sized in λ.

Eval(ek,x) →(y,π) takes as input the public param-

eter ek and x ∈ X and produces an output y ∈ Y

and a (possibly empty) proof π. Eval may use ran-

dom bits to generate the proof π but not to com-

pute y. For all pp generated by Setup(λ,t) and all

x ∈ X , algorithm (eval,ek,x) must run in parallel

time t with poly(log(t), λ) processors.

Verify

V DF

(vk, x,y,π) → {Accept, Re ject} is a deter-

ministic algorithm that takes as inputs the public

parameter vk, an entry x ∈ X , the supposed cor-

responding output y ∈ Y and the supposed corre-

sponding proof π and outputs Accept or Re ject.

Verify

V DF

must run in total time polynomial in

log(t) and λ.

Sequentiality. Any honest user can generate the

pair (y, π) ← Eval(pp, x) in t sequential steps, while

any parallel-machine adversary with a polynomial

number of processors cannot distinguish the output y

from random values in signiﬁcantly fewer steps.

Efﬁcient Veriﬁability. The algorithm Verify

V DF

aimed to be as fast as possible for honest users to

run. In particular, the total time should be of the order

O(polylog(t)).

Uniqueness. For every input x, it is difﬁcult to

obtain a value y such that Verify

V DF

(pp, x,y,π) →

Accept, but y ̸= Eval(pp, x).

Constructions. Two possible constructions are

Wesolowski’s construction (Wesolowski, 2019) and

Pietrzak’s construction (Pietrzak, 2018). They are

both efﬁcient and simple, though the ﬁrst is a little

more efﬁcient and the latter a little simpler. A de-

tailed comparison and analysis of both constructions

can be found in (Boneh et al., 2018b).

3 PROOF OF BEHAVIOR

Our generic blockchain is mined using a Proof of

Behavior (PoB) (Grollemund et al., 2020). The

blockchain’s genericity consists of the type of behav-

ior the blockchain seeks to promote.

A PoB should contain (i) data about the behavior

itself, which allows anyone to verify the behavor; (ii)

a timestamp (since a PoB has a limited duration) and

(iii) the identity of its producer. All these information

should be signed together by a validator binding the

producer with the timestamp with the behavior. The

validator could be operated by a human actor or by an

automatic veriﬁcation mechanism such as a Trusted

Platform Module. It is the signature by the validator

that prevents the user from modifying the timestamp.

Deﬁnition 3. A Proof of Behavior (PoB) is a tuple

π = (b||σ

) where b is the tuple b = (pk,ts, data) con-

taining pk the identity of the producer (seen here as a

public key), ts the timestamp of the behavior and data

some auxiliary data about the behavior itself; and σ

is the signature of b by a given validator able to verify

that the behavior included in data was done at times-

tamp ts by pk.

Accompanying a PoB is the Quantify function de-

ﬁned as follows:

Quantify(π) → v is a deterministic algorithm that

takes as input the PoB π, and outputs a non-

SECRYPT 2023 - 20th International Conference on Security and Cryptography

210

negative number v ≥ 0 that represents the value

of said behavior.

Quantify plays the role of a veriﬁcation function

such that Quantify returns a non-negative number to

allow for variation of behavior importance. In cer-

tain cases where all valid PoBs are equally important,

Quantify outputs only either 0 (invalid) or 1 (valid).

Example. Let us consider a behavior as mobility us-

ing public transportation where users tap their card on

the terminal. Such a terminal can be seen as a proxy

of the public transportation organization. When the

user taps their card on the terminal, the terminal, act-

ing as the validator, creates a PoB π = (b||σ

) with

b = (pk,ts, data) where pk is the public key of the

user, ts is a timestamp and data is data about the jour-

ney being travelled. To verify and quantify the proof,

we plug it into Quantify which should output 1 if the

PoB is valid and 0 otherwise. If in the underlying

transportation network it is required to tap one’s card

at entry and exit of stations (which is the case in many

places), then the Quantify function outputs a number

proportional to the distance covered.

Quantiﬁable. We say a PoB scheme is quantiﬁable

when ∃π,Quantify(π) ̸∈ {0, 1}.

Trust. In the example above, we must trust the

transportation auhority. This hardly makes for a uni-

versal trust-based system. Instead, it could lead to

different cities, states or countries adopting a clone of

the same blockchain, since they do not trust each oth-

ers’ transportation authorities. However, the validator

does not always need to be a physical or moral person.

In other instances, it could simply be a signer of some

Trusted Platform Module (TPM), or it could be any

of a set of validators. Centralization around valida-

tors depends on the instanciation of the blockchain.

PoB Expiration. Only “recent” PoBs should ever

be incorporated in the blockchain. Let exp be a time

unit. We consider a PoB expired when its timestamp

is more than exp older than the newest PoB in the

blockchain up to this point. A discussion on expira-

tion implications is given in Section 4.4.

4 BLOCKCHAIN AND

CRYPTOCURRENCY

We describe a possible generic cryptocurrency that

rewards speciﬁc human behaviors and its underlying

public permissionless blockchain based on our PoB

consensus mechanism.

4.1 Mining and Consensus

Our mining mechanism goes as follows: instead of

miners competing with raw computational power to

gain mining rights, they compete with their behav-

iors. If PoBs are quantiﬁable, then bigger behaviors

amount to more chance of being the next miner. To

mine atop a given block β, the miner m with a PoB

has to compute a VDF with a delay parameter de-

pending on π

. Speciﬁcally, this delay parameter is

t =

δ ·H(β||π

)

Quantify(π

)

(1)

where δ is a difﬁculty parameter and H(·) is a cryp-

tographic hash function. Table 1 summarizes all

blockchain parameters (i.e., values that have to be de-

termined with each instantiation of the blockchain).

Table 1: Blockchain parameters.

exp Expiration time unit

δ Difﬁculty

P Difﬁculty adjustment period

∆

Desired average mining time

f r Fee rate

tr Fixed miner transaction reward

k Miner’s reward rate for own PoB

′

Non-miners’ reward rate for own PoB

′′

Miner’s reward rate for not own PoB

min

cur

Minimal subdivision of currency

block

Demurrage rate per block

day

Demurrage rate per day

Discussion on Mining. Thanks to the β being one

of the inputs of the hash function, the length of the

VDF using a given PoB cannot be predicted (and thus

the VDF cannot be launched) until the previous block

is known. Furthermore, more important PoBs have

more chance of inducing a smaller t yielding a quicker

VDF thanks to the division by Quantify(π

). Natu-

rally, when there are more miners, the probability that

all of their PoBs yield long VDFs is lower. The vari-

able δ should be adjusted every given time period P

(that corresponds to a certain number of blocks). For

instance, for a desired average mining time ∆

, every

P blocks, for an average mining time of

∆

over the

last P blocks, δ is updated as follows: δ ←δ·

∆

. Like

is done in Bitcoin (Nakamoto, 2008), we could natu-

rally add minimum and maximum values for δ’s up-

date, such as no less than the quarter of the previous

value and no more than the quadruple of the previous

value.

Generic Blockchain on Generic Human Behavior

211

Furthermore, notice that the VDF does not depend

on the current block’s contents. Hence, on the down-

side the miner could potentially create many valid sib-

ling blocks simultaneously, but on the upside it is im-

possible for a miner to parallelize mining by comput-

ing many VDFs in parallel, each with a different block

content. More on the downside of this in Section 5.

Figure 1 summarizes the mining process: people

produce PoBs and transactions (denoted by Tx), and

put them in a pool. Then miners, using their own

PoBs, compute the VDF, and the ﬁrst miner to com-

plete their computations publishes a new block.

Main Chain. As in Bitcoin (Nakamoto, 2008), the

main chain is the sub-chain with the highest cumula-

tive difﬁculty, consisting of the sum of the δ of each

of its blocks.

4.2 Cryptocurrency

In a permissionless blockchain, the miner is rewarded

for creating the block as well as the work put in for

having mining rights, i.e., in our case this is doing

a PoB and the corresponding VDF. The reward r is

proportional to the quantiﬁcation of the behavior r =

k ·Quantify(π) for k > 0.

We choose to reward all PoBs, and not only the

miners’. To do so, the miner can incorporate in their

block not only transactions, but PoBs as well. And the

producers of those PoBs get rewarded – but to a lesser

extent than the miner. The reward r

′

for a PoB not

used for mining is also proportional to the quantiﬁca-

tion of the underlying PoB π

′

: r

′

= k

′

·Quantify(π

′

with 0 < k

′

< k.

To incentivize the miner to incorporate PoBs in the

block, the miner gets rewarded for doing so. Specif-

ically, let r

′′

be that reward for a given PoB π

′

incor-

porated by the miner, the reward is proportional to the

quantiﬁcation of said PoB: r

′′

= k

′′

·Quantify(π

′

) with

0 < k

′′

< k

′

< k.

4.3 Transactions

Coins can only be created by doing PoBs. Every PoB

incorporated in the blockchain should be associated

with a special transaction that creates coins.

There are three types of transactions:

1. Regular transactions: send coins.

2. Reward transactions: reward PoB producers.

3. Coinbase transactions: reward the miner.

Below we describe those three types of transaction.

4.3.1 Regular Transactions

Regular transactions are divided into three parts, the

ﬁrst containing the transaction input, the second con-

taining the fees and the third containing the transac-

tion output, as shown in Figure 2. Each transaction

can have as many inputs as the sender wishes. How-

ever, they only have one or two outputs (one input for

the receiver, and a second one for returning the re-

mainder to the sender), plus one fee.

Transaction Fees. We wish to incentivize the miner

to incorporate transactions in the blockchain. We

also wish to not distinguish between transactions:

cryptocurrencies generally favor transactions with big

fees, which favor bigger transactions over smaller

ones (since the fees could be higher while remaining

the same proportion of the amount transacted).

Our solution is to have the sender destroy (“pay”)

a certain rate of the transaction’s value, the fee rate de-

noted as f r ∈]0, 1[, and the miner be always paid the

same ﬁxed amount for any transaction, the transac-

tion reward denoted as tr. There must be restrictions

on the fee rate, the transaction reward, the minimal

amount sent, denoted as min

sent

, and the minimal unit

of currency, denoted as min

cur

, as follows:

f r ·min

sent

≥ tr ≥ min

cur

(2)

This prohibits the miner, economically, from making

many bogus transactions with themselves.

Valid Regular Transactions. Let n be the number

of inputs to the transaction, and in

denote the i

in-

put. Let m denote the number of outputs, and out

denote the i

output. A transaction is valid if the next

two equations are veriﬁed:

(1 − f r) ·

∑

i=1

≥

∑

i=1

out

(3)

∀i ∈ [1, m],∃j ∈ N, out

= j ·min

cur

(4)

Equation 4 ensures that all outputted coins are indeed

multiples of the minimal value. Note that no upper

limit is imposed on the amount of burned coins. Equa-

tion 3 ensures that the output is less or equal to the

input minus the fees.

Example. Suppose the minimal unit of currency is

min

cur

= 1, the fee rate f r = 0.1, and the transac-

tion reward tr = 1. Firstly, with such values, we must

have min

sent

≥10. If Alice wishes to send 55 coins to

Bob, then out of these 55 coins, only

⌊

(1 − f r) ·55

⌋

⌊(1−0.1)·55⌋= ⌊(0.9)·55⌋= ⌊49.5⌋= 49 coins ac-

tually will be sent to Bob. Moreover, Alice will pay 6

coins as fees, and the miner will receive 1 coin only.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

212

Figure 1: Blockchain construction.

Transaction

...

Fees

Out

...

Figure 2: Transaction Structure.

4.3.2 Reward Transactions

There are as many reward transactions as there are

PoBs. Each reward transaction has one input, which

is a PoB, and one output, which rewards its producer.

Valid Reward Transactions. A reward transaction

is valid if and only if, for an input π and an output out,

we have:

′

·Quantify(π) ≥ out (5)

out + min

cur

≥ k

′

·Quantify(π) (6)

∃j ∈ N, out = j ·min

cur

(7)

Equation 5 ensures that the output is no more than the

value of the PoB. Equation 6 ensures that the miner

does not give the producer of the PoB less than what

they are expected to get. Equation 7 ensures that the

output is a multiple of the minimal value.

4.3.3 Coinbase Transactions

There is only one coinbase transaction per block. It

has no input, since it depends on the whole block, and

one output out which rewards the miner.

Valid Coinbase Transactions. Let n be the num-

ber of regular transactions in the block. Let m be the

number of reward transactions in the block. Let π

de-

note the PoB of the i

reward transaction in the block.

Let π

denote the miner’s PoB. Let Q(·) = Quantify(·)

(for space purposes). A coinbase transaction is valid

if and only if it veriﬁes the following:

∃j ∈ N, out = j ·min

cur

(8)

k ·Q(π

) + n ·tr +

∑

i=1

′′

·Q(π

) ≥ out (9)

Equation 9 ensures that the miner does not reward it-

self more than he is allowed to: on the left hand side,

the ﬁrst term considersthe miner’s reward for its own

PoB, the second considers the reward for including n

transactions and the third is the rewards for includ-

ing other people’s PoBs. Equation 8 ensures that the

output is a multiple of the minimal value.

4.4 Blocks

A block is comprised of a VDF output and its associ-

ated proof and PoB, the coinbase transaction (the re-

ward of the miner for the work put in), other PoBs and

their rewards, regular transactions, and the signature

of all aforementioned data by the miner. Concretely,

a block β contains β = (data

,σ

data

) with data

PoB

,y,π

V DF

,T x

miner

,(π

PoB

,T x

)

i∈I

,(T x

)

j∈J

, with

PoB

= (b||σ

) with b = (pk

,ts, data

PoB

Generic Blockchain on Generic Human Behavior

213

Block Size. The blocks’ size must be bounded. The

actual size should depend on the PoBs’ size and their

frequency, so this is blockchain dependent. Hence

we do not give a speciﬁc size in this paper. Also,

a certain percentage of the blocks must be allocated

to PoBs and another to transactions. Otherwise the

miner could ﬁll up the block with whatever is most re-

warding – potentially only PoBs or only transactions.

The percentage of the block size also depends on the

PoBs’ size and frequency.

Valid Blocks. For a block to be deemed valid, it

must verify the following:

• All transactions must be valid.

• All PoBs (including the miner’s) must be valid,

i.e., ∀π ∈PoBℓist, Quantify(π) > 0, as well as non-

expired and not already in the blockchain.

• The miner must be the person who has done the

VDF’s PoB, i.e., the recipient of T x

miner

is the ac-

count associated with pk

• The block must be signed by the miner, i.e.,

Verify

sign

(pk

,data

,σ

data

) → Accept.

• The VDF must be valid, i.e., with

v ← Quantify(π

PoB

) and t ←

δ·H(β||π

PoB

)

we have Setup(λ,t) → (ek, vk) and

Verify

V DF

(vk, β

,y,π

V DF

) → Accept.

Discussion on Expiration. For a block to be

deemed valid, all of its PoBs must be less than exp

older than the newest PoB in the blockchain. Note

that a PoB’s timestamp, which is signed by a val-

idator, is compared only to that of other PoBs (who

are already in the blockchain). This avoids any syn-

chrony assumption between miners and users. As a

consequence, when checking if a PoB is already in

the blockchain, one only needs to check the last cou-

ple of blocks. Speciﬁcally, to check if a PoB π that

is in the current block isn’t already in the blockchain,

we start by checking if it is in the previous block, then

the one before it, and so on, until we reach a block

where the newest PoB is more than exp older than π.

Hence π cannot be before such a block: suppose such

a block is valid and π exists in the blockchain before

that block; then that block’s PoBs are all more than

exp older than π which itself is at least as old as the

oldest PoB in the blockchain so far; then that block

cannot be valid because its PoBs are expired.

4.5 Energy Consumption

For the energy consumption we only take into account

the consensus mechanism. We do not take into ac-

count the required veriﬁcation of valid transactions

nor the optional quantiﬁcation of other people’s PoBs,

for the former is necessary in all blockchains and

the latter is optional. Suppose all miners are min-

ing using the entirety of their non-expired PoBs (less

than exp older than the newest PoB used for mining

in the blockchain), then corresponding to each such

PoB is a VDF being computed. Since VDFs are non-

parallelizable, for each non-expired PoB is one CPU

computing a VDF. Unlike other Nakamoto-style con-

sensuses, miners here cannot augment their mining

power by augmenting computers.

5 SECUIRTY ANALYSIS

Our blockchain achieves the same security properties

as Bitcoin’s Backbone Protocol (Garay et al., 2015):

Persistence (informally). Once a transaction goes

more than k blocks deep into the blockchain of

one honest miner, then it will be included in ev-

ery honest miner’s blockchain with overwhelming

probability, and it will be assigned a permanent

position in the ledger.

Liveness (informally). All transactions originating

from honest account holders will eventually end

up at a depth more than k blocks in an honest

miner’s blockchain, and hence the adversary can-

not perform a selective denial of service attack

against honest accoun holders.

Proof Sketch

Model. In the Bitcoin Backbone Protocol (Garay

et al., 2015), the execution of a protocol Π is driven by

an environment program Z which may spawn multi-

ple instances running the protocol Π. The programs in

question can be thought of as Interactive Turing ma-

chines (ITM) that have communication, input and out-

put tapes. The environment performs a round-robin

participant execution sequence for a ﬁxed set of par-

ties. The execution driven by Z is deﬁned with re-

spect to a protocol Π, an adversary A (also an ITM)

and a set of parties P

,··· , P

; these are hardcoded in

a control program C (also an ITM). The adversary can

corrupt at most t out of n total parties. Parties have ac-

cess to two functionalities: the random oracle and the

diffusion channel. The number of queries to the ran-

dom oracle is bound to at most q per round per party.

Remark that this is a ﬂat-model interpretation of the

parties’ computation power where all parties are as-

sumed equal. In the real world, different honest par-

ties may have different hashing power, nevertheless

the ﬂat-model does not sacriﬁce generality since one

SECRYPT 2023 - 20th International Conference on Security and Cryptography

214

can imagine that real honest parties are simply clus-

ters of some arbitrary number of honest ﬂat-model

parties. The protocol relies on 4 algorithms:

Chain Validation. The ﬁrst algorithm performs a

validation of the structural properties of a given

chain C. For each block of the chain, the algo-

rithm checks that the Proof of Work is properly

solved, that the counter ctr does not exceed q and

that the hash of the previous block is properly in-

cluded in the block. It also veriﬁes the consistency

of the data included in the blocks.

Chain Comparison. This algorithm ﬁnds the best

possible chain when given a set of chains i.e., the

longest chain. This algorithm relies on the chain

validation algorithm.

Proof of Work. This algorithm seeks to ﬁnd a valid

block by producing a PoW. To do so, it repeat-

edly queries the random oracle hash function with

the current block containing different nonces. The

nonce is represented with a counter variable ctr

initialized at 1 and incremented by 1 at each try.

The total number of queries is bounded by q. If

the algorithm ﬁnds a valid block, then the chain

is extended and returned; otherwise the chain is

returned unaltered. Part of the algorithm is repre-

sented below (where (ctr, h) represents the block

and T the hash target):

while ctr ≤ q do

if H(ctr, h) < T then

Append block to blockchain

return Blockchain

ctr ← ctr + 1

return Blockchain

The Backbone Protocol. This is the algorithm exe-

cuted by the miners and which is assumed to run

indeﬁnitely. Put simply, the algorithm calls the

chain comparison algorithm to get the best possi-

ble chain. Then it tries to produce a PoW using

the Proof of Work algorithm.

Assumptions. The authors in (Garay et al., 2015)

assume that the protocol is executed by a ﬁxed num-

ber of miners, however the number itself is not nec-

essarily known to the miners. The miners themselves

cannot authenticate each other and therefore there is

no way to know the source of a message. It is as-

sumed that messages are eventually delivered and all

parties in the network are able to synchronize in the

course of a round. The hypotheses are: (i) the adver-

sary controls less than half of the total hashing power,

(ii) the network synchonizes much faster relative to

the PoW solution rate and (iii) digital signatures can-

not be forged.

Parallel with Proof of Behavior. We propose ﬁrst

an equivalent version of the Proof of Work algorithm,

and then draw a parallel between the new algorithm

and our blockchain. Let τ be the smallest positive

counter value such that the hash of the block is less

than T . (Note that it may be that τ > q; this simply

means that it takes more than q hashes to get to the

counter realizing a valid block, which means that it

takes more than 1 round to realize a PoW.) Initialize

the counter at 1. Instead of checking if the hash of the

block is less than T , we check if the counter is equal

to τ. If it is, then we have found a valid block, if not

we increment the counter and repeat, until the counter

reaches q. This yields the following instead:

while ctr ≤ q do

if ctr = τ then

Append block to blockchain

return Blockchain

ctr ← ctr + 1

return Blockchain

This algorithm is equivalent to the one used in the

Proof of Work algorithm, yet it can encompass the

VDF construction. Indeed, when doing a VDF there

is also a ﬁxed number of steps to do before ﬁnish-

ing it. The only difference with a PoW is that this

number is known in advance, which does not change

the algorithms in the slightest. We can thus model

our blockchain with exactly the Bitcoin Backbone

Protocol. Their hashing power translates to mining

power, which in our case corresponds to the number

of PoBs per miner and their importance (i.e., quantiﬁ-

cation). Therefore all the proofs follow from (Garay

et al., 2015) (under the same assumptions), and our

blockchain is in fact an operational transaction ledger.

6 DEMURRAGE

The economist Silvio Gesell was a ﬁrm believer in

temporal monetary demurrage (Gesell, 1958). De-

murrage is money quantity diminishing with time.

For example suppose a demurrage rate of 10% per

day, then if Alice has 100 units today, she’ll have only

90 tomorrow, then 81 the day after, etc. The goal is to

incentivize spending and prevent hoarding. Demur-

rage has been replicated a couple of times throughout

history, but was difﬁcult to put in practice because of

the difﬁculty to discriminate old bills. The use of pe-

riodic stamps on bills was not practical. This would

be easy to implement in a digital currency. We can

smooth the demurrage over, by making the demur-

rage take place at every block. However, one can infer

the average daily demurrage rate from the block rate

and vise-versa. The daily demurrage rate d

day

and the

Generic Blockchain on Generic Human Behavior

215

block demurrage rate d

block

are related by the formula:

day

= 1−(1 −d

block

)

where n is the average number

of blocks mined per day.

Example. Suppose a rate of 10% per day. If Al-

ice has 100 coins today, she will be left with 90

coins tomorrow, then 81 coins the day after tomor-

row, etc... Suppose there are on average 144 blocks

per day (same mining rate as Bitcoin, i.e., one block

every 10 minutes (Nakamoto, 2008)). If we aim to

have a daily demurrage rate of d

day

= 10% = 0.1, then

we must have a block demurrage rate of d

block

= 1 −

1 −d

day

= 1 −

144

√

1 −0.1 = 0.00073 = 0.073%.

Demurrage must be taken into account during

transactions. So the input to transactions, minus the

demurrage, minus the fees must equal the output (to

the next whole integer). For n a total number of trans-

action inputs, and for i ∈ [1, n] let in

denote the i

input, let age

be the age (in number of blocks) of the

input. Then a block is deemed valid if and only if:

(1 − f r) ·

∑

i=1

(1 −d

block

)

age

×in

∑

i=1

out

(10)

∀i ∈ [1, m],∃k ∈ N, out

= k ·min

cur

(11)

The same idea of temporal demurrage was the

cornerstone of the Freicoin cryptocurrency

This is a

Proof of Work based blockchain implementing a tem-

poral demurrage. We explicit how to put the temporal

demurrage into work in our blockchain and its trans-

action system.

7 APPLICATIONS

7.1 EcoMobiCoin

One application of PoB-based blockchains is ecolog-

ical mobility. To go back to the example provided in

Section 3, we can have PoBs created by a transporta-

tion seller for their customers. When customers tap

their card upon the terminal, the terminal emits a PoB

for them

. Customers then have two options: they can

either utilize these PoBs and plug them into VDFs to

gain mining rights, or simply put it in a mining pool

where some miner might take it and incorporate it into

their block. The latter option still is less lucrative but

still provides them with some coins. Such a cryp-

tocurrency would indeed reward all willing customers

with coins while remaining fully distributed.

http://freico.in/ (accessed on 2023-03-15).

The Quantify function could for example quantify

PoBs based on the distance travelled by public transports.

7.2 Other Applications

Let us try to replace the digital currencies that re-

ward walking and running using our construction. In

this case, we have a PoB π = (b||σ

) where b =

(pk,ts, data) with pk the public key of the user, ts the

timestamp and data containing for instance the GPS

trace of the behavior along with acceleration detec-

tion information and gyroscope information. As for

, we require it to be the signature of b by either the

TPM while using virtualization, or by trusted sensors.

These are two constructions proposed in (Saroiu and

Wolman, 2010) who could play the role of a validator

and verify that data is indeed authentic and has not

been tampered with. As for Quantify, it is a public

classiﬁer that takes in π, and if the signature checks

out, returns a quantiﬁcation of the mobility. Classi-

ﬁers like this are already used by Google, Sweatcoin

or other applications.

8 IMPLEMENTATION

We are currently working on an implementation of

this blockchain. The work in progress is applied to

the ecological mobility idea. Though it is meant to

become generic to any type of behavior.

9 CONCLUSION

In this paper, we have put forth a truly distributed

generic cryptocurrency that rewards speciﬁc human

behavior. It is based on Proofs of Behavior (PoB), and

uses Veriﬁable Delay Functions (VDFs) among other

cryptographic primitives. Thanks to this construction,

the underlying blockchain is completely permission-

less, as long as the creation of PoBs is unrestricted.

Moreover, the mining process’s energy consumption

is extremely limited: only one CPU runs per PoB per

exp. We understand that many consensus mechanisms

are even less energy consuming, but they seldom are

permissionless. We also propose a non-biased fee sys-

tem: neither in favor of bigger transactions nor in fa-

vor of smaller ones. We have also depicted how to im-

plement demurrage into a cryptocurrency, which we

do in a different way then Freicoin. We are working

on an implementation of our blockchain. Technical

details thus lie as future work.

REFERENCES

Bitcoin cash. https://bitcoincash.org/. Accessed: 2023-02-

SECRYPT 2023 - 20th International Conference on Security and Cryptography

216

14.

Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,

Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,

Laventman, G., Manevich, Y., et al. (2018). Hyper-

ledger fabric: a distributed operating system for per-

missioned blockchains. In Proceedings of the thir-

teenth EuroSys conference, pages 1–15.

Bernabe, J. B., Canovas, J. L., Hernandez-Ramos, J. L.,

Moreno, R. T., and Skarmeta, A. (2019). Privacy-

preserving solutions for blockchain: Review and chal-

lenges. IEEE Access, 7:164908–164940.

Boneh, D., Bonneau, J., B

unz, B., and Fisch, B. (2018a).

Veriﬁable delay functions. In Annual international

cryptology conference, pages 757–788. Springer.

Boneh, D., B

unz, B., and Fisch, B. (2018b). A survey of two

veriﬁable delay functions. Cryptology ePrint Archive,

Paper 2018/712.

Bowman, M., Das, D., Mandal, A., and Montgomery, H.

(2021). On elapsed time consensus protocols. In In-

ternational Conference on Cryptology in India, pages

559–583. Springer.

Buterin, V. et al. (2014). A next-generation smart contract

and decentralized application platform. white paper,

3(37):2–1.

Chen, L., Xu, L., Shah, N., Gao, Z., Lu, Y., and Shi,

W. (2017). On security analysis of proof-of-elapsed-

time (poet). In International Symposium on Stabi-

lization, Safety, and Security of Distributed Systems,

pages 282–297. Springer.

Derlyatka, A., Fomenko, O., Eck, F., Khmelev, E., and

Elliott, M. T. (2019). Bright spots, physical activ-

ity investments that work: Sweatcoin: a steps gen-

erated virtual currency for sustained physical activity

behaviour change. British Journal of Sports Medicine,

53(18):1195–1196.

Elliott, M., Eck, F., Khmelev, E., Derlyatka, A., Fomenko,

O., et al. (2019). Physical activity behavior change

driven by engagement with an incentive-based app:

evaluating the impact of sweatcoin. JMIR mHealth

and uHealth, 7(7):e12445.

Fomenko, O. (2022). Sweat economy. Tech-

nical report, SweatCo Ltd. Accessed:

2023-03-07 :https://drive.google.com/ﬁle/d/

1IPklRcEQvgJkCaeYvGh43yjWl-Dj5 6i/view/.

Garay, J., Kiayias, A., and Leonardos, N. (2015). The bit-

coin backbone protocol: Analysis and applications.

In Advances in Cryptology-EUROCRYPT 2015: 34th

Annual International Conference on the Theory and

Applications of Cryptographic Techniques, Soﬁa, Bul-

garia, April 26-30, 2015, Proceedings, Part II, pages

281–310. Springer.

Gesell, S. (1958). The natural economic order. Owen Lon-

don.

Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and Zeldovich,

N. (2017). Algorand: Scaling byzantine agreements

for cryptocurrencies. In Proceedings of the 26th sym-

posium on operating systems principles, pages 51–68.

Goldwasser, S., Micali, S., and Rivest, R. L. (1988). A

Digital Signature Scheme Secure Against Adaptive

Chosen-Message Attacks. SIAM Journal on Comput-

ing, 17(2):281–308.

Goodman, L. (2014). Tezos: A self-amending crypto-ledger

position paper. self-published paper, 3.

Grollemund, P.-M., Lafourcade, P., Thiry-Atighehchi, K.,

and Tichit, A. (2020). Proof of behavior. In The 2nd

Tokenomics Conference on Blockchain Economics,

Security and Protocols. hal-02559573.

Hartnett, S., Henly, C., Hesse, E., Hildebrandt, T., Jentzch,

Christoph andKr

amer, K., MacDonald, G., Morris,

J., Touati, H., Trbovich, A., and von Waldenfels, J.

(2019). The energy web chain: Accelerating the

energy transition with an open-source, decentralized

blockchain platform. Technical report, Energy Web

Foundation.

Johnson, L., Isam, A., Gogerty, N., and Zitoli, J. (2015).

Connecting the blockchain to the sun to save the

planet. Available at SSRN 2702639.

King, S. (2013a). Primecoin: Cryptocurrency with prime

number proof-of-work. Technical report, PrimeCoin.

Accessed: 2023-02-14 :https://primecoin.io/.

King, S. (2013b). Primecoin: Cryptocurrency with prime

number proof-of-work. July 7th, 1(6).

King, S. and Nadal, S. (2012). Ppcoin: Peer-to-peer crypto-

currency with proof-of-stake. self-published paper,

19(1).

Lansky, J. (2018). Possible state approaches to cryptocur-

rencies. Journal of Systems integration, 9(1):19–31.

Miller, A., Juels, A., Shi, E., Parno, B., and Katz, J. (2014).

Permacoin: Repurposing bitcoin work for data preser-

vation. In 2014 IEEE Symposium on Security and Pri-

vacy, pages 475–490. IEEE.

Milutinovic, M., He, W., Wu, H., and Kanwal, M. (2016).

Proof of luck: An efﬁcient blockchain consensus pro-

tocol. In proceedings of the 1st Workshop on System

Software for Trusted Execution, pages 1–6.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic

cash system. Decentralized Business Review.

O’Dwyer, K. J. and Malone, D. (2014). Bitcoin mining and

its energy footprint. IET.

Park, S., Kwon, A., Fuchsbauer, G., Ga

zi, P., Alwen, J.,

and Pietrzak, K. (2018). Spacemint: A cryptocurrency

based on proofs of space. In International Conference

on Financial Cryptography and Data Security, pages

480–499. Springer.

Pietrzak, K. (2018). Simple veriﬁable delay functions.

In 10th Innovations in Theoretical Computer Science

conference (ITCS 2019).

Polosukhin, I. and Skidanov, A. (2022). The near

white paper. Technical report, SweatCo Ltd.

Accessed: 2023-03-07 :https://near.org/papers/

the-ofﬁcial-near-white-paper/.

Saroiu, S. and Wolman, A. (2010). I am a sensor, and i

approve this message. In Proceedings of the Eleventh

Workshop on Mobile Computing Systems & Applica-

tions, pages 37–42.

Van Mensvoort, K., Just, L., Perlin, A., Blezer, K., Baart,

R., Rolfe, K., and Sijmons, P. (2015). The eco coin:

A cryptocurrency backed by sustainable assets. Tech-

nical report, Eco Coin.

Van Saberhagen, N. (2013). Cryptonote v 2.0.

Wesolowski, B. (2019). Efﬁcient veriﬁable delay functions.

In Annual International Conference on the Theory

and Applications of Cryptographic Techniques, pages

379–407. Springer.

Generic Blockchain on Generic Human Behavior

217