On Thu, Sep 6, 2018 at 11:33 PM Tim Ruffing via bitcoin-dev
wrote:
> Now you can argue that the attacker is storing encrypted traffic today to
> decrypt it later.
That is the argument. We know for that state level parties are storing
unimaginable amounts of data for future decryption, that threa
Hi Tim
Thanks for the feedback.
I agree with all of Gregs answers.
> key. Together with the encrypted packet lengths, the entire data stream looks
> like random then,
> which is pretty useful against censorship resistance for example. (The only
> exception is that the
> stream will never start
On Fri, 2018-09-07 at 02:31 +, Gregory Maxwell wrote:
> Currently, Tor provides _no confidentiality at all_ in that threat
> model. Part of why I think this enhancement is interesting is
> because
> without it BIP151 doesn't actually add anything for those p2p
> connections running over Tor, b
Hi Jonas,
Great to see progress in this area. I have quite a few comments.
Post-quantum key exchange
=
I think that's overkill. Bitcoin has huge problems in the presence of a quantum
computer, and the
confidentiality of the P2P messages is the most minor one. If there is
Without commenting on the other merits of either proposal, the addition of the
service flag resolves bip151’s previously-discussed lack of backward
compatibility.
e
> On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev
> wrote:
>
> Hi
>
> During work on the implementation of BIP151 [1]
Hi
During work on the implementation of BIP151 [1] I figured out that the current
published proposal could be further optimized.
I wrote an overhauled BIP151 specification with some – partially radical –
changes.
Now it’s unclear to me if this should be published under a new BIP nr. or if it
is
