Nakamoto ResearchCommunication language |
Version | v0.3.0 | |
|---|---|---|---|
| Updated | |||
| Author | obxium | License | BY-NC-ND |
This content is about communication language, and certain discovered nuances found in the communications of Satoshi Nakamoto. The communications are the constituents of a corpus the author is building.
Many researchers note peculiarities in Nakamoto’s style of English usage. In particular, Nakamoto’s inconsistent use of British English. This section records some examples and supporting resources to consider.
If you analyze the text corpus, you’ll arrive at a few possibilities to explain the inconsistent language choices and lack of spell checking:
Here are statistics for an incomplete corpus of 81818 words with authorship attributed to Nakamoto.
Total American English variants found: 295
Total British English variants found: 33
Percentage split:
American English words found:
British English words found:
Here are the details on all the Nakamoto posts on the cryptography mailing list.
Total American English variants found: 12
Total British English variants found: 1
Percentage split:
American English words found:
British English words found: - neighbour: 1 (US: neighbor)
Here are the details on all the Nakamoto posts on the P2P Research forum.
Total American English variants found: 7
Total British English variants found: 0
Percentage split:
American English words found:
Here are the details on all the Nakamoto emails sent to Martti Malmi.
Total American English variants found: 62
Total British English variants found: 10
Percentage split:
American English words found:
British English words found:
Here’s a breakdown of all comments in the Bitcoin version 0.1.0 source code.
Total American English variants found: 39
Total British English variants found: 6
Percentage split:
American English words found:
British English words found:
This section deals with particular colloquialism use across the corpus.
“Screw” is primarily a British-originated euphemism or slang term used for centuries with varying meanings. Common uses for screw include screwed, or screwed up or screwing up, which are slang for a bad situation or unfortunate circumstances.
Nakamoto uses 2 variations of screw with this slang meaning in
screwed up and screwing up within the Bitcoin
version 0.1.2 announcement:
Bitcoin v0.1.2 is now available for download.
See http://www.bitcoin.org for the download link.
All the problems I've been finding are in the code that
automatically finds and connects to other nodes, since I wasn't
able to test it in the wild until now. There are many more ways
for connections to get screwed up on the real Internet.
Bugs fixed:
- Fixed various problems that were making it hard for new nodes to
see other nodes to connect to.
- If you're behind a firewall, it could only receive one
connection, and the second connection would constantly disconnect
and reconnect.
These problems are kind of screwing up the network and will get
worse as more users arrive, so please make sure to upgrade.
Satoshi NakamotoLen Sassaman also used the term “screwed up” in a 2007 cypherpunks mailing list post.
From cypherpunks Wed Nov 07 19:37:22 2007
From: Len Sassaman <rabbi () abditum ! com>
Date: Wed, 07 Nov 2007 19:37:22 +0000
To: cypherpunks
Subject: Re: For those who missed it: Hushmail is pwnd
Message-Id: <Pine.LNX.4.58.0711071119460.19938 () thetis ! deor ! org>
X-MARC-Message: https://marc.info/?l=cypherpunks&m=119446646713988
On Wed, 7 Nov 2007, J.A. Terranson wrote:
> My guess is that Hushmail has had subpoenas before and had to develop
> and install a modified java applet which captures the passphrase when
> the user enters it. With that and the stored keys, it can decrypt all
> the stored communications.
I wouldn't be so certain -- getting subpoenas is no big deal for
companies. At Anonymizer, I answered lots of them. Most of the time, I
couldn't comply. (If you pay for your Anonymizer account with your credit
card, and the Feds want to know if you bought an Anonymizer account, well,
you screwed up. Otherwise, I told the guy on the phone the truth -- I had
nothing in my logs about that IP address, sir. And they went away,
quickly and without fuss, unlike when I've had to deal with the same
thing as a private remop.)
Of course, that was in 2003 and times have changed all around -- I don't
think Hushmail was handing out info to TLAs back then either.
Possibly, the problem here is Hushmail's move away from using its Java
applet as default. (It has two modes now -- securish and securisher, from
what I can tell, and the more secure "everything happens in the browser,
including all key operations" part is the optional step now. In the less
secure case, while I haven't analyzed it yet, I believe the keys in those
cases are being stored decryptable on the server. The passphrase is
almost certainly passed to the server.)
But, also, bear in mind that Hushmail has *always* allowed people to send
non-PGP messages, especially to non-Hushmail users. If one party was a
Hushmail user, and one party was not a PGP user, then PGP's not going to
be involved.
Regardless, boo for Hushmail for not disclosing that they were answering
subpoenas like this.
...
There *are* bigger forces at play, though. The "mutual assistance"
provisions of the Council of Europe cybercrime treaty are horrible, as are
these data retention laws. These are going to affect companies based in
any country signed to that treaty, including the US.
Hushmail, in the end, is relatively weak compared to other Cypherpunk
tools, and other ways of using them. The big They are trying to make those
other tools and uses illegal. Already we have people in the academic
privacy field scampering to appease their new masters, and trying to find
ways to do backdoored anonymity safely (are you kidding me? We haven't
even worked out the kinks with regular anonymity systems.) But in the end,
those are academics scared that their field is going to be made illegal,
and so their actions are understandable, if deplorable.
Likewise for whatever Hushmail may be doing.
A statement from the folks over there would be nice.
--Len.Hal Finney also used similar terms in posts made to the cypherpunks
mailing list in 2004, but the screw and
screwed here relates more to the usage that describes
getting a bad deal, ripped off, or rugged as the kids call it these
days.
From cypherpunks Thu Nov 04 23:01:15 2004
From: hal () finney ! org ("Hal Finney")
Date: Thu, 04 Nov 2004 23:01:15 +0000
To: cypherpunks
Subject: RE: Your source code, for sale
Message-Id: <20041104230115.6A1CD57E2A () finney ! org>
X-MARC-Message: https://marc.info/?l=cypherpunks&m=109961094015550
"Tyler Durden" writes:
> So my newbie-style question is, is there an eGold that can be verified, but
> not accessed, until a 'release' code is sent?
>
> In other words, say I'm buying some hacker-ed code and pay in egold. I don't
> want them to be able to 'cash' the gold until I have the code. Meanwhile,
> they will want to see that the gold is at least "there", even if they can't
> cash it yet.
>
> Is there a way to send a 'release' to an eGold (or other) payment? Better
> yet, a double simultaneous release feature makes thing even more
> interesting.
I've been thinking about how to do this kind of thing with ecash.
One project I'm hoping to work on next year is a P2P gambling game (like
poker or something) using my rpow.net which is a sort of play-money ecash.
You'd like to be able to do bets and have some kind of reasonable
assurance that the other guy would pay up if he loses.
In the case of your problem there is the issue of whether the source
code you are buying is legitimate. Only once you have inspected it and
satisfied yourself that it will suit your needs would you be willing
to pay. But attaining that assurance will require examing the code in
such detail that maybe you will decide that you don't need to pay.
You could imagine a trusted third party who would inspect the code and
certify it, saying "the source code with hash XXX appears to be legitimate
Cisco source code". Then they could send you the code bit by bit and
incrementally show that it matches the specified hash, using a crypto
protocol for gradual release of secrets. You could simultaneously do
a gradual release of some payment information in the other direction.
If you don't have a TTP, one idea for using ecash is Markus Jakobsson's
"Ripping Coins for a Fair Exchange". Basically you withdraw ecash from
your account and in effect "rip it in half" and give half to the seller.
Now he gives you the product and you give him the other half of the coin.
The idea is that once you have given him the "ripped" ecash ("torn"
would be a better word because ripping means something else today),
you are out the value of the cash. You have no more incentive to cheat,
as giving him the other half won't cost you anything additional.
(Even without ecash, a service like egold could mimic this functionality.
You'd create an escrow account with two passwords, one known to each
party. Only with both passwords could data be withdrawn from the account.
Then the buyer would transfer funds into this account. After receiving
the goods, the buyer would send his password to the seller.)
The problem is that if the source code you are purchasing is bogus,
or if the other side doesn't come through, you're screwed because you've
lost the value of the torn cash. The other side doesn't gain anything
by this fraud, but they harm you, and if they are malicious that might
be enough. And likewise you might be malicious and harm them by refusing
to give them your half of the coin even after you have received the goods.
Again, this doesn't benefit you, you're still out the money, but maybe
you like causing trouble.
Another idea along these lines is gradual payment for gradual release
of the goods. You pay 10% of the amount and they give you 10% of the
source code. You pay another 10% and you get the next 10% of the source,
and so on. (Or it could be nonlinear; maybe they give out half the code
for free, but the final 10% requires a large payment.) The idea is that
you can sample and make sure they do appear to have the real thing with
a fairly small investment.
If there is some mechanism for the seller to have a reputation (like
Advogato's perhaps, with some spoofing immunity) then the problem is
easier; the seller won't want to screw buyers because it hurts his rep.
In that case it may be reasonable to ask the buyer to pay in advance,
perhaps using the partial payment system just discussed.
These various ideas all have tradeoffs, and in general this kind of
problem is hard to solve because of the complexity of what constitutes a
successful transaction. A reputation system helps a great deal to resolve
the issues, but opens up problems of its own. The betting problem I
want to work on is relatively easy because there is no ambiguity about
who wins, but even then it is hard to make sure that neither party can
maliciously harm the other.
Hal F.Originally a late 1800s phrase for smart alek, one who thinks they’re clever, or someone who is conceited, annoying, or brash.
You can find an instance of this term in the Bitcoin v0.1.0 source
file script.cpp at line 495:
// OP_NOTEQUAL is disabled because it would be too easy to say
// something like n != 1 and have some wiseguy pass in 1 with extra
// zero bytes after it (numerically, 0x01 == 0x0001 == 0x000001)These are certain peculiarities with how Nakamoto communicated, including mannerisms of English usage, key phrases, and quotations or sayings.
The quote appears in The Mythical Man-Month, which is a popular book among programmers.
You can find this quote in the Bitcoin v0.1.0 source file
util.cpp at line 320:
// "Never go to sea with two chronometers; take one or three."
// Our three chronometers are:
// - System clock
// - Median of other server's clocks
// - NTP servers
╭───────────────────────────────────────────────────────────────────────╮
│ ⚠ THIS CONTENT MAKES NO CLAIMS ABOUT THE IDENTITY OF SATOSHI NAKAMOTO │
╰───────────────────────────────────────────────────────────────────────╯