Skip to content
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

Merged
merged 1 commit into from
Jan 24, 2024

Conversation

harding
Copy link
Collaborator

@harding harding commented Jan 13, 2024

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.

Copy link
Collaborator

@murchandamus murchandamus left a 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.
Copy link
Collaborator

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.

Copy link

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 :)

Copy link
Collaborator Author

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.

Copy link
Collaborator

@murchandamus murchandamus left a 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"
Copy link
Contributor

@vostrnad vostrnad Jan 18, 2024

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:

Suggested change
- title: "Presentation: compact multisignatures for smaller blockchains"
- title: "Presentation: Compact Multi-Signatures for Smaller Blockchains"

Copy link
Collaborator Author

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)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- title: "Question about schnorr signatures versus BLS signatures"
- title: "Question about Schnorr signatures versus BLS signatures"

Copy link
Collaborator Author

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.

## 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Boneh-Lynn-Shacham signatures (**BLS signatures**) are digital
BonehLynnShacham signatures (**BLS signatures**) are digital

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving as-is.

Copy link
Contributor

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).

Copy link
Collaborator Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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).
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
by Bitcoin and are not as well studied as [schnorr signatures][topic
by Bitcoin and are not as well studied as [Schnorr signatures][topic

@murchandamus
Copy link
Collaborator

@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.

@vostrnad
Copy link
Contributor

@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.

@fjahr
Copy link

fjahr commented Jan 19, 2024

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.

@harding
Copy link
Collaborator Author

harding commented Jan 23, 2024

@vostrnad re: using proper names in terms of art, I have two reasons:

  1. Mixing cases in the middle of a sentence makes skimming harder, as we use words starting with an upprecase character to help quickly identify that a new sentence has begun. Making writing easy to skim seems really important to me when working with professional readers who might already know 90% of this stuff and just need to find the part that's relevant to what they're currently working on.

  2. Any name in a term of art is eventually going to be lowercased if it gets used frequently enough---think "algorithm"---so we might as well go straight to lowercasing anything we expect to use frequently.

Copy link
Contributor

@bitschmidty bitschmidty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK changes from fcb2a53 and 5890e85

@bitschmidty bitschmidty merged commit 331f5a5 into bitcoinops:master Jan 24, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants