Perpetual Powers of Tau

中文

The Privacy & Scaling Explorations team is conducting phase 1 of a multi-party trusted setup ceremony based on the Zcash Powers of Tau ceremony. The goal is to securely generate zk-SNARK parameters for circuits of up to $2^{28}$ (260+ million) constraints. This means that the process will generate twice as many minus one (530+ million) powers of tau.

As long as one party in the ceremony behaves honestly and is not compromised, the entire setup is trustworthy.

To take part, please get in touch with EF's PSE team via the #ppot Discord channel (Join PSE's Discord server here).

---

Contents:

Contribution List

Notes on Procedure

Participating

Phase 2 Files

---

Ceremony progress

Participant ID	Identity	GPG key	Attestation
0001	Koh Wei Jie	Keybase	0001_weijie_response
0002	Kobi Gurkan	Keybase	0002_kobi_response
0003	Roman Semenov	Keybase	0003_roman_response
0004	Paul Peregud	Keybase	0004_paul_response
0005	Muhd Amrullah	Keybase	0005_amrullah_response
0006	Zachary Williamson	Keybase	0006_zac_response
0007	Youssef El Housni	Keybase	0007_youssef_response
0008	Mike Lapinski	Keybase	0008_mike_response
0009	Brecht Devos	Keybase	0009_brecht_response
0010	Vano Narimanidze	Keybase	0010_vano_response
0011	Zhiniang Peng	Keybase	0011_zhiniang_response
0012	Daniel Wang	Keybase	0012_danielw_response
0013	Kevin Lackner	Keybase	0013_kevin_response
0014	Koh Wei Jie	Keybase	0014_weijie_response
0015	Anonymous Cryptographer		0015_anon0_response
0016	Aurélien Nicolas	Keybase	0016_qedit_response
0017	Philip Stehlik	Keybase	0017_philip_response
0018	Cody & Jennifer Burns	Keybase	0018_cody_response
0019	Petr Korolev	Keybase	0019_petr_response
0020	Eduardo Antuña	Keybase	0020_edu_response
0021	Raziel Finkelton		0021_rf_response
0022	Roman Storm	Keybase	0022_roman_response
0023	Shomari Prince	Keybase	0023_shomari_response
0024	Vitalik Buterin	Keybase	0024_vb_response
0025	Stefan Deml	Keybase	0025_stefan_response
0026	Geoff Lamperd	Keybase	0026_geoff_response
0027	Alex Skidanov	Keybase	0027_alex_response
0028	Dimitris Apostolou	Keybase	0028_dimitris_response
0029	Gustavo Frederico	Keybase	0029_gustavo_response
0030	Anant Upadhyay	Keybase	0030_anant_response
0031	Golem Factory		0031_golem_response
0032	JosephC	Keybase	0032_josephc_response
0033	Oskar Thorén	Keybase	0033_oskar_response
0034	Igor Gulamov	Keybase	0034_igor_response
0035	Leonard Tan		0035_leonard_response
0036	Stefaan Ponnet	Keybase	0036_stefaan_response
0037	Chih-Cheng Liang	Keybase	0037_chihcheng_response
0038	James Zaki	Keybase	0038_james_response
0039	Wanseob Lim	Keybase	0039_wanseob_response
0040	Wei Tang	PGP key	0040_wei_response
0041	Evan Van Ness	Keybase	0041_evan_response
0042	Vaibhav Chellani	Keybase	0042_vaibhav_response
0043	Albert Ni		0043_albert_response
0044	Ying Tong	Keybase	0044_yingtong_response
0045	Ben Edgington	Keybase	0045_ben_response
0046	Tkorwin	PGP	0046_tkorwin_response
0047	Saravanan Vijayakumaran	Keybase	0047_saravanan_response
0048	R. Tyler Smith	Keybase	0048_tyler_response
0049	Jordi Baylina	Keybase	0049_jordi_response
0050	Koh Wei Jie	Keybase	0050_weijie_response
0051	Joseph Bebel	Keybase	0051_joe_response
0052	Zaki Manian	Keybase	0052_zaki_response
0053	Juan Leni	Keybase	0053_juan_response
0054	Jarrad Hope	Keybase	0054_jarrad_response
0055	Tyler Blaise Smith	Keybase	0055_tyler_response
0056	Auryn Macmillan	Keybase	0056_auryn_response
0057	Gísli Kristjánsson	Keybase	0057_gisli_response
0058	Rasikh Morani	Keybase	0058_rasikh_response
	Why the gap? See here
0078	Soham Zemse		0078_soham_response
0079	atheartengineer	PGP	0079_atheartengineer_response
0080	Carter Feldman	Keybase	0080_carter_response
0081	Aayush Gupta	Keybase	0081_yushg_response
0082	Ali Parvizi	Keybase	0082_ali_response
0083	Yi Sun	Keybase	0083_yi_response
0084	Jonathan P Wang		0084_jpwang_response
0085	zircuit		0085_zircuit_response
0085	nebra		0086_nebra_response

Transcript files

Note: as each challenge file can be deterministically generated from a prior response file, we have only backed up 34 challenge files on an IPFS node, and if we need to free up space on its storage device, we will delete some challenge files (except, of course, challenge_initial).

IPFS	Filename
Qmb1ejQ2uSXJ5AukYEGdm73Lf8q8vg2As2beC2eYENnDtB	challenge_initial
QmePmggNmSmzkJm3W1Kdz73FsUcdDpUGdvj466xTw9gjrg	challenge_0002_kobi
QmSQXLTHVCNQQE2wF7q8n2vhNmLjzKpPXwsGSYkGboKefo	challenge_0003
QmZ4qMYTRWKSWce2g2pose7v6maKGrrGG8HvtWPqxXyKxM	challenge_0004
QmZfYvb1eeE1uXvBGQWFXq169Gh79qsdcho169MM2BJ3Z7	challenge_0005
QmeNukSckT7gkD354aQfzLh6T7ZGv51gPmQQEi18BmSpiC	challenge_0006
QmQpAUqQ1jx8ABwmvw1kjUhFUcN8JM4D14BkE2roBrYtux	challenge_0007
QmdRxyVimSRsAJ4HkD9AiMSCCM2qw5nrEAJVzUJXT4VpGT	challenge_0008
QmQ1tzZi7PdHKE8VJczfHNgZbGSUp73viuytBoofcTnW1C	challenge_0009
Qmd1gtTpWCy4LP1eskdF5jD8daGMvMz7oGVajMoKwHKsWA	challenge_0010
Qmbf4UtTzdy3Cz56nXeom2fecB6ngYcryyitiVmYDTB4Za	challenge_0011
QmYzPUEZ8BPjFMXXcPo1WA6zaHERthXLPGAMR8sPrGajA1	challenge_0012
QmY7MKhMN8heRK5Nwe5yhraepArWc5YZJCfarae7R9QuR4	challenge_0013
Qmepq4FrnagYp31cT7vKuagfF8vgT6RShnRvTr6zMQswkW	challenge_0014
QmcXfTmYMqLF8iVmsD6phfXBke9DBiVecpbDh3TMfQphkG	challenge_0015
Qmdq2k8TJcKmZbVStqfT95fPc9xc3hJFRd2szFMjYDj2ke	challenge_0016
Qma9EftTTUy3d1aARcDJVAbSckEPNi54zUaVaWpFSZmgQZ	challenge_0017
QmPBEnbatu5FLuM3jhNbDVTVe6UZsLC12E5f6Puwu9q5g6	challenge_0018
QmNWQ5Uhh6MzpgMqGgJm25UCTtRhmDtwFBBLhYFaAAo1DS	challenge_0019
QmekMXZsfBi8DRebYXraSa6r8jSAVo6fBBJeLoirdR7j8N	challenge_0020
QmdkWnwsM3gHt7A8Gxq2JzhawKRuMvHLdxH4aDHPTt7w3F	challenge_0021
QmXwig4F7QqdDs8cCRHKZbzyUPxi1TVTrghqs2W28bLeUr	challenge_0022
QmWw14WEH7nokJHatEf7WUmqwrJEoAXjq25io39e4AkuSt	challenge_0023
QmQbBwhEBEuMBwtLt5NWxmY8AcjFxvELvmBcb5nHRKf8i8	challenge_0024
QmQGwrxQ5voS4nTCRNLtb9SNMThxCuViN2xtM7ffDLCzA6	challenge_0025
QmQGwsABWrAaZ2uHpV1jTV7ynnG4xx5qD9aDb15u1oY1rL	challenge_0026
Qmc22ur3YbFLtUS8mxSqqLCX39ksZUDr3PWi6wXUmmFKj4	challenge_0027
Qmduu6rvGM15TdGnVoW9zGXDYvtsAK1w8KdG5Jbo28Pomp	challenge_0028
QmakEigT1NfyjSJ1kkKZCnWGTnHkinU7u4ezc8dJdipMEK	challenge_0029
QmUcSPMVZgUb782zxfSofQvcF66sQbRfb5kWt9kjX61uPh	challenge_0030
QmYivuQ3QwaxZwSqoXWrWiMNdaKQNm96V4mU2VTHZZdjDc	challenge_0031
QmYGPfW1tuJFtBShGKeMbUKuKVe79dAsrjREG1ZceS21Cr	challenge_0032
QmU3LoELzGFcMKozE71xZL9gpq2mUnp5qPzE9KaorTfRxj	challenge_0033
QmNwMEu1dLv2XeCqXtVrdiQBVaQFWeNtVP7HdnPP2Xdkfd	challenge_0034
QmcdU9c71mTZGQnUGkkoXTrwtjyoTLPE2qp196VGCVgCuw	response_0001_weijie
QmPE7QAVRAVdDMMMP9rMbNyhZ8jo9pkZUm5ycRgogsHVAD	response_0002_kobi
QmUcPEstiXAFxYGKxCswXEgky69LvDrCLKamySrugW2Z4i	response_0003_poma
QmeKL2woTQHoUHpZEu8MKLv6mPdqz9xAwGkdpAAurpAAzV	response_0004_pepesha
QmQQZYBBbfgGmxLUjcq11bcuUPSQd1JCVkJ3rX8nqGVocU	response_0005_amrullah
QmS3hMyQ9hworRi27Hkc85eTUXDx6ciw2QzZd8KcUNHb2x	response_0006_zac
Qmc3yEq5QmckJwaQY8P1qEWSvfBYqCqMzB3q4mHYrZbZEk	response_0007_youssef
QmQiu9W8nutk8Bkh5yg3aaiCCmYKjbCm48g6B8hWK2KjDw	response_0008_mike
QmRrkQD44brXuaB9uw4gNvoJ5dHnkS3f2GrEhW9Jtz4Kff	response_0009_brecht
QmU3Zj589iK67W5pYHMJEiVTzHVCsL9AeGqnBLhq6kU2Ww	response_0010_vano
QmYtrvaTBn7ro9EBpiaDf4NWMxAKttKXDLww8rP2zbfesH	response_0011_zhiniang
QmXBJ5d86CJfZzcqSeaqVMuJki8V4wsLsPR5bsSG23QmtC	response_0012_daniel
QmYSGujwVYCUkQiktdadsC2Dr16EZGstXePhCzHBp6sqL2	response_0013_kevin
QmTQ2jJS2rDnZrXXNKM3XcHfWvfJPQy4tAnfKhLThT95YL	response_0014_weijie
Qme4NoJyfmVqFgUUUounmxtk7C35iXhTCCjroJc4AxrL5V	response_0015_anon0
QmaFR9E8sV4o8xijkUwXQdkjS9hHESKPXZ1CerMXTDvvFM	response_0016_aurel
Qmba1LQXD7gPHzrmjzPpzhX7Xb2oT1k3JQVS9Rqj1taxfp	response_0017_philip
QmQM5LnyiM4B78k6bA5c1MRDNscG19SBH66A5Txdc8BZ5u	response_0018_cody
QmZpi6iwSRtBi4HcRAdUMXBVqQAD8RQqat2yz4xtzVDgry	response_0019_petr
QmWDRdmXy3sWQB6c4hcwBKCdvzCdc6feTJrPyasjRtyyVj	response_0020_edu
QmTPhwttSdHcafGWnttTaXncT1pVUyjMc7dneNzbvSqcv6	response_0021_rf
QmWMFxs6zwocgmGsQQscpaUhAmwkPBjF4nHaXnVNw6pLsP	response_0022_roman
QmVghB15aA8r4f8kaDGYRPHNtvXpug5xuJy166T5aLjGnw	response_0023_shomari
QmSNRqBixRjqbaRFxe2G9dV5i7UHiQZLG3y6MQq29CQEJw	response_0024_vb
QmQzcXktWYsqxeioxyCa6wxQ1FvVoCyDfkAN9TdmmNpdvH	response_0025_stefan
QmZwshpsydtkRFtV5nuyhzL1yXE5AfacvVmPUNGTyJYYM5	response_0026_geoff
QmNeMWxbS7YSEaFEV3X1i3ETsHCyHcsZUQazkTiKZLWGph	response_0027_alex
QmcwjhjzUe5fWKsY21FJE1GdBFR4bxBvDAQbaLPgrUMAEw	response_0028_dimitris
QmU285xoCQJD17QovgYf41dri8KsVgr9DoN7uDjYAUDBWu	response_0029_gustavo
QmR6MjUDhqsqG8ALThdzSH1kSdqHg3VgKDXsRzLTPAVhzt	response_0030_anant
QmdKRFAch8rhuFZ7Z7u5AC6qfXgdfWGhBoR4UNmD5yHfwZ	response_0031_witold
QmVj2pziSXbPjSg6wV8YkAcfybhpYFrqugMJxXwNjhtEDG	response_0032_josephc
QmXokCVS2u7LUopyBMYAVaUjbMgSRU1uxstoSc85fqwssT	response_0033_oskar
QmWqCbXs5eFzesJ5bSRu2UNYh1UdyWr16Y49DC3BWp1RiT	response_0034_igor
QmYMzNLijTut9WYWVcCANc2gBN5Q48jGELgAQatujiXyCM	response_0035_leonard
QmPZr6aQMKxxj5FYW5cA6oYwE5bNLd8ehatRGXuSBkJehp	response_0036_stefaan
QmP1zXaVbnhUriMhVGnf55VKaZwffYTPwp3jUMj8P6LE24	response_0037_chihcheng
QmZPXXidBBiS1Vtx9sw1dBdy4WT4qaJ9291i5vd7GwGDTf	response_0038_james
QmQrf3YhCqGN1xWgag6ySxtSMzxaLvWEkm2MZFRzrEU2rk	response_0039_wanseob
QmTrSs9cd1mky6LzzTucE5YccecLZGWxBe39gNkezN6Jiw	response_0040_weitang
QmbddejirR8TFVo5yDydmHP8TvTFtEg3CTgnDywxbb6xfz	response_0041_evan
QmWCHp3YivYKWfQ8FbMKn3wMSNyqawRn7zJUP6mjfmvkJj	response_0042_vaibhav
QmUfSAM1arv3nB5StxMMk4qBYGFpSNEY2BDgz3dqmaYUQx	response_0043_albert
Qmbuueqz56RXJNniG2fBHzTodbQ5e5mtjGP7UdpNGNXP7P	response_0044_yingtong
QmSwjgfGupXdPp9YGkjTkS5HEJqduafTvwc2FGceuXuo7H	response_0045_ben
QmcxPbWVX1ZNyeoSmtauPSUr2N7TqHnHLA8XVfFbTvmt8B	response_0046_tkorwin
QmWWsdJQn8vW7Wpwz5AhgjT8Hx8Zi1dgrMvdaWY6gh8xkN	response_0047_saravanan
QmNSKeimtsCALSVS2pTaHzr51LQdiQgAwCcVcDG5QPSNqK	response_0048_tyler
QmcedV8NzSp9kxbYC7Gwwp3kRd3Gbzztm9fBcfX6uXkHTy	response_0049_jordi
QmfJA4GxM4g422wVaWiLNMwFvNRK4NhF3ZGguBHSVhakce	response_0050_weijie
QmPw8XM7jBrykitCuDPb3mW8j4U4fj3LJNnFejjDVSCmKG	response_0051_joe
QmSQMM6NJwZT5JFnm4sd3gyQsGV17PwsvjqZkWmZ6Aeqr9	response_0052_zaki
QmUSyF5fzsteBuTUiHfkepsaQeSaD5Xc84RMUXgygtLSL8	response_0053_juan
QmSnaPnTfwLeauYEd5ZDBnUePHh4dzxfnAZnC3wVxrQeJn	response_0054_jarrad
QmTiquUD89xYTtXq27tyFTVQunLadB8fjWe1pofFz2Dtws	response_0055_tyler
QmQR8SmRVNmhR4MJzVUwQpeiR34QgAqswYaX5jPBPFv8T7	response_0056_auryn
QmaiWt8rm9VGLrMQhJD6n3RzVffjFSHdyC1ZQaDQUNgBuH	response_0057_gisli
QmVZ9SMbh3ZSpLK2qtHZkqLDsX2Ac7kz9CeeuvAAz1QMLb	response_0058_rasikh

Prepared Phase 2 Files

Files have been prepared, ready for use in Phase 2 operations, from contribution 0080. The response file from 0080 was converted to snarkjs .ptau format, had a beacon applied, then prepared for phase 2. Files for each lower power of 2 were extracted from the result. These files are available at the links below.

The complete file with $2^{28}$ powers of tau, in .ptau format, can be found here

Beacon

Randomness for the beacon used the randao_reveal value from slot 7,325,000 of the Ethereum beacon chain. The choice of slot number was announced in advance, as recorded in this transaction

Randao_reveal value: 0xaf941599f6d640b5b4b6116d3ded861b3362a964c390edc270aef45ba17b67148fb3d7ab901a68b1528c9bb3e16721cc000dda5d8466f4aa4a1c8ca9eb57d05e6c2d2e780d6a793df90a1ebd076bb3dd9b7d4075e3e68b36b86c1fb7c4feeded, as per the block summary.

31 iterations were used in calculating the beacon hash.

The beacon file has been saved here

Prepared and Truncated Files

A phase-2-ready .ptau file is available for each power of 2 up to 28. When choosing a file, the best choice is generally the smallest file with a number of points > the number of constraints in the circuit.

Degree	Link to File	Number of Points	Size
1	ppot_0080_01.ptau	1	93kb
2	ppot_0080_02.ptau	4	95.6kb
3	ppot_0080_03.ptau	8	100kb
4	ppot_0080_04.ptau	16	109kb
5	ppot_0080_05.ptau	32	127kb
6	ppot_0080_06.ptau	64	163kb
7	ppot_0080_07.ptau	128	235kb
8	ppot_0080_08.ptau	256	379kb
9	ppot_0080_09.ptau	512	667kb
10	ppot_0080_10.ptau	1,024	1.2mb
11	ppot_0080_11.ptau	2,048	2.3mb
12	ppot_0080_12.ptau	4,096	4.6mb
13	ppot_0080_13.ptau	8,192	9.1mb
14	ppot_0080_14.ptau	16,384	18.1mb
15	ppot_0080_15.ptau	32,768	36mb
16	ppot_0080_16.ptau	65,536	72mb
17	ppot_0080_17.ptau	131,072	144mb
18	ppot_0080_18.ptau	262,144	288mb
19	ppot_0080_19.ptau	524,288	576mb
20	ppot_0080_20.ptau	1,048,576	1.1gb
21	ppot_0080_21.ptau	2,097,152	2.3gb
22	ppot_0080_22.ptau	4,194,304	4.5gb
23	ppot_0080_23.ptau	8,388,608	9gb
24	ppot_0080_24.ptau	16,777,216	18gb
25	ppot_0080_25.ptau	33,554,432	36gb
26	ppot_0080_26.ptau	67,108,864	72gb
27	ppot_0080_27.ptau	134,217,728	144gb
28	ppot_0080_final.ptau	268,435,456	288gb

Contribution Procedure

There is a coordinator and multiple participants. The ceremony occurs in sequential rounds. Each participant performs one or more rounds at a time. The coordinator decides the order in which the participants act. There can be an indefinite number of rounds.

The ceremony starts with the coordinator generating an initial challenge file, and publishing it in a publicly accessible repository.

The first participant downloads challenge, runs a computation to produce a response file, and sends it to the coordinator.

The coordinator will then produce a new_challenge file, and publish it along with the response. The next selected participant will then download new_challenge and produce a response, and the process repeats indefinitely.

Whenever a new zk-SNARK project needs to perform a trusted setup, they can pick the latest response, verify the entire chain of challenges and responses up to the selected response, and finally apply a random beacon to it. Next, they can move on to phase 2 of the trusted setup which is circuit-specific and out of scope of phase 1.

To illustrate this process, consider a Coordinator, two participants (Alice and Bob), and a zk-SNARK project author Charlie:

1. Coordinator generates challenge_0 and publishes it.
2. Alice generates response_1 and publishes it.
3. Coordinator generates challenge_1 and publishes it.
4. Bob generates response_2 and publishes it.
5. Coordinator generates challenge_2 and publishes it.
6. Charlie applies the random beacon to challenge_2 to finalise the setup.

The resulting public transcript should contain:

1. challenge_0
2. response_1
3. challenge_1
4. response_2
5. challenge_2
6. The random beacon
7. The final parameters

The random beacon

Zcash announced on their ceremony mailing list that they would use the hash of a specific Bitcoin block. They made this announcement before the block was mined. See:

https://github.com/ZcashFoundation/powersoftau-attestations/tree/master/0088

A similar process can be used for this ceremony. Note that mining difficulty has grown since 2018, so there is now slightly less entropy per Bitcoin block hash.

The transcript

The transcript can be fully verified as long as it is public and that there are no bugs in the code used to generate challenges and responses.

Participants can choose to be anonymous. If they choose to be publicly known, they should own a GPG keypair whose public key is known to be associated with their real-world identity, socially or via any other means.

Given the above, the transcript should contain all the challenge and response files, and the Blake2b hash of each file.

It should also contain an attestation for each response. This is a text file with:

• Blake2b hashes of the challenge received and the response generated
• A detailed description of the hardware and software that the participant used to generate the response.
• A detailed description of any security and anti-surveillance measures that the participant has used.

Additionally, it should contain each participant's GPG signature of their attestation, so as to assure the public that it was generated by the person who had claimed to have done so.

Archiving

The transcript files will generally be saved in an archival storage, i.e. not available for immediate access, but can be made available by request. Such requests will entail a delay while the file is retrieved, and the file will be available for a limited number of days before it returns to archival status.

To raise a retrieval request, please raise an issue in this repo with the names of the files required.

Preserving the Data

We have a network sharing the data via torrents, as an alternative to the S3 bucket. Volunteers to help with this are welcome to participate. See here

Logistics

Each challenge file is about 97G in size and each response file is about 49G. An Azure compute VM (Standard F4s with 4 vcpus and 8GB memory) takes about 24 hours to generate.

The coordinator is using AWS Cloud VMs to generate new_challenge files, and S3 Storage to host challenges and responses.

Each participant can transfer their response to the coordinator via sftp. This process is semi-interactive as it requires either the participant to provide their SSH public key in advance, or the coordinator to send them a private key. Alternatively, they can use any of the following interactive methods:

• BitTorrent
• IPFS
• Third-party large-file transfer services like MASV
• SFTP: You will be provided details on request

Instructions for each participant

There are two implementations of the software which you can use to generate a contribution: phase2-bn254 and snarkjs.

You should use snarkjs if you do not mind running the software for 2-3 days. If you have no preference, please decide at random.

To use phase2-bn254, follow the instructions below. To use snarkjs, read this document instead.

First, set up a Linux machine and install Rust and Cargo following instructions here.

Ensure you have the necessary build prerequisites:

sudo apt update && sudo apt install build-essential

Download and compile the required source code:

git clone https://github.com/kobigurk/phase2-bn254.git --branch master && \
cd phase2-bn254/powersoftau && \
cargo build --release

Download the challenge_nnnn file from the coordinator. The filename might be something like challenge_0004. Rename it to challenge:

mv challenge_nnnn challenge

Also check with the coordinator (or this repository) for the expected Blake2b hash of challenge.

Run the computation with challenge in your working directory:

/path/to/phase2-bn254/powersoftau/target/release/compute_constrained challenge response 28 2097152

You will see this prompt:

Will contribute to accumulator for 2^28 powers of tau
In total will generate up to 536870911 powers
Type some random text and press [ENTER] to provide additional entropy...

Make sure that it says 2^28 powers of tau, and then enter random text as prompted. You should try to provide as much entropy as possible from sources which are truly hard to replicate. See below for examples derived from Zcash's own ceremony.

The computation will run for about 24 hours on a fast machine. Please try your best to avoid electronic surveillance or tampering during this time.

When it is done, you will see something like this:

Finishing writing your contribution to `./response`...
Done!

Your contribution has been written to `./response`

The BLAKE2b hash of `./response` is:
        12345678 90123456 78901234 56789012 
        12345678 90123456 78901234 56789012 
        0b5337cd bb05970d 4045a88e 55fe5b1d 
        507f5f0e 5c87d756 85b487ed 89a6fb50 
Thank you for your participation, much appreciated! :)

Upload the response file to the coordinator's server using SFTP or rsync. We will provide you with options and guidance on how to do this.

Your attestation

Finally, document the process you used, following the example here: https://github.com/weijiekoh/perpetualpowersoftau/blob/master/0027_alex_response/alex_attestation.md

We recommend that in your attestation, you include the git commit hash of the phase2-bn254 repository from which you built the binaries.

Sign your attestation with your Keybase account or GPG key and post it to the mailing list. We highly recommend using Keybase instead of GPG as it is easy to make time-consuming mistakes when attempting to publicise and/or share GPG keys.

Signing an attestation with an Ethereum account

If you wish to sign your attestation using an Ethereum account instead of GPG, please SHA256 hash your attestation and use an account publicly associated with your identity and store it in this Notary contract using the register(bytes32 _hash) function. Send the transaction hash to the coordinator, who will include it in the transcript.

This Notary contract is simply:

pragma solidity 0.5.11;

contract Notary {
    mapping (bytes32 => bool) public hashes ;
    
    function register(bytes32 _hash) public {
        hashes[_hash] = true;
    }
    
    function check(bytes32 _hash) public view returns (bool) {
        return hashes[_hash];
    }
}

Examples of entropy sources

1. /dev/urandom from one or more devices
2. The most recent Bitcoin block hash
3. Randomly mashing keys on the keyboard
4. Asking random people on the street for numbers
5. Geiger readings of radioactive material. e.g. a radioactive object, which can be anything from a banana to a Chernobyl fragment.
6. Environmental data (e.g. the weather, seismic activity, or readings from the sun)

Note on Chain Fork

The chain of contributions now has two forks, branching after contribution number 0058. This choice has been made for the reasons outlined below.

Contributions from 0001 to 0077 form the first branch. Contribution 0078 chains from 0058, and this second branch is the one to be continued for future contributions.

We have a complete set of data available for the second branch. This is not the case for the first branch. Data, including public keys, for some of the contributions (0059 to 0071) are no longer available.

The discontinued fork remains valid. Contribution 0077 has the longest chain of contributions, and may be used in phase 2 setups. The chain of hashes can be confirmed by referring to the contribution details stored in this repository. However, a stronger cryptographic verification requires a continuous and complete chain of public keys in addition to the contribution hashes. Such data is embedded in .ptau files, as used by snarkjs. A snarkjs powersoftau verify command will cryptographically validate the full chain of public keys. Thus, it is not possible for us to generate fully-compatible .ptau files from 0077 or its immediate predecessors.

We have a complete history of public keys up to 0058, and for the branch continuing from there with 0078. We will, from time to time, publish .ptau files from this branch.

Note also that links referred to files in ppot.blob.core.windows.net bucket are no longer working. Some of these files are available on either IPFS or S3 high-availability, or S3 Glacier (available only by request).

Contribution details for the discontinued fork are recorded here