Wednesday, July 18, 2018

Summary of Ian Grigg's Interview

Summary of Ian Grigg's Interview which shows he had extensive experience in exactly the areas Satoshi Nakamoto needed:



Indicates he's a good big-scale thinker:
I realised DigiCash’s vision was too narrow, and all of finance (shares, bonds, derivatives) could be implemented using this technology.
On mixing in the 1990's
This is what Gary and I used in the 90s, we created a pseudonymous system whereby if you wanted to preserve some sense of privacy you would swap coins back and forth to obfuscate the trail.
 Was aware of how wallets would need to function in order to allow mixing
Firstly the money was tranched into coins, denominated as a number which didn’t change. Eg if you want to send 9.99, you needed an exact set of coins to match. So you can track those specific numbers and see who is moving money around.
Secondly people weren’t really set up to hold their coins on their own wallets because of the difficulties with backups, so people would just use an account at the mint, and withdraw when they want to send to a merchant, then the merchant would cash them in.
So there’s a time and coin based tracking mechanism. You needed a lot of traffic before you could get privacy.
He was mixing int he 1990's:
The bitcoin arrangement is that you use a pseudonymous key, and if you want to spread your coins around, you write them to different keys which you control, creating a graph of confusion and security by obscurity.  This is what Gary and I used in the 90s, we created a pseudonymous system whereby if you wanted to preserve some sense of privacy you would swap coins back and forth to obfuscate the trail. 
Was aware of how companies fail. He knew from the beginning Ethereum would have a problem like the DOA.(End of article goes more into how smart contract coin will morph into a useful Ricardian contract, and how Ethereum will continue to have problems from lack of understanding basic problems)
-- interviewer: You mentioned 100 companies working on the problem, making the same mistakes.  Do you see the same mistakes being made again today by all the crypto companies?  
...The smarter companies quickly discover they’re always losing money due to hacks, crashes, failures, and bugs.  They then do more research and discover the solution is to implement double entry accounting.  Ethereum is going through this right now.
Other:
we were in the formative period trying to solve for money.  If you can’t get money working, can you get anything else going?  That was my field.  Everyone could understand cash, so we wanted to get that working first. 
Most people think cryptographers and programmers are interchangeable.  They are not!  They are very different fields and very few people understand both.  .. unless you have seriously good engineers putting together seriously complicated code you’re going to end up with a mess.  That’s what happened with a lot of systems, eg e-gold which I was partially involved in.  
Discovered that money is a simple smart contract
Once I understood this [what a bond is...a contract], I asked myself what a contract was, and that took me on a different journey.  I learnt that there were two parties, an offer and acceptance, some clauses, terms and conditions.  Goods go one way; value goes the other way.
The interesting thing is that my answer to how I issue bonds on the net is exactly the same as how I issue a contract onto the net.
And once I’ve worked out how to issue a contract onto the net, I can construct anything else including money!  So when we started, we thought we’d need money separate from bonds, but actually we just needed a contract system, with a contract for money and a contract for bonds.
This was a huge discovery which most people haven’t made yet. 
Realized hashing was needed to connect the fact of a contract to accounting
So we need a way to link the contract claim to the accounting.  That’s where cryptography came in. We took the contract document and hashed it (we were using SHA-1) and the hash became the unit which was accounted for. The accounting system just kept the numbers good and balanced and fair, and every time it moved a number around, it would move a number of these hashes.  So we elegantly sliced the world of law from the world of accounting, using a hash in the middle! 
Built servers that tried to remove centralization problem
Your pseudonym would digitally sign the request, creating the authorisation to move the money. That meant the issuer couldn’t just wave their hands and change the numbers. ... Most of the issuance servers I built revolved around that 
There can be only one
So Bitcoin is the exception that proves the rule that you need a contract if you’re issuing something.  Or you’re issuing something without a contract, there can only be one in the space.  
Consensus is 3rd column of triple entry ledger
From this concept came the notion of triple entry. The receipt itself was shared between the payer, payee, and the issuance server. If you only had 2 parties and one of them lost their copy, then there’s potential for abuse: you need all 3.  This is how we established “consensus” (in today’s terms) about a single transaction, and about a set of transactions....Later in 2004 I figured that this actually looked different to double entry – it turned out to be triple entry...So I wrote this paper and sent it to Todd Boyle who said that he’d invented this ages ago
How the Satoshi team began in engineering BTC:
When Satoshi (the team) were building Bitcoin, they looked at why the systems had failed – they found that it was because behind the contract there was an issuer, something to be attacked.....The problem was there was an issuer, there was a contract.  Satoshi figured out there needed to be an instrument without a contract, without an issuer, so after lots of thinking they came up with the notion where they just invent the number – they swept away the law and just kept the accounting, which just dealt with numbers.  

Tuesday, July 10, 2018

Ideal currency

The ideal cryptocurrency characteristics you listed are only the result of a characteristic that is the basis of all of Nick Szabo's charactersitics: constant value. Constant value means a certain amount of available (Gibb's) free energy (see Schrondinger's corrected "What is Life?" paper where he detailed what he meant by "negative entropy"). Since it is also a measure of control of other people, constant value is an amount of free energy per person.

Examples: if the real GDP of a marketplace increases, there is more free energy coming under control. In order to keep constant value so that prices, wages, and all other contracts in a marketplace to remain valid and enforceable to a common legal tender, the currency must expand and contract with the size of the "GDP". The best measure of "GDP" might be the free energy producible by the commodity infrastructure that uses the currency. It must also expand and contract inversely with the population that falls under its control. If there are too many people, employees become less valued so those holding the currency have more control of more people. The great problem is determining how to "fairly" or "properly" issue new coin (or destroy it) when it needs to expand or contract. "Properly" expanding and contracting probably means "in whatever way will lead to more free energy production in the future". That requires a governing intelligence above (controlling) the "invisible hand" on the macro scale. The marketplace is just micro solutions to the macro goal. One recent macro goal that has worked well (in terms of its ability to replace other systems) is more even distribution of wealth via democratic governing that subverts the marketplace by robbing from the rich to give to the average via progressive tax laws and equal rights that supply "welfare" such as roads, police/military/fire, education, and social security to all. (Marketplaces otherwise always evolved towards very unequal distribution of wealth and rights). Commodity-based coins of "old" like Bancor and William Graham's ideas were an attempt to partially solve the problem in a reverse manner: expand and contract the free energy via massive commodity storage and release when prices and wages started changing.

Satoshi: new book scores closest to Satoshi & Ian Grigg

Two years ago, here and here, I worked a lot trying to compare various authors to Satoshi Nakamoto by finding authors with the lowest entropy difference. A book supposedly by Satoshi is about to come out, so I ran the program again. The previous attempts started with Satoshi's writings as the baseline.  Ian Grigg scored fairly well then, and he and Satoshi are the best matches for the new book excerpt.

First, a caveat.  Ian Grigg matches so-so with Satoshi.  There's a reverse way of running the program, and they don't match at all. Another caveat is this: Ian likes to say "and so forth" but Satoshi never said that.

What is lowest entropy difference?
Imagine you have 1000 animals in your database and a new animal is discovered. How do you get a single number from the animal that will indicate how well he matches to each of the others? You could have 100 different animal characteristics you've defined like the weight of each organ and calculate the percent difference for each organ between your animal and the others, and add it up. The lowest value is the best match. This is like that, but using a mathematically more accurate method. It's really an absence of words that don't match more than matching words, so it's not trivial to trick. You can't easily pick matching words to exclude, but that would help trick it...if you do over 100 of them.

Although the book excerpt does not sound like Satoshi to me, the book is ranking closer to Satoshi and Ian Grigg than all the other bitcoin authors I have texts for. This is very interesting because Ian Grigg claimed to be part of the Satoshi team when supporting Craig Wright, who didn't match with Satoshi at all. He also posted to the mail list similar things. The anonymous "The Real Satoshi" also matches best with Ian Grigg, but not Satoshi, when discussing things other than bitcoin.  I really think Ian Grigg was most of the brains and voice of Satoshi, as this will show.

In trying to find strange word pairs between Satoshi, Ian rigg, and the book, I could only come up with "here to" that was used by all 3 in parenthesis:
Satoshi: (I'm using the word scarce here to only mean limited potential supply)
Book: (I'm going to take a moment here to explain something. I know that some of you...)
Book: (I want to take a moment here to explain that prebitcoin, ...) 3 more times
Ian Grigg: (Reference here to Amir's paper, and my comments on branding box.)
Ian Grigg and the book excerpt say Satoshi is a group:
Satoshi book:
that it could not have possibly been the work of just one person, that, perhaps it was a pseudonym, and in that regard...they were right. ... What didn't come up (at the time), which I found odd, was the question of whether Satoshi Nakamoto was just one, or a group of us.. Here is where I will stop. But the truth is one that people will not come to expect. Because the truth is too special to give away, requires a long answer, which will be in the book. I will say this though, consider for a moment the distinction; as to whether I had help or was part of that
help in creation, and then separate that from the person who followed, which for the most part, was very consistent.
Ian Grigg:
This team effort was one of a most severe cost to all members of that
team, and only privacy is holding us back from recognising it.

Further, the keys that controlled critical parts were moved several times between various persons. Which is to say that control of the keys does not indicate more than the holder being trustworthy to the goals of the team at a point in time. Even if Craig manages to sign over a coin, it does not and cannot prove he is "the one," only that he was at one point in time a trusted member of the team. Albeit, the team that he founded, but a wise leader controls for all risks, including those risks posed by the leader himself.

More: control at any time does not necessarily indicate ownership, either in the minds of the team nor in the eyes of the law. Recalling the reports of late 2015, can you rule out that the keys haven't been stolen?

Finally, as has been reported, the headline bulk of the value is controlled by a trust. Any movement of those coins needs to operate according to trust rules; if not, then we are in a state of sin. ... Breaking the trust is way off the scale of what anyone will desire.

Other clues: Ian's British and it's long been known Satoshi used British language. Ian in at least the above quote used two spaces after periods, as was noted in Satoshi's writing. Ian definitely has the big-scale type of thinking and extensive experience to be the original genius behind the plan. Here is my summary of that article that shows Ian had all the experience Satoshi needed.  He claims Craig Wright was the leader, but I think that just plays to CW's ego and Ian's desire to not be singled out.  Ian also submitted Satoshi's name for the Turing award. Look at this point in the video. The guy on the right of Ian seems like he can't look up because he knows or suspects (and some people in the audience seem to suspect) that Ian is Satoshi. Who would submit Satoshi's name if they were not really enthused about the Satoshi persona?   Another clue: Satoshi never said things that were at the forefront of Ian's background and central to BTC's utility: "ledger", "triple entry", "Ricardian contract", and "DigiCash". The absence of these is conspicuous, especially Digicash. Ian goes into detail in the article above explaining how Digicash's failings and the failings of companies trying to use the ideas are like a description of BTC's core features. Digicash showed coin fractions, mixing, triple entry, and peer-to-peer were needed. He was mixing coins in the 1990s.

The following is with the white paper removed. With the white paper, the book scores closest to Satoshi highest match to the book on almost all of them.

Another interesting thing with the entropy program is how a subset of the author's persona (his alter ego) can match with the author, but not vice versa. I called this the Huckleberry Finn effect because it was so striking as to how the simple but high-entropy language of the boy matched best with Mark Twain's other writings, but his other writings did not match to the Huckleberry Finn. By this reasoning, Ian is a subset of Satoshi because he did not match well with Satoshi.  It should have been the other way around, unless Satoshi was several writers.

baseline text: 66KB
Using first 322 KB of known author files

Single X with punctuation
1 = 9035579 satoshi.txt
2 = 9347104 ian_grigg_email_list.txt
3 = 9379150 eliezer_yudkowski_less_wrong_forum.txt
4 = 9380173 gavin andresen forum.txt
5 = 9387572 wei_dai_less_wrong_forum.txt
6 = 9399341 surely_youre_joking_mr_feynman.txt
7 = 9400538 hal_finney_email_list.txt
8 = 9444524 gavin andresen blog.txt
9 = 9453671 superintelligence.txt
10 = 9463130 craig_wright.txt
11 = 9469096 gwern_less_wrong_forum.txt
12 = 9477623 adam_back_email_list.txt
13 = 9496609 Ender's Game.txt
14 = 9522657 AUSTIN_sense and sensibility.txt
15 = 9529736 michael_clear_thesis.txt
16 = 9533329 rifkin_zero_marginal_society.txt

Pair X Y with punctuation
1 = 3.3945 ian_grigg_email.txt
2 = 3.4177 satoshi_all.txt
3 = 3.428 eliezer_yudkowski_not_wei.txt
4 = 3.428 lesswrong_not_wei_0.txt
5 = 3.4308 hal_finney_all.txt
6 = 3.4401 wei_dai_comments2.txt
7 = 3.4709 gavin andresen cleaned.txt
8 = 3.4877 adam_back_cypher_cleaned.txt
9 = 3.6001 craig_wright.txt
(2-1)/2 %: 0.68

Missing middle X o Y with punctuation
1 = 3.4946 ian_grigg_email.txt
2 = 3.5039 satoshi_all.txt
3 = 3.5198 gavin andresen cleaned.txt
4 = 3.5247 hal_finney_all.txt
5 = 3.5248 wei_dai_comments2.txt
6 = 3.5338 lesswrong_not_wei_0.txt
7 = 3.5338 eliezer_yudkowski_not_wei.txt
8 = 3.5468 adam_back_cypher_cleaned.txt
9 = 3.6873 craig_wright.txt
(2-1)/2 %: 0.26

Missing pair in middle X o o Y with punctuation
1 = 3.48 ian_grigg_email.txt
2 = 3.5016 hal_finney_all.txt
3 = 3.5064 satoshi_all.txt
4 = 3.5068 wei_dai_comments2.txt
5 = 3.5163 eliezer_yudkowski_not_wei.txt
6 = 3.5163 lesswrong_not_wei_0.txt
7 = 3.5238 gavin andresen cleaned.txt
8 = 3.5453 adam_back_cypher_cleaned.txt
9 = 3.6371 craig_wright.txt
(2-1)/2 %: 0.62

Triple X Y Z with punctuation
1 = 3.912 ian_grigg_email.txt
2 = 3.93 hal_finney_all.txt
3 = 3.9305 satoshi_all.txt
4 = 3.9387 wei_dai_comments2.txt
5 = 3.9402 eliezer_yudkowski_not_wei.txt
6 = 3.9402 lesswrong_not_wei_0.txt
7 = 3.9405 gavin andresen cleaned.txt
8 = 3.9604 adam_back_cypher_cleaned.txt
9 = 3.9787 craig_wright.txt
(2-1)/2 %: 0.46

Missing left X o Y Z with punctuation
1 = 3.9176 ian_grigg_email.txt
2 = 3.9274 satoshi_all.txt
3 = 3.9292 hal_finney_all.txt
4 = 3.9386 wei_dai_comments2.txt
5 = 3.9414 gavin andresen cleaned.txt
6 = 3.9443 lesswrong_not_wei_0.txt
7 = 3.9443 eliezer_yudkowski_not_wei.txt
8 = 3.9645 adam_back_cypher_cleaned.txt
9 = 3.98 craig_wright.txt
(2-1)/2 %: 0.25

Missing right X Y o Z with punctuation
1 = 3.8995 ian_grigg_email.txt
2 = 3.9039 satoshi_all.txt
3 = 3.9162 hal_finney_all.txt
4 = 3.9181 eliezer_yudkowski_not_wei.txt
5 = 3.9181 lesswrong_not_wei_0.txt
6 = 3.9236 wei_dai_comments2.txt
7 = 3.93 gavin andresen cleaned.txt
8 = 3.9562 adam_back_cypher_cleaned.txt
9 = 3.9842 craig_wright.txt
(2-1)/2 %: 0.11

Quad with punctuation
1 = 4.0165 ian_grigg_email.txt
2 = 4.017 satoshi_all.txt
3 = 4.0225 hal_finney_all.txt
4 = 4.0234 eliezer_yudkowski_not_wei.txt
5 = 4.0234 lesswrong_not_wei_0.txt
6 = 4.0242 gavin andresen cleaned.txt
7 = 4.0248 wei_dai_comments2.txt
8 = 4.0312 adam_back_cypher_cleaned.txt
9 = 4.0346 craig_wright.txt
(2-1)/2 %: 0.01

Missing middle pair with punctuation
1 = 4.0238 ian_grigg_email.txt
2 = 4.024 satoshi_all.txt
3 = 4.0248 hal_finney_all.txt
4 = 4.0256 lesswrong_not_wei_0.txt
5 = 4.0256 eliezer_yudkowski_not_wei.txt
6 = 4.0257 wei_dai_comments2.txt
7 = 4.028 craig_wright.txt
8 = 4.0283 gavin andresen cleaned.txt
9 = 4.0289 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0


Pair
1 = 3.4966 ian_grigg_email.txt
2 = 3.5013 satoshi_all.txt
3 = 3.515 eliezer_yudkowski_not_wei.txt
4 = 3.515 lesswrong_not_wei_0.txt
5 = 3.5151 wei_dai_comments2.txt
6 = 3.5255 hal_finney_all.txt
7 = 3.5405 gavin andresen cleaned.txt
8 = 3.5716 adam_back_cypher_cleaned.txt
9 = 3.6401 craig_wright.txt
(2-1)/2 %: 0.13

Missing middle
1 = 3.5658 satoshi_all.txt
2 = 3.5674 ian_grigg_email.txt
3 = 3.5838 gavin andresen cleaned.txt
4 = 3.5915 wei_dai_comments2.txt
5 = 3.5957 hal_finney_all.txt
6 = 3.6081 eliezer_yudkowski_not_wei.txt
7 = 3.6081 lesswrong_not_wei_0.txt
8 = 3.6209 adam_back_cypher_cleaned.txt
9 = 3.7046 craig_wright.txt
(2-1)/2 %: 0.04

Missing pair middle
1 = 3.5624 satoshi_all.txt
2 = 3.5701 ian_grigg_email.txt
3 = 3.5779 hal_finney_all.txt
4 = 3.5794 gavin andresen cleaned.txt
5 = 3.5796 wei_dai_comments2.txt
6 = 3.5933 lesswrong_not_wei_0.txt
7 = 3.5933 eliezer_yudkowski_not_wei.txt
8 = 3.6236 adam_back_cypher_cleaned.txt
9 = 3.6671 craig_wright.txt
(2-1)/2 %: 0.22

Triple
1 = 3.9615 ian_grigg_email.txt
2 = 3.9678 hal_finney_all.txt
3 = 3.9689 satoshi_all.txt
4 = 3.974 wei_dai_comments2.txt
5 = 3.9748 gavin andresen cleaned.txt
6 = 3.9814 eliezer_yudkowski_not_wei.txt
7 = 3.9814 lesswrong_not_wei_0.txt
8 = 3.9821 craig_wright.txt
9 = 3.9859 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.16

Missing left
1 = 3.9684 satoshi_all.txt
2 = 3.9698 ian_grigg_email.txt
3 = 3.9733 gavin andresen cleaned.txt
4 = 3.9758 hal_finney_all.txt
5 = 3.9765 wei_dai_comments2.txt
6 = 3.9792 eliezer_yudkowski_not_wei.txt
7 = 3.9792 lesswrong_not_wei_0.txt
8 = 3.9838 craig_wright.txt
9 = 3.9855 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.04

Missing right
1 = 3.9467 ian_grigg_email.txt
2 = 3.9507 satoshi_all.txt
3 = 3.9557 hal_finney_all.txt
4 = 3.9597 wei_dai_comments2.txt
5 = 3.9608 eliezer_yudkowski_not_wei.txt
6 = 3.9608 lesswrong_not_wei_0.txt
7 = 3.9661 gavin andresen cleaned.txt
8 = 3.9819 adam_back_cypher_cleaned.txt
9 = 3.9893 craig_wright.txt
(2-1)/2 %: 0.1

Quad
1 = 4.0243 ian_grigg_email.txt
2 = 4.0247 satoshi_all.txt
3 = 4.0273 gavin andresen cleaned.txt
4 = 4.0299 hal_finney_all.txt
5 = 4.0299 lesswrong_not_wei_0.txt
6 = 4.0299 eliezer_yudkowski_not_wei.txt
7 = 4.0308 wei_dai_comments2.txt
8 = 4.0311 adam_back_cypher_cleaned.txt
9 = 4.0318 craig_wright.txt
(2-1)/2 %: 0.01



I got to looking into "the real satoshi" because he responded in a comment to an article by Ian:
http://financialcryptography.com/mt/archives/001593.html

Low and behold, he matches up with Ian Grigg, but not Satoshi. Maybe just a coincidence.

Single X with punctuation
1 = 2.793 ian_grigg_email.txt
2 = 2.8076 adam_back_cypher_cleaned.txt
3 = 2.8619 lesswrong_not_wei_0.txt
4 = 2.8619 eliezer_yudkowski_not_wei.txt
5 = 2.9521 wei_dai_comments2.txt
6 = 2.9631 gavin andresen cleaned.txt
7 = 2.9692 hal_finney_all.txt
8 = 3.1174 satoshi_all.txt
(2-1)/2 %: 0.52

Pair X Y with punctuation
1 = 3.8701 ian_grigg_email.txt
2 = 3.9204 gavin andresen cleaned.txt
3 = 3.929 hal_finney_all.txt
4 = 3.9444 eliezer_yudkowski_not_wei.txt
5 = 3.9444 lesswrong_not_wei_0.txt
6 = 3.9481 wei_dai_comments2.txt
7 = 3.9505 satoshi_all.txt
8 = 3.9603 adam_back_cypher_cleaned.txt
(2-1)/2 %: 1.3

Missing middle X o Y with punctuation
1 = 3.9741 gavin andresen cleaned.txt
2 = 3.9777 ian_grigg_email.txt
3 = 4.0021 hal_finney_all.txt
4 = 4.0028 satoshi_all.txt
5 = 4.0034 wei_dai_comments2.txt
6 = 4.0153 lesswrong_not_wei_0.txt
7 = 4.0156 eliezer_yudkowski_not_wei.txt
8 = 4.018 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.09

Missing pair in middle X o o Y with punctuation
1 = 3.9292 ian_grigg_email.txt
2 = 3.944 gavin andresen cleaned.txt
3 = 3.9671 wei_dai_comments2.txt
4 = 3.9785 hal_finney_all.txt
5 = 3.9806 lesswrong_not_wei_0.txt
6 = 3.9806 eliezer_yudkowski_not_wei.txt
7 = 3.9815 satoshi_all.txt
8 = 4.0017 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.38

Triple X Y Z with punctuation
1 = 4.4498 ian_grigg_email.txt
2 = 4.4576 hal_finney_all.txt
3 = 4.4718 gavin andresen cleaned.txt
4 = 4.4773 satoshi_all.txt
5 = 4.4777 eliezer_yudkowski_not_wei.txt
6 = 4.4777 lesswrong_not_wei_0.txt
7 = 4.4779 wei_dai_comments2.txt
8 = 4.4951 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.17

Missing left X o Y Z with punctuation
1 = 4.4331 ian_grigg_email.txt
2 = 4.4509 hal_finney_all.txt
3 = 4.4614 satoshi_all.txt
4 = 4.4735 wei_dai_comments2.txt
5 = 4.4738 lesswrong_not_wei_0.txt
6 = 4.4738 eliezer_yudkowski_not_wei.txt
7 = 4.4759 gavin andresen cleaned.txt
8 = 4.4919 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.4

Missing right X Y o Z with punctuation
1 = 4.4492 ian_grigg_email.txt
2 = 4.4639 hal_finney_all.txt
3 = 4.474 lesswrong_not_wei_0.txt
4 = 4.474 eliezer_yudkowski_not_wei.txt
5 = 4.4774 gavin andresen cleaned.txt
6 = 4.4861 wei_dai_comments2.txt
7 = 4.4894 satoshi_all.txt
8 = 4.4987 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.33

Quad with punctuation
1 = 4.5521 ian_grigg_email.txt
2 = 4.5599 hal_finney_all.txt
3 = 4.5604 wei_dai_comments2.txt
4 = 4.5606 lesswrong_not_wei_0.txt
5 = 4.5606 eliezer_yudkowski_not_wei.txt
6 = 4.5644 gavin andresen cleaned.txt
7 = 4.5647 satoshi_all.txt
8 = 4.5685 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.17

Missing middle pair with punctuation
1 = 4.5507 satoshi_all.txt
2 = 4.5513 hal_finney_all.txt
3 = 4.5517 ian_grigg_email.txt
4 = 4.5517 gavin andresen cleaned.txt
5 = 4.5535 wei_dai_comments2.txt
6 = 4.5551 eliezer_yudkowski_not_wei.txt
7 = 4.5551 lesswrong_not_wei_0.txt
8 = 4.5553 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.01

Single
1 = 2.7665 ian_grigg_email.txt
2 = 2.8084 adam_back_cypher_cleaned.txt
3 = 2.8551 lesswrong_not_wei_0.txt
4 = 2.8551 eliezer_yudkowski_not_wei.txt
5 = 2.9284 gavin andresen cleaned.txt
6 = 2.9405 wei_dai_comments2.txt
7 = 2.9722 hal_finney_all.txt
8 = 3.105 satoshi_all.txt
(2-1)/2 %: 1.51

Pair
1 = 3.9848 ian_grigg_email.txt
2 = 4.0043 gavin andresen cleaned.txt
3 = 4.035 wei_dai_comments2.txt
4 = 4.0362 satoshi_all.txt
5 = 4.0441 hal_finney_all.txt
6 = 4.0505 eliezer_yudkowski_not_wei.txt
7 = 4.0505 lesswrong_not_wei_0.txt
8 = 4.053 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.49

Missing middle
1 = 4.0294 gavin andresen cleaned.txt
2 = 4.0417 ian_grigg_email.txt
3 = 4.0561 wei_dai_comments2.txt
4 = 4.0789 satoshi_all.txt
5 = 4.0809 eliezer_yudkowski_not_wei.txt
6 = 4.0812 lesswrong_not_wei_0.txt
7 = 4.0879 hal_finney_all.txt
8 = 4.0966 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.31

Missing pair middle
1 = 3.9951 gavin andresen cleaned.txt
2 = 4.0077 ian_grigg_email.txt
3 = 4.0378 wei_dai_comments2.txt
4 = 4.0478 satoshi_all.txt
5 = 4.0481 hal_finney_all.txt
6 = 4.054 eliezer_yudkowski_not_wei.txt
7 = 4.054 lesswrong_not_wei_0.txt
8 = 4.0708 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.32

Triple
1 = 4.4949 ian_grigg_email.txt
2 = 4.4957 hal_finney_all.txt
3 = 4.5012 gavin andresen cleaned.txt
4 = 4.5081 satoshi_all.txt
5 = 4.5118 wei_dai_comments2.txt
6 = 4.5126 lesswrong_not_wei_0.txt
7 = 4.5126 eliezer_yudkowski_not_wei.txt
8 = 4.516 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.02

Missing left
1 = 4.4923 ian_grigg_email.txt
2 = 4.4963 hal_finney_all.txt
3 = 4.4984 gavin andresen cleaned.txt
4 = 4.5033 satoshi_all.txt
5 = 4.5078 wei_dai_comments2.txt
6 = 4.515 eliezer_yudkowski_not_wei.txt
7 = 4.515 lesswrong_not_wei_0.txt
8 = 4.5218 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.09

Missing right
1 = 4.4967 ian_grigg_email.txt
2 = 4.5032 gavin andresen cleaned.txt
3 = 4.505 hal_finney_all.txt
4 = 4.5113 lesswrong_not_wei_0.txt
5 = 4.5113 eliezer_yudkowski_not_wei.txt
6 = 4.5153 wei_dai_comments2.txt
7 = 4.5184 satoshi_all.txt
8 = 4.5208 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.14

Quad
1 = 4.5611 ian_grigg_email.txt
2 = 4.5624 gavin andresen cleaned.txt
3 = 4.5626 wei_dai_comments2.txt
4 = 4.5651 hal_finney_all.txt
5 = 4.5653 satoshi_all.txt
6 = 4.5661 eliezer_yudkowski_not_wei.txt
7 = 4.5661 lesswrong_not_wei_0.txt
8 = 4.5669 adam_back_cypher_cleaned.txt
(2-1)/2 %: 0.03

Tuesday, May 29, 2018

Using coin fees to internally evolve intelligence and law


Posted to Zcash grant proposal issue

Each message (sent in the memo field of BTC-like coins) could be news or a proposed law. The community would automatically elect to finance or starve the writer or proposed law via direction of required fees from each recipient. It's required, but the recipient would select if the fee goes to the sender of the message (or to finance the law) or to be destroyed, sent to devs, or sent back to the chain (giving the protocol permission to issue more coin in the future, enabling a cycling of coin through an internal economy)

Senders of news must also pay to send messages with similar options. They would remove recipients who elected to not direct the fee to the sender. There would be a cap on messages per block, so only highest paying senders get to send. So there would be an evolution towards getting the "best" (most popular) news or other info.

The coin would have a reason for existing that is not threatened by any other coin. There would have to be a different coin for many different sources of information because it needs 2 tx per recipient per message. The message would be the recipient's decryption key for an RSA-encrypted article somewhere on the internet.

This could be used to select and finance a president anonymously based on the quality of his "orations". He would reveal himself at the beginning of a coup that he plans, and possibly finances via the fees received.

This is representation in exchange for taxation, automatically selecting the best representation.

The fees would need to be expressed in constant value which can be determined accurately over years by the coin's difficulty and a bounded estimator to get a Moore's law adjustment, provided the POW does not change and no algorithmic breakthroughs occur.

Wednesday, April 11, 2018

POW idea optimized for cell phones and CPUS

Cell phones should be able run the following algorithm more efficiently than ASICs and FPGAs at about the same electrical cost as GPUs and CPUs ... if you can write a routine to create a general class of functions from a seed that has the following characteristics:

1) Input size equal to output size, say 64 bits.
2) The class is complex enough to not be optimizable as a class (hence ASICs and FPGAs are not useful)
3) The class has an upper and lower bound on computation time for a given "CPU"

The last item seems to require a similar distribution of operations and a restricted way of using them. This would make achieving the 2nd to last item more difficult. To relax the computation time bounds in the last item without risking miners abandoning slow functions and going to the next nonce, the nonces must be in sequence.

The POW solution is then:


myhash = ffx32 
unless (myhash < target) {
   nonce++
   j =  hash(previous block hash + nonce)
   for (1 to 100)  { 
       j++
       function = generate_function( hash( j ) )
       for  (k=1 to 100,000) {
           input=output
           output = function( input )
       }
   }
   myhash = hash(output)
}
if ( myhash < target ) { claim my block }


The goal is to make memory useless and try to make the "CPU" burn as much electricity as possible. This is not more "polluting" or "wasteful" than investing in more hardware to avoid electrical expense.

The extra cost is similarly a waste of resources like electricity. For the most part that cost (like all costs) is also ultimately tied to a fuel cost or fictitious asset prices.

The amount of economic resources wasted to mine a coin per block is directly proportional to the dollar reward per block, which is equal to the difficulty times a proportionality constant. When x = the leading zeros of the target, the following should be approximately true for all coins:

2^x * difficulty = j * wasted dollars of fuel per block = k * dollar reward per block
where j is about 1/2 k and both are constants that should be about the same for all coins.

==========
https://github.com/monero-project/monero/issues/3545#issuecomment-380678092
https://github.com/zcash/zcash/issues/1211

>The rules that your automaton operates under are the actual instructions that matter, and again, they're fully known in advance.

They're not known in advance because I am changing the "automata" algorithm 100 times per nonce. See my psuedocode above. I thought of automata because I knew off-hand some classes can't be solved for "N loops" into the future without having already run the recursion itself. Then I remembered most real world differential equations are the same. My psuedocode is more general than either. The recursiveness was needed to address the problem of unknown execution time. Otherwise, I'm not arguing for something different than your idea. I'm trying to make it work and optimize it for cell phones.

Cryptnight's algorithm is known in advanced but ours' are not. My smaller instruction set is optional, but I wanted to pick instructions that are more efficient on RISC cell phones than on CPUs and GPUs. I didn't want complex instructions that are not implementable directly and completely on a RISC chip. A simpler instruction set may also enable better control of execution time and theoretical characterization of what the results will be.

To try to address your complaint about a simpler instruction set, suppose I have 5x more combinations of instructions than your scheme but use only 4 instructions. Then I would have 4^5 =1024 advanced instructions in each group of 5 instruction. Even 1 instruction is feasible: All javascript is expressible in NAND or XOR instructions in a specific type of arrangement.

Let's say I use only the NAND gate (a simple binary if-then statement). My output every 1,000 loops will be hashed to get a new set of NAND gate combinations out of a possible 2^256 combinations. There could be more if needed. An FPGA or ASIC or GPU program would have to figure out a simplified version of the NAND gate 100 times per nonce. This is possible if the inner loop of 1000 is too many loops. So there's an upper limit on it. Also, the algorithm generating function loop of 100 has an upper bound: it's a slow algorithm that could be optimized by ASIC or GPU programmer, so the time to generate the next algorithm must not be a large fraction of the time to do the inner loop.

A larger instruction set has the same problems to the exact same extent if I use log2(javascript instructions) more combinations of NAND gates. Both schemes seem to need some bound on how the instructions can be combined in order to get approximately reasonable exceution, but that should not change this point.

I found the need to change your scheme by making it change the algorithm 100 times per nonce in order to get an averaging out of solvetimes to be approximately the same while preventing ASIC and GPU programmers from skipping nonces that give apparently slow algorithms. Generalized loops and skipping sections of code within our created algorithms are not feasible due to creating an unknown completion time, which is a deal breaker. I have an interior loop of 1,000 to keep the created algorithm 1000x smaller, but thiis just to make sure no one benefits from larger memory. This is for cell phone efficiency per instruction while negating the benefit of a large CPU cache.
=======
Skipping nonces: what I'm saying is that I don't think you have bounds on the time-difficulty of the generated algorithms, but that an ASIC could be designed to quickly recognize if an algorithm is going to be difficult to solve, so they'll skip it.

I can't see if you still disagree. In reference to ASIC complexity, as I was saying, as I would just use the smaller set of instructions a larger number of times to equal your larger set of instructions with fewer steps. I want to send it assembly meant for ARM processors and for it to be as difficult as your javascript. We can go so far beyond what an ASIC can predict, I'm trying to cheat by redirecting it's output to its input, enabling "only" 2^256 different functions on random 32 byte seeds.

I think the general method of a small instruction set is the only one that can have predictably similarly difficult functions like I'm saying seems absolutely necessary. With say 4 instruction (they might just be well-chosen bit operations) it seems possible to know what average amount of computation they have, and to prove the 4 selected will continually add complexity rather than going towards patterns like all 0's or all 1's.

It's not that I know a larger instruction set won't work. The problem is that I view the task of getting similar execute time to be less daunting with fewer instructions. BTC script had to exclude loops and other things for the same reason. And still many scripts can go bad. Fewer instructions might be useful in proving the algorithms are well-behaved.

I think not only limiting the type of instructions is needed, but probably also limiting how they can combine. This increases the risk of an ASIC optimization of the gneral class of algorithms you produce.

+, -, /, and * creates something wider in scope than power series which can approximate any function. But maybe it should be required to follow the rules of power series. Actually power series are recursive like automata and D.E.s, it does fit in well with my desire that the only loop be external to the "function". I'm been using "function" very unmathematically to mean "algorithm of any type", since I don't have those details worked out.

@zawy12's point that it [fewer instruction] makes future optimization less likely.

I don't think I said that. I don't view my scheme as more difficult for ASICs to "hack", but that I have more hope it will help the design process in creating an "algorithm generator" that has well behaved output and similar execution time.

There's another potential advantage to doing recursive simple steps "on chip". When you have a large algorithm full of a wide range of instructions that are not going to be native to the chip, there are delays from going back and forth to RAM. If you have an instruction set of say 256, and if they all need to have 64 bit inputs and 64 bit outputs and follow each other sequentially (in order to be well behaved), then a lookup table 3GB in size (or much less with compression) could be used instead of actually computing each sequence of 4 instructions. There may be ways around this like changing input data before instructions by a 1 to 4 bit shift based on something unpredictable, or similarly every instruction could have two inputs where one is the output of a previous instruction and the other is seed data.

Fewer instructions has the same problem with this, but I'm hoping a chip can go through more instruction than can be pre-implemented in a lookup table, faster than the time for a lookup-memory transfer in an ASIC. I probably need to use as many on-chip instructions as possible, supporting @hyc 's viewpoint. But my reasons for wanting to keep a limit on instructions remain.

GPUs as well as CPUs can use a lookup table, and may not be improved upon by ASICs, but I feel like this is a problem that should tried to be avoided, and but my starting point (same size inputs and outputs going from 1 instruction to the next) is seductively simple in terms of getting constant compute time and good behavior implemented.

If one of the two ways to foil lookup tables works, an ASIC may still implement the actual logic of every hard-to-compute pair, triple, and maybe quadruple sequence of complex instructions. It can't do every pair due to the large instruction set. Just implementing all non-redundant pairs of 256 instructions could be difficult. It would have a lot more flexibility in exploiting sequences of fewer instructions, so that's a +1 for @hyc . I mean it could easily optimize and implement every 5-instruction sequence of a 4-instruction set, naively giving it a 4x speedup, if it can be done as a fast as on chip. So I'll say I'll make the instruction set as large as I can as long as it stays on the chip, and as long as I can make them predictable in computation time and otherwise well-behaved. So maybe I'm in trevador's ball park.

My pseudocode (that I've been changing all day as I realized problems) applies as well to large sets as small: I think the recursion outside the algorithm as the only loop allowed is a requirement for this to work. Without it, the algorithm will have to be a lot more complex which means a lot of complicated memory usage that means too much room for GPU optimization. It's not that I'm that strongly against GPUs, but I don't the long drawn out process of GPU devs slowly increasing hashpower for a pecentage. It makes me think if GPU optimization can be done, there's a loophole for ASICs. Assembly code doable solely on the chip seems like it has the nice possibility of never becoming optimizeable.

If the algorithm generator can make algorithms with solvetimes +/- 5%, then my 100 algos per nonce is not needed, and 1 algorithm per block might be sufficient. I don't think you can get a routine to optimize the algorithm and automatically reprogram an FPGA that fast. But since GPUs could, I might still prefer the per nonce method.

Tuesday, February 27, 2018

Herbie the love bug and rise of the machines

The 1969 Disney movie "The Love Bug" seemed to hit the nail on the head via the philosophizing of artist Tennessee Steinmetz played by Buddy Hackett who has a very likable speech impediment.


- Well then, if everything you say about this car is true, it's already starting to happen.
- What's starting to happen?
- Us human beings. We had a chance to make something out of this world. We blew it. Another kind of civilization is gonna take a turn ... I'm sitting up on top of this mountain, right?
- Right.
- I'm surrounded by these gurus and swamis and monks, right?
- Right.
- I got some contemplation goin'. I see things like they are. I coulda told you all this was comin'.
- What's coming?
- Jim, it's happening right under our noses and we can't see it. We take machines and stuff 'em with information until they're smarter than we are. ... Pretty soon, you know what? The machine starts to think it is somebody. .... You follow me?
- Yeah. I think you were up on that mountaintop too long.
- You're not listenin' to me.
- Don't lose your grip, old buddy. This little car didn't do one thing tonight that can't be explained...
- I don't think you got the picture.

Friday, January 26, 2018

Fundamental limits of computing

Moore's law has almost come to a halt in our typical computing devices. By "typical" I mean based on silicon and non-reversible synchronous computing. Reversible computing might achieve a lot more, but it is a suspect idea due to quantum-based dispersion of precision in moving forward and backwards. Switching to something like carbon nanotubes could extend the limits, but those and any other material will still have limits based on causes like those below. Asynchronous computing has no limit, but breaking tasks up into parts for disparate computing has fundamental problems. On the other hand, brains are mostly asynchronous and capable.

The computing limit for irreversible synchronous non-quantum silicon computing is based on:

1) A logic device requires a certain minimum number of atoms.

2) Heat per bit change is released in irreversible computing, aka Landauer's principle, Q = T*k*ln(2). There may be a way around this. This does not change the basic limit in entropy cost that will ultimately come at an energy cost, but it might be capable of computing without a local increase in heat.

3) Probability of error increases as the energy we use to store or transmit a bit gets near Landauer's limit. I think the probability of error per computation or transmission is based on e^(-E/Q) where E is the energy per bit used to transmit or store the bit and Q is Landauer's limit. A modest 100 M transistor 3 GHz device would have an error every hour if E is 40x Q.

4) The speed of light is limited.

5) Atoms break apart if they get too hot.

6) The amount of heat a cold sink can extract out of a computing device is limited, even if it is only 1-layer thick.

In order for transistors to change state in step with each other, the distance across the chip is limited by the speed of light and the processor speed. The faster the processor, the smaller the chip has to be. For example, if the longest trace from the clock input to a remote transistor is 4x the chip die diameter and every transistor has to acquire the needed state in 1/4 a clock cycle, then the max diameter at 3 GHz owing to speed of light is 3E8 m/s / 3 GHz / 4 / 4 = 6 mm. This is approximately what is seen in current chips. Since the number of transistors increases as diameter squared, and the available size limit due to speed of light increases linearly with decreases in speed, more synchronous computing can be done with slower chip speeds. This also reduces the heat problem so that more layers of transistors can be used. This is why chip speed is not increasing. To take advantage of this (if we wnet to a slower speed), going to more channels (128 and higher instead of 64 bit) or more cores would be needed. More cores is currently the method that takes advantage of the largest die diameter allowed by the speed of light. A 3 MHz chip could do 1,000x more computing at a cost of 1,000,000x more transistors. It would not need to be 6 meters per side as this implies because it needs to dissipate 1,000x less energy per second which means it could be more layers thick.

Based on the speed of light, the above was pretty good at predicting current chip diameter. Now I'll try to predict chips speeds based on Landauer's limit. I explained energy usage per bit needs to be at least 40x Q to have 50% chance of error every hour. It only needs to be 50x to increase that to 1 error every 100,000 hours. I'll assume in practice it is currently 100x. I see a 14 nm AMD Ryzen 7 1800X chip has 4.8 billion transistors (14 mm per side) and uses a max of 95 Watts. This is not an intel chip, but intel says a 14 nm die has a max of 105 C. I'll guess transistors actually reach about 150 C locally. It's 4 GHz. I'll guess the average transistor changes state only 1/4 the time (once per 4 clock cycles). So, 100x Landauer's limit times the number of transistors times the clock speed divided by 4 = 100*(150+273 kelvins)*1.38E-23*ln(2)*4.8E9*4E9/4 = 2 watts. Actually, if every transistor needs to be able to not an error in 100,000 hours with my 2x energy safety/inefficiency factor, then the 1/4 maybe should not be applied., giving 8 watts in a weird adjusted basis. They seem to be wasting 95/8 = 12x more energy than the limit of what they could. The limit here seems to be chip temperature. They've made it as fast as they could without "melting". They've made the dies as big as they could for that speed. Smaller chip processes allow a squared factor (or more) of less energy usage while allowing a squared factor of more chips per die of the same size. So they can continue to make them smaller at the same speed and the heat profile will not change. The 50x limit implies they could go SQRT(12) = 3.5x smaller with my 100x estimate of a hard limit. That would be down to 14/3.5 = 4 nm. This is far from the limit based on heat dissipation. My assumptions could have made it 1 nm. I see 5 nm is scheduled for about 2020. Since atoms are only 0.2 nm wide, that must be getting close to the size limit before they have to resort to slower processor speeds to enable larger dies (or more layers).