ethword deploying payword on ethereum - ifca · 2019-03-01 · on ethereum. 2 2 of 0 1980 1985 1990...
TRANSCRIPT
M. Elsheikh Amr Youssef Jeremy Clark
EthWord Deploying PayWord on Ethereum
acmqueue | july-august 2017 2
2 OF 30
1980
1985
1990
1995
2000
2005
2010
2015
smartcontracts
publickeys as
identitiesByzantinefault
toleranceproofof workdigital
cash
MerkleTree [33]
Haber &Stornetta [22]
Haber &Stornetta [23]
Benaloh &de Mare [6]
Bayer, Haber,
Stornetta [5]
Ecash [10]
anti-spam[15]
hashcash [2]Micro-mint [44]
clientpuzzles
[25]
offlineEcash [32]
DigiCash
Byzantine
Generals [27]
Paxos [28]
PBFT [8]
Paxos madesimple [29]
computational
impostors [1]
Chaum
anonymous
communication[9]
Chaum
security w/o
identification[11]
b-money [13]
Bit gold [42]
privateblockchains
Bitcoin [34]
Ethereum
Szaboessay [41]
Goldbergdisser-tation [20]
Sybil attack[14]
Nakamoto concensus
linked
timestamping,
verifiable logs
FIGURE 1: Chronology of key ideas found in Bitcoin
cryptocurrency
Pre-Bitcoin Post-Bitcoin
Auditable, anonymous electronic cash [Sander & Ta-Shma]
Zerocoin, etc[Miers et al]
Lottery Payments [Rivest] [Wheeler] [Jarecki & Odlyzko]
Micropayments for decentralized currencies [Pass, shelat]
An efficient distributed currency [Laurie]
RSCoin [Danezis & Meiklejohn]
Pre-Bitcoin Post-Bitcoin
Auditable, anonymous electronic cash [Sander & Ta-Shma]
Zerocoin, etc[Miers et al]
Lottery Payments [Rivest] [Wheeler] [Jarecki & Odlyzko]
Micropayments for decentralized currencies [Pass, shelat]
An efficient distributed currency [Laurie]
RSCoin [Danezis & Meiklejohn]
PayWord[Rivest & Shamir]
Pre-Bitcoin Post-Bitcoin
Auditable, anonymous electronic cash [Sander & Ta-Shma]
Zerocoin, etc[Miers et al]
Lottery Payments [Rivest] [Wheeler] [Jarecki & Odlyzko]
Micropayments for decentralized currencies [Pass, shelat]
An efficient distributed currency [Laurie]
RSCoin [Danezis & Meiklejohn]
PayWord[Rivest & Shamir]
EthWord[You are here]
PayWord and MicroMint:
Two Simple Micropayment Schemes
Ronald L. Rivest 1 and Adi Shamir 2
1 MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Mass.
02139, rivest @theory.lcs.mit.edu
2 Weizmann Institute of Science, Applied Mathematics Department, Rehovot, Israel,
1 I n t r o d u c t i o n
~Ve present two simple micropayment schemes, "PayWord" and :'MicroMint,"
for making small purchases over the Internet. We were inspired to work on this
problem by DEC's "Millicent" scheme[10]. Surveys of some electronic payment
schemes can be found in Hallam-Baker [6], Schneier[16], and Wayner[18].
Our main goal is to minimize the number of public-key operations required
per payment, using hash operations instead whenever possible. As a rough guide,
hash functions are about 100 times faster than RSA signature verification, and
about 10,000 times faster than RSA signature generation: on a typical worksta-
tion, one can sign two messages per second, verify 200 signatures per second,
and compute 20,000 hash function values per second.
To support micropayments, exceptional efficiency is required, otherwise the
cost of the mechanism will exceed the value of the payments. As a consequence,
our micropayment schemes are light-weight compared to full macropayment
schemes. We "don't sweat the small stuff": a user who loses a micropayment
is similar to someone who loses a nickel in a candy machine. Similarly, candy
machines aren't built with expensive mechanisms for detecting forged coins, and
yet they work well in practice, and the overall level of abuse is low. Large-scale
and/or persistent fraud must be detected and eliminated, but if the scheme de-
livers a volume of payments to the right parties that is roughly correct, we're
happy.
In our schemes the players are brokers, users, and vendors. Brokers authorize
users to make micropayments to vendors, and redeem the payments collected
by the vendors. While user-vendor relationships are transient, broker-user and
broker-vendor relationships are long-term. In a typical transaction a vendor sells
access to a World-Wide Web page for one cent. Since a user may access only a few
pages before moving on, standard credit-card arrangements incur unacceptably
high overheads.
The first scheme, "PayWord," is a credit-based scheme, based on chains of
"paywords" (hash values). Similar chains have been previously proposed for dif-
ferent purposes: by Lamport [9] and Haller (in S/Key) for access control [7],
and by Winternitz [11] as a one-time signature scheme. The application of this
Two Simple Micropayment Schemes
PayWord and MicroMint:
Two Simple Micropayment Schemes
Ronald L. Rivest 1 and Adi Shamir 2
1 MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Mass.
02139, rivest @theory.lcs.mit.edu
2 Weizmann Institute of Science, Applied Mathematics Department, Rehovot, Israel,
1 I n t r o d u c t i o n
~Ve present two simple micropayment schemes, "PayWord" and :'MicroMint,"
for making small purchases over the Internet. We were inspired to work on this
problem by DEC's "Millicent" scheme[10]. Surveys of some electronic payment
schemes can be found in Hallam-Baker [6], Schneier[16], and Wayner[18].
Our main goal is to minimize the number of public-key operations required
per payment, using hash operations instead whenever possible. As a rough guide,
hash functions are about 100 times faster than RSA signature verification, and
about 10,000 times faster than RSA signature generation: on a typical worksta-
tion, one can sign two messages per second, verify 200 signatures per second,
and compute 20,000 hash function values per second.
To support micropayments, exceptional efficiency is required, otherwise the
cost of the mechanism will exceed the value of the payments. As a consequence,
our micropayment schemes are light-weight compared to full macropayment
schemes. We "don't sweat the small stuff": a user who loses a micropayment
is similar to someone who loses a nickel in a candy machine. Similarly, candy
machines aren't built with expensive mechanisms for detecting forged coins, and
yet they work well in practice, and the overall level of abuse is low. Large-scale
and/or persistent fraud must be detected and eliminated, but if the scheme de-
livers a volume of payments to the right parties that is roughly correct, we're
happy.
In our schemes the players are brokers, users, and vendors. Brokers authorize
users to make micropayments to vendors, and redeem the payments collected
by the vendors. While user-vendor relationships are transient, broker-user and
broker-vendor relationships are long-term. In a typical transaction a vendor sells
access to a World-Wide Web page for one cent. Since a user may access only a few
pages before moving on, standard credit-card arrangements incur unacceptably
high overheads.
The first scheme, "PayWord," is a credit-based scheme, based on chains of
"paywords" (hash values). Similar chains have been previously proposed for dif-
ferent purposes: by Lamport [9] and Haller (in S/Key) for access control [7],
and by Winternitz [11] as a one-time signature scheme. The application of this
HashX Y
Hash
PayWord and MicroMint:
Two Simple Micropayment Schemes
Ronald L. Rivest 1 and Adi Shamir 2
1 MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Mass.
02139, rivest @theory.lcs.mit.edu
2 Weizmann Institute of Science, Applied Mathematics Department, Rehovot, Israel,
1 I n t r o d u c t i o n
~Ve present two simple micropayment schemes, "PayWord" and :'MicroMint,"
for making small purchases over the Internet. We were inspired to work on this
problem by DEC's "Millicent" scheme[10]. Surveys of some electronic payment
schemes can be found in Hallam-Baker [6], Schneier[16], and Wayner[18].
Our main goal is to minimize the number of public-key operations required
per payment, using hash operations instead whenever possible. As a rough guide,
hash functions are about 100 times faster than RSA signature verification, and
about 10,000 times faster than RSA signature generation: on a typical worksta-
tion, one can sign two messages per second, verify 200 signatures per second,
and compute 20,000 hash function values per second.
To support micropayments, exceptional efficiency is required, otherwise the
cost of the mechanism will exceed the value of the payments. As a consequence,
our micropayment schemes are light-weight compared to full macropayment
schemes. We "don't sweat the small stuff": a user who loses a micropayment
is similar to someone who loses a nickel in a candy machine. Similarly, candy
machines aren't built with expensive mechanisms for detecting forged coins, and
yet they work well in practice, and the overall level of abuse is low. Large-scale
and/or persistent fraud must be detected and eliminated, but if the scheme de-
livers a volume of payments to the right parties that is roughly correct, we're
happy.
In our schemes the players are brokers, users, and vendors. Brokers authorize
users to make micropayments to vendors, and redeem the payments collected
by the vendors. While user-vendor relationships are transient, broker-user and
broker-vendor relationships are long-term. In a typical transaction a vendor sells
access to a World-Wide Web page for one cent. Since a user may access only a few
pages before moving on, standard credit-card arrangements incur unacceptably
high overheads.
The first scheme, "PayWord," is a credit-based scheme, based on chains of
"paywords" (hash values). Similar chains have been previously proposed for dif-
ferent purposes: by Lamport [9] and Haller (in S/Key) for access control [7],
and by Winternitz [11] as a one-time signature scheme. The application of this
HashX HashY Y
Iterative Hash
HashX HashY HashY HashY Z
Hash ChainPayWord and MicroMint:
Two Simple Micropayment Schemes
Ronald L. Rivest 1 and Adi Shamir 2
1 MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Mass.
02139, rivest @theory.lcs.mit.edu
2 Weizmann Institute of Science, Applied Mathematics Department, Rehovot, Israel,
1 I n t r o d u c t i o n
~Ve present two simple micropayment schemes, "PayWord" and :'MicroMint,"
for making small purchases over the Internet. We were inspired to work on this
problem by DEC's "Millicent" scheme[10]. Surveys of some electronic payment
schemes can be found in Hallam-Baker [6], Schneier[16], and Wayner[18].
Our main goal is to minimize the number of public-key operations required
per payment, using hash operations instead whenever possible. As a rough guide,
hash functions are about 100 times faster than RSA signature verification, and
about 10,000 times faster than RSA signature generation: on a typical worksta-
tion, one can sign two messages per second, verify 200 signatures per second,
and compute 20,000 hash function values per second.
To support micropayments, exceptional efficiency is required, otherwise the
cost of the mechanism will exceed the value of the payments. As a consequence,
our micropayment schemes are light-weight compared to full macropayment
schemes. We "don't sweat the small stuff": a user who loses a micropayment
is similar to someone who loses a nickel in a candy machine. Similarly, candy
machines aren't built with expensive mechanisms for detecting forged coins, and
yet they work well in practice, and the overall level of abuse is low. Large-scale
and/or persistent fraud must be detected and eliminated, but if the scheme de-
livers a volume of payments to the right parties that is roughly correct, we're
happy.
In our schemes the players are brokers, users, and vendors. Brokers authorize
users to make micropayments to vendors, and redeem the payments collected
by the vendors. While user-vendor relationships are transient, broker-user and
broker-vendor relationships are long-term. In a typical transaction a vendor sells
access to a World-Wide Web page for one cent. Since a user may access only a few
pages before moving on, standard credit-card arrangements incur unacceptably
high overheads.
The first scheme, "PayWord," is a credit-based scheme, based on chains of
"paywords" (hash values). Similar chains have been previously proposed for dif-
ferent purposes: by Lamport [9] and Haller (in S/Key) for access control [7],
and by Winternitz [11] as a one-time signature scheme. The application of this
HashX HashY HashY HashY Z
Hash Chain
Given
HashX HashY HashY HashY Z
Hash Chain
GivenCompute
HashX HashY HashY HashY Z
Hash Chain
GivenCompute
Infeasible to Compute
HashX HashY HashY HashY Z
Zpreimage = $1 ea
PayWord
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $2
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3 $4
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
Y = $3
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
Y = $3H3(Y) = Z ?
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
Y = $3H3(Y) = Z ?
HashX HashY HashY HashY Z
EthWord Zpreimage = $1 ea
Y = $3
Y = $3H3(Y) = Z ?
DApp
preimage = $1 ea
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
Y = $3H3(Y) = Z ?
preimage = $1 eaDApp
preimage = $1 ea $100
Z
HashX HashY HashY HashY Z
Zpreimage = $1 ea
Y = $3
Y = $3H3(Y) = Z ?
preimage = $1 eaDApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
DApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
Payment Channel?
DApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
Payment Channel?
Offline / Monotonic / Unidirectional
DApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
Payment Channel?Bitcoin Ethereum
DApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
Payment Channel?Digital Signatures Hash
DApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
Payment Channel?Digital Signatures Hash & msg.sender
DApp
preimage = $1 ea $100
Z Claim(Pay,Y): if HPay(Y) = Z { Pay -> Bob (100-Pay) -> Alice }
Payment Channel?Very Compact 112 -> 256 bits
Ethereum Payment Channel in 50
Lines of Code
With the talk of state/payment channels being a “future” scalability
option in Ethereum, I wanted to write a contract to show that they’re
more than doable now. You don’t need to wait for Raiden, you can set up
your own trustless channels right now.
I’ll walk through the solidity code in channel.sol here:
https://github.com/mattdf/payment-channel
Let’s say Alice and Bob want to set up a payment channel for something
that requires micropayments that they don’t want to commit on chain to
save on transaction fees. In this case, Bob may be paying Alice to manage
a social media presence, and he pays her 0.001 ETH per tweet(24 cents)
— if Bob were to make an on-chain transaction for each tweet, 20% of
Alice’s income would be eaten up by fees.
On one hand, Alice does not want to do 100 tweets of work and trust Bob
will pay her at the end for all 100 tweets, and on the other hand, Bob
doesn’t want to pay Alice for 100 tweets all at once for her to just
disappear and not do any work.
We can solve this with a payment channel where Bob commits
100*0.001 = 0.1 ETH to the channel smart contract, where the money
can only either go to Alice or back to Bob. We see the constructor here:
Matthew Di Ferrante Follow
Jun 5, 2017 · 4 min read
200000
250000
300000
350000
400000
450000
500000
10 20 30 40 50 60 70 80 90 100
Cost
(ga
s)
Number of payments
Ether TransferEthWord
Pay50
200000
250000
300000
350000
400000
450000
500000
10 20 30 40 50 60 70 80 90 100
Cost
(ga
s)
Number of payments
Ether TransferEthWord
Pay50
1700 payments
5
EthWord Function Gas ETH USDChannel 312 031 0.00539 $0.689closeChannel (50) 18 905 0.00033 $0.042closeChannel (100) 22 205 0.00038 $0.049
Table 1. Function cost. Since closeChannel is dependent on how long the hash chainis for the claimed payment, we shows costs for length 50 and length 100.
that holds 1.00 ETH in escrow and the PayTaker supplies proof that they areentitled to, say, 0.45 of the 1.00 ETH by invoking this function. For Pay50, theproof is the claimed amount as signed by PayMaker and the contract validatesthe signature. For EthWord, it is a payword (i.e., the output of a hash function).In this case, the PayMaker might make a hash-chain of length 100, construct thecontract with the tip, specify the value of each hash as 0.01 ETH, and funds thecontract with 1.00 ETH.
Note that the contract does not care about the length of the hash chainbecause there is no simple way (nor reason) for the PayTaker to actually verifythe length of the hash-chain. If it is too short, then PayMaker cannot makepayments after a certain point. If it is longer, than PayTaker needs to stopaccepting payments in excess of what she has verified to the contract to hold.Similarly, since the length of the hashchain is unknown to PayTaker, the contractdoes not require a specific amount to be funded. The PayTaker will just treatthis amount as the maximum.
The PayMaker can make an o✏ine payment to the PayTaker by sending ahash (again see Protocol 1). Note that the hash is in no way bound to the identityof the PayTaker—the smart contract binds the use of the hash to the PayTaker.Next, note that technically the PayTaker can compute the chain and submitany hash from this chain to claim(), however they are incentivized to send themost valuable hash. For this same reason, the PayMaker can then later ‘up thepayment’ by sending a more valuable hash to the PayTaker. This can be repeateduntil the PayMaker runs out of hashes or PayTaker wants to run claim(). Thisis called replace-by-incentive [14] in the payment channel literature.
4.2 Evaluation
Footprint. Relative to Pay50, EthWord does not add to the lines of code; infact, it even shaves a few o↵. The more important property is the size of thepayment sent to the receiver; this is reduced from a digital signature to a hashor from 776 bits to 264 bits. Note that it is even possible to reduce EthWord to256-bits; an extra 8 bit value representing the length of the hash from the tip isincluded for a more convenient loop.
Gas Costs. As of January 15th, 2019, the weighted average price of 1 gas is17.26⇥10�9 ETH3 and the exchange rate of 1 ETH to USD is $127.85.4 Table 1shows the gas costs of each function in EthWord if run successfully. The cost
3 https://ethgasstation.info/4 https://coinmarketcap.com/
5
EthWord Function Gas ETH USDChannel 312 031 0.00539 $0.689closeChannel (50) 18 905 0.00033 $0.042closeChannel (100) 22 205 0.00038 $0.049
Table 1. Function cost. Since closeChannel is dependent on how long the hash chainis for the claimed payment, we shows costs for length 50 and length 100.
that holds 1.00 ETH in escrow and the PayTaker supplies proof that they areentitled to, say, 0.45 of the 1.00 ETH by invoking this function. For Pay50, theproof is the claimed amount as signed by PayMaker and the contract validatesthe signature. For EthWord, it is a payword (i.e., the output of a hash function).In this case, the PayMaker might make a hash-chain of length 100, construct thecontract with the tip, specify the value of each hash as 0.01 ETH, and funds thecontract with 1.00 ETH.
Note that the contract does not care about the length of the hash chainbecause there is no simple way (nor reason) for the PayTaker to actually verifythe length of the hash-chain. If it is too short, then PayMaker cannot makepayments after a certain point. If it is longer, than PayTaker needs to stopaccepting payments in excess of what she has verified to the contract to hold.Similarly, since the length of the hashchain is unknown to PayTaker, the contractdoes not require a specific amount to be funded. The PayTaker will just treatthis amount as the maximum.
The PayMaker can make an o✏ine payment to the PayTaker by sending ahash (again see Protocol 1). Note that the hash is in no way bound to the identityof the PayTaker—the smart contract binds the use of the hash to the PayTaker.Next, note that technically the PayTaker can compute the chain and submitany hash from this chain to claim(), however they are incentivized to send themost valuable hash. For this same reason, the PayMaker can then later ‘up thepayment’ by sending a more valuable hash to the PayTaker. This can be repeateduntil the PayMaker runs out of hashes or PayTaker wants to run claim(). Thisis called replace-by-incentive [14] in the payment channel literature.
4.2 Evaluation
Footprint. Relative to Pay50, EthWord does not add to the lines of code; infact, it even shaves a few o↵. The more important property is the size of thepayment sent to the receiver; this is reduced from a digital signature to a hashor from 776 bits to 264 bits. Note that it is even possible to reduce EthWord to256-bits; an extra 8 bit value representing the length of the hash from the tip isincluded for a more convenient loop.
Gas Costs. As of January 15th, 2019, the weighted average price of 1 gas is17.26⇥10�9 ETH3 and the exchange rate of 1 ETH to USD is $127.85.4 Table 1shows the gas costs of each function in EthWord if run successfully. The cost
3 https://ethgasstation.info/4 https://coinmarketcap.com/
5% fee -> settle for amounts ~$151% fee -> settle for amounts ~$75
Trickle
Untrusted Intermediary
Untrusted Intermediary
Other payment channel results?Open research
@PulpSpy
Q