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 62 (2019-09-04) #219
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,129 @@ | ||
--- | ||
title: 'Bitcoin Optech Newsletter #62' | ||
permalink: /en/newsletters/2019/09/04/ | ||
name: 2019-09-04-newsletter | ||
slug: 2019-09-04-newsletter | ||
type: newsletter | ||
layout: newsletter | ||
lang: en | ||
--- | ||
This week's newsletter relays a security announcement for LN | ||
implementations, describes a non-interactive coinjoin proposal, and | ||
notes a few changes in popular Bitcoin infrastructure projects. | ||
|
||
{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %} | ||
{% include references.md %} | ||
|
||
## Action items | ||
|
||
- **Upgrade LN implementations:** one or more issues that are scheduled | ||
to be disclosed at the end of this month affect older LN | ||
implementations. If you are using any of the following software | ||
versions, upgrading to a more recent version is [strongly | ||
recommended][cve ln]: | ||
|
||
- C-Lightning < 0.7.1 | ||
- LND < 0.7 | ||
- Eclair <= 0.3 | ||
|
||
## News | ||
|
||
- **SNICKER proposed:** Adam Gibson [posted][snicker email] to the Bitcoin-Dev mailing | ||
list with a [proposal][snicker] for *Simple Non-Interactive Coinjoin | ||
with Keys for Encryption Reused* (SNICKER), a method for | ||
allowing wallets to create coinjoins non-interactively in two steps, a | ||
*proposer step* and a *receiver step*. In the proposer step, | ||
Alice's wallet uses the block chain and UTXO set to find UTXOs for | ||
which she knows (or can infer) the owner's public key. | ||
She selects one of those UTXOs whose value is less than the amount | ||
controlled by her wallet and creates a proposed coinjoin between that | ||
UTXO and her wallet's UTXOs, producing three outputs: | ||
|
||
1. Coinjoin output to Alice | ||
|
||
2. Coinjoin output to the owner of the selected UTXO (Bob). Both | ||
coinjoin outputs pay the same amount to make them indistinguishable | ||
to third parties looking at the block chain | ||
|
||
3. Change output to Alice returning any of her money in excess of the | ||
coinjoin amount | ||
|
||
Addresses that already have transaction history can't be reused or the | ||
privacy benefits of coinjoin are lost, so Alice generates new unique | ||
addresses for her two outputs. However, Bob has no way in this | ||
non-interactive protocol to tell Alice what addresses to use for his | ||
output. Instead, Alice can use Bob's public key and [Elliptic Curve | ||
Diffie-Hellman][ECDH] (ECDH) to derive a shared secret that Bob will | ||
also be able to derive from Alice's public key. With the shared | ||
secret and Bob's public key, Alice is able to create a new public key | ||
that only Bob can sign for. That new public key is used to create the | ||
new address for Bob's coinjoin output. No one besides Alice and Bob | ||
can tell the difference between the addresses, ensuring privacy for | ||
the coinjoin. | ||
|
||
With information about the inputs and the outputs, Alice creates a | ||
[BIP174][] Partially-Signed Bitcoin Transaction (PSBT) containing the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Each time I read "Partially-Signed..." it strikes me as a (minor, perhaps pedantic) grammar error. "Partially" can only be an adverb. IIUC, dashes are only appended to adverbs when they can also be adjectives (or other), to clarify when they play the part of an adverb and modify the word they precede. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm going to leave this as-is since I have a busy todo list today and we've used this construction many times before, but tomorrow I'll look into this in more detail and will either get back to you with an explanation or will open a PR to remove the hyphen across the repository. (Omitting the hyphen feels wrong to me and I have a vague recollection of a rule requiring (or at least suggesting) it, but I need to research it.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hyphens, thank you. As a recovering liberal hyphenizer before coming across the rule I mentioned, I'm interested in your conclusion. Could imagine a possible exception to the rule for titles or proper nouns. |
||
signatures for her UTXO or UTXOs. She can then upload this PSBT to a | ||
public server (and she can encrypt it so that only Bob can decrypt it). | ||
This completes the proposer step in SNICKER. | ||
|
||
If Bob participates in the scheme, his wallet can begin the | ||
receiver step by periodically checking the server to see if | ||
anyone like Alice has sent him a proposed PSBT. If so, Bob can | ||
evaluate the PSBT to ensure it's correct, add his signature for his | ||
UTXO to finalize it, and broadcast the transaction to complete the | ||
coinjoin. | ||
|
||
The key advantage of this proposal is that no interaction is required | ||
between Alice and Bob. They each perform their steps independently | ||
and aren't limited by having each other as potential partners. Alice | ||
can create as many proposals as she wants at no cost (except server | ||
storage space) and Bob can receive multiple proposals from different | ||
people via a variety of servers, selecting whichever proposal he | ||
prefers (or none at all). Either party can also spend their UTXO | ||
normally at any time, automatically invalidating any pending proposals | ||
without any harm done. The PSBTs can be exchanged using any medium that doesn't require users to identify themselves, | ||
such as a via a simple FTP server over Tor, making it easy for anyone to host a | ||
SNICKER exchange server. | ||
|
||
The main downside of the proposal is that it requires the proposer | ||
(Alice) know the public key of the receiver (Bob). Almost all | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: s/know/to know/ There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. alternatively, s/requires the/requires that the/ |
||
transaction outputs today pay addresses that don't directly include public keys, | ||
although that may change if the proposed [taproot][bip-taproot] | ||
soft fork is activated and becomes widely adopted. In the meantime, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. note that here ("widely adopted") you did not use a hyphen 👼 |
||
the SNICKER proposal suggests scanning for reused addresses where public keys | ||
have been revealed via the block chain, or by using a public key | ||
from the input of a transaction that creates a UTXO. For a more | ||
detailed overview of the proposal, see [Gibson's blog post][snicker | ||
blog]. | ||
|
||
## Notable code and documentation changes | ||
|
||
*Notable changes this week in [Bitcoin Core][bitcoin core repo], | ||
[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo], | ||
[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals | ||
(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* | ||
|
||
- [C-Lightning #3002][] makes several small changes to comply with | ||
recent updates to the [LN specification][BOLTs], including the | ||
[BOLT4][] update to remove the `final_expiry_too_soon` error message | ||
as described in [last week's newsletter][bolts608]. | ||
|
||
- [Eclair #899][] implements extended queries as proposed in [BOLTs | ||
#557][], allowing an LN node to request only gossip updates that | ||
arrived after a certain time or which have a different checksum than | ||
those the node has already seen. | ||
|
||
- [Eclair #954][] adds a sync whitelist. If empty, the node will sync | ||
its gossip store with any peer. If not empty, the node will only sync | ||
with the specified peers. | ||
|
||
{% include linkers/issues.md issues="3002,899,557,954" %} | ||
|
||
[cve ln]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002130.html | ||
[bolts608]: /en/newsletters/2019/08/28/#bolts-608 | ||
[bolts]: https://github.com/lightningnetwork/lightning-rfc/ | ||
[snicker]: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79 | ||
[ecdh]: https://en.wikipedia.org/wiki/Elliptic_curve_Diffie-Hellman | ||
[snicker email]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017283.html | ||
[snicker blog]: https://joinmarket.me/blog/blog/snicker/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proposed to Adam to drop by and have a look-see