Newsletters add #16 (2018-10-09) #72
Conversation
| layout: newsletter | ||
| lang: en | ||
| --- | ||
| This week's newsletter includes a summary of several notable talks |
There was a problem hiding this comment.
This is good, but I think the two paragraphs can be squashed and made less verbose. Something like:
This week's newsletter consists entirely of summaries of several notable talks presented at the Scaling Bitcoin workshop last weekend, since there was very little to report in our usual Action Items, News, and Notable Code Changes sections. We will return to our usual format next week.
| provided by Bryan Bishop. | ||
|
|
||
| For convenience, at the end of each summary we directly link to its | ||
| video and transcript (and paper, if available). We also indicate |
There was a problem hiding this comment.
I don't think I like the hard fork/soft fork/possible now classification. I don't like those terms in general, because they tend to hide complexity and nuance (eg if forward blocks were deployed with block interval reduced to one second, could current clients keep up with the tip? Does the terminology 'softfork' therefore make sense if no current clients can stay in consensus?). There have been suggestions for other classifications for consensus changes (eg https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013985.html), but for here I don't think that there's any need provide a classification, given that you're already giving a summary of the talk.
|
|
||
| *Research by Anthony (AJ) Towns* | ||
|
|
||
| This talk asks whether Bitcoin pays more for security than it needs to |
There was a problem hiding this comment.
I think it's important to include AJ's introduction "And this idea is also not endorsed by me, and I would just like people to think about it." Suggesting changes to Bitcoin's monetary policy is indeed playing with fire, and I wouldn't want to lead the angry internet mob to AJ's door :)
| often and less of their proof of work is wasted. | ||
|
|
||
| For two perfectly fair miners half a world apart, the network delay | ||
| can be about one second, meaning a small miner far away from most |
There was a problem hiding this comment.
How did you come to the one second delay?
There was a problem hiding this comment.
Years ago I'd occasionally need to ping servers in western Australia, which is within 500 miles of being the opposite side of the world from where I live, and the RTT was 700ms---so I rounded up to 1,000ms = 1 second. Now that I write that, I realize that RTT is 2x the minimum relay time, giving me 350ms which is in line with the figures I've found in a quick survey of Google search results suggesting 200ms is roughly the floor for practical packet routing. I'll update this footnote to use 200ms as a baseline.
Thanks for calling out my shoddy assumption!
| ## Footnotes | ||
|
|
||
| [^freq-pow-waste]: | ||
| When a miner creates a new block at the tip of the chain, he can |
There was a problem hiding this comment.
I like this footnote a lot!
| fundamental security assumption beyond those made by both Bitcoin's | ||
| current ECDSA scheme and proposed Schnorr scheme, the authors present | ||
| evidence that their scheme would produce smaller signatures in general, | ||
| be much more computationally efficient in some multisignature use cases, |
There was a problem hiding this comment.
I don't think 'be much more computationally efficient' is accurate. The presented scheme requires pairing operations. Even if a single pairing operation can be shared across multiple signature verifications, it is still some order(s) of magnitude slower than simple EC multiplications.
There was a problem hiding this comment.
Pieter has confirmed this. The BLS system always requires more computation because the pairing operation is more expensive. The system demonstrated by Neven in this talk reduces the number of pairing operations across aggregated signatures, but there always need to be at least two (one for the signatures/generator and one for the messages/pubkeys).
The advantage of the BLS system is that aggregation can be non-interactive.
|
|
||
| *Research by Conner Fromknecht* | ||
|
|
||
| At Scaling Bitcoin IV (Stanford 2017), Andrew Poelstra |
There was a problem hiding this comment.
This sentence is a bit long and unwieldy. Consider splitting to something like:
At Scaling Bitcoin IV (Stanford 2017), Andrew Poelstra [presented][scriptless scripts transcript] his existing "scriptless scripts" work. Scriptless scripts allow outputs to be encumbered with conditions in the same way that is currently possible with Bitcoin Script, but by using only Schnorr-based keys and signatures.
There was a problem hiding this comment.
Actually, I think this introductory paragraph should be less focused on general scriptless scripts, and more on reblinding the challenge in lightning routes. As far as I'm aware, this concept was introduced in Andrew Poesltra's mailing list post here: https://lists.launchpad.net/mimblewimble/msg00086.html and required the linear property of Schnorr signatures to be able to aggregate 2-of-2 multisignatures into a single signatures.
I don't think that there are efficient ways of doing general threshold signatures in ECDSA, but last year Yehuda Lindell published a paper for efficient 2-of-2 signatures (https://eprint.iacr.org/2017/552), which was applied to lightning routes in the Multi-hop locks paper (https://eprint.iacr.org/2018/472.pdf). This talk was about making a working implementation of that scheme.
The non-linearity of ECDSA makes those 2-of-2 aggregate signatures a lot more complex to produce, but Conner argued that:
- we'll want the reblinded challenge in lightning when/if schnorr signatures are available
- doing it now with ECDSA allows a graceful upgrade path (since 2P-ECDSA lightning channels could interop with Schnorr lightning channels)
- it may be better to just do it now with ECDSA while the lightning network is small.
There was a problem hiding this comment.
I've just confirmed the above with Andrew Poelstra.
| *[video][vid accumulators], [transcript][tx accumulators], soft fork for | ||
| new applications such as UTXO set commitments* | ||
|
|
||
| ### Scriptless ECDSA |
There was a problem hiding this comment.
The name of the talk was "Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin". I think a better heading for this section would be "Implementing two party ECDSA" or similar.
There was a problem hiding this comment.
I think "two-party ECDSA" is an unfamiliar and non-descriptive term (isn't all ECDSA two-party, as in why could you create keys and sigs if it was just you? ;-) So I'm changing the title just slightly; however, feel free to change it to whatever you think is most approprate before merge.
There was a problem hiding this comment.
I think the new text for this section is excellent, but I think 'Scriptless ECDSA security for Lightning Network payment channels' still isn't quite right (isn't all ECDSA scriptless? 🙂). I'm going to change the section title to "Multiparty ECDSA for scriptless Lightning Network payment channels". I hope that's ok for you!
|
|
||
| - **Schnorr signature scheme:** an opt-in feature providing smaller | ||
| signatures in all cases, much smaller public key and signature data | ||
| for cooperative multisigs, and faster validation. Easier |
There was a problem hiding this comment.
'Easier compatibility with scriptless scripts' is an incomplete sentence. Perhaps squash with previous sentence?
| *[video][vid scriptless ecdsa], [transcript][tx scriptless ecdsa], possible | ||
| now* | ||
|
|
||
| ## Discussion wrap-up: the evolution of bitcoin script |
There was a problem hiding this comment.
I didn't attend this talk, so I can only rely on the transcript. Everything below looks fine to me.
|
Also Bitcoin Edge Dev++ took place during the 2 days prior to Scaling.
Many of the talks were focused on basic bitcoin data structures and concepts. There were a few forward looking presentations looking at things like applications of blind signatures, and another talk on taproot and graftroot. Also, there was an interesting presentation on security for companies in our industry which might be of general interest to the audience. There was also a Scaling transcript from a workshop about script advancements: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/bitcoin-script/ Additionally, there are some transcripts from another meetup including:
|
| [pairing-based cryptography]: https://en.wikipedia.org/wiki/Pairing-based_cryptography | ||
| [bls sigs]: https://en.wikipedia.org/wiki/Boneh%E2%80%93Lynn%E2%80%93Shacham | ||
| [forced fork]: https://petertodd.org/2016/forced-soft-forks | ||
| [scriptless scripts transcript]: https://scalingbitcoin.org/transcript/stanford2017/using-the-chain-for-what-chains-are-good-for |
There was a problem hiding this comment.
That's not the best link for a transcript about scriptless scripts; I like these:
There was a problem hiding this comment.
Actually, nevermind. It's not so bad. It just has no headings.
| watchtowers that send breach remedy transactions on behalf of offline | ||
| users, or it could be useful for fee bumping group transactions. | ||
|
|
||
| However, the presenter concluded this section of the wrap-up by saying, |
There was a problem hiding this comment.
This section should be attributed to a member of the workshop; it wasn't @Roasbeef that said this quote.
| matter how many elements are members of the set, adding or removing | ||
| elements from an accumulator can be efficiently batched (e.g. one update | ||
| per block), and validation that one or more elements are members of a | ||
| set could potentially be much faster (although this has not yet been |
There was a problem hiding this comment.
I'm not sure I'd add this last point about being faster. See the section "Too Slow?" in the transcript. Although the proofs are smaller and constant size, the verification time does increase with the number of elements.
My understanding is that the RSA accumulator is still slow compared to hash-based systems, and classgroup performance is completely unknown.
| {% include references.md %} | ||
|
|
||
| [videos]: https://tokyo2018.scalingbitcoin.org/#remote-participation | ||
| [transcripts]: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/ |
There was a problem hiding this comment.
(please consider using https for the diyhpl.us server links)
|
@kanzure I did see the Edge Dev++ transcripts and I was initially going to include some of them in this newsletter, but I think this newsletter is already bordering on too long (and is probably over the line on too complicated). Also, by the time I opened this PR, I was a bit fatigued from trying to summarize topics I know I haven't fully digested yet. @jnewbery made the suggestion that we consider including shorter summaries of some of the Edge Dev++ talks in next newsletter as it'll probably also be a relatively light news week with many people still in Tokyo. For the CoreDev.Tech transcripts, I will probably include regular News items in next week's newsletter based on some of them. As always, thank you very much for transcribing! It would not have been possible for me to have written even these few summaries this weekend if I didn't have the transcripts to refer to. |
harding
force-pushed
the
2018-10-09-newsletter
branch
from
b2ee2b1 to
70a2df1
Compare
|
I believe I've addressed all feedback (many thanks for it!) and have pushed a fully-squashed updated commit to this branch. In a separate branch I made each set of updates to a particular bit of feedback in a different commit and labeled them with the username of the person who provided the feedback, so you can look over there if you're wondering what I changed. An additional change not requested was that I added a Special Thanks section thanking the people y'all told me helped us with this newsletter. The section does note that any remaining errors are my fault. If you see anything that needs to be edited tomorrow (publication day), please feel free to make the changes yourself as usual. Have a good remainder of CoreDev.tech and safe travels! |
|
Great stuff. Thanks Dave! I've made only one small change - the section title for the 2P-ECDSA talk. ACK 09dacf0. Will squash and merge later today and send the newsletter out before Tuesday morning east coast time. |
jnewbery
force-pushed
the
2018-10-09-newsletter
branch
from
09dacf0 to
76b1122
Compare
) (#1260) Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com>
…itcoinops#72) (bitcoinops#1260) Co-authored-by: editor-Ajian <34365188+editor-Ajian@users.noreply.github.com>
As mentioned in the introduction, it completely focuses on Scaling Bitcoin because there was no other news. (Seriously: this week a total of only 8 minor commits for Bitcoin Core, 4 for LND, and 0 for C-Lightning; only one thing I could find that possibly qualified as news and it was pretty lame.)