Newsletters: add 83 (2020-02-05) #334
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Pushed a small edit on the 16702 write-up (partially based on feedback from moneyball) |
jnewbery
reviewed
Feb 3, 2020
|
I read the newsletter but didn't scrutinize it closely. LGTM! |
|
ACK 084b2a2 |
adamjonas
reviewed
Feb 5, 2020
bitschmidty
force-pushed
the
2020-02-05-newsletter
branch
from
b4a114a
to
b6724a6
Compare
|
Added a commit for @adamjonas feedback, thanks for those catches. Squashed and merged. |
|
Oh! This was merged earlier than usual. Sorry, I've been caught up reviewing for today's review club session I'm hosting. Will still have a look. |
jonatack
reviewed
Feb 5, 2020
| However, there remains a risk that inexperienced developers will not | ||
| perform this step, and so it seems preferable to use Jonas Nick's | ||
| suggestion (relayed by Maxwell) of including the public key in the | ||
| data used to produce a deterministic nonce. |
There was a problem hiding this comment.
Just now on #secp256k1 irc:
08:05 <gmaxwell> https://bitcoinops.org/en/newsletters/2020/02/05/ is kinda odd
08:06 <gmaxwell> anyone ever find any implementation that verifies after in open source code in the wild?
08:06 <gmaxwell> I think it's strange to say " However, there remains a risk that inexperienced developers will not perform this step" regarding a pretty computationally expensive step that I don't ever recall seeing any implementation take.
08:08 <sipa> gmaxwell: agree
08:10 <sipa> harding: ping ^... perhaps it's better to say something like "However, the computational overhead of this approach may not be acceptable to many applications" or so
There was a problem hiding this comment.
08:17 <gmaxwell> (I think probably _we_ should do this in libsecp, optionally annd have it controllable with a context flag...because our signing is usually used in cases where performance doesn't matter)
08:33 <gmaxwell> I guess in bitcoin-core it kind of accidentally verifies after since it puts stuff in the mempool before relaying.
08:33 <gmaxwell> I think you could extract from the wallet via getraw a txn with a failing signature however.
08:41 <sipa> gmaxwell: no, even before that
08:41 <sipa> the script signing logic invokes validation
08:41 <sipa> to determine whether it's done signing
08:42 <sipa> though i'm not sure that failure at that level would e.g. not result in the invalid signature ending up in a PSBT or so
jonatack
reviewed
Feb 5, 2020
There was a problem hiding this comment.
ACK, LGTM.
Humble possible suggestion for notable changes next week: bitcoin/bitcoin#17585 affects RPC API users by deprecating the getwalletinfo label field, which has been superceded by labels.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.