On October 11th, 2022, @ajtowns publicly disclosed a zero-day consensus fault in btcd in a github issue. The issue was posted on a public repo viewable by anyone.
According to gharchive.org logs, the github issue remained up for at least 10 hours before being deleted. The original github issue resided at https://github.com/Roasbeef/btcd/issues/35
The issue and comment can be found and reconstructed from the following JSON dumps:
This translates sections [7.1.3][1] ("Reserved Identifiers") and [7.13][1] ("Future library directions") of the ISO C90 specification into English (and regexes).
This document will also cover the additions introduced by C99's section [7.26][3] ("Future library directions"), C11's section [7.31][4] ("Future library directions"), and C17's section [7.1.3][5] ("Reserved Identifiers").
| . 172800 IN DNSKEY 256 3 8 AwEAAcH+axCdUOsTc9o+jmyVq5rsGTh1EcatSumPqEfsPBT+whyj0/Uh D7cWeixV9Wqzj/cnqs8iWELqhdzGX41ZtaNQUfWNfOriASnWmX2D9m/E unplHu8nMSlDnDcT7+llE9tjk5HI1Sr7d9N16ZTIrbVALf65VB2ABbBG 39dyAb7tz21PICJbSp2cd77UF7NFqEVkqohl/LkDw+7Apalmp0qAQT1M gwi2cVxZMKUiciA6EqS+KNajf0A6olO2oEhZnGGY6b1LTg34/YfHdiII ZQqAfqbieruCGHRiSscC2ZE7iNreL/76f4JyIEUNkt6bQA29JsegxorL zQkpF7NKqZc= ; ZSK ; alg = RSASHA256 ; bits = 2048,17 ; key id = 16749 | |
| . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU= ; KSK ; alg = RSASHA256 ; bits = 2048,17 ; key id = 20326 | |
| . 172800 IN DNSKEY 385 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX b |
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.
| " | |
| " ~/.vimrc | |
| " | |
| set nocompatible | |
| set hidden | |
| set ruler | |
| set visualbell | |
| set noerrorbells | |
| set nostartofline |
| #!/usr/bin/env node | |
| /* eslint no-control-regex: "off" */ | |
| 'use strict'; | |
| const assert = require('assert'); | |
| const Path = require('path'); | |
| const { |
| 'use strict'; | |
| const path = require('path'); | |
| const fs = require('./lib/utils/fs'); | |
| async function findFiles(dir, match, ignore, files) { | |
| const list = await fs.readdir(dir); | |
| for (const name of list) { | |
| if (ignore.has(name)) |
| 'use strict'; | |
| // Sweep bcc from trezor multisig. | |
| const assert = require('assert'); | |
| const util = require('util'); | |
| const trezor = require('trezor.js-node'); | |
| const HDPublicKey = require('bcoin/lib/hd/public'); | |
| const HARDENED = 0x80000000; |
| [ | |
| { | |
| "hash": "0000000000000000018c59d807bff651ead9f8fd6eef075ee5cffcf98bf4674c", | |
| "height": 464208, | |
| "size": 998109, | |
| "txs": 684, | |
| "inputs": 6162, | |
| "outputs": 1362, | |
| "inputCost": 5578086, | |
| "outputCost": 271012, |