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

Newsletters: add #46 (2019-05-14) #141

Merged
merged 1 commit into from May 14, 2019

Conversation

@harding
Copy link
Contributor

harding commented May 12, 2019

A newsletter with pretensions of being a book.

@harding harding force-pushed the harding:2019-05-14-newsletter branch from 4773703 to 2db4827 May 12, 2019
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
consensus changes. This is because the signature algorithm is only
looking for a single pubkey and a single signature that are valid under
rules described in the single-sig subsection above. That said, of the
methods known, the [MuSig protocol][] is probably the best studied

This comment has been minimized.

Copy link
@moneyball

moneyball May 12, 2019

Contributor

I think we should point out here that, compared with traditional OP_CHECKMULTISIG, Schnorr-based multisig requires interaction when signing, and, for k-of-n where k<n, requires interaction at key setup (at least for known protocols...I've no idea whether it is proven that this will always be required).

With the current Musig implementation, 3 rounds of interaction at signing are required, with sensitive state needing to be maintained between rounds. There is another design in the works that reduces this to 2 rounds and is stateless, but required several orders of magnitude more computation.

This comment has been minimized.

Copy link
@harding

harding May 13, 2019

Author Contributor

Right, I was hoping to avoid those details here because they're not directly relevant to the bip-taproot proposal. The point I want to make is that you can use any protocol you want as long is it produces a valid sig for a valid pubkey. There are ways known for creating aggregated pubkeys and signatures without interaction---they're just not secure against your counter signers. Maybe that isn't a problem for some application, so they can use that protocol. Or, as you say, maybe improvements will be made. I don't think those specifics matter in the context of bip-taproot; what matters is that we know aggregation is possible and that it's up to individiual application developers to choose how they want to do it and what tradeoffs they want to make.

_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
@kanzure

This comment has been minimized.

Copy link

kanzure commented May 13, 2019

Hi, there were some slightly technical talks at MCC over the weekend that might warrant inclusion http://diyhpl.us/wiki/transcripts/magicalcryptoconference/2019/

@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented May 13, 2019

@kanzure thanks! I don't have the time to include anything else non-trivial in this week's newsletter but I've got your link open in a tab and I plan to go through the transcripts as soon as I finish the edits for this week. (As always, thanks for typing the transcripts; their existence makes writing summaries for the newsletter so much easier for me.)

Copy link

ajtowns left a comment

nice work

_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
Copy link
Contributor

jnewbery left a comment

Looks great! I've left a few mostly stylistic nits inline. As always, feel free to ignore.


- **No activation mechanism specified:** if users decide they want to
begin enforcing the soft fork's new rules, safety requires that all
users begin enforcing the new rules at the same block. Various

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 13, 2019

Contributor

I think this is confusing. The point of a soft-fork is that users do not need to start enforcing

In a soft-fork, users explicitly do not need to start enforcing the new rules at the same block. I'd suggest changing the wording to "if users decide they want to begin enforcing the soft fork's new rules, safety requires that they know when other users are also enforcing the rules." or similar.

This comment has been minimized.

Copy link
@harding

harding May 13, 2019

Author Contributor

@jnewbery I've pushed an edit to rephase the bit about what's needed for soft fork activation, but I'm not entirely sure it satisfies your concerns. If we're not in agreement by tomorrow's publication deadline, I think this entire bullet can be deleted at merge time with no impact on the rest of the newsletter.

_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-05-14-newsletter.md Outdated Show resolved Hide resolved
@harding harding changed the title [WIP] Newsletters: add #46 (2019-05-14) Newsletters: add #46 (2019-05-14) May 13, 2019
@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented May 13, 2019

The newsletter is now complete and I believe I've addressed all feedback. However, I'm still happy to make more edits if anyone is crazy enough to read it again.

My deepest thanks to each of you for all of your excellent review comments and for your work, both past and present, on this amazing improvement proposal.

| Private key | (Same as above) | `0x807d[...]0101` |
| Public key | (Same as above) | `0x02e5[...]3c23` |
| Alter key prefix | (key[0] - 2),key[1:33]) | `0x00e5[...]3c23` |
| Address | bech32.encode('bc', 1, 0x00e5[...]3c23) | `bc1pqr[...]xg73` |

This comment has been minimized.

Copy link
@practicalswift

practicalswift May 14, 2019

What about including the full private key 0x807d[...]0101 to allow for using all the examples in the post as test vectors? I think that would be helpful.

This comment has been minimized.

Copy link
@harding

harding May 14, 2019

Author Contributor

@practicalswift test vectors are good, but I don't want to encourage people to write implementations based on an overview of the proposals. If anyone wants to write a toy implementation now, I'd highly encourage them to try to read only the proposed BIPs; that way they can identify any confusing sections or omitted details or other problems in what will be the primary sources for Taproot and Tapscript details---and they can then ask the BIP author to make edits while the document is still a discussion draft.

@harding harding force-pushed the harding:2019-05-14-newsletter branch 2 times, most recently from d455660 to 5afb2e2 May 14, 2019
For aggregation, two or more private keys are created and their pubkeys
are derived. The pubkeys are then combined into a single pubkey that's
indistinguishable from any other Bitcoin pubkey. This is used as the
segwit witness program (e.g. bech32 address) as described in the

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 14, 2019

Contributor

@harding - I'd suggest dropping "(e.g. bech32 address)" unless you think it makes this sentence a lot easier to understand.

@@ -3,6 +3,7 @@
set style line 1 lc rgb '#8b1a0e' pt 4 ps 0.25 lt 1 lw 2
set style line 2 lc rgb '#5e9c36' pt 4 ps 0.25 lt 1 lw 2
set style line 3 lc rgb '#0025ad' pt 4 ps 0.25 lt 1 lw 2
set style line 4 lc rgb '#7e2f8e' pt 4 ps 0.25 lt 1 lw 2

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 14, 2019

Contributor

blue-purple isn't the clearest contrast (eg for people with certain color blindness). Could you be persuaded to change this to purple-yellow or something else with more contrast?

trying to select what valid transactions to include in a block:
fee density (fee/vbyte) and sigop density (sigops/vbyte). This is
much more difficult than just optimizing block composition based on a
single parameter, such as fee density (feerate).

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 14, 2019

Contributor

I don't like that we have "fee density (fee/vbyte)" in the previous sentence and "fee density (feerate)" here. Suggested change: "fee density (fee/vbyte) and sigop density (sigops/vbyte). This is much more difficult than optimizing block composition based on just fee density."

@harding harding force-pushed the harding:2019-05-14-newsletter branch from 5afb2e2 to 5873701 May 14, 2019
@harding harding force-pushed the harding:2019-05-14-newsletter branch from 5873701 to a763cea May 14, 2019
@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented May 14, 2019

A book's worth of content with the humility of being a newsletter.

ACK a763cea.

@jnewbery jnewbery merged commit aecd9eb into bitcoinops:master May 14, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
netlify/bitcoinops/deploy-preview Deploy preview ready!
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.