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 #16 (2018-10-09) #72

Merged
merged 1 commit into from Oct 9, 2018

Conversation

@harding
Copy link
Contributor

harding commented Oct 7, 2018

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

Copy link
Contributor

jnewbery left a comment

Looks great! I've added a few comments, but this is a really great summary, and you picked out exactly the talks that I would have chosen. I think our readers are going to really enjoy this.

layout: newsletter
lang: en
---
This week's newsletter includes a summary of several notable talks

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

How did you come to the one second delay?

This comment has been minimized.

Copy link
@harding

harding Oct 8, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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,

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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.

This comment has been minimized.

Copy link
@harding

harding Oct 8, 2018

Author Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 9, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

'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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

I didn't attend this talk, so I can only rely on the transcript. Everything below looks fine to me.

@kanzure

This comment has been minimized.

Copy link

kanzure commented Oct 8, 2018

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

This comment has been minimized.

This comment has been minimized.

Copy link
@kanzure

kanzure Oct 8, 2018

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,

This comment has been minimized.

Copy link
@kanzure

kanzure Oct 8, 2018

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Oct 8, 2018

Contributor

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/

This comment has been minimized.

Copy link
@kanzure

kanzure Oct 8, 2018

(please consider using https for the diyhpl.us server links)

@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Oct 8, 2018

@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 harding force-pushed the harding:2018-10-09-newsletter branch from b2ee2b1 to 70a2df1 Oct 8, 2018
@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Oct 8, 2018

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!

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Oct 9, 2018

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 jnewbery force-pushed the harding:2018-10-09-newsletter branch from 09dacf0 to 76b1122 Oct 9, 2018
@jnewbery jnewbery merged commit 0e106f2 into bitcoinops:master Oct 9, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.