Pieter Wuille sipa

Published as BIP 103

Zero-length integers are accepted (with value 0), 8.3.1 says this is not allowed.
Expected-to-be-unsigned integers are parsed as if they weren't two's complement, violating 8.3.3.
Integers with excessive padding are accepted, violating 8.3.2.
Primitive values with indefinite length are accepted, when they are inside a constructed value with known length, violating 8.3.2.a. End-of-contents octets are not supported in this case, violating 8.1.5.
Lengths of constructed values are ignored in several cases.
Garbage inside sequences is accepted.
Garbage at the end is accepted.
Data types that are required to be primitive can be encoded as constructed instead, in which case the concatenation of all primitive values inside is used (ignoring their data types), violating for example 8.3.1.
127-byte long length descriptors are accepted (ASN.1 allows up to 126 bytes), violating 8.1.3.5.c.
Older OpenSSL code only accepted length descriptors up to the size of a 'long int' (which is platform dependent),

The algorithm that used to be described here is broken.

I hereby claim:

I am sipa on github.
I am pwuille (https://keybase.io/pwuille) on keybase.
I have a public key whose fingerprint is 133E AC17 9436 F14A 5CF1 B794 860F EB80 4E66 9320

To claim this, I am signing this object:

	Beyond IP Transactions: towards a payment protocol
	==================================================

	IP transactions were originally introduced as a first "out-of-band" protocol
	for negotiating a transaction output's public key. Being inconvenient and
	insecure, they became obsolete, and recent versions of bitcoin don't support
	them anymore.

	The result is that static bitcoin addresses have become the most common way of
	defining requested payments. This may be fine for anonymous donations, but is not

	Given the series of (i(n),f(n)), where subsequent checks happen whether a
	predicate with chance f(n) is true after i(n) iterations. A seed that
	satisfies f(n), but not any f(k) with k<n is said to be of strength n. We
	want the following two properties:
	* (a) constructing a seed of a given strength n takes on average A*B^n
	iterations.
	* (b) assuming an attacker has an oracle that tells all valid seeds of a
	given (known) strength n, it takes as many iterations to construct
	all derived keys as there are elements in the seedspace.

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256

	Here is a public key of mine, usable for the CoinJoin bounty fund:
	0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592
	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.4.12 (GNU/Linux)

	iQGcBAEBCAAGBQJSpLf6AAoJEI9lMlXIeZLgtRkL/3ufWgLyhTKM9T30JqA0a/Xh
	5KUMD0csuxTMYraVOy9x7tRVZh+fETt4Y3clhErZj8g6VraC5ku+4pyHxtFztWor

	Chances of not detecting an error in a Bech32 string. Lengths exclude the separator character '1'. Chances are multiples of 1 in 2^30.

	Len 1 Error 2 Errors 3 Errors 4 Errors 5 Errors 6 Errors 7 Errors 8 Errors
	1 0.000000000000000
	2 0.000000000000000 0.000000000000000
	3 0.000000000000000 0.000000000000000 0.000000000000000
	4 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000
	5 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000
	6 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000
	7 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000 0.000000000000000 1.209844924575586