Newsletters: add #46 (2019-05-14) #141
Conversation
harding
force-pushed
the
2019-05-14-newsletter
branch
from
4773703
to
2db4827
Compare
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Hi, there were some slightly technical talks at MCC over the weekend that might warrant inclusion http://diyhpl.us/wiki/transcripts/magicalcryptoconference/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.) |
|
|
||
| - **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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
harding
changed the title
|
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` | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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
force-pushed
the
2019-05-14-newsletter
branch
2 times, most recently
from
d455660
to
5afb2e2
Compare
| 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 |
There was a problem hiding this comment.
@harding - I'd suggest dropping "(e.g. bech32 address)" unless you think it makes this sentence a lot easier to understand.
img/posts/segwit-savings.gnuplot
Outdated
| @@ -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 | |||
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
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
force-pushed
the
2019-05-14-newsletter
branch
from
5afb2e2
to
5873701
Compare
harding
force-pushed
the
2019-05-14-newsletter
branch
from
5873701
to
a763cea
Compare
|
A book's worth of content with the humility of being a newsletter. ACK a763cea. |
A newsletter with pretensions of being a book.