-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topics: add several new topic pages #1467
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except for the comment I left on CISA
produce a single 16-vbyte [MuSig]topic musig]-style [scriptless | ||
multisigature][topic multisignature] that corresponded to the aggregate | ||
public key, proving that she controlled the private key for both of the | ||
original public keys. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I’m wrong, but I thought that full aggregation must be interactive, and only half-aggregation can be non-interactive, because only the s values can be aggregated non-interactively, aggregating the r values requires interaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the two concepts are a bit mixed up in this paragraph I think. In the case of halfagg any node can aggregate but the resulting signature would be 24-vbytes, see 2nd paragraph in the halfagg bip draft (motivation section): https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/half-aggregation.mediawiki. For fullagg only Alice can aggregate but the result would be a 16 vbyte signature. To make the (interactivity) downsides of fullagg clearer it would probably also be good to let the two outputs be controlled by different users.
I can suggest a bit more detailed version of the paragraph that distinguishes between halfagg and fullagg if that's ok for you @harding ? I am not sure if you were aiming for this to only be about halfagg for now though :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@murchandamus @fjahr thanks for the reviews! I've almost totally rewritten that topic page to separate full and half agg and describe other tradeoffs I'm aware of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK LGTM
- title: Library announced for BLS signatures | ||
url: /en/newsletters/2018/08/07/#library-announced-for-bls-signatures | ||
|
||
- title: "Presentation: compact multisignatures for smaller blockchains" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The actual title of the presentation:
- title: "Presentation: compact multisignatures for smaller blockchains" | |
- title: "Presentation: Compact Multi-Signatures for Smaller Blockchains" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna leave this as-is.
- title: "Presentation: compact multisignatures for smaller blockchains" | ||
url: /en/newsletters/2018/10/09/#compact-multi-signatures-for-smaller-blockchains | ||
|
||
- title: "Using Bitcoin-compatible BLS signatures for Discree Log Contracts (DLCs)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- title: "Using Bitcoin-compatible BLS signatures for Discree Log Contracts (DLCs)" | |
- title: "Using Bitcoin-compatible BLS signatures for Discreet Log Contracts (DLCs)" |
- title: "Using Bitcoin-compatible BLS signatures for Discree Log Contracts (DLCs)" | ||
url: /en/newsletters/2022/08/17/#using-bitcoin-compatible-bls-signatures-for-dlcs | ||
|
||
- title: "Question about schnorr signatures versus BLS signatures" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- title: "Question about schnorr signatures versus BLS signatures" | |
- title: "Question about Schnorr signatures versus BLS signatures" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving as-is per our style guide.
_topics/en/bls-signatures.md
Outdated
## Required. Use Markdown formatting. Only one paragraph. No links allowed. | ||
## Should be less than 500 characters | ||
excerpt: > | ||
Boneh-Lynn-Shacham signatures (**BLS signatures**) are digital |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Boneh-Lynn-Shacham signatures (**BLS signatures**) are digital | |
Boneh–Lynn–Shacham signatures (**BLS signatures**) are digital |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's wrong though? Authors of a work are combined with an en dash, not hyphen (or at least, I've never seen it done otherwise).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, but this is not a rule I care about.
excerpt: > | ||
Boneh-Lynn-Shacham signatures (**BLS signatures**) are digital | ||
signatures that provide a different set of tradeoffs compared to the | ||
ECDSA and schnorr signatures currently used in Bitcoin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ECDSA and schnorr signatures currently used in Bitcoin. | |
ECDSA and Schnorr signatures currently used in Bitcoin. |
allow non-interactive signature aggregation. For example, if Alice and | ||
Bob both independently sign the same transaction, a third party can | ||
combine their signatures into a single signature that proves both of | ||
them signed. By comparison, using a Bitcoin's existing [schnorr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
them signed. By comparison, using a Bitcoin's existing [schnorr | |
them signed. By comparison, using Bitcoin's existing [Schnorr |
combine their signatures into a single signature that proves both of | ||
them signed. By comparison, using a Bitcoin's existing [schnorr | ||
signatures][topic schnorr signatures], a single signature proving both | ||
of them signed can only be produce through an interactive protocol like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of them signed can only be produce through an interactive protocol like | |
of them signed can only be produced through an interactive protocol like |
signatures was added, miners could aggregate all signatures together | ||
before producing a block, allowing blocks to contain only a single | ||
signature, which would moderately improve onchain capacity and might | ||
speed block verification when cached verification was unavailable (e.g. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
speed block verification when cached verification was unavailable (e.g. | |
speed up block verification when cached verification is unavailable (e.g. |
before producing a block, allowing blocks to contain only a single | ||
signature, which would moderately improve onchain capacity and might | ||
speed block verification when cached verification was unavailable (e.g. | ||
during initial block download). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that with assumevalid
the vast majority of signatures already aren't validated during IBD.
during initial block download). | ||
|
||
BLS signatures are not directly compatible with the elliptic curve used | ||
by Bitcoin and are not as well studied as [schnorr signatures][topic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by Bitcoin and are not as well studied as [schnorr signatures][topic | |
by Bitcoin and are not as well studied as [Schnorr signatures][topic |
@vostrnad: We treat "schnorr" (and also "merkle") as common nouns according to our style guide which is why they are not capitalized. I forgot the detailed explanation why @harding prefers that, but figured that I could point out that it was by-design. |
@murchandamus You're right, I should have checked the style guide. Though I did grep the repo for uppercase "Schnorr" and found numerous instances, and also went online to try and find a single reliable source with lowercase "schnorr" and failed, so I'd very much like to hear that detailed explanation. |
ACK c22e5ae The CISA part looks good to me, I will keep it in mind to come back in the future and add more details. I am not as familiar with the other topics but I gave them all a light read and didn't notice any issues. |
@vostrnad re: using proper names in terms of art, I have two reasons:
|
c22e5ae
to
fcb2a53
Compare
fcb2a53
to
5890e85
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Includes some of the topics from #721 (all the ones I plan to do today; I'll open a new PR for additional topics at a later time).
Also includes a new topic category, "Invoicing", which is seeded with entries for BIP70, Offers, and LNURL.