Funny it uses the names Alice and Bob too, are those normally used in money transmit examples? Saw that with Bitcoin too.
As Edward explains, these names are used everywhere in cryptography. See also https://en.wikipedia.org/wiki/Alice_and_Bob. 
Topic: Antecedent to bitcoin. (Read 1772 times)
Um... Wei Dai's paper is listed as a reference in Satoshi's original Bitcoin whitepaper. It's well known that it served as a source of inspiration. Nothing new.
Alice and Bob (and Carol, and David, and Eunice, ..... and Zeke) commonly used name in description of cryptographic protocol. Always appear in alphabetic order in protocol description. Common to all crypto papers. Gender alternate, first letter of name consecutive.
Are also several name reserve for specific type threat model. If protocol description require five honest actors (so require female E name), description use "Eunice" never "Eve" for E name; "Eve" mean something else. Same with other special names.
"Eve" (for eavesdropper) can listen on lines. Protocol often describe in term of what Eve know or can learn. "Trent" (for trust) is trusted central authority or server. Depending on protocol, subverting Trent may cause some breakage or total breakage. "Mallory" (forget what English mnemonic was) is toughest opponent; can listen on lines or change messages arbitrarily in route, but has not infinite compute power. Can usually launch man-in-the-middle attack, but can't decrypt with brute force in real time. Protocol often described in term of what Mallory can know or learn from which transaction, or in term of what damage Mallory can do, or in term of what trouble Mallory must do to remain long undetected.
Several others such name, but rarely seen because attack mode impractical. Example "Brutus" (for brute force) is attacker with very large compute power. Can defeat cryptography, in time period depend on protocol description. Brutus usually work with Eve, record all transactions for decrypt later. Protocol often described in term of what capability Brutus need for decrypt, or in term of time period secrets safe from Brutus. Sometime Brutus work with Mallory, decrypt and re-encrypt in real-time. Protocol described in term of what capability and acceptable communication delay Brutus need for fool anybody. "Brutus" easy work in real-time with mild encryption such as password-protect zipfile, etc, work in near-real-time with medium encryption like buggy SSL.
Are also several name reserve for specific type threat model. If protocol description require five honest actors (so require female E name), description use "Eunice" never "Eve" for E name; "Eve" mean something else. Same with other special names.
"Eve" (for eavesdropper) can listen on lines. Protocol often describe in term of what Eve know or can learn. "Trent" (for trust) is trusted central authority or server. Depending on protocol, subverting Trent may cause some breakage or total breakage. "Mallory" (forget what English mnemonic was) is toughest opponent; can listen on lines or change messages arbitrarily in route, but has not infinite compute power. Can usually launch man-in-the-middle attack, but can't decrypt with brute force in real time. Protocol often described in term of what Mallory can know or learn from which transaction, or in term of what damage Mallory can do, or in term of what trouble Mallory must do to remain long undetected.
Several others such name, but rarely seen because attack mode impractical. Example "Brutus" (for brute force) is attacker with very large compute power. Can defeat cryptography, in time period depend on protocol description. Brutus usually work with Eve, record all transactions for decrypt later. Protocol often described in term of what capability Brutus need for decrypt, or in term of time period secrets safe from Brutus. Sometime Brutus work with Mallory, decrypt and re-encrypt in real-time. Protocol described in term of what capability and acceptable communication delay Brutus need for fool anybody. "Brutus" easy work in real-time with mild encryption such as password-protect zipfile, etc, work in near-real-time with medium encryption like buggy SSL.
Some very clear similarities yes:
Signing of transactions is the same and escrow possibilities are mentioned.
Funny it uses the names Alice and Bob too, are those normally used in money transmit examples? Saw that with Bitcoin too.
I have no idea if the doc is legit though.
Quote
3. Computation. After seeing the bids, the ones who placed bids in the
bidding phase may now solve the problems in their bids and broadcast the
solutions.
Sounds like proof of work to me, though some of the rest is more like proof of stake... the document is very unclear on specifics though.bidding phase may now solve the problems in their bids and broadcast the
solutions.
Signing of transactions is the same and escrow possibilities are mentioned.
Funny it uses the names Alice and Bob too, are those normally used in money transmit examples? Saw that with Bitcoin too.
I have no idea if the doc is legit though.
http://www.weidai.com/bmoney.txt
This paper publish in 1998, propose protocol for cryptographic money much like Bitcoin. In fact is clear elements of protocol design were adopted or adapted into Bitcoin itself. Was initially published on mail list, call "Cypherpunks." List still exist I think. Don't know where now.
Wei Dai is paper's author, also is maintainer of very extensive cryptographic library which kept in public domain. Many routine from Dai library appear in initial implementation of Bitcoin.
Is clear Satoshi Nakamoto read this paper and used Dai crypto library in implementing Bitcoin. Was probably on Cypherpunk mailing list in 1998.
This is interesting.
Jump to: