sipa

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

sipa

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.

sipa

Mailed as https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001516.html

sipa

-----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

sipa

Published as BIP 103

sipa

• 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),

sipa

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

sipa

The algorithm that used to be described here is broken.

A better alternative is described here: https://github.com/sipa/writeups/tree/main/elligator-square-for-bn

sipa

Keybase proof

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:

sipa

1 state:
Output rate: 0.25
N0 (pos 0)
S0: 0=S1 1=S2 [0.5]
S1: 0=S0 1=0,S0 [0.25]
S2: 0=1,S0 1=S0 [0.25]

2 states:
Output rate: 0.375
N0 (pos 0)