jonajosejg

c701 6f06 a004 4027 0908 0000 0e00 0080
d401 e000 a002 2402 0900 118c d002 400b
0009 d002 402b 0009 0e00 04b0 0000 0604
2fe6 4f22 d324 430b 0009 d324 430b 0009
d323 430b 0009 d323 430b 0009 d322 430b
0009 ee00 d321 430b 0009 7e01 e207 3e23
8bf8 d31f 430b 0009 d01e a00d 6001 d31e
430b 0009 a00e 0009 b058 0009 a00a 0009
b00a 0009 a006 0009 8800 89f0 8801 89f3
8802 89f5 afe8 0009 4f22 d014 a035 6001

jonajosejg

Nvidia GTX 1080 Ti Hashcat Benchmarks

Software: Hashcat v3.40-49-g20057d8, Nvidia driver 378.13

Accelerator: 1x Nvidia GTX 1080 Ti FE

Highlights

1. This card is clock-for-clock identical to the Titan X Pascal, so the numbers should not be new or surprising to anyone.

jonajosejg

Solving the 0-conf problem using forfeits

by /u/awemany

Overview

The problem of ensuring good security for unconfirmed transactions in Bitcoin is repeatedly discussed in the community. Right now these so-called 0-conf transactions are usually expected to be of low risk in the case of small amounts and face-to-face interaction of merchant and customer.

jonajosejg

Covert ECDH over secp256k1

If ECDH is used to establish a shared session secret for an encrypted connection, two elliptic curve points need to be transmitted (one in each direction) before encryption starts. In order to avoid being identifiable as a (specific) ECDH negotiation, ideally those two points are sent in a way that is indistinguishable from random.

This problem is easily addressed by using curves that support Elligator-style encodings: functions that encode a (subset of) elliptic curve points as sequences of bytes with no observable bias: (almost) every byte sequence corresponds to exactly one point, and the others correspond to none.

Unfortunately, no Elligator-style encoding is known for secp256k1.