path: root/c2/e26e6467c22deb0980b5a307de33c6f33e54c5

Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D29A5C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Jan 2024 15:26:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id AE3BA423F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Jan 2024 15:26:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AE3BA423F0
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=mail.wpsoftware.net
 header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default
 header.b=QNYFf2wW
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pUTu2ps9cC8p
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Jan 2024 15:26:21 +0000 (UTC)
X-Greylist: delayed 408 seconds by postgrey-1.37 at util1.osuosl.org;
 Fri, 05 Jan 2024 15:26:21 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8F31D40260
Received: from mail.wpsoftware.net (unknown [66.183.0.205])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8F31D40260
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Jan 2024 15:26:21 +0000 (UTC)
Received: from camus (camus-andrew.lan [192.168.0.190])
 by mail.wpsoftware.net (Postfix) with ESMTPSA id 047AD40120
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Jan 2024 15:19:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net;
 s=default; t=1704467973;
 bh=F9F4qYdRc0ffUxK8QdmtsydIB2ZdUscB8XsiqOk5mUI=;
 h=Date:From:To:Subject:References:In-Reply-To;
 b=QNYFf2wW5dVawFn8NW2JWXhOlSQLSWdiwUSmOGku/pOZXdtycARKTedjj5Z6zlDET
 /L9vmK3WpJaBwO07rVpQNd/J/GzLwQHisKuC9c4F9W/WFYlQN8H5HVh0iHuRV4M0Id
 5sPbBF1E/1CmORzp71Z/zEn29CzcSKowSYbaSZT70WFjlpEE7uxWlY8lua0FryVkPR
 7T/Vt3vIr2Jrad1Yd6ZilbJ3twXgl50Nd/+x28R6XLufnr9CidziAg3WoHRYKGM/kI
 rsKw9fgEg0R1lSh6g1JfKjIAhGZ9ASQmJa1rpGc647tfPSntKR7MDYnB3YsFwVsaKo
 POfUXEKsMrVRQ==
Date: Fri, 5 Jan 2024 15:19:31 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZZgeA1KPUbLtQjoT@camus>
References: <WJoM7dyrk0o8ujOZOo462r66wS2Kl3L1ZZRodvaLK-HKEUc90yvwOqXbUUrGbV1lk6cOywTqLoCyHzk2Tm3TtBFyUL0NZ6D7v9NmTXypJPA=@protonmail.com>
 <KSmH1MBTPLuXMF4TWbWq6vaft_K_7IZS2YcoZ1iHwtHY06It1DjExVgSdrLBMQZA8mLGz8xdOzyXRHAZ2qCAugwG8gMtEGsGj-XNTPN0v0w=@protonmail.com>
 <ZPHtgiJQ4Yqrr941@camus> <ZPdswQ7uAJr35YbC@petertodd.org>
 <hd13VCUTiTaX_Z4oeZpzwjdVOcmkbcg-kgfThk9b1LUt2YUCEXrwVuEq8BiNWtfzeAafo6GdsrFzGg3pQI5kSjuRc4TtFGmRndvVukAwAiY=@protonmail.com>
 <xk6TD_XVlJodelVrD6HTzj-YZ6MaRJ8lU_ugEddOixoQfCmn59oQYKw-QZOwjL7b_LENm1Jza4NtBKAaXWqwHwcOOyvwlUbJuKw7f5lkm1s=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="HbhjV7xdyunpbc01"
Content-Disposition: inline
In-Reply-To: <xk6TD_XVlJodelVrD6HTzj-YZ6MaRJ8lU_ugEddOixoQfCmn59oQYKw-QZOwjL7b_LENm1Jza4NtBKAaXWqwHwcOOyvwlUbJuKw7f5lkm1s=@protonmail.com>
Subject: Re: [bitcoin-dev] Compressed Bitcoin Transactions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jan 2024 15:26:23 -0000


--HbhjV7xdyunpbc01
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Thanks Tom.

It looks like you posted a text-scrape of the rendered markdown, which
is hard to read. For posterity here is the full text.

Best
Andrew


=3D=3D=3D begin compressed_transactions.md =3D=3D=3D

# Compressed Transaction Schema
By (Tom Briar) and (Andrew Poelstra)

## 1. Abstract

With this Transaction Compression Schema we use several methods to compress=
 transactions,
including dropping data and recovering it on decompression by grinding unti=
l we obtain
valid signatures.

The bulk of our size savings come from replacing the prevout of each input =
by a block
height and index. This requires the decompression to have access to the blo=
ckchain, and
also means that compression is ineffective for transactions that spend unco=
nfirmed or
insufficiently confirmed outputs.

Even without compression, Taproot keyspends are very small: as witness data=
 they
include only a single 64/65-byte signature and do not repeat the public key=
 or
any other metadata. By using pubkey recovery, we obtain Taproot-like compre=
ssion
for legacy and Segwit transactions.

The main applications for this schema are for steganography, satellite/radi=
o broadcast, and
other low bandwidth channels with a high CPU availability on decompression.=
 We
assume users have some ability to shape their transactions to improve their
compressibility, and therefore give special treatment to certain transactio=
n forms.

This schema is easily reversible except for compressing the Txid/Vout input=
 pairs(Method 4).
Compressing the input Txid/Vout is optional, and without it still gleans 50=
% of the
total compression. This allows for the additional use case of P2P communica=
tion.

## 2. Methods

The four main methods to achieve a lower transactions size are:

1. packing transaction metadata before the transaction and each of its inpu=
ts and
outputs to determine the structure of the following data.
2. replacing 32-bit numeric values with either variable-length integers (Va=
rInts) or compact-integers (CompactSizes).
3. using compressed signatures and public key recovery upon decompression.
4. replacing the 36-byte txid/vout pair with a blockheight and output index.

Method 4 will cause the compressed transaction to be undecompressable if a =
block
reorg occurs at or before the block it's included in. Therefore, we'll only=
 compress
the Txid if the transaction input is at least one hundred blocks old.


## 3 Schema

### 3.1 Primitives

| Name             | Width     | Description |
|------------------|-----------|-------------|
| CompactSize      | 1-5 Bytes | For 0-253, encode the value directly in on=
e byte. For 254-65535, encode 254 followed by 2 little-endian bytes. For 65=
536-(2^32-1), encode 255 followed by 4 little-endian bytes. |
| CompactSize flag | 2 Bits    | 1, 2 or 3 indicate literal values. 0 indic=
ates that the value will be encoded in a later CompactInt. |
| VarInt           | 1+ Bytes  | 7-bit little-endian encoding, with each 7-=
bit word encoded in a byte. The highest bit of each byte is 1 if more bytes=
 follow, and 0 for the last byte. |
| VLP-Bytestream   | 2+ Bytes  | A VarInt Length Prefixed Bytestream. Has a=
 VarInt prefixed to determine the length. |

### 3.2 General Schema

| Name                           | Width           | Description |
|--------------------------------|-----------------|-------------|
| Transaction Metadata           | 1 Byte    | Information on the structure=
 of the transaction. See Section 3.3. |
| Version                        | 0-5 Bytes | An optional CompactSize cont=
aining the transactions version. |
| Input Count                    | 0-5 Bytes | An optional CompactSize cont=
aining the transactions input count. |
| Output Count                   | 0-5 Bytes | An optional CompactSize cont=
aining the transactions output count. |
| LockTime                       | 0-5 Bytes | An optional CompactSize cont=
aining the transaction LockTime if its non zero. |
| Minimum Blockheight            | 1-5 Bytes | A VarInt containing the Mini=
mum Blockheight of which the transaction locktime and input blockheights ar=
e given as offsets. |
| Input Metadata+Output Metadata | 1+ Bytes  | A Encoding containing metada=
ta on all the inputs and then all the outputs of the transaction. For each =
input see Section 3.4, for each output see Section 3.5. |
| Input Data                     | 66+ Bytes | See Section 3.6 for each inp=
ut. |
| Output Data                    | 3+ Bytes  | See Section 3.7 for each out=
put. |

For the four CompactSize listed above we could use a more compact bit encod=
ing for these but they are already a fall back for the bit encoding of the =
Transaction Metadata.

### 3.3 Transaction Metadata

| Name         | Width  | Description |
|--------------|--------|-------------|
| Version      | 2 Bits | A CompactSize flag for the transaction version. |
| Input Count  | 2 Bits | A CompactSize flag for the transaction input coun=
t. |
| Output Count | 2 Bits | A CompactSize flag for the transaction output cou=
nt. |
| LockTime     | 1 Bit  | A Boolean to indicate if the transaction has a Lo=
ckTime. |

### 3.4 Input Metadata

| Name                 | Width  | Description |
|----------------------|--------|-------------|
| Compressed Signature | 1 Bit  | Signature compression flag. For P2TR: 1 f=
or keyspend, 0 for scriptspend; For P2SH: 0 for p2sh, 1 for p2sh-wpkh. |
| Standard Hash        | 1 Bit  | A flag to determine if this Input's Signa=
ture Hash Type is standard (0x00 for Taproot, 0x01 for Legacy/Segwit). |
| Standard Sequence    | 2 Bits | A CompactSize flag for the inputs sequenc=
e. Encode literal values as follows: 1 =3D 0x00000000, 2 =3D 0xFFFFFFFE, 3 =
=3D 0xFFFFFFFF. |

### 3.5.1 Output Metadata

| Name                | Width  | Description |
|---------------------|--------|-------------|
| Encoded Script Type | 3 Bits | Encoded Script Type. |

#### 3.5.2 Script Type encoding

| Script Type                | Value |
|----------------------------|-------|
| Uncompressed P2PK          | 0b000 |
| Compressed P2PK            | 0b001 |
| P2PKH                      | 0b010 |
| P2SH                       | 0b011 |
| P2WSH                      | 0b100 |
| P2WPKH                     | 0b101 |
| P2TR                       | 0b110 |
| Uncompressed Custom Script | 0b111 |

### 3.6 Input Data

| Name                    | Width     | Description |
|-------------------------|-----------|-------------|
| Sequence                | 0-5 Bytes | An Optional VarInt containing the s=
equence if it was non-standard. |
| Txid Blockheight        | 1-5 Bytes | A VarInt Either containing 0 if thi=
s an uncompressed input, or it contains the offset from Minimum Blockheight=
 for this Txid. |
| Txid/Signature Data     | 65+ Bytes | Txid/Signatures are determined to b=
e uncompressed either by the output script of the previous transaction, or =
if the Txid Blockheight is zero. For each Compressed Txid/Signature See Sec=
tion 3.6.1. For each Uncompressed Txid/Signature See Section 3.6.2. |

### 3.6.1 Compressed Txid/Signature Data

| Name              | Width     | Description |
|-------------------|-----------|-------------|
| Txid Block Index  | 1-5 Bytes | A VarInt containing the flattened index f=
rom the Txid Blockheight for the Vout. |
| Signature         | 64 Bytes  | Contains the 64 byte signature. |
| Hash Type         | 0-1 Bytes | An Optional Byte containing the Hash Type=
 if it was non-standard.|

### 3.6.2 Uncompressed Txid/Signature Data

| Name      | Width     | Description |
|-----------|-----------|-------------|
| Txid      | 32 Bytes  | Contains the 32 byte Txid. |
| Vout      | 1-5 Bytes | A CompactSize Containing the Vout of the Txid. |
| Signature | 2+ Bytes  | A VLP-Bytestream containing the signature. |

### 3.7 Output Data

| Name          | Width     | Description |
|---------------|-----------|-------------|
| Output Script | 2+ Bytes  | A VLP-Bytestream containing the output script=
=2E |
| Amount        | 1-9 Bytes | A VarInt containing the output amount. |

## 4 Ideal Transaction

The target transaction for the most optimal compression was chosen
based off the most common transactions that are likely to be used
for purposes that requires the best compression.

| Field           | Requirements                      | Possible Savings   =
               |
|-----------------|-----------------------------------|--------------------=
---------------|
| Version         | Less than four                    | 30 Bits            =
               |
| Input Count     | Less then four                    | 30 Bits            =
               |
| Output Count    | Less then four                    | 30 Bits            =
               |
| LockTime        | 0                                 | 30 Bits            =
               |
| Input Sequence  | 0x00, 0xFFFFFFFE, or 0xFFFFFFFF   | 62 Bits For Each In=
put            |
| Input Txid      | Compressed Outpoint               | 23-31 Bytes For Eac=
h Input        |
| Input Vout      | Compressed Outpoint               | (-1)-3 Bytes For Ea=
ch Input       |
| Input Signature | Non-custom Script Signing         | 40-72 Bytes For Eac=
h Legacy Input |
| Input Hash Type | 0x00 for Taproot, 0x01 for Legacy | 7 Bits For Each Inp=
ut             |
| Output Script   | Non-custom Scripts                | 2-5 Bytes For Each =
Output         |
| Output Amount   | No Restrictions                   | (-1)-7 Bytes For Ea=
ch Output      |

## 5 Test Vectors

| Transaction              | Before Compression | Possible Savings         =
| After Compression |
|--------------------------|--------------------|--------------------------=
|-------------------|
| 2-(input/output) Taproot | 312 Bytes          | 78-124 Bytes and 2 Bits  =
| 190-226 Bytes     |
| 2-(input/output) Legacy  | 394 Bytes          | 118-196 Bytes and 2 Bits =
| 176-244 Bytes     |

Taproot (Uncompressed)
```
020000000001028899af77861ede1ee384c333974722c96eabba8889506725b00735fc35ba4=
1680000000000000000008899af77861ede1ee384c333974722c96eabba8889506725b00735=
fc35ba41680000000000000000000288130000000000002251206b10142cffb29e9d83f63a7=
7a428be41f96bd9b6ccc9889e4ec74927058b41dda00f000000000000225120dd00ac641dc0=
f399e62a6ed6300aba1ec5fa4b3aeedf1717901e0d49d980efd20140f3d9bcc844eab7055a1=
68a62f65b8625e3853fad8f834d5c82fdf23100b7b871cf48c2c956e7d76cdd367bbfefe496=
c426e64dcfeaef800ab9893142050714b6014081c15fe5ed6b8a0c0509e871dfbb7784ddb22=
dd33b47f3ad1a3b271d29acfe76b5152b53ed29a7f6ea27cb4f5882064da07e8430aacafab8=
9a334b32780fcb2700000000
```

Taproot (Compressed)
```
2a81de3177d8019c2ef3d9bcc844eab7055a168a62f65b8625e3853fad8f834d5c82fdf2310=
0b7b871cf48c2c956e7d76cdd367bbfefe496c426e64dcfeaef800ab9893142050714b6019c=
2e81c15fe5ed6b8a0c0509e871dfbb7784ddb22dd33b47f3ad1a3b271d29acfe76b5152b53e=
d29a7f6ea27cb4f5882064da07e8430aacafab89a334b32780fcb276b10142cffb29e9d83f6=
3a77a428be41f96bd9b6ccc9889e4ec74927058b41dd8827dd00ac641dc0f399e62a6ed6300=
aba1ec5fa4b3aeedf1717901e0d49d980efd2a01f
```

Legacy (Uncompressed)
```
02000000000102c583fe4f934a0ed87e4d082cd52967cc774b943fbb2e21378ec18b926b8dc=
549000000000000000000c583fe4f934a0ed87e4d082cd52967cc774b943fbb2e21378ec18b=
926b8dc5490000000000000000000288130000000000002251206b10142cffb29e9d83f63a7=
7a428be41f96bd9b6ccc9889e4ec74927058b41dda00f000000000000225120dd00ac641dc0=
f399e62a6ed6300aba1ec5fa4b3aeedf1717901e0d49d980efd202473044022000d1c81efcf=
6d20d87253749bcef8bf1be7ba51ccdf7a3b328174ea874226c3c02202d810c20f92d49c821=
eaa6e3a9ec7d764e0e71006e572d6ea96b631bd921767c0121037833d05665f3b21c479583e=
e12c6c573d1f25977dedfae12c70c18ec9dd4618702473044022000d1c81efcf6d20d872537=
49bcef8bf1be7ba51ccdf7a3b328174ea874226c3c02202d810c20f92d49c821eaa6e3a9ec7=
d764e0e71006e572d6ea96b631bd921767c0121037833d05665f3b21c479583ee12c6c573d1=
f25977dedfae12c70c18ec9dd4618700000000
```

Legacy (Compressed)
```
2ad1e53044d801ae276c0002473044022000d1c81efcf6d20d87253749bcef8bf1be7ba51cc=
df7a3b328174ea874226c3c02202d810c20f92d49c821eaa6e3a9ec7d764e0e71006e572d6e=
a96b631bd921767c0121037833d05665f3b21c479583ee12c6c573d1f25977dedfae12c70c1=
8ec9dd461870001ae276c0002473044022000d1c81efcf6d20d87253749bcef8bf1be7ba51c=
cdf7a3b328174ea874226c3c02202d810c20f92d49c821eaa6e3a9ec7d764e0e71006e572d6=
ea96b631bd921767c0121037833d05665f3b21c479583ee12c6c573d1f25977dedfae12c70c=
18ec9dd46187006b10142cffb29e9d83f63a77a428be41f96bd9b6ccc9889e4ec74927058b4=
1dd8827dd00ac641dc0f399e62a6ed6300aba1ec5fa4b3aeedf1717901e0d49d980efd2a01f
```


--=20
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


--HbhjV7xdyunpbc01
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmWYHgMACgkQxYjWPOQb
l8Fd2wf8CLFXTI5mcKDwmlJDQZwC9cRuwTVZxpYxbu+c+k0BZGKGacG6LQrM8MsD
8YHFdAAauX59teh39laEvaIZ3Pie+ulOk7uguP8rdXmXtTIA49kgoEBfluoqxiv5
UukTB7vs1Wp1gf79ducyqcEO8ELcdeibbvRFTFIx9LoZh6W9Sr9Yfq8OG4HIWc2z
qnicRE/q+7BwMDiHcS71k/1KWmXp1erD4+eMHr90sOPwrYe3PskN1tGhcjdN0Rst
BRk33XsQ2/UgX58MVDpHKEHEpil72ywpLMxWJNAwNmpBrugNPrFkEVueqsVNfD76
Vjr6q7y6Clho25OXvhgFrLUhJCKO0A==
=X6yd
-----END PGP SIGNATURE-----

--HbhjV7xdyunpbc01--