8000 fix(content): fix BLS signature aggregation language · filecoin-project/specs@2fad89b · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Commit 2fad89b

Browse files
StebalienStebalien
authored
fix(content): fix BLS signature aggregation language
1. Messages, not transactions. I only fixed this for BLS signatures, we need to fix the rest of the spec separately. 2. We're relying on the first condition, not the second. 3. We're not "aggregating the transaction's signature of a block". Transactions don't sign blocks. We're aggregating all BLS message signatures within a single block. 4. I removed the final sentence about transaction validity. It doesn't seem to say anything useful, and I'm not entirely sure what it was trying to convey.
1 parent d52fe97 commit 2fad89b

File tree

1 file changed

+8
-10
lines changed

1 file changed

+8
-10
lines changed

‎content/algorithms/crypto/signatures.md

Lines changed: 8 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -114,7 +114,7 @@ candidates in recent blockchain systems:
114114
terms of grinding, which is a real concern in recent proof of stake systems.
115115
- BLS signatures are aggregatable: one can aggregate signatures from different
116116
signers into one single signature. This feature enables drastically saving
117-
space on the blockchain, especially when aggregating user transactions.
117+
space on the blockchain, especially when aggregating user messages.
118118

119119
**Aggregation Functionality**: The aggregation functionality is commutative and
120120
associative, enabling _partial_ aggregation. For example, given
@@ -130,14 +130,12 @@ of measures, as explained [here](https://crypto.stanford.edu/~dabo/pubs/papers/B
130130
- Prove knowledge of the secret key
131131
- Use a modified scheme (such as [BLS Multi Sig](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html))
132132

133-
Fortunately, Filecoin can enforce the second condition to safely use the
133+
Fortunately, Filecoin can enforce the first condition to safely use the
134134
aggregation property:
135-
Filecoin uses aggregation only for aggregating the transaction's signature of a
136-
block. Since Filecoin uses the account model to represent the state of the
137-
chain, each message for a given signer is used in combination with a nonce to
138-
avoid replay attacks. As a direct consequence, every transaction's message is
139-
unique thereby the aggregation is done on distinct messages. Obviously, the
135+
Filecoin uses aggregation only for aggregating message signatures within a
136+
single block. Since Filecoin uses the account model to represent the state of
137+
the chain, each message for a given signer is used in combination with a nonce
138+
to avoid replay attacks. As a direct consequence, every message is unique
139+
thereby the aggregation is done on distinct messages. Obviously, the
140140
**assumption** here is that the block producer **enforces that distinction** and
141-
the other miners will **check all transactions** to make sure they are valid.
142-
The validity of a transaction in Filecoin's context implies that the signature
143-
is correctly formed over the message with the correct nonce.
141+
the other miners will **check all messages** to make sure they are valid.

0 commit comments

Comments
 (0)
0