96b71a19de
Avoid Python-specific negative operation
2020-06-30 16:58:56 +08:00
9dc43957e2
a fix according to @protolambda comments
2020-06-18 03:39:51 +03:00
759185632f
Merge branch 'dev' into phase1-validator
2020-06-16 16:07:20 -06:00
58935c19d6
Move constant
2020-06-16 17:23:09 +01:00
df1a932534
Rename misleading variable all_secrets_are_revealed
2020-06-16 15:19:45 +01:00
4bc849bcc2
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-16 15:05:12 +01:00
4b8b3f2cbc
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-16 15:05:01 +01:00
a0175ca1b3
Merge branch 'dankrad-custody-256bit' into dankrad-custody-0.01bit
2020-06-16 07:15:00 -06:00
458d343497
Fix configs and put domain types to the same table
2020-06-15 21:15:11 +08:00
e80f6727dc
Merge branch 'dev' into dankrad-custody-256bit
2020-06-15 15:13:45 +08:00
f6d7dac30c
Change to 2**14 epoch (73 day) custody periods as per #1888
2020-06-13 15:15:37 +01:00
42a9f1afdf
Fix Legendre bit computations
2020-06-12 23:44:36 +01:00
04fb9926e8
Remove custody bits from phase 1 and tests
2020-06-12 17:16:08 +01:00
398fc833b8
Fix TOC
2020-06-12 12:07:31 +01:00
59b35afcd9
Refactor universal hash function
2020-06-12 12:04:30 +01:00
65c3417f90
Fix replace_empty_or_append, remove assert False & test
2020-06-12 11:53:32 +01:00
7bf491d49d
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-12 11:28:49 +01:00
0e8bba2ce3
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-12 11:28:30 +01:00
d41b6a5775
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-12 11:18:07 +01:00
31654d8bf4
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-12 11:17:44 +01:00
7c6280aa8e
Update specs/phase1/custody-game.md
...
Co-authored-by: Hsiao-Wei Wang <hwwang156@gmail.com>
2020-06-12 11:16:19 +01:00
3a4db69a20
Merge branch 'dev' into dankrad-custody-256bit
2020-06-01 18:45:22 -06:00
de03ebb143
many custody game formatting cleanups
2020-05-19 09:58:33 -06:00
3f0e58a8ed
add chunk challenge and response to block and operations
2020-05-19 07:50:05 -06:00
3851a26a0f
add phase 1 custody objects to custody-game.md
2020-05-19 07:34:06 -06:00
cdd0ed0f7b
Update to IETF BLS draft-irtf-cfrg-bls-signature-02
2020-05-09 11:48:48 +08:00
964bf42335
Fix type
2020-05-01 00:32:02 +01:00
d30f11a781
Fix lint
2020-05-01 00:16:00 +01:00
d58d7627b7
Fix toc
2020-04-30 19:25:18 +01:00
0e2931b9b3
All tests passed
2020-04-28 01:09:20 +01:00
2449db1bb6
Phase 1 block tests are working
2020-04-27 16:08:49 +01:00
ab2ee0e2c2
Restoring chunk challenges and testing
2020-04-24 17:06:27 +01:00
907c56dabd
Fix ToC
2020-04-05 15:47:59 +01:00
c3c24b4fc4
Fix lint
2020-04-05 15:35:11 +01:00
bf34fdf023
Fix ToC
2020-04-05 15:10:09 +01:00
ca6af0c2e9
256-bit custody atoms for better alignment with rest of the spec and greater efficiency
2020-04-05 14:39:00 +01:00
073f78efa1
Merge branch 'dev' into phase1-tests
2020-03-29 17:04:25 -06:00
d299b06a1c
fix custody bit calculation format
2020-03-16 09:52:27 -06:00
9b7e0ab2be
Fix error in custody bit computation
2020-03-13 17:15:25 +00:00
1293320675
Merge branch 'dev' into phase1-tests
2020-03-12 07:12:41 -06:00
b4c7481b35
Fix the misc table
2020-03-03 01:28:58 +01:00
129aa02cb3
support tests with SLOTS_PER_EPOCH * 256 vals
2020-02-10 17:56:05 -07:00
2a91b43eaf
Remove shard block chunking
...
Only store a 32 byte root for every shard block
Rationale: originally, I added shard block chunking (store 4 chunks for every shard block instead of one root) to facilitate construction of data availability roots. However, it turns out that there is an easier technique. Set the width of the data availability rectangle's rows to be 1/4 the max size of a shard block, so each block would fill multiple rows. Then, non-full blocks will generally create lots of zero rows. For example if the block bodies are `31415926535` and `897932` with a max size of 24 bytes, the rows might look like this:
```
31415926
53500000
00000000
89793200
00000000
00000000
```
Zero rows would extend rightward to complete zero rows, and when extending downward we can count the number of zero rows, and reduce the number of extra rows that we make, so we only make a new row for every nonzero row in the original data. This way we get only a close-to-optimal ~4-5x blowup in the data even if the data has zero rows in the middle.
2020-01-28 17:31:51 -07:00
f04a686db7
doctoc
2020-01-14 01:42:19 +01:00
702b253361
update configs for phase1
2020-01-13 19:50:36 +01:00
419b6a3250
config change, need more space for worst-case reveals
2020-01-13 19:00:24 +01:00
507a9afbfb
apply custody bit fix suggestion from Dankrad
2020-01-13 18:57:56 +01:00
4732c7beb1
merge in dev (v0.10) and fix reorg/lint issues
2020-01-13 18:55:21 +01:00
676e216beb
reorg specs by fork and move ssz out to own folder. make all of the build and link changes to support move
2020-01-10 11:55:13 -07:00
Hsiao-Wei Wang
ericsson
Danny Ryan
Dankrad Feist
dankrad
vbuterin
protolambda