Add more information about the beacon

0088/README.md

@@ -1,12 +1,24 @@
 # Random Beacon
 
+* Mailing list post: https://lists.z.cash.foundation/pipermail/zapps-wg/2018/000337.html
+* [Signed announcement of the beacon](./beacon.txt.asc)
+* [Timestamp](./beacon.txt.asc.ots) of the beacon using [OpenTimestamps](https://opentimestamps.org/)
+
+Response file:
+
+* https://powersoftau-transcript.s3-us-west-2.amazonaws.com/88dc1dc6914e44568e8511eace177e6ecd9da9a9bd8f67e4c0c9f215b517db4d1d54a755d051978dbb85ef947918193c93cd4cf4c99c0dc5a767d4eeb10047a4
+
+Explanation:
+
 The random beacon is the 2^42 iteration of SHA256 over the hash of block 514200, with hash:
 
 ```
 00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58
 ```
 
-It's being computed currently. Here is a list of every 2^32 iterations currently computed.
+The process and code for calculating the beacon value was announced on the mailing list before the block appeared.
+
+Here is a list of every 2^32 iterations computed by the beacon (still being confirmed):
 
 ```
 0: 00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58

0088/beacon.txt.asc

@@ -0,0 +1,76 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA256
+
+Hi all,
+
+I covered the random beacon in a previous post on the mailing list:
+https://lists.z.cash.foundation/pipermail/zapps-wg/2018/000262.html
+
+The security proof for the ceremony requires that a random beacon is
+queried and applied at the end, like a simulated participant. The
+beacon's output can be somewhat influenced by an adversary, and it won't
+impact our security margins much. In any case, it's likely that security
+holds even if the beacon is totally compromised, we just haven't had
+time to write a proof of this yet. Also, if you think we used a bad
+beacon, you can just apply a better beacon yourself.
+
+I still wanted a strong and rigid beacon so there weren't any questions.
+This means using one source for the beacon. The strongest source I can
+imagine is a "delay function" applied to a Bitcoin block. As long as the
+delay function takes a long time to compute with respect to the average
+time between Bitcoin blocks (10 minutes) it becomes difficult to argue
+that a miner could have influenced the beacon much, if at all.
+
+The ideal delay function is an iterated SHA256 hash over the Bitcoin
+block hash. I think 2^42 iterations should be sufficient. (Note that
+this is not a proof-of-work function! The hashes are not
+parallelizable, so there's a practical limit to how fast this beacon
+can be computed on classical hardware.)
+
+The result of the beacon (the SHA256 digest at the end) will seed a
+ChaCha20 PRNG. I've written code for the beacon and placed it into my
+git repository.
+
+I'll be applying this to the block hash of block #514200.
+
+Hash of the most recent response file:
+
+    77fc8ccb a8550a6c 7255b82b 3352bb83
+    075fdc07 9a84beec 8175287a 6cf9b47f
+    89f49a29 1025da84 994753d8 3d9169d1
+    b370345f 367cb2db c18b2137 33c5b303
+
+Here's the (SHA256) hashes of the current code on my powersoftau repo:
+
+src/lib.rs:
+5f1a7703e78a4f5ad8b083b838b2672c35e75cf8dc17a55a32a38f5e30aa2ecb
+src/bin/beacon.rs:
+6043fe25ae68b547c74632f0573a5b65fc6f5a040c468d65ab9c2b6942f5d1dc
+src/bin/compute.rs:
+c0eeb6b496052a3f1a2f4b311690af94d639ef2a0d606c488f06776cf1684dba
+src/bin/new.rs:
+1bca0dc358548b1cd4fd6c7e2c1a053c244927e457a61ef6973f7bba539f1079
+src/bin/verify_transform.rs:
+dd73283c5f618af43147327063f7659d73870f9684c85f5c80514d9da16d1746
+Cargo.toml:
+7b686d1b308fcfe5023929100b84cfafbbfac8feae454ded4ceb6e7bece897d6
+Cargo.lock:
+346e03229383df01620de095c217a63b035c520db7dabdb24ec9d710567b342a
+
+Sean Bowe
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAEBCAAdFiEEA5XeClAnvgwfWvsDlWhCV9j4sDEFAlquxTsACgkQlWhCV9j4
+sDEnzxAAqEv7Bs/7l9xDQBfQ+7ty1Pz0+qdv6AhnjOTx1h+LggS7C4xWKr4cK+VR
+tFZk3ReTXSLmxANjZKj8dPi0A4/17fo415RhaR09JbHNqIft+0MtnvU5josJPUxJ
+NGQcTU3nvcPJK5SPv8PhWgKeHeogeeJ80b4PlVAsOwZOQ5eC92kcGuoSDfkOP+nS
+J7b8zErIfPsiPg4tbAYMINDxJSey6VI6Pqd02ayXYUSKBoAYe6dWQXfc+yvv2oTO
+ShfpGzzX6UQLz0GCz2AVwZOXF6Ij6dBOcYO3qkaxXOsKRbLAu4ky7WdBOqKjAzrJ
+OHnY5XRcOemF7dWNfmrMd+0hW12XGcpJoKKIU13//dq7E2aKLxHx4ErnII80mQvW
+vRLClQuZcHCi1L4Vtq9bpzKztRsYWdqZtSET3cwKPWt3+8Vw+z+fzhWksFlaQheC
+i1IQYmzppxTkgFP5cn4NQuGp4s20ZcVJmJLC/4uw8zrBmG09v7EV0VIhcK8ixA4S
+gbXJZzZOU/mBoFuBD/2XQr7+KP0cgbpeV8/Ww/UbPt3zUma6AgVQkCYx2ToxaZeF
+JmflkykJAcAJ9411ngQpHdJmgUxgRb+vcF5iozvDTA8LfRTKZAawFbG2dGBA++wJ
++7MOsPCwnCHLbmfvsARdW+YviZ+qvmJl5mZF12tVmGauh/5oGRU=
+=V+gB
+-----END PGP SIGNATURE-----