ArticlePDF Available

Hashcash - A Denial of Service Counter-Measure

  • Cypherspace


Hashcash was originally proposed as a mechanism to throttle systematic abuse of un-metered internet resources such as email, and anonymous remailers in May 1997. Five years on, this paper captures in one place the various applications, improvements suggested and related subsequent publications, and describes initial experience from experiments using hashcash.
Hashcash - A Denial of Service Counter-Measure
Adam Back
1st August 2002
Hashcash was originally proposed as a mechanism to throttle systematic abuse of un-metered internet resources
such as email, and anonymous remailers in May 1997. Five years on, this paper captures in one place the various
applications, improvements suggested and related subsequent publications, and describes initial experience from
experiments using hashcash.
The hashcash CPU cost-function computes a token which can be used as a proof-of-work. Interactive and non-
interactive variants of cost-functions can be constructed which can be used in situations where the server can issue
a challenge (connection oriented interactive protocol), and where it can not (where the communication is store–and–
forward, or packet oriented) respectively.
Key Words: hashcash, cost-functions
1 Introduction
Hashcash [1] was originally proposed as a mechanism to throttle systematic abuse of un-metered internet resources
such as email, and anonymous remailers in May 1997. Five years on, this paper captures in one place the various
applications, improvements suggested and related subsequent publications, and describes initial experience from ex-
periments using hashcash.
The hashcash CPU cost-function computes a token which can be used as a proof-of-work. Interactive and non-
interactive variants of cost-functions can be constructed which can be used in situations where the server can issue
a challenge (connection oriented interactive protocol), and where it can not (where the communication is store–and–
forward, or packet oriented) respectively.
At the time of publication of [1] the author was not aware of the prior work by Dwork and Naor in [2] who
proposed a CPU pricing function for the application of combatting junk email. Subsequently applications for cost-
functions have been further discussed by Juels and Brainard in [3]. Jakobsson and Juels propose a dual purpose for
the work spent in a cost-function: to in addition perform an otherwise useful computation in [4].
2 Cost-Functions
A cost-function should be efficiently verifiable, but parameterisably expensive to compute. We use the following
notation to define a cost-function.
In the context of cost-functions we use client to refer to the user who must compute a token (denoted ) using a
cost-function MINT() which is used to create tokens to participate in a protocol with a server. We use the term mint
for the cost-function because of the analogy between creating cost tokens and minting physical money.
The server will check the value of the token using an evaluation function VALUE(), and only proceed with the
protocol if the token has the required value.
The functions are parameterised by the amount of work that the user will have to expend on average to mint a
With interactive cost-functions, the server issues a challenge to the client – the server uses the CHAL function
to compute the challenge. (The challenge function is also parameterised by the work factor.)
CHAL server challenge function
MINT mint token based on challenge
VALUE token evaluation function
With non-interactive cost-functions the client choses it’s own challenge or random start value in the MINT() func-
tion, and there is no CHAL() function.
MINT mint token
VALUE token evaluation function
Clearly a non-interactive cost-function can be used in an interactive setting, whereas the converse is not possible.
2.1 Publicly Auditable, Probabilistic Cost
A publicly auditable cost-function can be efficiently verified by any third party without access to any trapdoor
or secret information. (When we say publicly auditable we mean implicitly that the cost-function is efficiently
publicly auditable compared to the cost of minting the token, rather than auditable in the weaker sense that the
auditor could repeat the work done by the client.)
A fixed cost cost-function takes a fixed amount of resources to compute. The fastest algorithm to mint a fixed
cost token is a deterministic algorithm.
A probabilistic costcost-functionis onewhere the cost to theclient ofminting a tokenhasa predictable expected
time, but a random actualtime as the client canmost efficientlycomputethe cost-function by starting ata random
start value. Sometimes the client will get lucky and start close to the solution.
There are two types of probabilistic cost bounded probabilistic cost and unbounded probabilistic cost.
An unbounded probabilistic cost cost-function, can in theory take forever to compute, though the proba-
blity of taking significantly longer than expected decreases rapidly towards zero. (An example would be
the cost-function of being required to throw a head with a fair coin; in theory the user could be unlucky
and end up throwing many tails, but in practice the probability of not throwing a head for throws tends
towards rapidly as .)
With a bounded probabilistic cost cost-function there is a limit to how unlucky the client can be in it’s
search for the solution; for example where the client is expected to search some key space for a known
solution; the size of the key space imposes an upper bound on the cost of finding the solution.
2.2 Trapdoor-free
A disadvantage of known solution cost-functions is that the challenger can cheaply create tokens of arbitrary value.
This precludes public audit where the server may have a conflict of interests, for example in web hit metering, where
the server may have an interest to inflate the number of hits on it’s page where it is being paid per hit by an advertiser.
A trapdoor-free cost-function is one where the server has no advantage in minting tokens.
An example of a trapdoor-free cost-function is the Hashcash [1] cost-function. Juels and Brainard’s client-puzzle
cost-function is an example of a known-solution cost-function where the server has an advantage in minting tokens.
Client-puzzles as specified in the paper are in addition not publicly auditable, though this is due to a storage optimiza-
tion and not inherent to their design.
3 The Hashcash cost-function
Hashcash is a non-interactive, publicly auditable, trapdoor-free cost function with unbounded probabilistic cost.
First we introduce some notation: consider bitstring , we define to means the bit at offset i, where
is the left-most bit, and is the right-most bit. means the bit-wise substring between and including bits
and , . So .
We define a binary infix comparison operator where b is the length of the common left-substring from the two
Hashcash is computed relative to a service-name , to prevent tokens minted for one server being used on another
(servers only accept tokens minted using their own service-name). The service-name can be any bit-string which
uniquely identifies the service (eg. host name, email address, etc).
The hashcash function is defined as (note this is an improved simplifed variant since initial publication see note in
section 5:
PUBLIC: hash function with output size bits
MINT find st
The hashcash cost-function is based on finding partial hash collisions on the all 0 bits -bit string . The fastest
algorithm for computing partial collisions is brute force. There is no challenge as the client can safely choose his
own random challenge, and so the hashcash cost-function is a trapdoor-free and non-interactive cost-function. In
addition the Hashcash cost-function is publicly auditable, because anyone can efficiently verify any published tokens.
(In practice should be chosen to be large enough to make the probability that clients reuse a previously used start
value negligible; bits should be enough even for a busy server.)
The server needs to keep a double spending database of spent tokens, to detect and reject attempts to spend the
same token again. To prevent the database growing indefinitely, the service string can include the time at which it was
minted. This allows the server to discard entries from the spent database after they have expired. Some reasonable
expiry period should be chosen to take account of clock inaccuracy, computation time, and transmission delays.
Hashcash was originally proposed as a counter-measure against email spam, and against systematic abuse of
anonymous remailers. It is necessary to use non-interactive cost-functions for these scenarios as there is no channel
for the server to send a challenge over. However one advantage of interactive cost-functions is that it is possible
to prevent pre-computation attacks. For example, if there is a cost associated with sending each email this may be
sufficient to limit the scale of email abuse perpetrated by spammers; however for a pure DoS-motivated attack a
determined adversary may spend a year pre-computing tokens to all be valid on the same day, and on that day be able
to temporarily overload the system.
It would be possible to reduce the scope for such pre-computation attacks by using a slowly changing beacon
(unpredictable broadcast authenticated value changing over time) such as say this weeks winning lottery numbers. In
this event the current beacon value is included in the start string, limiting pre-computation attacks to being conducted
within the time period between beacon value changes.
4 Interactive Hashcash
With the interactive form of hashcash, for use in interactive settings such as TCP, TLS, SSH, IPSEC etc connection
establishment a challenge is chosen by the server. The aim of interactive hashcash is to defend server resources from
premature depletion, and provide graceful degradation of service with fair allocation across users in the face of a DoS
attack where one user attempts to deny service to the other users by consuming as many server resources as he can. In
the case of security protocols such as TLS, SSH and IPSEC with computationally expensive connection establishment
phases involving public key crypto the server resource being defended is the servers available CPU time.
The interactive hashcash cost-function is defined as follows:
CHAL choose
MINT find st
4.1 Dynamic throttling
With interactive hashcash it becomes possible to dynamically adjust the work factor required for the client based on
server CPU load. The approach also admits the possibility that interactive hashcash challenge-response would only
be used during periods of high load. This makes it possible to phase-in DoS resistent protocols without breaking
backwards compatibility with old client software. Under periods of high load non-hashcash aware clients would be
unableto connect, or would beplaced ina limited connection pool subject toolderless effective DoS counter-measures
such as random connection dropping.
4.2 hashcash-cookies
With connection-slot depletion attacks such as the syn-flood attack, and straight-forward TCP connection-slot deple-
tion the server resource that is being consumed is space available to the TCP stack to store per-connection state.
In this scenario it may be desirable to avoid keeping per connection state, until the client has computed a token
with the interactive hashcash cost-function. This defense is similar to the syn-cookie defense to the syn-flood attack,
but here we propose to additionally impose a CPU cost on the connecting machine to reserve a TCP connection-slot.
To avoid storing the challenge in the connection state (which itself consumes space) the server may choose to
compute a keyed MAC of the information it would otherwise store and sent it to the client as part of the challenge so
it can verify the authenticity of the challenge and token when the client returns them. (This general technique of
sending a record you would otherwise store together with a MAC to the entity the information is about is referred
to as a symmetric key certificate.) This approach is analogous to the technique used in syn-cookies, and Juels and
Brainard proposed a related approach but at the application protocol level in their client-puzzles paper.
For example with MAC function keyed by server key the challenge MAC could be computed as:
PUBLIC: MAC function
CHAL choose
The client must send the MAC , and the challenge and challenge parameters with the response token so
that the server can verify the challenge and the response. The server should also include in the MAC the connection
parameters, at minimum enough to identify the connection-slot and some time measurement or increasing counter
so that old challenge responses can not be collected and re-used after the connection-slots are free. The challenge and
MAC would be sent in the TCP SYN-ACK response message, and the client would include the interactive hashcash
token (challenge-response) in the TCP ACK message. As with syn-cookies, the server would not need to keep any
state per connection prior to receiving the TCP ACK.
For backwards compatibility with syn-cookie aware TCP stacks, a hashcash-cookie aware TCP stack would only
turn on hashcash-cookies when it detected that it was subject to a TCP connection-depletion attack. Similar arguments
as given by Dan Bernstein in [5] can be used to show that backwards compatibility is retained, namely under syn-flood
attacks Bernstein’s arguments show how to provide backwards compatibility with non syn-cookie aware implementa-
tions; similarly under connection-depletion attack hashcash-cookies are only turned on at a point where service would
anyway otherwise be unavailable to a non-hashcash-cookie aware TCP stack.
As the flood increases in severity the hashcash-cookie algorithm would increase the collision size required to be in
the TCP ACK message. The hashcash-cookie aware client can still connect (albeit increasinly slowly) with a more fair
chance against the DoS attacker presuming the DoSer has limited CPU resources. The DoS attacker will effectively
be pitting his CPU against all the other (hashcash-cookie aware) clients also trying to connect. Without the hashcash-
cookie defense the DoSer can flood the server with connection establishments and can more easily tie up all it’s slots
by completing n connections per idle connection time-out where n is the size of the connection table, or pinging the
connections once per idle connection time-out to convince the server they are alive.
Connections will be handed out to users collectively in rough proportion to their CPU resources, and so fairness is
CPU resource based (presuming each user is trying to open as many connections as he can) so the result will be biased
in favor of clients with fast processors as they can compute more interactive-hashcash challenge-response tokens per
5 Hashcash improvements
In the initially published hashcash scheme, the target string to find a hash collision on was chosen fairly by using the
hash of the service-name (and respectively the service-name and challenge in the interactive setting). A subsequent
improvement suggested independently by Hal Finney [6] and Thomas Boschloo [7] for hashcash is to find a collision
against a fixed output string. Their observation is that a fixed collision target is also fair, simpler and reduces verifica-
tion cost by a factor of 2. A fixed target string which is convenient to compare trial collisions against is the k-bit string
where is the hash output size.
6 Low Variance
Ideallycost-functiontokens should takea predictable amount of computingresources tocompute. Juels andBrainard’s
client-puzzle construction provides a probabilistic bounded-cost by issuing challenges with known-solutions, however
while this limits thetheoretical worst case runningtime, itmakes limited practicaldifference to the variance andtypical
experienced running time. The technique of using known solutions is also not applicable to the non-interactive setting.
It is an open question as to whether there exist probabilistic bounded-cost, or fixed-cost non-interactive cost-functions
with the same order of magnitude of verification cost as hashcash.
The other more significant incremental improvement due to Juels and Brainard is the suggestion to use multiple
sub-puzzles with the same expected cost, but lower variance in cost. This technique should be applicable to both the
non-interactive and interactive variants of hashcash.
6.1 Non-Parallelizability and Distributed DoS
Roger Dingledine, Michael Freedman and David Molnar put forward the argument that non-parallelizable cost-
functions are less vulnerable to Distributed DoS (DDoS) in chapter 16 of [8]. Their argument is that non-parallelizable
cost-functions frustrate DDoS because the attacker is then unable sub-divide and farm out the work of computing an
individual token.
The author described a fixed-cost cost-function in [9] using Rivest, Shamir and Wagner’s time-lock puzzle [10]
which also happens to be non-parallelizable. The time-lock puzzle cost-function can be used in either an interactive
or non-interactive setting as it is safe for the user to chose their own challenge. The applicability of Rivest et al’s
time-lock puzzle as a cost-function was also subsequently observed by Dingledine et al in [8].
For completeness we present the time-lock puzzle based fixed-cost and non-parallelizable cost-function from [9]
PRIVATE: primes and
CHAL choose
MINT compute
VALUE compute
if return
else return
The client does not know , and so the most efficient method for the client to calculate MINT() is repeated
exponentiation, which requires exponentiations. The challenger knows which allows a more efficient compu-
tation by reducing the exponent , so the challenger can execute VALUE() with 2 modular exponentiations.
The challenger as a side-effect has a trapdoor in computing the cost-function as he can compute MINT() efficiently
using the same algorithm.
We argue however that the added DDoS protection provided by non-parallelizable cost-functions is marginal:
unless the server restricts the number of challenges it hands out to a recognizably unique client the DDoS attacker can
farm out multiple challenges as easily as farmout a sub-divided single challenge, and consume resources on the server
at the same rate as before. Further it is not that hard for a single client to masquerade as multiple clients to a server.
Consider also: the DDoS attacker has generally due to the nature of his method of commandeering nodes an equal
number of network connected nodes at his disposal as processors. He can therefore in any case have each attack
node directly participate in the normal protocol indistinguisably from any legitimate user. This attack strategy is also
otherwise optimal anyway as the attack nodes will present a varied set of source addresses which will foil attempts
at per-connection fairness throttling strategies and router based DDoS counter-measures based on volume of traffic
across IP address ranges. Therefore for the natural attack node marshalling patterns non-parallelizable cost-functions
offer limited added resistance.
As well as the arguments against the practical efficacy and value of non-parallelizable cost-functions, to date
non-parallelizable cost functions have had orders of magnitude slower verification functions than non-parallelizable
cost-functions. This is because thenon-parallelizablecost-functions so far discussedin theliterature are related to trap-
door public key cryptography constructs which are inherently less efficient. It is an open question as to whether there
exist non-parallelizable cost-functions based on symmetric-key (or public-key) constructs with verification functions
of the same order of magnitude as those of symmetric-crypto based cost-functions.
While for the application of time-lock puzzles to cost-functions, a reduced public key size could be used to speed
up the verification function, this approach introduces risk that the modulus will be factored with the result that the
attacker gains a big advantage in minting tokens. (Note: factoring is itself a largely parallelizable computation.)
To combat this the server should change the public parameters periodically. However in the particular case of the
public parameters used by time-lock puzzles (which are the same as the RSA modulus used in RSA encryption), this
operation is itself moderately expensive, so this operation would not be performed too frequently. It would probably
not be wise to deploy software based on key sizes below 768 bits for this aplication, in addition it wouldhelp to change
keys periodically, say every hour or so. (RSA modulii of 512 bits have recently been factored by a closed group as
discussed in [11] and more recently have been demonstrated by Nicko van Someren et al to be factorizable using
standard equipment in an office as reported in [12]; DDoS attackers are known be able to muster significant resources,
probably easily exceeding those used in this demonstration.)
The time-lock puzzle cost-function also is necessarily trap-door as the server needs a private verification-key to
allow it to efficiently verify tokens. The existance of a verification-key presents the added risk of key compromise
allowing the attacker to by-pass the cost-function protection. (The interactive hashcash cost-function by comparison
is trap-door-free, so there is no key which would allow an attacker a short-cut in computing tokens). In fact if the
verification-key were compromised, it could be replaced, but this need adds complexity and administrative overhead
as this event needs to be detected and manual intervention or some automated detection triggering key-replacement
The time-lock puzzle cost-function also will tend to have larger messages as there is a need to communicate
planned and emergency re-keyed public parameters. For some applications, for example the syn-cookie and hashcash-
cookie protocols, space is at a premium due to backwards compatibility and packet size constraints imposed by the
network infrastructure.
So in summary we argue that non-parallelizable cost-functions are of questionable practical value in protecting
against DDoS attacks, have more expensive verification functions, incur the risk of verification key compromise and
attendant key management complexities, have larger messages, and are significantly more complex to implement. We
therefore recommend instead the simpler hashcash protocol (or if the public-auditability and non-interactive options
are not required Juels and Brainards client-puzzles are roughly equivalent).
7 Applications
Apart from the initially proposed applications for hashcash of throttling DoS against remailer networks and detering
email spam, since publicationthe followingapplications havebeen discussed, explored and insome cases implemented
and deployed:
hashcash-cookies, a potential extension of the syn-cookie as discussed in section 4.2 for allowing more graceful
service degradation in the face of connection-depletion attacks.
interactive-hashcash as discussed in section 4 for DoS throttling and graceful service degradation under CPU
overload attacks on security protocols with computationally expensive connection establishment phases. No
deployment but the analogous client-puzzle system was implemented with TLS in [13]
hashcash throttling of DoS publication floods in anonymous publication systems such as Freenet [14], Publius
[15], Tangler [16],
hashcash throttling of service requests in the cryptographic Self-certifying File System [17]
hashcash throttling of USENET flooding via mail2news networks [18]
hashcash as a minting mechanism for Wei Dai’s b-money electronic cash proposal, an electronic cash scheme
without a banking interface [19]
8 Cost-function classification scheme
We list here a classification of characteristics of cost-functions. We use the following notation to denote the properties
of a cost-function:
Where is theefficiency: value means efficiently-verifiable verifiablewithcost comparable to orlowerthan
the cost of verifying symmetric key constructs such as hashcash which consume just a single compression round of an
iterative compression function based hash function such as SHA1 or MD5. Value
means practically-verifiable
we mean less efficiently than efficienty-verifiable, but still efficient enough to be practical for some applications, for
example the author considers the time-lock puzzle based cost-function with it’s two modular exponentiations to fall
into this category. Value means verifiable but impractical, that the cost-function is verifiable but the verification
function is impractically slow such that the existance of the cost-function serves only as a proof of concept to be
improved upon for practical use.
And is a characterization of the standard-deviation, value means fixed-cost, means bounded
probabilistic cost and means unbounded probabilistic cost. Note by bounded probabilistic-cost we mean
usefully bounded a bound in the work factor in excess of a work-factor that an otherwise functionally similar
unbounded cost-function would only reach with negligible probability would not be useful.
And denotes that the cost-function is interactive, and that the cost-function is non-interactive.
And denotes that the cost-function is publicly auditable, denotes that the cost-functionis not publicly auditable,
which means inpractice thatit is only verifiable by the serviceusing a private key material. Note bypublic-auditability
we mean efficiently publicly-auditable, and would not consider repeating the work of the token minter as adequate
efficiency to classify.
And denotes that the server has a trapdoor in computing the cost-function, conversely denotes that server has
no trapdoor in computing the cost-function.
And denotes that the cost-function is parallelizable, deontes that the cost-function is non-parallelizable.
trapdoor-free trapdoor
interactive hashcash client-puzzles
non-interactive hashcash
8.1 Open Problems
existance of efficiently-verifiable non-interactive fixed-cost cost-functions (and the related
weaker problem: existance of same with probabilistic bounded-cost )
existance of efficiently-verifiable non-interactive non-parallelizable cost-functions (and the related
weaker problem: existance of same in interactive setting )
existance of publicly-auditable non-interactive fixed-cost cost-functions (and the related weaker
problem: existance of same with bounded probabilistic-cost )
[1] Adam Back. Hashcash, May 1997. Published at
[2] Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In Proceedings of Crypto,
1992. Also available as
[3] Ari Juels and John Brainard. Client puzzles: A cryptographic countermeasure against connection depletion
attacks. In Network and Distributed System Security Symposium, 1999. Also available as http://www.
[4] Markus Jakobsson and Ari Juels. Proofs of work and bread pudding protocols. In Proceedings of the IFIP TC6
and TC11 Joint Working Conference on Communications and Multimedia Security (CMS ’99), Leuven, Belgium,
September 1999. Also available as
[5] Dan Bernstein. Syn cookies. Published at
[6] Hal Finney. Personal communication, Mar 2002.
[7] Thomas Boschloo. Personal communication, Mar 2002.
[8] Andy Oram, editor. Peer-to-Peer: Harnessing the Power of Disruptive Technologies. O’Reilly
and Associates, 2001. Chapter 16 also available as
[9] Adam Back. Hashcash - amortizable publicly auditable cost functions. Early draft of paper, 2000.
[10] Ronald L Rivest, Adi Shamir, and David A Wagner. Time-lock puzzles and timed-release crypto. Tech-
nical Report MIT/LCS/TR-684, 1996. Also available as˜rivest/
[11] Herman te Riele. Security of e-commerce threatened by 512-bit number factorization. Published at http:
//˜kik/persb-UK.html, Aug 1999.
[12] Dennis Fisher. Experts debate risks to crypto, Mar 2002. Also available as
[13] Drew Dean and Adam Stubblefield. Using cleint puzzles to protect tls. In Proceedings of the 10th USENIX
Security Symposium, Aug 2001. Also available as˜astubble/papers.
[14] Ian Clarke, OskarSandberg, Brandon Wiley, andTheodore Hong. Freenet: A distributedanonymous information
storage and retrieval system. In Hannes Federrath, editor, Proceedings of the International Workshop on Design
Issues in Anonymity and Unobservability. Springer, 2001. Also available as http://freenetproject.
[15] Marc Waldman, Aviel D Rubin, and Lorrie Faith Cranor. Publius: A robust, tamper-evident, censorship-
resistant web publishing system. In Proceedings of the 9th USENIX Security Symposium, Aug 2000.
Also available as
[16] Marc Waldman and David Mazieres. Tangler: A censorship resistant publishing system based on document
entanglement. In Proceedings of the 8th ACM Conference on Computer and Communication Security, Nov
2001. Also available as˜waldman/.
[17] David Mazieres. Self-certifying File System. PhD thesis, Massachusetts Institute of Technology, May 2000. Also
available as˜dm/.
[18] Alex de Joode. Hashcash support at dizum mail2news gateway. Published at
hashcash/, 2002.
[19] Wei Dai. b-money. Published at˜weidai/bmoney.txt, Nov 1998.
... In our citation network, the node for [37] is prominent, highlighting Bitcoin's white paper's critical influence on DLT [53,67]. Other key nodes include Hashcash, a 2002 PoW system combating E-mail spam, which inspired Bitcoin [4], and Ethereum's 2014 whitepaper (a) Filter for papers below the 10th percentile of total numbers of tokens. ...
... The increase in papers with high Consensus content density points to the research into consensus algorithms and blockchain architectures that are more efficient, scalable, and secure (e.g., research into Byzantine Fault Tolerance, etc.) (Figure 4b). The late 1990s and early 2000s saw PoW emerge as a named entity, aligning with the foundational work of [4], and its prominence surged post-2010, postdating Bitcoin's whitepaper. Examining the citation network reveals a rising academic interest in ESG and consensus-related terms in recent years (Figure 7b and Figure 7a). ...
Full-text available
Distributed Ledger Technologies (DLTs) have rapidly evolved, necessitating comprehensive insights into their diverse components. However, a systematic literature review that emphasizes the Environmental, Sustainability, and Governance (ESG) components of DLT remains lacking. To bridge this gap, we selected 107 seed papers to build a citation network of 63,083 references and refined it to a corpus of 24,539 publications for analysis. Then, we labeled the named entities in 46 papers according to twelve top-level categories derived from an established technology taxonomy and enhanced the taxonomy by pinpointing DLT's ESG elements. Leveraging transformer-based language models, we fine-tuned a pre-trained language model for a Named Entity Recognition (NER) task using our labeled dataset. We used our fine-tuned language model to distill the corpus to 505 key papers, facilitating a literature review via named entities and temporal graph analysis on DLT evolution in the context of ESG. Our contributions are a methodology to conduct a machine learning-driven systematic literature review in the DLT field, placing a special emphasis on ESG aspects. Furthermore, we present a first-of-its-kind NER dataset, composed of 54,808 named entities, designed for DLT and ESG-related explorations.
... At the heart of Bitcoin [15] is the Nakamoto consensus protocol, which is based on proof-ofwork [7,12,1]. The system participants, called miners, maintain a ledger that records all transactions-payments or so-called smart-contract operations. ...
... For example, under some minimal modeling assumptions, even a coalition that controls 1/4 of the computational power can increase its reward by deviating from the Nakamoto Consensus protocol. 1 Stated differently, the Nakamoto consensus protocol is not a coalition-resistant equilibrium if there are coalitions that control more than 1/4 of the mining power. ...
Full-text available
We present Colordag, a blockchain protocol where following the prescribed strategy is, with high probability, a best response as long as all miners have less than 1/2 of the mining power. We prove the correctness of Colordag even if there is an extremely powerful adversary who knows future actions of the scheduler: specifically, when agents will generate blocks and when messages will arrive. The state-of-the-art protocol, Fruitchain, is an epsilon-Nash equilibrium as long as all miners have less than 1/2 of the mining power. However, there is a simple deviation that guarantees that deviators are never worse off than they would be by following Fruitchain, and can sometimes do better. Thus, agents are motivated to deviate. Colordag implements a solution concept that we call epsilon-sure Nash equilibrium and does not suffer from this problem. Because it is an epsilon-sure Nash equilibrium, Colordag is an epsilon Nash equilibrium and with probability (1 - epsilon) is a best response.
... However, this protocol prone to system vulnerabilities such as malicious behavior, potential cyber-attacks, and collusion. For instance, PoW (Back, 2002) algorithm is using intensive energy to validate transactions but finality may not be suitable for certain use cases (Pilkington, 2015). While, PoS (Castor, 2017) algorithm allows validators to simultaneously create blocks in multiple chains and automatically deducting coins owned or deposited. ...
Full-text available
Current military supply chain management is complex and complicated. Activities such as information, and knowledge sharing among involved parties are prone to cybercriminal. Protection of such private and confidential documents are very important. Therefore, a military supply chain derives a critical need for decentralized and digitize transactions in the ledger. This study is proposing a new traceability chain algorithm for military shipment using blockchain. The development of this traceability chain algorithm is based on algorithm development methodology. The new traceability chain algorithm is expected to trace product movement along with the blockchain network. In addition, it is also believed that this study will provide positive results for defense shipment. Future work is to broaden the scope to other military areas such as threat intelligence.
... hash) funkcija, što ih čini jako otpornim na bilo kakav vid izmene nakon što se blok upiše u lanac. Najpoznatiji predstavnik ove tehnologije je Bitcoin [3], koji uspostavlja konsenzus na osnovu algoritama baziranih na lutriji, poput dokaza posla [4]. ...
Full-text available
U ovom radu će biti predstavljena distribuirana platforma za federativno učenje, zasnovana na razdeljenom blokčejn rešenju. Takođe, biće predstav­ljene i teorijske osnove koje stoje iza dva glavna aspekta platforme, federativnog učenja i tehnologija distribuirane glavne knjige.
... Bitcoin leverages the Hashcash algorithm [43], which entails the miners competing to validate a block by solving a hash puzzle. Miners compete to find the nonce value that meets the target difficulty. ...
Full-text available
The rise of computational power has led to unprecedented performance gains for deep learning models. As more data becomes available and model architectures become more complex, the need for more computational power increases. On the other hand, since the introduction of Bitcoin as the first cryptocurrency and the establishment of the concept of blockchain as a distributed ledger, many variants and approaches have been proposed. However, many of them have one thing in common, which is the Proof of Work (PoW) consensus mechanism. PoW is mainly used to support the process of new block generation. While PoW has proven its robustness, its main drawback is that it requires a significant amount of processing power to maintain the security and integrity of the blockchain. This is due to applying brute force to solve a hashing puzzle. To utilize the computational power available in useful and meaningful work while keeping the blockchain secure, many techniques have been proposed, one of which is known as Proof of Deep Learning (PoDL). PoDL is a consensus mechanism that uses the process of training a deep learning model as proof of work to add new blocks to the blockchain. In this paper, we survey the various approaches for PoDL. We discuss the different types of PoDL algorithms, their advantages and disadvantages, and their potential applications. We also discuss the challenges of implementing PoDL and future research directions.
A Blockchain network consists of a distributed ledger and a set of nodes participating in the network. The consistency in the ledger’s state is maintained by a Blockchain consensus mechanism. This property is essential since it is assumed that the participants in the network do not trust each other. Most Blockchain consensus algorithms are unsuitable for resource-constrained nodes due to their power consumption, storage, network overhead, and computation requirements. Furthermore, many consensus methods do not address the issue of data accountability, which guarantees that an entity will be judged on its performance or conduct concerning a duty they have taken. This study proposes a novel consensus mechanism termed Proof of Block Height ( PoBH ) that prioritizes accountability for reporting IoT data transactions and considers factors such as low computation cost and energy consumption. The approach relies on a pre-existing comparable deterministic value based on the height of the committed blocks. The model identifies a malicious intent using a set of predicates and consequently incurs a computation penalty to keep such nodes away from the network. As a preventive measure, the model also seeks to increment this penalty appropriately by making the network free from dishonest nodes for as long as possible, thus sanitizing the network. Importantly, the developed method does not augment the basic hierarchy of an IoT network. A formal analysis of the mechanism’s operation shows that the resource and time required to cheat the system grows exponentially with the number of faulty blocks a node tries to append to the shared ledger. The factors affecting the mechanism’s performance, scalability, and effort required (by malicious nodes) to stay within the network are also quantitatively evaluated.
Full-text available
In some situations, the transfer of authentication authority is necessary for user authentication. In traditional authentication, a trust mechanism based on a trusted party establishes trust between two unfamiliar entities. However, a trusted party's failure or malicious behavior could undermine the trust system. Additionally, traditional authentication methods often involve complex and time-consuming procedures and may incur high costs. With the advancement of technology, more decentralized authentication methods and blockchain-based identity verification solutions have been proposed to address these limitations and enhance the security and efficiency of trust establishment. There are still cases where the number of transfers of their authentication authority should be limited for authentication in blockchain networks. Meanwhile, an authentication scheme consisting only of efficient operations such as hash functions is desirable. However, to the best of our knowledge, blockchain networks have no authentication schemes that consist of only hash functions and allow the transfer of authentication authority. In this paper, we propose an efficient authentication scheme based on only a hash function that can limit the number of times authentication authority can be transferred by using hash chains and Hashcash techniques in a blockchain network. As a result, our scheme has the advantage of reducing the computational complexity and gas costs in smart contracts. Furthermore, we deployed the smart contracts on the Goerli test network and completed authentication, proving the solution's effectiveness. On the Goerli testnet, our smart contract consumed 304.6kgas when deployed and 29.9kgas when performing authentication.
Full-text available
Green marketing is an undeniable fact that has grown in prominence in today's market. This concept has enabled the re-marketing and packaging of existing products in environmentally friendly materials in accordance with the guidelines. Furthermore, the advancement of green marketing has created opportunities for companies to create a g-brand (co brand), brand of their products into a separate line, lauding the green-friendliness of some products while ignoring that of others. Such marketing techniques will be explained as a direct result of consumer market movement. As a result, business men have increased their rate of targeting environmentally conscious consumers. Through their concern, these same consumers are interested in incorporating environmental issues into their purchasing decisions by incorporating them into the process and content of the marketing strategy for whatever product is required. In this chapter we discuss how it is critical for a company to fulfil its corporate responsibility and how businesses have increased their rate of targeting green consumers, those who are concerned about the environment and allow it to influence their purchasing decisions. It also examines the current trends of green marketing in India and describes why companies are adopting it, what are the compulsions for business organizations to go green as well as the future of green marketing, concluding that green marketing will continue to grow in both practice and demand.
Full-text available
We present a distributed efficiently amortizable CPU cost-function with no trap--door. The absence of a trap--door allows us to avoid needing to trust any party.
Conference Paper
ABSTRACT We describe the design of a censorship-resistant system that em- ploys a unique document,storage mechanism.,Newly published documents,are dependent,on the blocks of previously published documents. We call this dependency,an entanglement. Entangle- ment makes replication of previously published content an intrinsic part of the publication process. Groups of files, called collections, can be published together and named,in a host-independent manner. Individual documents,within a collection can be securely updated in such a way that future readers of the collection see and tamper- check the updates. The system employs,a self-policing network of servers designed to eject non-compliant servers and prevent them from doing more harm than good.
Conference Paper
We formalize the notion of a proof of work (POW). In many cryptographic protocols, a prover seeks to convince a verifier that she possesses knowledge of a secret or that a certain mathematical relation holds true. By contrast, in a POW, a prover demonstrates to a verifier that she has performed a certain amount of computational work in a specified interval of time. POWs have served as the basis of a number of security protocols in the literature, but have hitherto lacked careful characterization. In this paper, we offer definitions treating the notion of a POW and related concepts. We also introduce the dependent idea of a bread pudding protocol. Bread pudding is a dish that originated with the purpose of reusing bread that has gone stale. In the same spirit, we define a bread pudding protocol to be a POW such that the computational effort invested in the proof may be reused by the verifier to achieve a separate, useful, and verifiably correct computation. As an example of a bread pudding protocol, we show how the MicroMint scheme of Rivest and Shamir can be broken up into a collection of POWs. These POWs can not only serve in their own right as mechanisms for security protocols, but can also be harvested in order to outsource the MicroMint minting operation to a large group of untrusted computational devices.
Conference Paper
We present a computational technique for combatting junk mail, in particular, and controlling access to a shared resource, in general. The main idea is to require a user to compute a moderately hard, but not intractable, function in order to gain access to the resource, thus preventing frivolous use. To this end we suggest several pricing functions, based on, respectively, extracting square roots modulo a prime, the Fiat-Shamir signature scheme, and the Ong-Schnorr-Shamir (cracked) signature scheme.
Conference Paper
Client puzzles are commonly proposed as a solution to denial-of-service attacks. However, very few implemen- tations of the idea actually exist, and there are a num- ber of subtle details in the implementation. In this pa- per, we describe our implementation of a simple and backwards compatible client puzzle extension to TLS. We also present measurements of CPU load and latency when our modified library is used to protect a secure webserver. These measurements show that client puz- zles are a viable method for protecting SSL servers from SSL based denial-of-service attacks.
Our motivation is the notion of "timed-release crypto", where the goal is to encrypt a message so that it can not be decrypted by anyone, not even the sender, until a pre-determined amount of time has passed. The goal is to "send information into the future." This problem was first discussed by Timothy May [6]. What are the applications of "timed-release crypto"? Here are a few possibilities (some due to May): -- A bidder in an auction wants to seal his bid so that it can only be opened after the bidding period is closed. -- A home owner wants to give his mortgage holder a series of encrypted mortgage payments. These might be encrypted digital cash with different decryption dates, so that one payment becomes decryptable (and thus usable by the bank) at the beginning of each successive month. -- An individual wants to encrypt his diaries so that they are only decryptable after fifty years. -- A key-escrow scheme can be based on timed-release crypto, so that the government can get...
We describe a system that we have designed and implemented for publishing content on the web. Our publishing scheme has the property that it is very di#cult for any adversary to censor or modify the content. In addition, the identity of the publisher is protected once the content is posted. Our system di#ers from others in that we provide tools for updating or deleting the published content, and users can browse the content in the normal point and click manner using a standard web browser and a client-side proxy that we provide. All of our code is freely available. 1