Nostr notes by

📅 Original date posted:2023-02-16 🗒️ Summary of this ...

2023-06-08T01:19:39+02:00

In reply to nevent1q…9urd
_________________________

📅 Original date posted:2023-02-16
🗒️ Summary of this message: Ancient scrolls discovered in Pennsylvania reveal the existence of a secret society devoted to computation in 200 BC, using a system of cryptographic computations.
📝 Original message:I've been asked by Dr. Curr and Professor Snead to forward this message to
this mailing list, as it may be of general interest to Bitcoin users.

Dear Colleague:

In 1967, during excavation for the construction of a new shopping center in
Monroeville, Pennsylvania, workers uncovered a vault containing a cache of
ancient scrolls[1]. Most were severely damaged, but those that could be
recovered confirmed the existence of a secret society long suspected to
have
been active in the region around the year 200 BC.

Based on a translation of these documents, we now know that the society,
the
Cult of the Bound Variable, was devoted to the careful study of
computation,
over two millennia before the invention of the digital computer.

While the Monroeville scrolls make reference to computing machines made of
sandstone, most researchers believed this to be a poetic metaphor and that
the
"computers" were in fact the initiates themselves, carrying out the
unimaginably tedious steps of their computations with reed pens on
parchment.

Within the vault, a collection of sandstone wheels marked in a language
consisting of 32 glyphs was found. After 15 years of study, we have
successfully
completed the translation of what is known as "Codex32," a document that
describes the functions of the wheels. It was discovered that the wheels
operate
a system of cryptographic computations that was used by cult members to
safeguard their most valuable secrets.

The Codex32 system allows secrets to be carved into multiple tablets and
scattered to the far corners of the earth. When a sufficient number of
tablets are
brought together the stone wheels are manipulated in a manner to recover the
secrets. This finding may be of particular interest to the Bitcoin
community.

Below we provide a summary of the cult's secret sharing system, which is
graciously hosted at
<
https://github.com/apoelstra/bips/blob/2023-02--volvelles/bip-0000.mediawiki
>.
We are requesting a record assignment in the Bibliography of Immemorial
Philosophy (BIP) repository.

Thank you for your consideration.

Dr. Leon O. Curr and Professor Pearlwort Snead
Department of Archaeocryptography
Harry Q. Bovik Institute for the Advancement

[1] http://www.boundvariable.org/task.shtml

-----BEGIN BIP-----

<pre>
BIP: ????
Layer: Applications
Title: codex32
Author: Leon Olsson Curr and Pearlwort Sneed <pearlwort at wpsoftware.net>
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: ????
Created: 2023-02-13
License: BSD-3-Clause
Post-History: FIXME
</pre>

==Introduction==

===Abstract===

This document describes a standard for backing up and restoring the master
seed of a
[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032]
hierarchical deterministic wallet, using Shamir's secret sharing.
It includes an encoding format, a BCH error-correcting checksum, and
algorithms for share generation and secret recovery.
Secret data can be split into up to 31 shares.
A minimum threshold of shares, which can be between 1 and 9, is needed to
recover the secret, whereas without sufficient shares, no information about
the secret is recoverable.

===Copyright===

This document is licensed under the 3-clause BSD license.

===Motivation===

BIP-0032 master seed data is the source entropy used to derive all private
keys in an HD wallet.
Safely storing this secret data is the hardest and most important part of
self-custody.
However, there is a tension between security, which demands limiting the
number of backups, and resilience, which demands widely replicated backups.
Encrypting the seed does not change this fundamental tradeoff, since it
leaves essentially the same problem of how to back up the encryption key(s).

To allow users freedom to make this tradeoff, we use Shamir's secret
sharing, which guarantees that any number of shares less than the threshold
leaks no information about the secret.
This approach allows increasing safety by widely distributing the generated
shares, while also providing security against the compromise of one or more
shares (as long as fewer than the threshold have been compromised).

[https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039]
has essentially the same motivations as this standard.
However, unlike SLIP-0039, this standard also aims to be simple enough for
hand computation.
Users who demand a higher level of security for particular secrets, or have
a general distrust in digital electronic devices, have the option of using
hand computation to backup and restore secret data in an interoperable
manner.
Note that hand computation is optional, the particular details of hand
computation are outside the scope of this standard, and implementers do not
need to be concerned with this possibility.

[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
serves the same purpose as this standard: encoding master seeds for storage
by users.
However, BIP-0039 has no error-correcting ability, cannot sensibly be
extended to support secret sharing, has no support for versioning or other
metadata, and has many technical design decisions that make implementation
and interoperability difficult (for example, the use of SHA-512 to derive
seeds, or the use of 11-bit words).

==Specification==

===codex32===

A codex32 string is similar to a Bech32 string defined in [
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173].
It reuses the base32 character set from BIP-0173, and consists of:

* A human-readable part, which is the string "ms" (or "MS").
* A separator, which is always "1".
* A data part which is in turn subdivided into:
** A threshold parameter, which MUST be a single digit between "2" and "9",
or the digit "0".
*** If the threshold parameter is "0" then the share index, defined below,
MUST have a value of "s" (or "S").
** An identifier consisting of 4 Bech32 characters.
** A share index, which is any Bech32 character. Note that a share index
value of "s" (or "S") is special and denotes the unshared secret (see
section "Unshared Secret").
** A payload which is a sequence of up to 74 Bech32 characters. (However,
see '''Long codex32 Strings''' below for an exception to this limit.)
** A checksum which consists of 13 Bech32 characters as described below.

As with Bech32 strings, a codex32 string MUST be entirely uppercase or
entirely lowercase.
The lowercase form is used when determining a character's value for
checksum purposes.
For presentation, lowercase is usually preferable, but uppercase SHOULD be
used for handwritten codex32 strings.

===Checksum===

The last thirteen characters of the data part form a checksum and contain
no information.
Valid strings MUST pass the criteria for validity specified by the Python3
code snippet below.
The function <code>ms32_verify_checksum</code> must return true when its
argument is the data part as a list of integers representing the characters
converted using the bech32 character table from BIP-0173.

To construct a valid checksum given the data-part characters (excluding the
checksum), the <code>ms32_create_checksum</code> function can be used.

<source lang="python">
MS32_CONST = 0x10ce0795c2fd1e62a

def ms32_polymod(values):
GEN = [
0x19dc500ce73fde210,
0x1bfae00def77fe529,
0x1fbd920fffe7bee52,
0x1739640bdeee3fdad,
0x07729a039cfc75f5a,
]
residue = 0x23181b3
for v in values:
b = (residue >> 60)
residue = (residue & 0x0fffffffffffffff) << 5 ^ v
for i in range(5):
residue ^= GEN[i] if ((b >> i) & 1) else 0
return residue

def ms32_verify_checksum(data):
if len(data) >= 96: # See Long codex32 Strings
return ms32_verify_long_checksum(data)
if len(data) <= 93:
return ms32_polymod(data) == MS32_CONST
return False

def ms32_create_checksum(data):
if len(data) > 80: # See Long codex32 Strings
return ms32_create_long_checksum(data)
values = data
polymod = ms32_polymod(values + [0] * 13) ^ MS32_CONST
return [(polymod >> 5 * (12 - i)) & 31 for i in range(13)]
</source>

===Error Correction===

A codex32 string without a valid checksum MUST NOT be used.
The checksum is designed to be an error correcting code that can correct up
to 4 character substitutions, up to 8 unreadable characters (called
erasures), or up to 13 consecutive erasures.
Implementations SHOULD provide the user with a corrected valid codex32
string if possible.
However, implementations SHOULD NOT automatically proceed with a corrected
codex32 string without user confirmation of the corrected string, either by
prompting the user, or returning a corrected string in an error message and
allowing the user to repeat their action.
We do not specify how an implementation should implement error correction.
However, we recommend that:

* Implementations make suggestions to substitute non-bech32 characters with
bech32 characters in some situations, such as replacing "B" with "8", "O"
with "0", "I" with "l", etc.
* Implementations interpret "?" as an erasure.
* Implementations optionally interpret other non-bech32 characters, or
characters with incorrect case, as erasures.
* If a string with 8 or fewer erasures can have those erasures filled in to
make a valid codex32 string, then the implementation suggests such a string
as a correction.
* If a string consisting of valid Bech32 characters in the proper case can
be made valid by substituting 4 or fewer characters, then the
implementation suggests such a string as a correction.

===Unshared Secret===

When the share index of a valid codex32 string (converted to lowercase) is
the letter "s", we call the string a codex32 secret.
The subsequent data characters in a codex32 secret, excluding the final
checksum of 13 characters, is a direct encoding of a BIP-0032 HD master
seed.

The master seed is decoded by converting the data to bytes:

* Translate the characters to 5 bits values using the bech32 character
table from BIP-0173, most significant bit first.
* Re-arrange those bits into groups of 8 bits. Any incomplete group at the
end MUST be 4 bits or less, and is discarded.

Note that unlike the decoding process in BIP-0173, we do NOT require that
the incomplete group be all zeros.

For an unshared secret, the threshold parameter (the first character of the
data part) is ignored (beyond the fact it must be a digit for the codex32
string to be valid).
We recommend using the digit "0" for the threshold parameter in this case.
The 4 character identifier also has no effect beyond aiding users in
distinguishing between multiple different master seeds in cases where they
have more than one.

===Recovering Master Seed===

When the share index of a valid codex32 string (converted to lowercase) is
not the letter "s", we call the string an codex32 share.
The first character of the data part indicates the threshold of the share,
and it is required to be a non-"0" digit.

In order to recover a master seed, one needs a set of valid codex32 shares
such that:

* All shares have the same threshold value, the same identifier, and the
same length.
* All of the share index values are distinct.
* The number of codex32 shares is exactly equal to the (common) threshold
value.

If all the above conditions are satisfied, the <code>ms32_recover</code>
function will return a codex32 secret when its argument is the list of
codex32 shares with each share represented as a list of integers
representing the characters converted using the bech32 character table from
BIP-0173.

<source lang="python">
bech32_inv = [
0, 1, 20, 24, 10, 8, 12, 29, 5, 11, 4, 9, 6, 28, 26, 31,
22, 18, 17, 23, 2, 25, 16, 19, 3, 21, 14, 30, 13, 7, 27, 15,
]

def bech32_mul(a, b):
res = 0
for i in range(5):
res ^= a if ((b >> i) & 1) else 0
a *= 2
a ^= 41 if (32 <= a) else 0
return res

def bech32_lagrange(l, x):
n = 1
c = []
for i in l:
n = bech32_mul(n, i ^ x)
m = 1
for j in l:
m = bech32_mul(m, (x if i == j else i) ^ j)
c.append(m)
return [bech32_mul(n, bech32_inv[i]) for i in c]

def ms32_interpolate(l, x):
w = bech32_lagrange([s[5] for s in l], x)
res = []
for i in range(len(l[0])):
n = 0
for j in range(len(l)):
n ^= bech32_mul(w[j], l[j][i])
res.append(n)
return res

def ms32_recover(l):
return ms32_interpolate(l, 16)
</source>

===Generating Shares===

If we already have ''t'' valid codex32 strings such that:

* All strings have the same threshold value ''t'', the same identifier, and
the same length
* All of the share index values are distinct

Then we can derive additional shares with the <code>ms32_interpolate</code>
function by passing it a list of exactly ''t'' of these codex32 strings,
together with a fresh share index distinct from all of the existing share
indexes.
The newly derived share will have the provided share index.

Once a user has generated ''n'' codex32 shares, they may discard the
codex32 secret (if it exists).
The ''n'' shares form a ''t'' of ''n'' Shamir's secret sharing scheme of a
codex32 secret.

There are two ways to create an initial set of ''t'' valid codex32 strings,
depending on whether the user already has an existing master seed to split.

====For an existing master seed====

Before generating shares for an existing master seed, it first must be
converted into a codex32 secret, as described above.
The conversion process consists of:

* Choosing a threshold value ''t'' between 2 and 9, inclusive
* Choosing a 4 bech32 character identifier
** We do not define how to choose the identifier, beyond noting that it
SHOULD be distinct for every master seed the user may need to disambiguate.
* Setting the share index to "s"
* Setting the payload to a Bech32 encoding of the master seed, padded with
arbitrary bits
* Generating a valid checksum in accordance with the Checksum section

Along with the codex32 secret, the user must generate ''t''-1 other codex32
shares, each with the same threshold value, the same identifier, and a
distinct share index.
The set of share indexes may be chosen arbitrarily.
The payload of each of these codex32 shares is chosen uniformly at random
such that it has the same length as the payload of the codex32 secret.
For each share, a valid checksum must be generated in accordance with the
Checksum section.

The codex32 secret and the ''t''-1 codex32 shares form a set of ''t'' valid
codex32 strings from which additional shares can be derived as described
above.

====For a fresh master seed====

In the case that the user wishes to generate a fresh master seed, the user
chooses a threshold value ''t'' and an identifier, then generates ''t''
random codex32 shares, using the generation procedure from the previous
section.
As before, each share must have the same threshold value ''t'', the same
identifier, and a distinct share index.

With this set of ''t'' codex32 shares, new shares can be derived as
discussed above. This process generates a fresh master seed, whose value
can be retrieved by running the recovery process on any ''t'' of these
shares.

===Long codex32 Strings===

The 13 character checksum design only supports up to 80 data characters.
Excluding the threshold, identifier and index characters, this limits the
payload to 74 characters or 46 bytes.
While this is enough to support the 32-byte advised size of BIP-0032 master
seeds, BIP-0032 allows seeds to be up to 64 bytes in size.
We define a long codex32 string format to support these longer seeds by
defining an alternative checksum.

<source lang="python">
MS32_LONG_CONST = 0x43381e570bf4798ab26

def ms32_long_polymod(values):
GEN = [
0x3d59d273535ea62d897,
0x7a9becb6361c6c51507,
0x543f9b7e6c38d8a2a0e,
0x0c577eaeccf1990d13c,
0x1887f74f8dc71b10651,
]
residue = 0x23181b3
for v in values:
b = (residue >> 70)
residue = (residue & 0x3fffffffffffffffff) << 5 ^ v
for i in range(5):
residue ^= GEN[i] if ((b >> i) & 1) else 0
return residue

def ms32_verify_long_checksum(data):
return ms32_long_polymod(data) == MS32_LONG_CONST

def ms32_create_long_checksum(data):
values = data
polymod = ms32_long_polymod(values + [0] * 15) ^ MS32_LONG_CONST
return [(polymod >> 5 * (14 - i)) & 31 for i in range(15)]
</source>

A long codex32 string follows the same specification as a regular codex32
string with the following changes.

* The payload is a sequence of between 75 and 103 Bech32 characters.
* The checksum consists of 15 Bech32 characters as defined above.

A codex32 string with a data part of 94 or 95 characters is never legal as
a regular codex32 string is limited to 93 data characters and a long
codex32 string is at least 96 characters.

Generation of long shares and recovery of the master seed from long shares
proceeds in exactly the same way as for regular shares with the
<code>ms32_interpolate</code> function.

The long checksum is designed to be an error correcting code that can
correct up to 4 character substitutions, up to 8 unreadable characters
(called erasures), or up to 15 consecutive erasures.
As with regular checksums we do not specify how an implementation should
implement error correction, and all our recommendations for error
correction of regular codex32 strings also apply to long codex32 strings.

==Rationale==

This scheme is based on the observation that the Lagrange interpolation of
valid codewords in a BCH code will always be a valid codeword.
This means that derived shares will always have valid checksum, and a
sufficient threshold of shares with valid checksums will derive a secret
with a valid checksum.

The header system is also compatible with Lagrange interpolation, meaning
all derived shares will have the same identifier and will have the
appropriate share index.
This fact allows the header data to be covered by the checksum.

The checksum size and identifier size have been chosen so that the encoding
of 128-bit seeds and shares fit within 48 characters.
This is a standard size for many common seed storage formats, which has
been popularized by the 12 four-letter word format of the BIP-0039 mnemonic.

The 13 character checksum is adequate to correct 4 errors in up to 93
characters (80 characters of data and 13 characters of the checksum). This
is somewhat better quality than the checksum used in SLIP-0039.

For 256-bit seeds and shares our strings are 74 characters, which fits into
the 96 character format of the 24 four-letter word format of the BIP-0039
mnemonic, with plenty of room to spare.

A longer checksum is needed to support up to 512-bit seeds, the longest
seed length specified in BIP-0032, as the 13 character checksum isn't
adequate for more than 80 data characters.
While we could use the 15 character checksum for both cases, we prefer to
keep the strings as short as possible for the more common cases of 128-bit
and 256-bit master seeds.
We only guarantee to correct 4 characters no matter how long the string is.
Longer strings mean more chances for transcription errors, so shorter
strings are better.

The longest data part using the regular 13 character checksum is 93
characters and corresponds to a 400-bit secret.
At this length, the prefix <code>MS1</code> is not covered by the checksum.
This is acceptable because the checksum scheme itself requires you to know
that the <code>MS1</code> prefix is being used in the first place.
If the prefix is damaged and a user is guessing that the data might be
using this scheme, then the user can enter the available data explicitly
using the suspected <code>MS1</code> prefix.

==Backwards Compatibility==

codex32 is an alternative to BIP-0039 and SLIP-0039.
It is technically possible to derive the BIP32 master seed from seed words
encoded in one of these schemes, and then to encode this seed in codex32.
For BIP-0039 this process is irreversible, since it involves hashing the
original words.
Furthermore, the resulting seed will be 512 bits long, which may be too
large to be safely and conveniently handled.

SLIP-0039 seed words can be reversibly converted to master seeds, so it is
possible to interconvert between SLIP-0039 and codex32.
However, SLIP-0039 '''shares''' cannot be converted to codex32 shares
because the two schemes use a different underlying field.

The authors of this BIP do not recommend interconversion.
Instead, users who wish to switch to codex32 should generate a fresh seed
and sweep their coins.

==Reference Implementation==

* [https://secretcodex32.com/docs/2023-02-14--bw.ps Reference PostScript
Implementation]
* FIXME add Python implementation
* FIXME add Rust implementation

==Test Vectors==

===Test vector 1===

This example shows the codex32 format, when used without splitting the
secret into any shares.
The data part contains 26 Bech32 characters, which corresponds to 130 bits.
We truncate the last two bits in order to obtain a 128-bit master seed.

codex32 secret (Bech32):
<code>ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw</code>

Master secret (hex): <code>318c6318c6318c6318c6318c6318c631</code>

* human-readable part: <code>ms</code>
* separator: <code>1</code>
* k value: <code>0</code> (no secret splitting)
* identifier: <code>test</code>
* share index: <code>s</code> (the secret)
* data: <code>xxxxxxxxxxxxxxxxxxxxxxxxxx</code>
* checksum: <code>4nzvca9cmczlw</code>

===Test vector 2===

This example shows generating a new master seed using "random" codex32
shares, as well as deriving an additional codex32 share, using ''k''=2 and
an identifier of <code>NAME</code>.
Although codex32 strings are canonically all lowercase, it's also valid to
use all uppercase.

Share with index <code>A</code>:
<code>MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM</code>

Share with index <code>C</code>:
<code>MS12NAMECACDEFGHJKLMNPQRSTUVWXYZ023FTR2GDZMPY6PN</code>

* Derived share with index <code>D</code>:
<code>MS12NAMEDLL4F8JLH4E5VDVULDLFXU2JHDNLSM97XVENRXEG</code>
* Secret share with index <code>S</code>:
<code>MS12NAMES6XQGUZTTXKEQNJSJZV4JV3NZ5K3KWGSPHUH6EVW</code>
* Master secret (hex): <code>d1808e096b35b209ca12132b264662a5</code>

Note that per BIP-0173, the lowercase form is used when determining a
character's value for checksum purposes.
In particular, given an all uppercase codex32 string, we still use
lowercase <code>ms</code> as the human-readable part during checksum
construction.

===Test vector 3===

This example shows splitting an existing 128-bit master seed into "random"
codex32 shares, using ''k''=3 and an identifier of <code>cash</code>.
We appended two zero bits in order to obtain 26 Bech32 characters (130 bits
of data) from the 128-bit master seed.

Master secret (hex): <code>ffeeddccbbaa99887766554433221100</code>

Secret share with index <code>s</code>:
<code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code>

Share with index <code>a</code>:
<code>ms13casha320zyxwvutsrqpnmlkjhgfedca2a8d0zehn8a0t</code>

Share with index <code>c</code>:
<code>ms13cashcacdefghjklmnpqrstuvwxyz023949xq35my48dr</code>

* Derived share with index <code>d</code>:
<code>ms13cashd0wsedstcdcts64cd7wvy4m90lm28w4ffupqs7rm</code>
* Derived share with index <code>e</code>:
<code>ms13casheekgpemxzshcrmqhaydlp6yhms3ws7320xyxsar9</code>
* Derived share with index <code>f</code>:
<code>ms13cashf8jh6sdrkpyrsp5ut94pj8ktehhw2hfvyrj48704</code>

Any three of the five shares among <code>acdef</code> can be used to
recover the secret.

Note that the choice to append two zero bits was arbitrary, and any of the
following four secret shares would have been valid choices.
However, each choice would have resulted in a different set of derived
shares.

* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code>
* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qpte35dvzkjpt0r</code>
* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qzfatvdwq5692k6</code>
* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qrsx6ydhed97jx2</code>

===Test vector 4===

This example shows converting a 256-bit secret into a codex32 secret,
without splitting the secret into any shares.
We appended four zero bits in order to obtain 52 Bech32 characters (260
bits of data) from the 256-bit secret.

256-bit secret (hex):
<code>ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100</code>

* codex32 secret:
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code>

Note that the choice to append four zero bits was arbitrary, and any of the
following sixteen codex32 secrets would have been valid:

*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqpj82dp34u6lqtd</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqzsrs4pnh7jmpj5</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqrfcpap2w8dqezy</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqy5tdvphn6znrf0</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq9dsuypw2ragmel</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqx05xupvgp4v6qx</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq8k0h5p43c2hzsk</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqgum7hplmjtr8ks</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqf9q0lpxzt5clxq</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq28y48pyqfuu7le</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqt7ly0paesr8x0f</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqvrvg7pqydv5uyz</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqd6hekpea5n0y5j</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqwcnrwpmlkmt9dt</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq0pgjxpzx0ysaam</code>

===Test vector 5===

This example shows generating a new 512-bit master seed using "random"
codex32 characters and appending a checksum.
The payload contains 103 Bech32 characters, which corresponds to 515 bits.
The last three bits are discarded when converting to a 512-bit master seed.

This is an example of a '''Long codex32 String'''.

* Secret share with index <code>S</code>:
<code>MS100C8VSM32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06FHPV80UNDVARHRAK</code>
* Master secret (hex):
<code>dc5423251cb87175ff8110c8531d0952d8d73e1194e95b5f19d6f9df7c01111104c9baecdfea8cccc677fb9ddc8aec5553b86e528bcadfdcc201c17c638c47e9</code>

==Appendix==

===Mathematical Companion===

Below we use the Bech32 character set to denote values in GF[32].
In Bech32, the letter <code>Q</code> denotes zero and the letter
<code>P</code> denotes one.
The digits <code>0</code> and <code>2</code> through <code>9</code> do
''not'' denote their numeric values.
They are simply elements of GF[32].

The generating polynomial for our BCH code is as follows.

We extend GF[32] to GF[1024] by adjoining a primitive cube root of unity,
<code>ζ</code>, satisfying <code>ζ^2 = ζ + P</code>.

We select <code>β := G ζ</code> which has order 93, and construct the
product <code>(x - β^i)</code> for <code>i</code> in <code>{17, 20, 46, 49,
52, 77, 78, 79, 80, 81, 82, 83, 84}</code>.
The resulting polynomial is our generating polynomial for our 13 character
checksum:

x^13 + E x^12 + M x^11 + 3 x^10 + G x^9 + Q x^8 + E x^7 + E x^6 + E x^5
+ L x^4 + M x^3 + C x^2 + S x + S

For our long checksum, we select <code>γ := E + X ζ</code>, which has order
1023, and construct the product <code>(x - γ^i)</code> for <code>i</code>
in <code>{32, 64, 96, 895, 927, 959, 991, 1019, 1020, 1021, 1022, 1023,
1024, 1025, 1026}</code>.
The resulting polynomial is our generating polynomial for our 15 character
checksum for long strings:

x^15 + 0 x^14 + 2 x^13 + E x^12 + 6 x^11 + F x^10 + E x^9 + 4 x^8 + X
x^7 + H x^6 + 4 x^5 + X x^4 + 9 x^3 + K x^2 + Y x^1 + H

(Reminder: the character <code>0</code> does ''not'' denote the zero of the
field.)

-----END BIP-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230215/4ef5f4ec/attachment-0001.html>;

📅 Original date posted:2023-02-07 🗒️ Summary of this ...

2023-06-08T01:19:27+02:00

In reply to nevent1q…p5ju
_________________________

📅 Original date posted:2023-02-07
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated multiple times, incurring different Tapfee rates. Always know the entire Taptree when interacting with someone's Tapspend.
📝 Original message:There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.

The countermeasure is that you should always know the entire Taptree when
interacting with someone's Tapspend.

On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> Some people highlighted some minor problems with my last email:
>
> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
> wrote:
> >
> > <snip>
> >
> > [1] https://bitcoin.sipa.be/miniscript/
> > [2] In Taproot, if you want to prevent signatures migrating to another
> > branch or within a branch, you can use the CODESEPARATOR opcode
> > which was redisegned in Taproot for exactly this purpose... we
> > really did about witness malleation in its design!
>
> In Taproot the tapleaf hash is always covered by the signature (though
> not in some ANYONECANPAY proposals) so you can never migrate signatures
> between tapbranches.
>
> I had thought this was the case, but then I re-confused myself by
> reading BIP 341 .... which has much of the sighash specified, but not
> all of it! The tapleaf hash is added in BIP 342.
>
> >
> > If you want to prevent signatures from moving around *within* a
> > branch,
> >
>
> And this sentence I just meant to delete :)
>
>
> --
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/57930553/attachment.html>;

📅 Original date posted:2022-07-11 📝 Original message:Oops, ...

2023-06-08T01:11:42+02:00

In reply to nevent1q…khvt
_________________________

📅 Original date posted:2022-07-11
📝 Original message:Oops, you are right. We need the bribe to be the output of the coinbase,
but due to the maturity rule, it isn't really a bribe.

Too bad coinbases cannot take other coinbase outputs as inputs to bypass
the maturity rule.

I guess that means the bribe has to be by leaving transactions in the
mempool.

Also your point about centralization pressure is well taken.

On Mon, Jul 11, 2022 at 5:56 PM Peter Todd <pete at petertodd.org> wrote:

> On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
> > > > What happens after that I'm not sure.
> > > >
> > >
> > > Miners will learn to create anyone-can-spend outputs to bribe other
> miners
> > > to build on their block rather than reorg it. (Due to the coinbase
> > > maturity, this will require some amount of floating capital.)
> >
> > ...and that's a disaster for mining centralization, because the smaller
> miners
> > need to pay larger bribes than larger miners. Not to mention having to
> keep
> > capital around to do it.
>
> Also, note how from a practical point of view, we'll need to add a new
> type of
> tx that's only valid in a specific block, or other miners will just reorg
> those
> anyone-can-spend outputs to steal them. It's not all that trivial to
> actually
> do that... you'd have to have a signature that commits to the non-segwit
> part
> of the coinbase outputs. Ugh.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/2b9c824a/attachment.html>;

📅 Original date posted:2022-07-11 📝 Original message:On ...

2023-06-08T01:11:41+02:00

In reply to nevent1q…dcga
_________________________

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't how it works in the real world.
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very
> strongly) and this pattern keeps up (overwhelmingly likely) then this is
> going to become a serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure.
>

Miners will learn to create anyone-can-spend outputs to bribe other miners
to build on their block rather than reorg it. (Due to the coinbase
maturity, this will require some amount of floating capital.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/6e8e216d/attachment-0001.html>;

📅 Original date posted:2022-05-11 📝 Original message:Hi ...

2023-06-08T01:09:33+02:00

In reply to nevent1q…mlz0
_________________________

📅 Original date posted:2022-05-11
📝 Original message:Hi alicexbt,

As far as I understand things, I believe the whole notion of a MUST_SIGNAL
state is misguided today. Please correct me if I'm misunderstanding
something here.

Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
where many existing clients waiting for segwit signalling had already been
deployed. The purpose of mandatory signaling at that point in time was to
ensure all these existing clients would be activated together with any BIP8
clients.

However, if such other clients do not exist, the MUST_SIGNAL state no
longer accomplishes its purpose. Going forward, I think there is little
reason to expect such other clients to exist alongside a BIP8 deployment.
If everyone uses a BIP8 deployment, then there are no other clients to
activate. Alternatively, Speedy Trial was specifically designed to avoid
this parallel deployment for the reason that several people object to
allowing their client's non-BIP8 activation logic to be hijacked in this
manner.

Now I understand that some people would like *some* signal on the chain
that indicates a soft-fork activation in order to allow people who object
to the fork to make an "anti-fork" that rejects blocks containing the
soft-fork signal. And while some sort of mandatory version bit signaling
*could* be used for this purpose, we do not *have* to use version bits. We
also don't need such a signal span over multiple blocks. Indeed, using
version bits and signaling over multiple blocks is quite bad because it
risks losing mining power if miners don't conform, or are unable to
conform, to the version bits signal. (Recall at the time taproot's
signaling period started, the firmware needed for many miners to signal
version bits did not even exist yet!).

A soft-fork signal to enable an "anti-fork" only needs to be on a single
block and it can be almost anything. For example we could have a signal
that at the block at lockin or perhaps the block at activation requires
that the coinbase must *not* contain the suffix "taproot sucks!". This
suffices to prepare an "anti-fork" which would simply require that the
specified block must contain the suffix "taproot sucks!".

Anyway, I'm sure there are lots of design choices available better than a
MUST_SIGNAL state that does not risk potentially taking a large fraction of
mining hardware offline for a protracted period of time.

On Tue, May 10, 2022 at 10:02 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram:
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/>; secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/2cdd2915/attachment.html>;

📅 Original date posted:2022-04-23 📝 Original message:Okay, ...

2023-06-08T01:07:44+02:00

In reply to nevent1q…gjsf
_________________________

📅 Original date posted:2022-04-23
📝 Original message:Okay, Matt explained to me the intended application of CTV vaults off list,
so I have a better understanding now.

The CTV vault scheme is designed as an improvement over the traditional
management of hot-wallets and cold-wallets. The CTV vault is logically on
the "cold-side" and lets funds be sent from the "cold" side to *one's own*
the hot wallet after the unvaulting delay. In this case, the hot wallet
funds are always at risk, so it isn't unexpected that those funds could be
stolen. After all, that is how hot wallets are today. The advantage is
that funds can be moved from the "cold" side without needing to dig out the
cold keys.

The MES vault scheme applies to a different scenario. In the MES case it
is the hot funds are inside the vault, and it is the hot key that unvaults
the funds and sends them to *customer's addresses* after a delay. If the
hot-key is used in any unauthorised way, then funds can be sent to the
address of the cold key (the MES vault actually does something fancy in
case of recovery, but it could be adapted to simply send funds to a cold
wallet).

The MES vault lie somewhere between "better" and "different" when compared
to the CTV vault. If one is unwilling to use the MES vault on the hot side
and have every withdrawl vetted, then, while you could use the MES design
on the cold side like the CTV vault, it wouldn't really offer you any
advantages over a CTV vault. However, if you are interested in managing
all your payments through a vault (as I've been imagining) then the CTV
vault comes across as ineffective when compared to an MES style vault.

On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> Still trying to make sure I understand this concern, let me know if I get
> this all wrong.
>
> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > It's not the attackers *only choice to succeed*. If an attacker steals
> the hot key, then they have
> > the option to simply wait for the user to unvault their funds of their
> own accord and then race /
> > outspend the users transaction with their own. Indeed, this is what we
> expect would happen in the
> > dark forest.
>
> Right, a key security assumption of the CTV-based vaults would be that you
> MUST NOT EVER withdraw
> more in one go than your hot wallet risk tolerance, but given that your
> attack isn't any worse than
> simply stealing the hot wallet key immediately after a withdraw.
>
> It does have the drawback that if you ever get a hot wallet key stole you
> have to rotate all of your
> CTV outputs and your CTV outputs must never be any larger than your hot
> wallet risk tolerance
> amount, both of which are somewhat frustrating limitations, but not
> security limitations, only
> practical ones.
>
> > And that's not even mentioning the issues already noted by the document
> regarding fee management,
> > which would likely also benefit from a less constrained design for
> covenants.
>
> Of course I've always been in favor of a less constrained covenants design
> from day one for ten
> reasons, but that's a whole other rabbit hole :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/8077c9f2/attachment-0001.html>;

📅 Original date posted:2022-04-23 📝 Original message:On ...

2023-06-08T01:07:44+02:00

In reply to nevent1q…we2h
_________________________

📅 Original date posted:2022-04-23
📝 Original message:On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud <billy.tetrud at gmail.com>
wrote:

> > If an attacker steals the hot key, then they have the option to simply
> wait for the user to unvault their funds
>
> This is definitely true. Its kind of a problem with most vault proposals.
> Its one of the primary reasons I designed an alternative proposal
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults>;. The
> OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by
> automatically swapping control of the UTXO over to the intended recipient
> after a timeout. Alternatively, if OP_BBV weren't available, OP_POS in
> conjunction with OP_CD could encode things such that the transaction
> with the hot key could only spend to the intended recipient.
>
> I'm curious if there are any other covenant proposals that have a solution
> to that problem. I'm not aware of any that do other than my proposal.
>

As I noted, the original MES vault
https://fc16.ifca.ai/bitcoin/papers/MES16.pdf, commits to the destination
address during unvaulting. Their proposal uses CheckOutputVerify that
checks if a given output has a given amount and a given scriptPubKey. (The
MES vault then goes on to add a PATTERN parameter to OP_COV's scriptPubKey
parameter in order to make a recursive vault, but that is used to deter
cold-key theft, not hot-key theft).

Our paper https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
impelments the MES vault in Elements (alpha) using CAT and
CHECKSIGFROMSTACK. While I wouldn't necessarily call it a covenant
proposal, rather it is an observation that these opcodes happen to be
adequate for the task.

With such a big security caveat, I really don't find CTV vaults a
compelling example of using CTV. Sure, if CTV happens to exist, by all
means do whatever you like. But if anything, the CTV vault scheme instead
illustrates BlueMatt's point that we aren't really finished with covenant
research design yet:

Q: What ways can we build a secured vault that commits to the destination
address?
Q: Are there elegant ways of building secure vaults by using CTV plus
something else. Presumably CAT + CTV would be enough, though maybe some
people are concerned that CAT might enable recursive covenants (if people
aren't willing to have even CAT, I don't see how we will ever really have
programmable money).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/4e7b865d/attachment.html>;

📅 Original date posted:2022-04-22 📝 Original message:On ...

2023-06-08T01:07:43+02:00

In reply to nevent1q…6trn
_________________________

📅 Original date posted:2022-04-22
📝 Original message:On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> This vault design (https://github.com/jamesob/simple-ctv-vault)
> is a good benchmark for evaluating covenant proposals because it's (i)
> simple and (ii) has high utility for many users of Bitcoin. I would
> love to see it implemented in one or all of these alternatives, but I
> am almost certain no one will do it in the next few months because the
> implementations, tooling, and in some cases even complete
> specifications do not exist.
>

Quoting from the link above:
Detecting theft

This unvault step is critical because it allows us to detect unexpected
behavior. If an attacker had stolen our hot wallet keys, their only choice
to succeed in the theft is to trigger an unvault.

It's not the attackers *only choice to succeed*. If an attacker steals the
hot key, then they have the option to simply wait for the user to unvault
their funds of their own accord and then race / outspend the users
transaction with their own. Indeed, this is what we expect would happen in
the dark forest.

A key feature of the MES vault design is that the destination address is
included, and committed to, by the unvaulting step. However, this can only
be achieved with a less constrained design for covenants.

I suppose I can see that the damage from a hot key theft could be more
contained under some circumstances using a CTV vault, but let us not
overstate the value of the CTV vault.

And that's not even mentioning the issues already noted by the document
regarding fee management, which would likely also benefit from a less
constrained design for covenants.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/a55ab1e9/attachment.html>;

📅 Original date posted:2022-03-22 📝 Original message:Thanks ...

2023-06-08T01:06:34+02:00

In reply to nevent1q…lzvw
_________________________

📅 Original date posted:2022-03-22
📝 Original message:Thanks for the clarification.

You don't think referring to the microcode via its hash, effectively using
32-byte encoding of opcodes, is still rather long winded?

On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Russell,
>
> > Setting aside my thoughts that something like Simplicity would make a
> better platform than Bitcoin Script (due to expression operating on a more
> narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
> is an issue with namespace management.
> >
> > If I understand correctly, your implication was that once opcodes are
> redefined by an OP_RETURN transaction, subsequent transactions of that
> opcode refer to the new microtransaction. But then we have a race
> condition between people submitting transactions expecting the outputs to
> refer to the old code and having their code redefined by the time they do
> get confirmed (or worse having them reorged).
>
> No, use of specific microcodes is opt-in: you have to use a specific
> `0xce` Tapscript version, ***and*** refer to the microcode you want to use
> via the hash of the microcode.
>
> The only race condition is reorging out a newly-defined microcode.
> This can be avoided by waiting for deep confirmation of a newly-defined
> microcode before actually using it.
>
> But once the microcode introduction outpoint of a particular microcode has
> been deeply confirmed, then your Tapscript can refer to the microcode, and
> its meaning does not change.
>
> Fullnodes may need to maintain multiple microcodes, which is why creating
> new microcodes is expensive; they not only require JIT compilation, they
> also require that fullnodes keep an index that cannot have items deleted.
>
>
> The advantage of the microcode scheme is that the size of the SCRIPT can
> be used as a proxy for CPU load ---- just as it is done for current Bitcoin
> SCRIPT.
> As long as the number of `UOP_` micro-opcodes that an `OP_` code can
> expand to is bounded, and we avoid looping constructs, then the CPU load is
> also bounded and the size of the SCRIPT approximates the amount of
> processing needed, thus microcode does not require a softfork to modify
> weight calculations in the future.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220322/4fd9e0be/attachment.html>;

📅 Original date posted:2022-03-22 📝 Original ...

2023-06-08T01:06:32+02:00

In reply to nevent1q…vaua
_________________________

📅 Original date posted:2022-03-22
📝 Original message:Setting aside my thoughts that something like Simplicity would make a
better platform than Bitcoin Script (due to expression operating on a more
narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
is an issue with namespace management.

If I understand correctly, your implication was that once opcodes are
redefined by an OP_RETURN transaction, subsequent transactions of that
opcode refer to the new microtransaction. But then we have a race
condition between people submitting transactions expecting the outputs to
refer to the old code and having their code redefined by the time they do
get confirmed (or worse having them reorged).

I've partially addressed this issue in my Simplicity design where the
commitment of a Simplicity program in a scriptpubkey covers the hash of the
specification of the jets used, which makes commits unambiguously to the
semantics (rightly or wrongly). But the issue resurfaces at redemption
time where I (currently) have a consensus critical map of codes to jets
that is used to decode the witness data into a Simplicity program. If one
were to allow this map of codes to jets to be replaced (rather than just
extended) then it would cause redemption to fail, because the hash of the
new jets would no longer match the hash of the jets appearing the the
input's scriptpubkey commitment. While this is still not good and I don't
recommend it, it is probably better than letting the semantics of your
programs be changed out from under you.

This comment is not meant as an endorsement of ths idea, which is a little
bit out there, at least as far as Bitcoin is concerned. :)

My long term plans are to move this consensus critical map of codes out of
the consensus layer and into the p2p layer where peers can negotiate their
own encodings between each other. But that plan is also a little bit out
there, and it still doesn't solve the issue of how to weight reused jets,
where weight is still consensus critical.

On Tue, Mar 22, 2022 at 1:37 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning list,
>
> It is entirely possible that I have gotten into the deep end and am now
> drowning in insanity, but here goes....
>
> Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
>
> Introduction
> ============
>
> Recent (Early 2022) discussions on the bitcoin-dev mailing
> list have largely focused on new constructs that enable new
> functionality.
>
> One general idea can be summarized this way:
>
> * We should provide a very general language.
> * Then later, once we have learned how to use this language,
> we can softfork in new opcodes that compress sections of
> programs written in this general language.
>
> There are two arguments against this style:
>
> 1. One of the most powerful arguments the "general" side of
> the "general v specific" debate is that softforks are
> painful because people are going to keep reiterating the
> activation parameters debate in a memoryless process, so
> we want to keep the number of softforks low.
> * So, we should just provide a very general language and
> never softfork in any other change ever again.
> 2. One of the most powerful arguments the "general" side of
> the "general v specific" debate is that softforks are
> painful because people are going to keep reiterating the
> activation parameters debate in a memoryless process, so
> we want to keep the number of softforks low.
> * So, we should just skip over the initial very general
> language and individually activate small, specific
> constructs, reducing the needed softforks by one.
>
> By taking a page from microprocessor design, it seems to me
> that we can use the same above general idea (a general base
> language where we later "bless" some sequence of operations)
> while avoiding some of the arguments against it.
>
> Digression: Microcodes In CISC Microprocessors
> ----------------------------------------------
>
> In the 1980s and 1990s, two competing microprocessor design
> paradigms arose:
>
> * Complex Instruction Set Computing (CISC)
> - Few registers, many addressing/indexing modes, variable
> instruction length, many obscure instructions.
> * Reduced Instruction Set Computing (RISC)
> - Many registers, usually only immediate and indexed
> addressing modes, fixed instruction length, few
> instructions.
>
> In CISC, the microprocessor provides very application-specific
> instructions, often with a small number of registers with
> specific uses.
> The instruction set was complicated, and often required
> multiple specific circuits for each application-specific
> instruction.
> Instructions had varying sizes and varying number of cycles.
>
> In RISC, the micrprocessor provides fewer instructions, and
> programmers (or compilers) are supposed to generate the code
> for all application-specific needs.
> The processor provided large register banks which could be
> used very generically and interchangeably.
> Instructions had the same size and every instruction took a
> fixed number of cycles.
>
> In CISC you usually had shorter code which could be written
> by human programmers in assembly language or machine language.
> In RISC, you generally had longer code, often difficult for
> human programmers to write, and you *needed* a compiler to
> generate it (unless you were very careful, or insane enough
> you could scroll over multiple pages of instructions without
> becoming more insane), or else you might forget about stuff
> like jump slots.
>
> For the most part, RISC lost, since most modern processors
> today are x86 or x86-64, an instruction set with varying
> instruction sizes, varying number of cycles per instruction,
> and complex instructions with application-specific uses.
>
> Or at least, it *looks like* RISC lost.
> In the 90s, Intel was struggling since their big beefy CISC
> designs were becoming too complicated.
> Bugs got past testing and into mass-produced silicon.
> RISC processors were beating the pants off 386s in terms of
> raw number of computations per second.
>
> RISC processors had the major advantage that they were
> inherently simpler, due to having fewer specific circuits
> and filling up their silicon with general-purpose registers
> (which are large but very simple circuits) to compensate.
> This meant that processor designers could fit more of the
> design in their merely human meat brains, and were less
> likely to make mistakes.
> The fixed number of cycles per instruction made it trivial
> to create a fixed-length pipeline for instruction processing,
> and practical RISC processors could deliver one instruction
> per clock cycle.
> Worse, the simplicity of RISC meant that smaller and less
> experienced teams could produce viable competitors to the
> Intel x86s.
>
> So what Intel did was to use a RISC processor, and add a
> special Instruction Decoder unit.
> The Instruction Decoder would take the CISC instruction
> stream accepted by classic Intel x86 processors, and emit
> RISC instructions for the internal RISC processor.
> CISC instructions might be variable length and have variable
> number of cycles, but the emitted RISC instructions were
> individually fixed length and fixed number of cycles.
> A CISC instruction might be equivalent to a single RISC
> instruction, or several.
>
> With this technique, Intel could deliver performance
> approaching their RISC-only competition, while retaining
> back-compatibility with existing software written for their
> classic CISC processors.
>
> At its core, the Instruction Decoder was a table-driven
> parser.
> This lookup table could be stored into on-chip flash memory.
> This had the advantage that the on-chip flash memory could be
> updated in case of bugs in the implementation of CISC
> instructions.
> This on-chip flash memory was then termed "microcode".
>
> Important advantages of this "microcode" technique were:
>
> * Back-compatibility with existing instruction sets.
> * Easier and more scalable underlying design due to ability
> to use RISC techniques while still supporting CISC instruction
> sets.
> * Possible to fix bugs in implementations of complex CISC
> instructions by uploading new microcode.
>
> (Obviously I have elided a bunch of stuff, but the above
> rough sketch should be sufficient as introduction.)
>
> Bitcoin Consensus Layer As Hardware
> -----------------------------------
>
> While Bitcoin fullnode implementations are software, because
> of the need for consensus, this software is not actually very
> "soft".
> One can consider that, just as it would take a long time for
> new hardware to be designed with a changed instruction set,
> it is similarly taking a long time to change Bitcoin to
> support changed feature sets.
>
> Thus, we should really consider the Bitcoin consensus layer,
> and its SCRIPT, as hardware that other Bitcoin software and
> layers run on top of.
>
> This thus opens up the thought of using techniques that were
> useful in hardware design.
> Such as microcode: a translation layer from "old" instruction
> sets to "new" instruction sets, with the ability to modify this
> mapping.
>
> Microcode For Bitcoin SCRIPT
> ============================
>
> I propose:
>
> * Define a generic, low-level language (the "RISC language").
> * Define a mapping from a specific, high-level language to
> the above language (the microcode).
> * Allow users to sacrifice Bitcoins to define a new microcode.
> * Have users indicate the microcode they wish to use to
> interpret their Tapscripts.
>
> As a concrete example, let us consider the current Bitcoin
> SCRIPT as the "CISC" language.
>
> We can then support a "RISC" language that is composed of
> general instructions, such as arithmetic, SECP256K1 scalar
> and point math, bytevector concatenation, sha256 midstates,
> bytevector bit manipulation, transaction introspection, and
> so on.
> This "RISC" language would also be stack-based.
> As the "RISC" language would have more possible opcodes,
> we may need to use 2-byte opcodes for the "RISC" language
> instead of 1-byte opcodes.
> Let us call this "RISC" language the micro-opcode language.
>
> Then, the "microcode" simply maps the existing Bitcoin
> SCRIPT `OP_` codes to one or more `UOP_` micro-opcodes.
>
> An interesting fact is that stack-based languages have
> automatic referential transparency; that is, if I define
> some new word in a stack-based language and use that word,
> I can replace verbatim the text of the new word in that
> place without issue.
> Compare this to a language like C, where macro authors
> have to be very careful about inadvertent variable
> capture, wrapping `do { ... } while(0)` to avoid problems
> with `if` and multiple statements, multiple execution, and
> so on.
>
> Thus, a sequence of `OP_` opcodes can be mapped to a
> sequence of equivalent `UOP_` micro-opcodes without
> changing the interpretation of the source language, an
> important property when considering such a "compiled"
> language.
>
> We start with a default microcode which is equivalent
> to the current Bitcoin language.
> When users want to define a new microcode to implement
> new `OP_` codes or change existing `OP_` codes, they
> can refer to a "base" microcode, and only have to
> provide the new mappings.
>
> A microcode is fundamentally just a mapping from an
> `OP_` code to a variable-length sequence of `UOP_`
> micro-opcodes.
>
> ```Haskell
> import Data.Map
> -- type Opcode
> -- type UOpcode
> newtype Microcode = Microcode (Map.Map Opcode [UOpcode])
> ```
>
> Semantically, the SCRIPT interpreter processes `UOP_`
> micro-opcodes.
>
> ```Haskell
> -- instance Monad Interpreter -- can `fail`.
> interpreter :: Transaction -> TxInput -> [UOpcode] -> Interpreter ()
> ```
>
> Example
> -------
>
> Suppose a user wants to re-enable `OP_CAT`, and nothing
> else.
>
> That user creates a microcode, referring to the current
> default Bitcoin SCRIPT microcode as the "base".
> The base microcode defines `OP_CAT` as equal to the
> sequence `UOP_FAIL` i.e. a micro-opcode that always fails.
> However, the new microcode will instead redefine the
> `OP_CAT` as the micro-opcode sequence `UOP_CAT`.
>
> Microcodes then have a standard way of being represented
> as a byte sequence.
> The user serializes their new microcode as a byte
> sequence.
>
> Then, the user creates a new transaction where one of
> the outputs contains, say, 1.0 Bitcoins (exact required
> value TBD), and has the `scriptPubKey` of
> `OP_TRUE OP_RETURN <serialized_microcode>`.
> This output is a "microcode introduction output", which
> is provably unspendable, thus burning the Bitcoins.
>
> (It need not be a single user, multiple users can
> coordinate by signing a single transaction that commits
> their funds to the microcode introduction.)
>
> Once the above transaction has been deeply confirmed,
> the user can then take the hash of the microcode
> serialization.
> Then the user can use a SCRIPT with `OP_CAT` enabled,
> by using a Tapscript with, say, version `0xce`, and
> with the SCRIPT having the microcode hash as its first
> bytes, followed by the `OP_` codes.
>
> Fullnodes will then process recognized microcode
> introduction outputs and store mappings from their
> hashes to the microcodes in a new microcodes index.
> Fullnodes can then process version-`0xce` Tapscripts
> by checking if the microcodes index has the indicated
> microcode hash.
>
> Semantically, fullnodes take the SCRIPT, and for each
> `OP_` code in it, expands it to a sequence of `UOP_`
> micro-opcodes, then concatenates each such sequence.
> Then, the SCRIPT interpreter operates over a sequence
> of `UOP_` micro-opcodes.
>
> Optimizing Microcodes
> ---------------------
>
> Suppose there is some new microcode that users have
> published onchain.
>
> We want to be able to execute the defined microcode
> faster than expanding an `OP_`-code SCRIPT to a
> `UOP_`-code SCRIPT and having an interpreter loop
> over the `UOP_`-code SCRIPT.
>
> We can use LLVM.
>
> WARNING: LLVM might not be appropriate for
> network-facing security-sensitive applications.
> In particular, LLVM bugs. especially nondeterminism
> bugs, can lead to consensus divergence and disastrous
> chainsplits!
> On the other hand, LLVM bugs are compiler bugs and
> the same bugs can hit the static compiler `cc`, too,
> since the same LLVM code runs in both JIT and static
> compilation, so this risk already exists for Bitcoin.
> (i.e. we already rely on LLVM not being buggy enough
> to trigger Bitcoin consensus divergence, else we would
> have written Bitcoin Core SCRIPT interpreter in
> assembly.)
>
> Each `UOP_`-code has an equivalent tree of LLVM code.
> For each `Opcode` in the microcode, we take its
> sequence of `UOpcode`s and expand them to this tree,
> concatenating the equivalent trees for each `UOpcode`
> in the sequence.
> Then we ask LLVM to JIT-compile this code to a new
> function, running LLVM-provided optimizers.
> Then we put a pointer to this compiled function to a
> 256-long array of functions, where the array index is
> the `OP_` code.
>
> The SCRIPT interpreter then simply iterates over the
> `OP_` code SCRIPT and calls each of the JIT-compiled
> functions.
> This reduces much of the overhead of the `UOP_` layer
> and makes it approach the current performance of the
> existing `OP_` interpreter.
>
> For the default Bitcoin SCRIPT, the opcodes array
> contains pointers to statically-compiled functions.
> A microcode that is based on the default Bitcoin
> SCRIPT copies this opcodes array, then overwrites
> the entries.
>
> Future versions of Bitcoin Core can "bless"
> particular microcodes by providing statically-compiled
> functions for those microcodes.
> This leads to even better performance (there is
> no need to recompile ancient onchain microcodes each
> time Bitcoin Core starts) without any consensus
> divergence.
> It is a pure optimization and does not imply a
> tightening of rules, and is thus not a softfork.
>
> (To reduce the chance of network faults being used
> to poke into `W|X` memory (since `W|X` memory is
> needed in order to actually JIT compile) we can
> isolate the SCRIPT interpreter into its own process
> separate from the network-facing code.
> This does imply additional overhead in serializing
> transactions we want to ask the SCRIPT interpreter
> to validate.)
>
> Comparison To Jets
> ------------------
>
> This technique allows users to define "jets", i.e.
> sequences of low-level general operations that users
> have determined are common enough they should just
> be implemented as faster code that is executed
> directly by the underlying hardware processor rather
> than via a software interpreter.
> Basically, each redefined `OP_` code is a jet of a
> sequence of `UOP_` micro-opcodes.
>
> We implement this by dynamically JIT-compiling the
> proposed jets, as described above.
> SCRIPTs using jetted code remain smaller, as the
> jet definition is done in a previous transaction and
> does not require copy-pasta (Do Not Repeat Yourself!).
> At the same time, jettification is not tied to
> developers, thus removing the need to keep softforking
> new features --- we only need define a sufficiently
> general language and then we can implement pretty much
> anything worth implementing (and a bunch of other things
> that should not be implemented, but hey, users gonna
> use...).
>
> Bugs in existing microcodes can be fixed by basing a
> new microcode from the existing microcode, and
> redefining the buggy implementation.
> Existing Tapscripts need to be re-spent to point to
> the new bugfixed microcode, but if you used the
> point-spend branch as an N-of-N of all participants
> you have an upgrade mechanism for free.
>
> In order to ensure that the JIT-compilation of new
> microcodes is not triggered trivially, we require
> that users petitioning for the jettification of some
> operations (i.e. introducing a new microcode) must
> sacrifice Bitcoins.
>
> Burning Bitcoins is better than increasing the weight
> of microcode introduction outputs; all fullnodes are
> affected by the need to JIT-compile the new microcode,
> so they benefit from the reduction in supply, thus
> getting compensated for the work of JIT-compiling the
> new microcode.
> Ohter mechanisms for making microcode introduction
> outputs expensive are also possible.
>
> Nothing really requires that we use a stack-based
> language for this; any sufficiently FP language
> should allow referential transparency.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220322/402ad6eb/attachment-0001.html>;

📅 Original date posted:2022-03-05 📝 Original message:On ...

2023-06-08T01:05:14+02:00

In reply to nevent1q…x0yn
_________________________

📅 Original date posted:2022-03-05
📝 Original message:On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> It seems like a decent concept for exploration.
>
> AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the Lightning
> Network look like on Chia?
>
>
> One question that I have had is that it seems like to me that neither
> simplicity nor chia lisp would be particularly suited to a ZK prover...
>

Not that I necessarily disagree with this statement, but I can say that I
have experimented with compiling Simplicity to Boolean circuits. It was a
while ago, but I think the result of compiling my SHA256 program was within
an order of magnitude of the hand made SHA256 circuit for bulletproofs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/d223d490/attachment.html>;

📅 Original date posted:2022-03-06 📝 Original message:The ...

2023-06-08T01:05:14+02:00

In reply to nevent1q…g6ea
_________________________

📅 Original date posted:2022-03-06
📝 Original message:The circuit generated from Simplicity was larger than the hand made one.

On Sat, Mar 5, 2022 at 6:20 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Russell,
>
> > On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > It seems like a decent concept for exploration.
> > >
> > > AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the Lightning
> Network look like on Chia?
> > >
> > > One question that I have had is that it seems like to me that neither
> simplicity nor chia lisp would be particularly suited to a ZK prover...
> >
> > Not that I necessarily disagree with this statement, but I can say that
> I have experimented with compiling Simplicity to Boolean circuits. It was
> a while ago, but I think the result of compiling my SHA256 program was
> within an order of magnitude of the hand made SHA256 circuit for
> bulletproofs.
>
> "Within" can mean "larger" or "smaller" in this context, which was it?
> From what I understand, compilers for ZK-provable circuits are still not
> as effective as humans, so I would assume "larger", but I would be much
> interested if it is "smaller"!
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/b803a6b5/attachment.html>;

📅 Original date posted:2021-07-06 📝 Original message:On ...

2023-06-08T00:56:29+02:00

In reply to nevent1q…uvdm
_________________________

📅 Original date posted:2021-07-06
📝 Original message:On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud <billy.tetrud at gmail.com> wrote:

> > when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think about enabling
> covenants, I'm thinking more about OP_CTV (or some similarly specific
> opcode
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>;
> ).
>
> > OP_TWEAK
>
> I wasn't able to find anything about what that is. Would you mind
> clarifying what that concept is?
>

In tapscript one can generally recover the current input's scriptPubkey
through sighash introspection via the usual covenant tricks. This allows
you to make a recursive covenant by spending funds back to the same
identical scriptPubkey. However, in order for a recursive covenant to be
actually interesting, there needs to be some sort of state update in each
transition. If there is no state update then sending funds back to itself
is of very limited value. It will reset the timer on relative locks, but
that is about all.

The "normal" way of writing useful recursive covenants is to modify the
scriptPubkey by changing a fragment of it that contains some sort of
state. However in order to update a tapscript pubkey one needs to apply
not only hashing, to create a Merkel root, but also to create a tweaked
taproot pubkey that commits to this root. While script currently comes
with a SHA-256 hashing opcode, there is no opcode that will let you perform
the necessary tweaking to create a taproot scriptPubkey.

But as I mentioned afterwards, there are other places in the UTXO that you
could put data in order to perform a state update.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/e7b418bc/attachment.html>;

📅 Original date posted:2021-07-03 📝 Original message:There ...

2023-06-08T00:56:15+02:00

In reply to nevent1q…kp8d
_________________________

📅 Original date posted:2021-07-03
📝 Original message:There is one line written at
https://github.com/ElementsProject/elements/pull/949/files#r660130155. I
suppose we need to decide on which variants of *VERIFY and *ADD we want to
include (presumably all of them) and choose which opcodes they will be
assigned to. And I guess for CHECKSIGFROMSTACKADD will want to place the n
value between the signature and the message on the stack. ... So I suppose
we will need more than one sentence.

The semantics would be basically to call secp256k1_schnorrsig_verify <
https://github.com/bitcoin-core/secp256k1/blob/0440945fb5ce69d335fed32827b5166e84b02e05/include/secp256k1_schnorrsig.h#L158>;,
treating pubkeys and signatures the same way the other CHECKSIG operations
do, and in passing the (variable length) message from the stack.
CHECKSIGFROMSTACK would also be subject to the same sigops budget that
CHECKSIG has in tapscript.

On Sat, Jul 3, 2021 at 2:30 PM Jeremy <jlrubin at mit.edu> wrote:

> Awesome to hear that!
>
> Actually I don't think I did know (or I forgot/didn't catch it) that there
> was an updated spec for elements, I searched around for what I could find
> and came up empty handed. Do you have any links for that? That sounds
> perfect to me.
>
>
> On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor <roconnor at blockstream.com>
> wrote:
>
>> Hi Jermy,
>>
>> As you are aware, we, and by we I mean mostly Sanket, are developing an
>> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The
>> plan here would be to effectively support the an interface to the
>> variable-length extension of BIP-0340 schnorr signatures.
>>
>> BIP-0340 would dispense with DER encoding (good riddance).
>> BIP-0340 signatures are batch verifiable along with other BIP-0340
>> transaction signatures and taproot tweak verification.
>> Support for variable length messages in BIP-0340 has been discussed in <
>> https://github.com/sipa/bips/issues/207>; and an implementation has
>> recently been merged in <
>> https://github.com/bitcoin-core/secp256k1/pull/844>;. The BIP has not
>> yet been updated but the difference is that the message m does not have to
>> be 32-bytes (it is recommended that the message be a 32-bit tagged hash or
>> a message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
>> operation (in tapscript) would use a stack item for this m value to
>> BIP-0340 signature verification and would not necessarily have to be 32
>> bytes.
>>
>> I think this design we are aiming for would be perfectly suited for
>> Bitcoin as well.
>>
>> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>>> specification for "CheckDataSig", more or less the same thing as
>>> CHECKSIGFROMSTACK
>>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>>> In contrast to Element's implementation, it does not have Element's bugs
>>> around verify semantics and uses the nullfail rule, and there is a
>>> specification document so it seemed like the easiest starting point for
>>> discussion v.s. drafting something from scratch.
>>>
>>> Does anyone have any issue with adapting this exact text and
>>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>>
>>> Note that with *just* CheckSigFromStack, while you can do some very
>>> valuable use cases, but without OP_CAT it does not enable sophisticated
>>> covenants (and as per
>>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>>> just CAT alone enables such uses).
>>>
>>> Design questions worth considering as modifications:
>>>
>>> 1. Should CSFS require some sort of tagged hash? Very likely answer is
>>> no – tags interfere with certain use cases
>>> 2. Should CSFS split the signature’s R & S value stack items for some
>>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>>> allows you to extract a private key if ever double signed, using 2 R values
>>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>>> desired then OP_CAT can be introduced
>>> 3. Should CSFS support a cheap way to reference the taproot internal or
>>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>>> One might want to use the internal key, if the signed data should be valid
>>> independent of the tapscript tree. One might want to use the external key,
>>> if the data should only be valid for a single tapscript key + tree.
>>> 4. Should invalid public keys types be a NOP to support future extended
>>> pubkey types?
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>> Jeremy
>>>
>>>
>>> ---
>>> layout: specification
>>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>>> category: spec
>>> date: 2018-08-20
>>> activation: 1542300000
>>> version: 0.6
>>> ---
>>>
>>> OP_CHECKDATASIG
>>> ===============
>>>
>>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid with respect to a message and a public key.
>>>
>>> OP_CHECKDATASIG permits data to be imported into a script, and have its validity checked against some signing authority such as an "Oracle".
>>>
>>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG functionality being replaced by OP_CHECKDATASIG, along with a separate Op Code to create a hash from the transaction based on the SigHash algorithm.
>>>
>>> OP_CHECKDATASIG Specification
>>> -----------------------------
>>>
>>> ### Semantics
>>>
>>> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be well formed, the stack must contain at least three elements [`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the top element and
>>> * `<pubKey>` must be a validly encoded public key
>>> * `<msg>` can be any string
>>> * `<sig>` must follow the strict DER encoding as described in [2] and the S-value of `<sig>` must be at most the curve order divided by 2 as described in [3]
>>>
>>> If the stack is well formed, then OP_CHECKDATASIG pops the top three elements [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true onto the stack if `<sig>` is valid with respect to the raw single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1 elliptic curve. Otherwise, it pops three elements and pushes false onto the stack in the case that `<sig>` is the empty string and fails in all other cases.
>>>
>>> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature does not match the supplied public key and message hash, and the signature is not an empty byte array, the entire script fails.
>>>
>>> ### Opcode Number
>>>
>>> OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in hex encoding)
>>>
>>> ### SigOps
>>>
>>> Signature operations accounting for OP_CHECKDATASIG shall be calculated the same as OP_CHECKSIG. This means that each OP_CHECKDATASIG shall be counted as one (1) SigOp.
>>>
>>> ### Activation
>>>
>>> Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>>>
>>> ### Unit Tests
>>>
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if 15 November 2018 protocol upgrade is not yet activated.
>>> - `<sig> <msg> OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<pubKey>` is not a validly encoded public key.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass the Low S check.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass signature validation of `<msg>` and `<pubKey>`.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes false onto the stack if `<sig>` is an empty byte array.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes true onto the stack if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>>>
>>> OP_CHECKDATASIGVERIFY Specification
>>> -----------------------------------
>>>
>>> ### Semantics
>>>
>>> OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by OP_VERIFY. It leaves nothing on the stack, and will cause the script to fail immediately if the signature check does not pass.
>>>
>>> ### Opcode Number
>>>
>>> OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187 (0xbb in hex encoding)
>>>
>>> ### SigOps
>>>
>>> Signature operations accounting for OP_CHECKDATASIGVERIFY shall be calculated the same as OP_CHECKSIGVERIFY. This means that each OP_CHECKDATASIGVERIFY shall be counted as one (1) SigOp.
>>>
>>> ### Activation
>>>
>>> Use of OP_CHECKDATASIGVERIFY, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>>>
>>> ### Unit Tests
>>>
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November 2018 protocol upgrade is not yet activated.
>>> - `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3 item on stack.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is not a validly encoded public key.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature `<sig>` is not empty and does not pass the Low S check.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a valid signature of `<msg>` with respect to `<pubKey>`.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three stack elements if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>>>
>>> Sample Implementation [4, 5]
>>> ----------------------------
>>>
>>> ```c++
>>> case OP_CHECKDATASIG:
>>> case OP_CHECKDATASIGVERIFY: {
>>> // Make sure this remains an error before activation.
>>> if ((flags & SCRIPT_ENABLE_CHECKDATASIG) == 0) {
>>> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
>>> }
>>>
>>> // (sig message pubkey -- bool)
>>> if (stack.size() < 3) {
>>> return set_error(
>>> serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>>> }
>>>
>>> valtype &vchSig = stacktop(-3);
>>> valtype &vchMessage = stacktop(-2);
>>> valtype &vchPubKey = stacktop(-1);
>>>
>>> if (!CheckDataSignatureEncoding(vchSig, flags,
>>> serror) ||
>>> !CheckPubKeyEncoding(vchPubKey, flags, serror)) {
>>> // serror is set
>>> return false;
>>> }
>>>
>>> bool fSuccess = false;
>>> if (vchSig.size()) {
>>> valtype vchHash(32);
>>> CSHA256()
>>> .Write(vchMessage.data(), vchMessage.size())
>>> .Finalize(vchHash.data());
>>> uint256 message(vchHash);
>>> CPubKey pubkey(vchPubKey);
>>> fSuccess = pubkey.Verify(message, vchSig);
>>> }
>>>
>>> if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &&
>>> vchSig.size()) {
>>> return set_error(serror, SCRIPT_ERR_SIG_NULLFAIL);
>>> }
>>>
>>> popstack(stack);
>>> popstack(stack);
>>> popstack(stack);
>>> stack.push_back(fSuccess ? vchTrue : vchFalse);
>>> if (opcode == OP_CHECKDATASIGVERIFY) {
>>> if (fSuccess) {
>>> popstack(stack);
>>> } else {
>>> return set_error(serror,
>>> SCRIPT_ERR_CHECKDATASIGVERIFY);
>>> }
>>> }
>>> } break;
>>> ```
>>>
>>> Sample Usage
>>> ------------
>>>
>>> The following example shows a spend and redeem script for a basic use of CHECKDATASIG. This example validates the signature of some data, provides a placeholder where you would then process that data, and finally allows one of 2 signatures to spend based on the outcome of the data processing.
>>>
>>> ### spend script:
>>> ```
>>> push txsignature
>>> push txpubkey
>>> push msg
>>> push sig
>>> ```
>>> ### redeem script:
>>> ```
>>> (txsig, txpubkey msg, sig)
>>> OP_OVER (txsig, txpubkey, msg, sig, msg)
>>> push data pubkey (txsig, txpubkey, msg, sig, msg, pubkey)
>>> OP_CHECKDATASIGVERIFY (txsig, txpubkey, msg)
>>> ```
>>> Now that msg is on the stack top, the script can write predicates on it,
>>> resulting in the message being consumed and a true/false condition left on the stack: (txpubkey, txsig, boolean)
>>> ```
>>> OP_IF (txsig, txpubkey)
>>> OP_DUP (txsig, txpubkey, txpubkey)
>>> OP_HASH160 (txsig, txpubkey, address)
>>> push <p2pkh spend address> (txsig, txpubkey, address, p2pkh spend address)
>>> OP_EQUALVERIFY (txsig, txpubkey)
>>> OP_CHECKSIG
>>> OP_ELSE
>>> (same as if clause but a different <p2pkh spend address>)
>>> OP_ENDIF
>>> ```
>>>
>>> History
>>> -------
>>>
>>> This specification is based on Andrew Stone’s OP_DATASIGVERIFY proposal [6, 7]. It is modified from Stone's original proposal based on a synthesis of all the peer-review and feedback received [8].
>>>
>>> References
>>> ----------
>>>
>>> [1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)
>>>
>>> [2] [Strict DER Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)
>>>
>>> [3] [Low-S and Nullfail Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki)
>>>
>>> [4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)
>>>
>>> [5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D1646)
>>>
>>> [6] [Andrew Stone’s OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md)
>>>
>>> [7] [Andrew Stone's article on Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9)
>>>
>>> [8] [Peer Review of Andrew Stone's Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/e56d5b04/attachment-0001.html>;

📅 Original date posted:2021-07-03 📝 Original message:Hi ...

2023-06-08T00:56:13+02:00

In reply to nevent1q…3y9w
_________________________

📅 Original date posted:2021-07-03
📝 Original message:Hi Jermy,

As you are aware, we, and by we I mean mostly Sanket, are developing an
updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The
plan here would be to effectively support the an interface to the
variable-length extension of BIP-0340 schnorr signatures.

BIP-0340 would dispense with DER encoding (good riddance).
BIP-0340 signatures are batch verifiable along with other BIP-0340
transaction signatures and taproot tweak verification.
Support for variable length messages in BIP-0340 has been discussed in <
https://github.com/sipa/bips/issues/207>; and an implementation has recently
been merged in <https://github.com/bitcoin-core/secp256k1/pull/844>;. The
BIP has not yet been updated but the difference is that the message m does
not have to be 32-bytes (it is recommended that the message be a 32-bit
tagged hash or a message with a 64-bit application specific prefix). The
CHECKSIGFROMSTACK operation (in tapscript) would use a stack item for this
m value to BIP-0340 signature verification and would not necessarily have
to be 32 bytes.

I think this design we are aiming for would be perfectly suited for Bitcoin
as well.

On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
> specification for "CheckDataSig", more or less the same thing as
> CHECKSIGFROMSTACK
> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
> In contrast to Element's implementation, it does not have Element's bugs
> around verify semantics and uses the nullfail rule, and there is a
> specification document so it seemed like the easiest starting point for
> discussion v.s. drafting something from scratch.
>
> Does anyone have any issue with adapting this exact text and
> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants (and as per
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
> CAT alone enables such uses).
>
> Design questions worth considering as modifications:
>
> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
> – tags interfere with certain use cases
> 2. Should CSFS split the signature’s R & S value stack items for some
> applications that otherwise may require OP_CAT? E.g. using a pinned R value
> allows you to extract a private key if ever double signed, using 2 R values
> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
> desired then OP_CAT can be introduced
> 3. Should CSFS support a cheap way to reference the taproot internal or
> external key? Perhaps, can be handled with undefined upgradeable keytypes.
> One might want to use the internal key, if the signed data should be valid
> independent of the tapscript tree. One might want to use the external key,
> if the data should only be valid for a single tapscript key + tree.
> 4. Should invalid public keys types be a NOP to support future extended
> pubkey types?
>
>
>
> Best,
>
>
> Jeremy
>
>
> ---
> layout: specification
> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
> category: spec
> date: 2018-08-20
> activation: 1542300000
> version: 0.6
> ---
>
> OP_CHECKDATASIG
> ===============
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid with respect to a message and a public key.
>
> OP_CHECKDATASIG permits data to be imported into a script, and have its validity checked against some signing authority such as an "Oracle".
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG functionality being replaced by OP_CHECKDATASIG, along with a separate Op Code to create a hash from the transaction based on the SigHash algorithm.
>
> OP_CHECKDATASIG Specification
> -----------------------------
>
> ### Semantics
>
> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be well formed, the stack must contain at least three elements [`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the top element and
> * `<pubKey>` must be a validly encoded public key
> * `<msg>` can be any string
> * `<sig>` must follow the strict DER encoding as described in [2] and the S-value of `<sig>` must be at most the curve order divided by 2 as described in [3]
>
> If the stack is well formed, then OP_CHECKDATASIG pops the top three elements [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true onto the stack if `<sig>` is valid with respect to the raw single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1 elliptic curve. Otherwise, it pops three elements and pushes false onto the stack in the case that `<sig>` is the empty string and fails in all other cases.
>
> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature does not match the supplied public key and message hash, and the signature is not an empty byte array, the entire script fails.
>
> ### Opcode Number
>
> OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in hex encoding)
>
> ### SigOps
>
> Signature operations accounting for OP_CHECKDATASIG shall be calculated the same as OP_CHECKSIG. This means that each OP_CHECKDATASIG shall be counted as one (1) SigOp.
>
> ### Activation
>
> Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>
> ### Unit Tests
>
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if 15 November 2018 protocol upgrade is not yet activated.
> - `<sig> <msg> OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<pubKey>` is not a validly encoded public key.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass the Low S check.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass signature validation of `<msg>` and `<pubKey>`.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes false onto the stack if `<sig>` is an empty byte array.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes true onto the stack if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>
> OP_CHECKDATASIGVERIFY Specification
> -----------------------------------
>
> ### Semantics
>
> OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by OP_VERIFY. It leaves nothing on the stack, and will cause the script to fail immediately if the signature check does not pass.
>
> ### Opcode Number
>
> OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187 (0xbb in hex encoding)
>
> ### SigOps
>
> Signature operations accounting for OP_CHECKDATASIGVERIFY shall be calculated the same as OP_CHECKSIGVERIFY. This means that each OP_CHECKDATASIGVERIFY shall be counted as one (1) SigOp.
>
> ### Activation
>
> Use of OP_CHECKDATASIGVERIFY, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>
> ### Unit Tests
>
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November 2018 protocol upgrade is not yet activated.
> - `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3 item on stack.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is not a validly encoded public key.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature `<sig>` is not empty and does not pass the Low S check.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a valid signature of `<msg>` with respect to `<pubKey>`.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three stack elements if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>
> Sample Implementation [4, 5]
> ----------------------------
>
> ```c++
> case OP_CHECKDATASIG:
> case OP_CHECKDATASIGVERIFY: {
> // Make sure this remains an error before activation.
> if ((flags & SCRIPT_ENABLE_CHECKDATASIG) == 0) {
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> }
>
> // (sig message pubkey -- bool)
> if (stack.size() < 3) {
> return set_error(
> serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> }
>
> valtype &vchSig = stacktop(-3);
> valtype &vchMessage = stacktop(-2);
> valtype &vchPubKey = stacktop(-1);
>
> if (!CheckDataSignatureEncoding(vchSig, flags,
> serror) ||
> !CheckPubKeyEncoding(vchPubKey, flags, serror)) {
> // serror is set
> return false;
> }
>
> bool fSuccess = false;
> if (vchSig.size()) {
> valtype vchHash(32);
> CSHA256()
> .Write(vchMessage.data(), vchMessage.size())
> .Finalize(vchHash.data());
> uint256 message(vchHash);
> CPubKey pubkey(vchPubKey);
> fSuccess = pubkey.Verify(message, vchSig);
> }
>
> if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &&
> vchSig.size()) {
> return set_error(serror, SCRIPT_ERR_SIG_NULLFAIL);
> }
>
> popstack(stack);
> popstack(stack);
> popstack(stack);
> stack.push_back(fSuccess ? vchTrue : vchFalse);
> if (opcode == OP_CHECKDATASIGVERIFY) {
> if (fSuccess) {
> popstack(stack);
> } else {
> return set_error(serror,
> SCRIPT_ERR_CHECKDATASIGVERIFY);
> }
> }
> } break;
> ```
>
> Sample Usage
> ------------
>
> The following example shows a spend and redeem script for a basic use of CHECKDATASIG. This example validates the signature of some data, provides a placeholder where you would then process that data, and finally allows one of 2 signatures to spend based on the outcome of the data processing.
>
> ### spend script:
> ```
> push txsignature
> push txpubkey
> push msg
> push sig
> ```
> ### redeem script:
> ```
> (txsig, txpubkey msg, sig)
> OP_OVER (txsig, txpubkey, msg, sig, msg)
> push data pubkey (txsig, txpubkey, msg, sig, msg, pubkey)
> OP_CHECKDATASIGVERIFY (txsig, txpubkey, msg)
> ```
> Now that msg is on the stack top, the script can write predicates on it,
> resulting in the message being consumed and a true/false condition left on the stack: (txpubkey, txsig, boolean)
> ```
> OP_IF (txsig, txpubkey)
> OP_DUP (txsig, txpubkey, txpubkey)
> OP_HASH160 (txsig, txpubkey, address)
> push <p2pkh spend address> (txsig, txpubkey, address, p2pkh spend address)
> OP_EQUALVERIFY (txsig, txpubkey)
> OP_CHECKSIG
> OP_ELSE
> (same as if clause but a different <p2pkh spend address>)
> OP_ENDIF
> ```
>
> History
> -------
>
> This specification is based on Andrew Stone’s OP_DATASIGVERIFY proposal [6, 7]. It is modified from Stone's original proposal based on a synthesis of all the peer-review and feedback received [8].
>
> References
> ----------
>
> [1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)
>
> [2] [Strict DER Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)
>
> [3] [Low-S and Nullfail Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki)
>
> [4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)
>
> [5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D1646)
>
> [6] [Andrew Stone’s OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md)
>
> [7] [Andrew Stone's article on Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9)
>
> [8] [Peer Review of Andrew Stone's Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/ce1d831d/attachment-0001.html>;

📅 Original date posted:2021-04-06 📝 Original ...

2023-06-07T20:31:09+02:00

In reply to nevent1q…syd3
_________________________

📅 Original date posted:2021-04-06
📝 Original message:I'm pretty sure that the question of "is signalling still possible by the
time enough miners have upgraded and are ready to start signalling?"
Strongly benefits from a guaranteed number of signaling periods that height
based activation offers. Especially for the short activation period of
Speedy Trial.

The other relevant value of giving enough time for users to upgrade is not
very sensitive. It's not like 180 days is magic number that going over is
safe and going below is unsafe.

That said, as Jeremy has pointed out before (maybe it was on IRC), we can
almost ensure a minimum of 7 retargeting periods by carefully selecting
signaling start and end dates to line up in the middle of expected
retargeting periods that we would otherwise chose with height based
activation. Why we would rather use MTP to fake a height based activation,
I will never understand. But if this is what it takes to activate taproot,
that is fine by me.

The differences between height and MTP activation are too small to matter
that much for what is ultimately transient code. As long as MTP activation
can pass code review it is okay with me.

On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:
> > As such, the main conversation in this agenda item is
> > around the pros/cons of height or MTP and determining if we can reach
> consensus
> > on either approach.
>
> Here's some numbers.
>
> Given a desired signalling period of xxx days, where signaling begins
> on the first retarget boundary after the starttime and ends on the last
> retarget boundary before the endtime, this is how many retarget periods
> you get (based on blocks since 2015-01-01):
>
> 90 days: mainnet 5-7 full 2016-block retarget periods
> 180 days: mainnet 11-14
> 365 days: mainnet 25-27
> 730 days: mainnet 51-55
>
> (This applies to non-signalling periods like the activation/lock in delay
> too of course. If you change it so that it ends at the first retarget
> period after endtime, all the values just get incremented -- ie, 6-8,
> 12-15 etc)
>
> If I've got the maths right, then requiring 1814 of 2016 blocks to signal,
> means that having 7 periods instead of 5 lets you get a 50% chance of
> successful activation by maintaining 89.04% of hashpower over the entire
> period instead of 89.17%, while 55 periods instead of 51 gives you a 50%
> chance of success with 88.38% hashpower instead of 88.40% hashpower.
> So the "repeated trials" part doesn't look like it has any significant
> effect on mainnet.
>
> If you target yy periods instead of xxx days, starting and ending on a
> retarget boundary, you get the following stats from the last few years
> of mainnet (again starting at 2015-01-01):
>
> 1 period: mainnet 11-17 days (range 5.2 days)
> 7 periods: mainnet 87-103 days (range 15.4 days)
> 13 periods: mainnet 166-185 days (range 17.9 days)
> 27 periods: mainnet 352-377 days (range 24.4 days)
> 54 periods: mainnet 711-747 days (range 35.0 days)
>
> As far as I can see the questions that matter are:
>
> * is signalling still possible by the time enough miners have upgraded
> and are ready to start signalling?
>
> * have nodes upgraded to enforce the new rules by the time activation
> occurs, if it occurs?
>
> But both those benefit from less real time variance, rather than less
> variance in the numbers of signalling periods, at least in every way
> that I can think of.
>
> Corresponding numbers for testnet:
>
> 90 days: testnet 5-85
> 180 days: testnet 23-131
> 365 days: testnet 70-224
> 730 days: testnet 176-390
>
> (A 50% chance of activating within 5 periods requires sustaining 89.18%
> hashpower; within 85 periods, 88.26% hashpower; far smaller differences
> with all the other ranges -- of course, presumably the only way the
> higher block rates ever actually happen is by someone pointing an ASIC at
> testnet, and thus controlling 100% of blocks for multiple periods anyway)
>
> 1 period: testnet 5.6minutes-26 days (range 26.5 days)
> 13 periods: testnet 1-135 days (range 133.5 days)
> 27 periods: testnet 13-192 days (range 178.3 days)
> 54 periods: testnet 39-283 days (range 243.1 days)
> 100 periods: testnet 114-476 days (range 360.9 days)
> (this is the value used in [0] in order to ensure 3 months'
> worth of signalling is available)
> 132 periods: testnet 184-583 days (range 398.1 days)
> 225 periods: testnet 365-877 days (range 510.7 days)
> 390 periods: testnet 725-1403 days (range 677.1 days)
>
> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-621934640
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/1049635d/attachment.html>;

📅 Original date posted:2021-03-06 📝 Original message:Hi ...

2023-06-07T20:30:31+02:00

In reply to nevent1q…xvz3
_________________________

📅 Original date posted:2021-03-06
📝 Original message:Hi Andrew,

This is a slight misunderstanding of the proposal. Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.

Thus using your figures it would instead be:

* start height = 681408 /* about May 1st */
* timeout height = 695520 /* about Aug 7th */
* min activation height = 709632 /* about Nov 13th */
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)

This guarantees 7 retargeting periods between start height and timeout
height.

Being able to make a guarantee about how many retargeting periods we get is
perhaps something worth pursuing given that the signaling period is so
short for this trial.

On Sat, Mar 6, 2021 at 1:04 AM Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I like this idea.
>
> In terms of actual parameters, I propose that we base this Speedy Trial
> off of BIP 8 with the following parameters:
> * start height = 681408
> * timeout height = 695520
> * lockinontimeout = False
> * signaling bit = 2
> * threshold = 1815/2016 blocks (90%)
>
> For the extended lockin period, I propose 14112 blocks, which is 7
> retarget periods. Thus the earliest activation height will be 697536 and
> the latest activation height will be 709632.
>
> This will give us an approximate start time of May 1st 2021 and an
> approximate timeout time of August 7th 2021, for a total activation
> period of just over 3 months. The extended lockin period is the same
> number of blocks as the activation period so that will also be just over
> 3 months, giving us the latest activation time of November 13th, 2021.
> If miners activated as soon as possible, the earliest activation time
> would be August 21st 2021.
>
> Additionally, this timeline assumes a mid-April release of Bitcoin Core
> 0.21.1 containing these parameters. They could be changed to move up if
> the expected release date were sooner.
>
>
> Andrew Chow
>
> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor recently
> > proposed a modification of the "Let's see what happens" activation
> > proposal.[1] The idea received significant discussion and seemed
> > acceptable to several people who could not previously agree on a
> > proposal (although this doesn't necessarily make it their first
> > choice). The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing this
> > proposed activation logic, nodes will begin counting blocks towards
> > the 90% threshold required to lock in taproot.[2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within approximately
> > three months, the activation attempt fails. There is no mandatory
> > activation and everyone is encouraged to try again using different
> > activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin threshold
> > is reached, taproot is guaranteed to eventually activate---but not
> > until approximately six months after signal tracking started.
> >
> > ## Example timeline
> >
> > (All dates approximate; see the section below about BIP9 vs BIP8.)
> >
> > - T+0: release of one or more full nodes with activation code
> > - T+14: signal tracking begins
> > - T+28: earliest possible lock in
> > - T+104: locked in by this date or need to try a different activation
> process
> > - T+194: activation (if lockin occurred)
> >
> > ## Analysis
> >
> > The goal of Speedy Trial is to allow a taproot activation attempt to
> > either quickly succeed or quickly fail---without compromising safety in
> > either case. Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large part of
> > the economy or there's a risk that a long chain of blocks breaking the
> > rules will be accepted by some users and rejected by others, causing a
> > chain split that can result in large direct losses to transaction
> > receivers and potentially even larger indirect losses to holders due to
> > reduced confidence in the safety of the Bitcoin system.
> >
> > One step developers have taken in the past to ensure widespread adoption
> > of new consensus rules is programming in a delay between the time
> software
> > with those rules is expected to be released and when the software starts
> > tracking which blocks signal for activation. For example:
> >
> > Soft fork | Release | Start | Delta
> > -----------------+------------+------------+----------
> > BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
> > BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
> >
> > Sources: BitcoinCore.org,
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend delay.
> > No matter how fast taproot's activation threshold is reached by miners,
> > there will be six months between the time signal tracking starts and when
> > nodes will begin enforcing taproot's rules. This gives the userbase even
> > more time to upgrade than if we had used the most recently proposed start
> > date for a BIP8 activation (~July 23rd).[2]
> >
> > ### Succeed, or fail fast
> >
> > The earlier version of this proposal was documented over 200 days ago[3]
> > and taproot's underlying code was merged into Bitcoin Core over 140 days
> > ago.[4] If we had started Speedy Trial at the time taproot
> > was merged (which is a bit unrealistic), we would've either be less than
> > two months away from having taproot or we would have moved on to the
> > next activation attempt over a month ago.
> >
> > Instead, we've debated at length and don't appear to be any closer to
> > what I think is a widely acceptable solution than when the mailing list
> > began discussing post-segwit activation schemes over a year ago.[5] I
> > think Speedy Trial is a way to generate fast progress that will either
> > end the debate (for now, if activation is successful) or give us some
> > actual data upon which to base future taproot activation proposals.
> >
> > Of course, for those who enjoy the debate, discussion can continue while
> > waiting for the results of Speedy Trial.
> >
> > ### Base activation protocol
> >
> > The idea can be implemented on top of either Bitcoin Core's existing
> > BIP9 code or its proposed BIP8 patchset.[6]
> >
> > - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
> > these values plus a time-based parameter for the minimum activation
> > delay would give three months for miners to activate taproot, but some
> > of that time near the start or the end might not be usable due to
> > signals only being measured in full retarget periods. However, the
> > six month time for users to upgrade their node would be not be
> > affected by either slow or fast block production.
> >
> > BIP9 is already part of Bitcoin Core and I think the changes being
> > proposed would be relatively small, resulting in a small patch that
> > could be easy to review.
> >
> > - BIP8 uses two height-based parameters, startheight and timeoutheight.
> > Using height values would ensure miners had a certain number of
> > retarget periods (6) to lock in taproot and that there'd be a certain
> > number of blocks (about 24,000) until activation, although latest lock
> > in and expected activation could occur moderately earlier or later
> > than the estimated three and six months.
> >
> > BIP8 would likely be used if Speedy Trial fails, so it could be
> > advantageous to base this proposal on BIP8 so that we gain
> > experience running that code in production.
> >
> > For additional discussion about using times versus heights, see today's
> > log for ##taproot-activation.[11]
> >
> > ### Additional concerns
> >
> > - Encourages false signaling: false signaling is when miners signal
> > readiness to enforce rules that their nodes don't actually support.
> > This was partially responsible for a six-block reorg shortly after the
> > final BIP66 activation[8] and was found to still be a problem during
> > the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
> >
> > Because Speedy Trial only gives miners a maximum of three months to
> > signal support for taproot, it may encourage such false signaling. If
> > taproot locks in as a result of their signaling but most of them fail
> > to upgrade by the activation date several months later, unprepared
> > miners could lose large amounts of money and users could see long
> > reorgs (with unupgraded nodes and SPV lite clients potentially losing
> > money).
> >
> > Compared to other activation proposals, I think the only difference is
> > Speedy Trial's short timeline. False signaling is possible with any
> > other proposal and the same problems can occur if miners fail to
> > upgrade for any mandatory activation.
> >
> > ### Additional advantages
> >
> > - No mandatory signaling: at no time are miners required to signal by
> > Speedy Trial. This includes no mandatory signaling during the
> > locked_in period(s), although such signaling will be encouraged (as it
> > was with BIP9[10]).
> >
> > - Party time: to a lesser degree, a benefit mentioned for flag day
> > activation may also apply here: we could get up to six months
> > advanced notice of taproot activation, allowing users, developers, and
> > organizations to prepare software, announcements, and celebrations for
> > that event.
> >
> > ## Implementation details and next steps
> >
> > Initial discussion about implementation may be found in today's
> > ##taproot-activation log.[11] If it appears Speedy Trial may have
> > traction, Russell O'Connor has offered to work on a patch against BIP8
> > implementing it.
> >
> > ## Acknowledgments
> >
> > The original idea for a short-duration attempt was discussed in the
> > ##taproot-activation IRC channel last July and the revised idea saw
> > additional evaluation there this week. Despite growing frustration,
> > discussion has been overwhelmingly constructive, for which all the
> > contributors should be commended. Although this should not in any way
> > imply endorsement, I'm grateful for the review and comments on a draft
> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> > O'Connor, and IRC users maybehuman and proofofkeags
> >
> > ## Footnotes
> >
> > [1]
> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
> >
> > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> > seemed to have near-universal support during the 2021-02-16 IRC
> > meeting. See:
> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> >
> > [3]
> https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
> >
> > [4] https://github.com/bitcoin/bitcoin/pull/19953
> >
> > [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
> >
> > [6] https://github.com/bitcoin/bitcoin/pull/19573
> >
> > [7] BIP9's times are based on the median of the past 11 blocks, which
> > usually trails UTC by about 90 minutes but which can trail behind
> > realtime significantly if miners are doing weird things.
> >
> > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
> >
> > [9]
> https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
> >
> > [10]
> https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
> >
> > [11] http://gnusha.org/taproot-activation/2021-03-05.log
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210306/ac5abbef/attachment-0001.html>;

📅 Original date posted:2020-05-02 📝 Original message:> ...

2023-06-07T20:24:14+02:00

In reply to nevent1q…3c0l
_________________________

📅 Original date posted:2020-05-02
📝 Original message:> If you didn't verify the output scriptPubKeys, you would *only* be able
> to care about fees since you couldn't verify where any of the funds went?
> And you'd only be able to say fees are "at least x", since they could be
> more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might
> almost make sense for a transaction accelerator that's trying to increase
> the fees; but only if you were doing it for someone else's transaction
> (since otherwise you'd care about the output addresses) and only if you
> were happy to not receive any change? Seems like a pretty weird use case?
>

You are right of course. I was thinking of cases where you only care about
where some of the outputs go but not all. But of course, even in that case
you will need to wade through all of the output ScriptPubKeys anyways.
The current design shares the hashOuputs value with the one computed with
BIP-143, and that is a somewhat valuable property to keep.

Thanks for setting me straight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200502/6d03957c/attachment.html>;

📅 Original date posted:2020-05-01 📝 Original message:While ...

2023-06-07T20:24:11+02:00

In reply to nevent1q…txxn
_________________________

📅 Original date posted:2020-05-01
📝 Original message:While I'm not entirely convinced yet that accertaining non-ownership of an
input is a robust method of solving the problem here, I also see little
reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
already indirectly covered through the outpoints, so it is just a matter of
optimization. Furthermore in the consensus code, the ScriptPubKeys are
part of the UTXO data set, and it is already being retrieved as part of the
transaction checking process, so it is readily available.

I'm not sure how much my opinion on the topic matters, but I did include
this kind of functionality in my design for Simplicity on Elements, and I
have been leaning towards adding this kind of functionality in my Bitcoin
demo application of Simplicity.

Regarding specifics, I personally think it would be better to keep the
hashes of the ScriptPubKeys separate from the hashes of the input values.
This way anyone only interested in input values does not need to wade
through what are, in principle, arbitrarily long ScriptPubKeys in order to
check the input values (which each fixed size). To that end, I would also
(and independently) propose separating the hashing of the output values
from the output ScriptPubKeys in `sha_outputs` so again, applications
interested only in summing the values of the outputs (for instance to
compute fees) do not have to wade through those arbitrarily long
ScriptPubKeys in the outputs.

On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> In the current draft of BIP-0341 [1] the signature message commits to the
> scriptPubKey of the output being spent by the input. I propose that the
> signature message should commit to the scriptPubKeys of *all* transaction
> inputs.
>
> In certain applications like CoinJoin, a wallet has to deal with
> transactions containing external inputs. To calculate the actual amount
> that the user is spending, the wallet needs to reliably determine for each
> input whether it belongs to the wallet or not. Without such a mechanism an
> adversary can fool the wallet into displaying incorrect information about
> the amount being spent, which can result in theft of user funds [2].
>
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input. It must acquire the full transaction being spent and verify its
> hash against that which is given in the outpoint. This is an obstacle in
> the implementation of lightweight air-gapped wallets and hardware wallets
> in general. If the signature message would commit to the scriptPubKeys of
> all transaction inputs, then the wallet would only need to acquire the
> scriptPubKey of the output being spent without having to acquire and verify
> the hash of the entire previous transaction. If an attacker would provide
> an incorrect scriptPubKey, then that would cause the wallet to generate an
> invalid signature message.
>
> Note that committing only to the scriptPubKey of the output being spent is
> insufficient for this application, because the scriptPubKeys which are
> needed to ascertain non-ownership of external inputs are precisely the ones
> that would not be included in any of the signature messages produced by the
> wallet.
>
> The obvious way to implement this is to add another hash to the signature
> message:
> sha_scriptPubKeys (32): the SHA256 of the serialization of all
> scriptPubKeys of the previous outputs spent by this transaction.
>
> Cheers,
> Andrew Kozlik
>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200501/cc57f1b0/attachment.html>;

📅 Original date posted:2020-03-21 📝 Original message:On ...

2023-06-07T20:23:12+02:00

In reply to nevent1q…j8hu
_________________________

📅 Original date posted:2020-03-21
📝 Original message:On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Pieter,
>
> Let's take a step back first. If we believe that malicious hardware
> wallets are big enough of a concern, then signing is only part of the
> problem. The other issue is key generation. The PRG from which the seed
> is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO
> chosen by the hardware manufacturer. I haven't seen an argument why
> attacks during the signing model should more realistic than attacks
> during key generation, so I'd be very hesitant to deploy anti-covert
> channel singing protocols without deploying protocols for key
> generation that are secure in the same attacker model.
>

Public keys are deterministic and can be spot checked. In fact, AFAIU if
hardened HD key derivations are not used, then spot checking is very easy.

While spot checking isn't ideal, my original concern with the synthetic
none standard proposal was that it is inherently non-deterministic and
cannot ever be spot checked. This is why anti-covert signing protocols are
so important if we are going to use synthetic nonces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200321/33b4ef58/attachment.html>;

📅 Original date posted:2019-11-08 📝 Original message:I do ...

2023-06-07T20:21:39+02:00

In reply to nevent1q…9y92
_________________________

📅 Original date posted:2019-11-08
📝 Original message:I do like the idea of length prefixing the witness program. I will note
that the 1 byte witness version is really more like a 1 character witness
version. There are 17 different segwit versions and there are 32
characters in the bech32 alphabet. That leaves 15 unused characters that
we can use for assigning new meanings too.

That said, it is probably most sensible to define a new
human-readable-prefix for length prefixed bitcoin witness programs. "btc1"
anyone?

On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning Pieter, and all,
>
> Can we modify Bech32 SegWit address format for version 1 and above as
> below?
>
> * The data-part values:
> ** 1 byte: the witness version
> + ** If the witness version is non-zero, 1 byte: the length of the
> witness program.
> ** A conversion of the 2-to-40-byte witness program (as defined by [
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141])
> to base32:
> *** Start with the bits of the witness program, most significant bit
> per byte first.
> *** Re-arrange those bits into groups of 5, and pad with zeroes at
> the end if needed.
> *** Translate those bits to characters using the table above.
>
> This retains the ability of a bech32 address to specify any valid witness
> length and allows future version 1 addresses with lengths other than 32,
> while closing this malleation.
>
> Older software being given the modified v1 address format would mis-send
> it to the wrong witness program, however.
>
> Alternately we could just keep using version 0 in the address format
> forever.
> The requirement would be to ensure that SegWit vN (N >= 1) output witness
> programs would have a data-part value encoded as below:
>
> * The data-part values:
> ** 1 byte: legacy witness version, which must always be 0.
> ** 1 byte: actual witness version, which must be non-zero.
> ** 1 byte: padding length: 0 or 1.
> ** If padding length is 1, 1 byte: padding, which must be 0.
> ** 1 byte: witness program length.
> ** variable: witness program.
>
> A writer for a v1 or later address would initially set an empty padding,
> then compute:
>
> 1 // actual witness version
> + 1 // padding length
> + 1 // witness length
> + witness_length
>
> If the above sum is 20 or 32, then the writer selects a non-zero padding
> and inserts the padding byte so that the above sum is now 21 or 33.
>
> To a reader that understands only bech32 v0, such an encoding would look
> like a SegWit v0 invalid-program-length, and be rejected.
> A reader which understands the above protocol would, instead of rejecting
> a SegWit v0 invalid-program-length, instead attempt to parse it as above
> first, and consider it as SegWit v1 or higher if it was parsed correctly as
> above.
>
> The above proposal is of course ridiculous and I am now currently running
> diagnostics on my processing units to see if further glitches occur in test
> reasoning skills.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/7280da70/attachment.html>;

📅 Original date posted:2019-06-18 📝 Original message:Just ...

2023-06-07T20:18:27+02:00

In reply to nevent1q…3g9n
_________________________

📅 Original date posted:2019-06-18
📝 Original message:Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of
covenants if it pulled data from the stack, the OP_SECURETHEBAG probably
cannot create covenants even if it were to pull the data from the stack
unless some OP_TWEEKPUBKEY operation is added to Script because the
"commitment of the script itself" isn't part of the OP_SECURETHEBAG.

So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason
to complicate the spec to ensure the digest is precommitted as part of the
opcode."

On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning aj,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:
> >
> > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> >
> > I think you could generalise that slightly and make it fit in
> > with the existing opcode naming by calling it something like
> > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
> > consisting of a sha256 hash and a sighash-byte, and adding a new sighash
> > value corresponding to the set of info you want to include in the hash,
> > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL"
> >
> > FWIW, I'm not really seeing any reason to complicate the spec to ensure
> > the digest is precommitted as part of the opcode.
> >
>
> I believe in combination with `OP_LEFT` and `OP_CAT` this allows
> Turing-complete smart contracts, in much the same way as
> `OP_CHECKSIGFROMSTACK`?
>
> Pass in the spent transaction (serialised for txid) and the spending
> transaction (serialised for sighash) as part of the witness of the spending
> transaction.
>
> Script verifies that the spending transaction witness value is indeed the
> spending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT
> OP_CHECKTXDIGESTVERIFY`.
> Script verifies the spent transaction witness value is indeed the spent
> transaction by hashing it, then splitting up the hash with `OP_LEFT` into
> bytes, and comparing the bytes to the bytes in the input of the spending
> transaction witness value (txid being the bytes in reversed order).
>
> Then the Script can extract a commitment of itself by extracting the
> output of the spent transaction.
> This lets the Script check that the spending transaction also pays to the
> same script.
>
> The Script can then access a state value, for example from an `OP_RETURN`
> output of the spent transaction, and enforce that a correct next-state is
> used in the spending transaction.
> If the state is too large to fit in a standard `OP_RETURN`, then the
> current state can be passed in as a witness and validated against a hash
> commitment in an `OP_RETURN` output.
>
> I believe this is the primary reason against not pulling data from the
> stack.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190618/783d5ba9/attachment.html>;

📅 Original date posted:2019-06-02 📝 Original message:On ...

2023-06-07T20:18:26+02:00

In reply to nevent1q…ecu9
_________________________

📅 Original date posted:2019-06-02
📝 Original message:On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi All,
>
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> OP_SECURETHEBAG does more or less the same thing, but fixes malleability
> issues and lifts the single output restriction to a known number of inputs
> restriction.
>
> OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and
> locktime. OP_SECURETHEBAG commits to both of these values.
>

Can you elaborate a bit more on what the issues were?

> OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPUTSVERIFY had
> to be spent as only a single input, and instead just commits to the number
> of inputs. This allows for more flexibility, but keeps it easy to get the
> same single output restriction.
>
> BIP:
> https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki
> Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_bag
>
> A particularly useful topic of discussion is how best to eliminate the
> PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought
> about how the interpreter works and is implemented and couldn't come up
> with something noninvasive.
>

I'm not a Core developer but from what I understand, I'd be inclined to to
treat OP_SECURETHEBAG as with an immediate 32-byte parameter by modifying
GetScriptOp to return the 32-byte parameter through pvchRet.

bool GetScriptOp(CScriptBase::const_iterator& pc,
CScriptBase::const_iterator end, opcodetype& opcodeRet,
std::vector<unsigned char>* pvchRet)
{
opcodeRet = OP_INVALIDOPCODE;
if (pvchRet)
pvchRet->clear();
if (pc >= end)
return false;

// Read instruction
if (end - pc < 1)
return false;
unsigned int opcode = *pc++;

// Immediate operand
if (opcode <= OP_PUSHDATA4)
{
// ...
}

if (opcode == OP_SECURETHEBAG) {
if (end - pc < 0 || (unsigned int)(end - pc) < 32)
return false;
if (pvchRet)
pvchRet->assign(pc, pc + 32);
pc += 32;
}

opcodeRet = static_cast<opcodetype>(opcode);
return true;
}

and go from there.

Thank you for your review and discussion,
>
> Jeremy
>
> * Plus the name is better
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190602/74ada17f/attachment-0001.html>;

📅 Original date posted:2019-03-12 📝 Original message:On ...

2023-06-07T20:16:48+02:00

In reply to nevent1q…7zm5
_________________________

📅 Original date posted:2019-03-12
📝 Original message:On Tue, Mar 12, 2019 at 6:39 PM Jacob Eliosoff <jacob.eliosoff at gmail.com>
wrote:

> Also, if future disabling isn't the point of making a tx type like
> OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
> support of these oddball features, what do we gain by making them hard to
> use/mine?
>

The purpose of making OP_CODESEPARATOR non-standard was to partly mitigate
the risk of the vulnerability that OP_CODESEPARATOR induces while we
consider how to patch it.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190312/3a355816/attachment.html>;

📅 Original date posted:2019-03-11 📝 Original message:Hi ...

2023-06-07T20:16:47+02:00

In reply to nevent1q…8z3s
_________________________

📅 Original date posted:2019-03-11
📝 Original message:Hi Jacob,

> Huh?! The whole point of non-standardness in this context is to (a) make
>>> soft-forking something out safer by derisking miners not upgrading right
>>> away and (b) signal something that may be a candidate for soft-forking
>>> out so that we get feedback. Who is getting things disabled who isn't
>>> bothering to *tell* people that their use-case is being hurt?!
>>>
>>
>> People have told me that they are hurt by some other non-standardness
>> changes and I understand that they have been sitting on those funds for
>> years. Maybe they don't realize their is some place to complain or maybe
>> they think there must be a good reason why they are not allowed to do what
>> they were previously allowed to do. Perhaps others don't want to risk
>> blowing their pseudonymity. Perhaps they think that attempting to undo
>> some of these non-standardness changes is futile. I can bring up the
>> specific cases I've encountered in a new thread if you think it is
>> worthwhile.
>>
>
> Like Matt, I understand non-standardness to be specifically for making a
> transaction type more difficult to set the stage for a future disabling.
>
> If anyone is actually harmed by this change, let them at least speak up
> pseudonymously as others have before. Backwards compatibility shouldn't
> mean letting imaginary implausible cases veto net-beneficial changes.
>

It is so easy to say stuff like this when one's own money isn't what is at
risk.

While I encourage users who would be harmed to chime in if they can,
unfortunately, I think it is mostly wishful thinking on our part that they
necessarily would. In fact, there is evidence that in practice people
don't.

To illustrate this, consider the example of the people affected by PR #5247
<https://github.com/bitcoin/bitcoin/pull/5247>;, which makes unparsable
public keys non-standard. As far as I am aware none have commented on this
mailing list about it yet even though I happen to know such people do exist
because I've talked with them on Slack. I believe the person I spoke with
to took over a year (and probably more than two years) to even notice that
the transactions they want to redeem with are no longer standard. To be
fair, their money that is stuck due to PR #5247 isn't lost yet, but I'm
skeptical they would think or know to speak up here even if their money was
on the chopping block. The fact that they haven't been able to move their
money in the last *4 years* doesn't mean they wouldn't like it back one day.

While non-standardness is a helpful in dissuading users from committing new
funds to OP_CODESEPARATOR scripts, it doesn't do anything to help users
that may have been caught unaware by the non-standardness change.
Furthermore, because these transactions are non-standard, anyone caught off
guard by the change is going to have a very hard time redeeming their
funds, as we have already seen with PR #5247, a non-standardness change
that is far older than the OP_CODESERPATOR change in PR #11423
<https://github.com/bitcoin/bitcoin/pull/11423>;.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190311/4722d88f/attachment-0001.html>;

📅 Original date posted:2019-03-09 📝 Original message:Hi ...

2023-06-07T20:16:46+02:00

In reply to nevent1q…h3dr
_________________________

📅 Original date posted:2019-03-09
📝 Original message:Hi Matt,

On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> Replies inline.
>
> On 3/8/19 3:57 PM, Russell O'Connor wrote:
> > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists at mattcorallo.com
> > <mailto:lf-lists at mattcorallo.com>> wrote:
> > It's very easy to construct a practical script using OP_CODESEPARATOR.
> >
> > IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
> > CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
> >
> > Now when someone hands Alice, the CFO of XYZ corp., some transaction,
> > she has the option of either signing it unilaterally herself, or
> > creating a partial signature such that the transaction additionally
> > needs Bob, the CEOs signature as well, and Alice's choice is committed
> > to the blockchain for auditing purposes later.
> >
> > Now, there are many things you might object about this scheme, but my
> > point is that (A) regardless of what you think about this scheme, it, or
> > similar schemes, may have been devised by users, and (B) users may have
> > already committed funds to such schemes, and due to P2SH you cannot know
> > that this is not the case.
>
> The common way to set that up is to have a separate key, but, ok, fair
> enough. That said, the argument that "it may be hidden by P2SH!" isn't
> sufficient here. It has to *both* be hidden by P2SH and have never been
> spent from (either on mainnet or testnet) or be lock-timed a year in the
> future. I'm seriously skeptical that someone is using a highly esoteric
> scheme and has just been pouring money into it without ever having
> tested it or having withdrawn any money from it whatsoever. This is just
> a weird argument.
>

No one is required to test their Scripts on a public testnet; they can use
regtest. Because these transactions are non-standard on mainnet, it could
take years to arrange for these funds to be recovered by having their
transactions mined directly, or take years to become valuable enough to be
worth bothering having them directly mined. As I have noted elsewhere, you
cannot first make transactions non-standard and then use the fact that you
don't see them being used on mainnet to justify a soft-fork.

My argument isn't weird; it is principled. You are skeptical that any uses
of OP_CODESEPARATOR have P2SH commitments. I am also skeptical, and so is
everyone reading this mailing list. But none of us know this with
certainty, and it is /wrong/ for any of us to gamble with other people's
money that our assumptions are true.

Instead, it is this soft-fork proposal that is unprecedented. Let me
reiterate what I posted in another thread:

Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
invalidated transactions that send secured inputs to secured outputs
(excluding uses of OP_NOP1-OP_NOP10).

The fact that Bitcoin has stuck to this principle gives me and everyone
else confidence in the protocol; that anyone can secure their funds by
whatever scheme they dream up, and deploy it without needing permission or
anyone else to vet their Scripts. So long as they are not impairing the
Bitcoin protocol itself, the most that Bitcoin Core will do is stop
relaying their transactions by default.

Undermining this principle means undermining what provides Bitcoin's value
in the first place.

The problem in this particular case is that there exist valid secure
transactions that make use OP_CODESEPARATOR such that these transactions
themselves impair the Bitcoin protocol (through excessive validation costs)
in a way that, AFAIU, is fundamental to the nature of such transactions (in
particular, it isn't just due to an implementation detail of Bitcoin
Core). Thus to fix this vulnerability we must necessarily violate the
principle of not invalidating, secure transactions. However, this fact
isn't license to freely invalidate any transactions we want. We ought to
strive to minimize the scope of violation of this principle. Alice and Bob
from XYZ. corp should be able to keep their benign transaction illustrated
above, and we only eliminate those transactions that actually impair the
Bitcoin protocol.

This is the perfect opportunity to show the world that Bitcoin Core simply
doesn't take chances when it comes to other people money.

> Please don't strawman my position. I am not suggesting we don't fix a
> > vulnerability in Bitcoin. I am suggesting we find another way. One
> > that limits the of risk destroying other people's money.
> >
> > Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR
> > is, it cannot be worse than instead including another input that spends
> > another identically sized UTXO. So how about we soft-fork in a rule
> > that says that an input's weight is increased by an amount equal to the
> > number of OP_CODESEPARATORs executed times the sum of weight of the UTXO
> > being spent and 40 bytes, the weight of a stripped input. The risk of
> > destroying other people's money is limited and AFAIU it would completely
> > address the vulnerabilities caused by OP_CODESEPARATOR.
>
> You're already arguing that someone has such an esoteric use of script,
> suggesting they aren't *also* creating pre-signed, long-locktimed
> transactions with many inputs isn't much of a further stretch
> (especially since this may result in the fee being non-standardly low if
> you artificially increase its weight).
>

There is no consensus rule about minimum fees, and CPFP could add the more
fees. But yes, I am saying that Alice and Bob could be building on their
transaction illustrated above, but not creating a many input tx that
wouldn't fit into a block with my proposed added weight, because if their
transaction won't fit into a block with the added weight then it was a
malicious transaction to begin with.

Do you not recognize the material difference between a soft-fork that
doubles the cost of a transaction like Alice and Bob's versus making their
transaction entirely illegal?

> Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
> of complexity and reduces the simple analysis that fees (almost) have
> today vs just removing it allows us to also remove a ton of code.

Further note that if you don't remove it getting the efficiency wins
> right is even harder because instead of being able to cache sighashes
> you now have to (at a minimum) wipe the cache between each
> OP_CODESEPARATOR call, which results in a ton of additional
> implementation complexity.
>

How can this be "additional" complexity when this is how the protocol works
today? All you have to do is not change the semantics of
OP_CODESEPARATOR. It is literally no work.
Regarding the efficiency wins, let me repeat myself: The performance costs
of wiping the cached sighashs is not worse than what the performance costs
would be if the transaction had an additional input spending an equally
sized UTXO.

> > > I suggest an alternative whereby the execution of OP_CODESEPARATOR
> > > increases the transactions weight suitably as to temper the
> > > vulnerability caused by it. Alternatively there could be some
> > sort of
> > > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
> > allowed to be
> > > executed per script, but that would require an argument as to why
> > > exceeding that limit isn't reasonable.
> >
> > You could equally argue, however, that any such limit could render
> some
> > moderately-large transaction unspendable, so I'm somewhat skeptical
> of
> > this argument. Note that OP_CODESEPARATOR is non-standard, so getting
> > them mined is rather difficult in any case.
> >
> >
> > I already know of people who's funds are tied up due to in other changes
> > to Bitcoin Core's default relay policy. Non-standardness is not an
> > excuse to take other people's tied up funds and destroy them permanently.
>
> Huh?! The whole point of non-standardness in this context is to (a) make
> soft-forking something out safer by derisking miners not upgrading right
> away and (b) signal something that may be a candidate for soft-forking
> out so that we get feedback. Who is getting things disabled who isn't
> bothering to *tell* people that their use-case is being hurt?!
>

People have told me that they are hurt by some other non-standardness
changes and I understand that they have been sitting on those funds for
years. Maybe they don't realize their is some place to complain or maybe
they think there must be a good reason why they are not allowed to do what
they were previously allowed to do. Perhaps others don't want to risk
blowing their pseudonymity. Perhaps they think that attempting to undo
some of these non-standardness changes is futile. I can bring up the
specific cases I've encountered in a new thread if you think it is
worthwhile.

Regarding OP_CODESEAPRATOR specifically, disabling the rely of such
transactions partially mitigates the vulnerability. Once the vulnerability
is properly patched, for example by suitably increasing the weight of the
operation or opcode, we could drop the prohibition on relaying such
transactions. Non-standardness is not necessarily a path to a new
consensus rule. We have several non-standardness rules in place that are
never intended to become new consensus rules. Sometimes non-standardness
is a temporary mitigation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190309/9a5108cc/attachment.html>;

📅 Original date posted:2019-03-08 📝 Original message:On ...

2023-06-07T20:16:45+02:00

In reply to nevent1q…r4nh
_________________________

📅 Original date posted:2019-03-08
📝 Original message:On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> Replies inline.
>
> Matt
>
> On 3/7/19 3:03 PM, Russell O'Connor wrote:
> >
> > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script
> validation.
> > This includes OP_CODESEPARATORs in unexecuted branches of if
> > statements,
> > similar to other disabled opcodes, but unlike OP_RETURN.
> >
> >
> > OP_CODESEPARATOR is the only mechanism available that allows users to
> > sign which particular branch they are authorizing for within scripts
> > that have multiple possible conditions that reuse the same public key.
>
> This is true, and yet it does not appear to actually be practically
> usable. Thus far, despite a ton of effort, I have not yet seen a
> practical use-case for OP_CODESEPARATOR (except for one example of it
> being used to make SegWit scripts ever-so-slightly more effecient in
> TumbleBit, hence why this BIP does not propose disabling it for SegWit).
>

It's very easy to construct a practical script using OP_CODESEPARATOR.

IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR
<ALICEPUBKEY> CHECKSIGVERFY ENDIF

Now when someone hands Alice, the CFO of XYZ corp., some transaction, she
has the option of either signing it unilaterally herself, or creating a
partial signature such that the transaction additionally needs Bob, the
CEOs signature as well, and Alice's choice is committed to the blockchain
for auditing purposes later.

Now, there are many things you might object about this scheme, but my point
is that (A) regardless of what you think about this scheme, it, or similar
schemes, may have been devised by users, and (B) users may have already
committed funds to such schemes, and due to P2SH you cannot know that this
is not the case.

> > Because of P2SH you cannot know that no one is currently using this
> > feature. Activating a soft-fork as describe above means these sorts of
> > funds would be permanently lost. It is not acceptable to risk people's
> > money like this.
>
> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in
> Bitcoin today, and (3) lots of effort has gone into attempting to find
> practical use-cases for OP_CODESEPARATOR's specific construction, with
> no successes as of yet. I strongly, strongly disagree that the
> highly-unlikely remote possibility that someone created something before
> which could be rendered unspendable is sufficient reason to not fix a
> vulnerability in Bitcoin today.
>

Please don't strawman my position. I am not suggesting we don't fix a
vulnerability in Bitcoin. I am suggesting we find another way. One that
limits the of risk destroying other people's money.

Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR is,
it cannot be worse than instead including another input that spends another
identically sized UTXO. So how about we soft-fork in a rule that says that
an input's weight is increased by an amount equal to the number of
OP_CODESEPARATORs executed times the sum of weight of the UTXO being spent
and 40 bytes, the weight of a stripped input. The risk of destroying other
people's money is limited and AFAIU it would completely address the
vulnerabilities caused by OP_CODESEPARATOR.

Even soft forking a rule like, "it is illegal to execute an
OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation", would be
vastly better than the current proposal, even though I would still object
to it.

> > I suggest an alternative whereby the execution of OP_CODESEPARATOR
> > increases the transactions weight suitably as to temper the
> > vulnerability caused by it. Alternatively there could be some sort of
> > limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be
> > executed per script, but that would require an argument as to why
> > exceeding that limit isn't reasonable.
>
> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of
> this argument. Note that OP_CODESEPARATOR is non-standard, so getting
> them mined is rather difficult in any case.
>

I already know of people who's funds are tied up due to in other changes to
Bitcoin Core's default relay policy. Non-standardness is not an excuse to
take other people's tied up funds and destroy them permanently.

There is some sort of crisis in the Bitcoin protocol stemming from the
possible excessive usage of OP_CODESEPARTOR otherwise we wouldn't even be
considering this soft fork. Fine. But presumably it is impossible for a
transaction to both be produced in good faith for legitimate use and at the
same time are expensive enough to be used as an attack vector, and
hopefully there is a wide gap between these two cases. So let's draw a
line between the two cases to rule out attacks while allowing legitimate
uses by simply suitably pricing the OP_CODESEPARATOR opcode by weight. At
worst case this moderately-large transaction is very expensive, reflecting
its true cost, or is was so expensive that it couldn't possibly have been
legitimate to begin with since the resources to validate it exceed the
amount that are reasonable to validate an entire block of regular
transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190308/b6349b97/attachment-0001.html>;

📅 Original date posted:2019-03-07 📝 Original message:> * ...

2023-06-07T20:16:44+02:00

In reply to nevent1q…65jt
_________________________

📅 Original date posted:2019-03-07
📝 Original message:> * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
> This includes OP_CODESEPARATORs in unexecuted branches of if statements,
> similar to other disabled opcodes, but unlike OP_RETURN.
>

OP_CODESEPARATOR is the only mechanism available that allows users to sign
which particular branch they are authorizing for within scripts that have
multiple possible conditions that reuse the same public key. Because of
P2SH you cannot know that no one is currently using this feature.
Activating a soft-fork as describe above means these sorts of funds would
be permanently lost. It is not acceptable to risk people's money like this.

I suggest an alternative whereby the execution of OP_CODESEPARATOR
increases the transactions weight suitably as to temper the vulnerability
caused by it. Alternatively there could be some sort of limit (maybe 1) on
the maximum number of OP_CODESEPARATORs allowed to be executed per script,
but that would require an argument as to why exceeding that limit isn't
reasonable.

--
Russell O'Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190307/0f0ed246/attachment.html>;

📅 Original date posted:2018-12-11 📝 Original message:I ...

2023-06-07T20:15:35+02:00

In reply to nevent1q…y4vx
_________________________

📅 Original date posted:2018-12-11
📝 Original message:I don't believe that the default RBF policy works that way. My
understanding is that current policy requires an absolute fee increase (by
an amount related to incrementalrelayfee). There have been proposals to
change default RBF policy, however even my proposal <
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html>;
still requires a minimal amount of absolute fee increase as a DoS defense.

(I'm reading your comment as attempting to rebroadcast the original
transaction with the same fee amount, with its relatively higher fee-rate).

On Mon, Dec 10, 2018 at 10:00 AM David A. Harding <dave at dtrt.org> wrote:

> On Thu, Dec 06, 2018 at 11:57:09AM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > One more item to consider is "signature covers witness weight".
> >
> > While signing the witness weight doesn't completely eliminate witness
> > malleability (of the kind that can cause grief for compact blocks), it
> does
> > eliminate the worst kind of witness malleability from the user's
> > perspective, the kind where malicious relay nodes increase the amount of
> > witness data and therefore reduce the overall fee-rate of the
> transaction.
>
> To what degree is this an actual problem? If the mutated transaction
> pays a feerate at least incremental-relay-fee[1] below the original
> transaction, then the original transaction can be rebroadcast as an RBF
> replacement of the mutated transaction (unless the mutated version has
> been pinned[2]).
>
> -Dave
>
> [1] $ bitcoind -help-debug | grep -A2 incremental
> -incrementalrelayfee=<amt>
> Fee rate (in BTC/kB) used to define cost of relay, used for mempool
> limiting and BIP 125 replacement. (default: 0.00001)
>
> [2]
> https://bitcoin.stackexchange.com/questions/80803/what-is-meant-by-transaction-pinning
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181211/ba277d2d/attachment.html>;

📅 Original date posted:2018-12-13 📝 Original message:On ...

2023-06-07T20:15:34+02:00

In reply to nevent1q…jgqt
_________________________

📅 Original date posted:2018-12-13
📝 Original message:On Wed, Dec 12, 2018 at 2:53 PM Johnson Lau <jl2012 at xbt.hk> wrote:

>
> I think the root cause of witness weight malleability is some opcodes
> accept variable size input (without affecting the output), and that input
> is provided by the puzzle solver. Going through the opcode list, I think
> such opcodes include IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, and all
> arithmetic opcode that accepts CScriptNum (including CHECKMULTISIG)
>
> VERIFY, DROP, 2DROP, NIP are not real problem, since they should not be
> the first opcode to interact with data directly provided by the puzzle
> solver.
>
> CHECKMULTISIG is fixed by BIP147. For the key number and sig number, they
> should be part of the script, so not malleable.
>
> DEPTH is a problem only if its inputs are not later examined by other
> opcodes. Again, this is pointless.
>
> The liberally example should be protected by the MINIMAL_IF policy, which
> requires the input of OP_IF be minimal. As you note, OP_IF could be
> replaced by taproot in many cases
>
> Non-minimal CScriptNum is also banned as BIP62 policy.
>
> For the purpose of preventing malicious third party witness bloating, all
> we need is the miners to enforce the policy. There is no reason for miners
> to accept size malleated txs, as that will reduce the usable block space.
> If they hate a tx, they would simply drop it, instead of wasting the block
> space.
>

I don't know if it such a clear cut case for miner's policy. A miner is
passed a malleated tx. They know that there is probably a non-malleated
variant floating around out there somewhere, and they would rather have
it. But right now they don't, and they probably not going to try to
unmalleate it themselves. So, why not stick it into their mempool? If it
eventually makes it into one of their blocks, then it will because it has
the best fee rate available, and to reject it outright is harmful to their
bottom line. If they find the non-malleated variant later, great, they can
replace it and gain a higher-fee rate tx. Of course, such a policy opens
them up to a Denial of Service attack.

So what do they do? Do they accept malleated tx's and implement an RBF
policy that requires sufficient fee rate increases? Do they reject
malleated txs outright to avoid falling in this trap in the first place as
you suggest? I don't know, but I don't think things are as clear cut as
you present.

That aside, your list of weight malleable opcodes is shorter than I
imagined and I'm grateful you've compiled it. Perhaps the best solution is
to make MINIMAL_IF and minimal CScriptNum consensus enforced in the next
version of Script and all but eliminate weight malleability in practice?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181213/b5787537/attachment.html>;

📅 Original date posted:2018-12-11 📝 Original message:On ...

2023-06-07T20:15:33+02:00

In reply to nevent1q…xa83
_________________________

📅 Original date posted:2018-12-11
📝 Original message:On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012 at xbt.hk> wrote:

> The current proposal is that a 64-byte signature will be used for the
> default “signing all” sighash, and 65-byte for other sighash types. The
> space saved will allow a few more txs in a block, so I think it worths
> doing. However, this also makes witness weight estimation more difficult in
> multisig cases.
>
> This idea of signing witness weight has been brought up before. I think
> the concern is the difficulty to estimate the witness weight for complex
> scripts, which need this feature most. So it will work when it is not
> needed, and will not work when it is needed.
>
> Is there any script example that witness size malleability is unavoidable?
>

I tend to think in opposite terms. Is there a proof that any script can be
transformed into an equivalent one that avoids witness weight
malleability? But I admit there is a trade off: If we don't allow for
signature covers weight, and we do need it, it will be too late to add. On
the other hand if we add signature covers weight, but it turns out that no
Script ever needs to use it, then we've added that software complexity for
no gain. However, I think the software complexity is relatively low,
making it worthwhile.

Moreover, even if witness weight malleability is entirely avoidable, it
always seems to come at a cost. Taking as an example libwally's proposed "
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>csv_2of3_then_2";
Script
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>;,
it begins with "OP_DEPTH OP_1SUB OP_1SUB" spending 3 vbytes to avoid any
possible witness malleability versus just taking a witness stack item to
determine the branch, costing 1 or 2 (unmalleated) vbytes. Now to be fair,
under Taproot this particular script's witness malleability problem
probably goes away. Nonetheless, I think it is fair to say that Bitcoin
Script was designed without any regard given to scriptSig/witness
malleability concerns and the result is that one is constantly fighting
against malleability issues. Short of a wholesale replacement of Bitcoin
Script, I do think that having an option for signature covers weight is one
of the best ways to address the whole problem.

Regarding your point about 64/65-byte signatures; I speculate that in most
protocols, all parties that are able to consider signing the weight, know
what sighash flags the other parties are expected to be using. However,
your point is well-taken, and if we choose to adopt the option of
signatures covering weight, we ought to make sure there exists a 65-byte
signature that performs the equivalent of a sigHashAll (of course, still
covering that particular sighash flag under the signature), to ensure that
anti-weight-malleability can be use even when the sighash flags that other
parties will use are unknown. Even with the extra vbytes in the
signatures, there may be a net weight savings by avoiding the need for
anti-malleability Script code. (It might also be reasonable to have
participants create signatures for a small range of different weight
values? (Sorry in advance to PSBT)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181211/1f119c76/attachment.html>;

📅 Original date posted:2018-12-06 📝 Original message:One ...

2023-06-07T20:15:32+02:00

In reply to nevent1q…rnld
_________________________

📅 Original date posted:2018-12-06
📝 Original message:One more item to consider is "signature covers witness weight".

While signing the witness weight doesn't completely eliminate witness
malleability (of the kind that can cause grief for compact blocks), it does
eliminate the worst kind of witness malleability from the user's
perspective, the kind where malicious relay nodes increase the amount of
witness data and therefore reduce the overall fee-rate of the transaction.
Generally users should strive to construct their Bitcoin Scripts in such a
way that witness malleability isn't possible, but as you are probably
aware, this can be quite difficult to achieve as Scripts become more
complex and maybe isn't even possible for some complex Scripts.

Given the new fixed-sized signature of the Schnorr BIP, it becomes much
easier to compute the final witness weight prior to signing. In complex
multi-party signing protocol, the final witness weight might not be known
at signing time for everyone involved, so the "signature covers witness
weight" ought to be optional.

On Tue, Nov 27, 2018 at 11:59 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Mon, 19 Nov 2018 at 14:37, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
> > Here is a combined proposal:
> > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, and
> SIGHASH_SCRIPTMASK.
> > * A new opcode OP_MASK is added, which acts as a NOP during execution.
> > * The sighash is computed like in BIP143, but:
> > * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> the subsequent opcode/push is removed.
> > * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
> > * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is
> set.
> > * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> Thanks for all the input so far. Going over the suggestions and other
> ideas:
>
> * OP_MASK should be required to be followed by a push, as suggested by
> Anthony Towns. The alternative would permit substituting arbitrary
> opcodes for masked pushes, which is at least very hard to reason
> about. This would effectively turn it into a multi-byte OP_MASKEDPUSH
> opcode.
>
> * It's probably better to sign the amounts of all inputs, as suggested
> by Johnson Lau. As that would cause default sighashes to sign all
> input and output amounts, is there still a need to sign the tx fee
> explicitly? Or in other words, are there situations where changing the
> set of inputs or outputs after signing is desired, but the net
> difference between them cannot change? If not, that would remove the
> need for NOFEE.
>
> * Do we need to keep the rule that sequence values of other inputs are
> only signed with default sighash? It feels cleaner to always sign the
> sequence values of all inputs that are included in the sighash anyway
> (so all of them, unless ANYONECANPAY or NOINPUT, which would make it
> sign only the current input's sequence value). If NOINPUT also blanks
> the sequence values (as currently specified by BIP118), and all input
> amounts are signed, that would make amounts/sequence values always be
> treated identically.
>
> * If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of
> them can be encoded in just 2 bits using the
> PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns
> suggested.
>
> * Regarding the discussion about preventing signatures from being
> rebound to a different script(path)/checksig:
> * With MAST there is indeed less need for this, but at least
> single-tree MAST constructions cannot replace all script branches (a
> script with 40 IF/THEN/ELSE constructions may have 2^40 different
> execution paths, for which computing a Merkle tree is intractable).
> * Just signing the opcode position of the CHECKSIG operator isn't
> enough for all cases either. For example, you could have a complex
> nested set of branches that puts a number of pubkeys on the stack, and
> then a CHECKMULTISIG after the last ENDIF to verify all of them. In
> such a situation, if the same key can occur in multiple combinations,
> you still may want to prevent a signature generated for one
> combination from being rebindable to the same key in another
> combination. I believe that signing the opcode position plus the
> true/false condition of all previous(?) IF statements is probably
> sufficient to achieve that, but it would also introduce unnecessary
> complexity for signers in most cases (see next point).
> * Thinking about signing code, adding these sort of execution trace
> commitments to the sighash means they need to know which checksig
> operator etc. they are signing for. I believe that in practice for
> example HW devices will just whatever position the wallet indicated,
> rather than verifying it corresponds with a particular intended code
> path. Preventing rebinding isn't very useful if an attacker can make
> you bind to the wrong thing regardless, so I'm not convinced this is
> even worth having by default.
> * An alternative (not sure who suggested it) is to simply make every
> CHECKSIG sign the opcode position of the last executed CODESEPARATOR
> (and remove the earlier cut-of-scriptCode effect of CODESEPARATOR).
> This gives a simple (but somewhat limited) way for scripts that need
> to prevent certain kinds of cross-execution-trace rebinding.
>
> A few misc ideas:
> * (Taken from
> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki)
> For a default sign-everything sighash, the sighash byte can be
> dropped.
> * For the commitments to the scriptPubKey and scriptCode, an
> intermediary hash should be used (so the data included in the sighash
> includes a hash of those, rather than the script directly). This
> prevents a blow up in hashing time for large scripts with many
> different sighash types in its signatures.
> * When masking the scriptCode, the push opcode immediately following
> OP_MASKEDPUSH can be replaced by OP_VERIF (which will never collide
> with any real script, as OP_VERIF makes a script invalid even when
> occurring in an unexecuted branch).
> * Sighashes (and really all new hashes that are introduced) should be
> prefixed with a fixed 64-byte array as "tag", chosen to not collide
> with any existing use of SHA256 in Bitcoin, to prevent signatures from
> being re-interpretable as something else. Picking 64 bytes as tag size
> means it can be efficiently implemented as just a modified SHA256 IV.
>
> So a combined proposal:
> * All existing sighash flags, plus NOINPUT and MASK
> (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).
> * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is
> failing if not immediately followed by a push, or when appearing as
> last opcode in the script.
> * Signatures are 64 plus an optional sighash byte. A missing sighash
> byte implies ALL, and ALL cannot be specified explicitly.
> * The sighash is computed from the following:
> * A 64-byte constant tag
> * Data about the spending transaction:
> * The transaction version number
> * The hash of txins' prevouts+amounts+sequences (or nothing if
> ANYONECANPAY)
> * The hash of all txouts (or just the corresponding txout if
> SINGLE; nothing if NONE)
> * The transaction locktime
> * Data about the output being spent:
> * The prevout (or nothing if NOINPUT)
> * The amount
> * The sequence number
> * The hash of the scriptPubKey (or nothing if MASK)
> * Data about the script being executed:
> * The hash of the scriptCode (after masking out, if MASK is set)
> * The opcode number of the last executed OP_CODESEPARATOR (or
> 0xFFFFFFFF if none)
> * The sighash mode
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181206/49fae6ab/attachment.html>;

📅 Original date posted:2018-11-22 📝 Original message:On ...

2023-06-07T20:15:19+02:00

In reply to nevent1q…y2wc
_________________________

📅 Original date posted:2018-11-22
📝 Original message:On Thu, Nov 22, 2018 at 3:53 PM Johnson Lau <jl2012 at xbt.hk> wrote:

> Assuming a script size of 128 bytes (including SHA256 padding), 2^20
> scripts is 134MB. Double it to 268MB for the merkle branch hashes. With
> roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However,
> memory use is not considered.
>
> >each call to this operation effectively takes O(script-size) time
> I’m not sure if this is correct. Actually,
> CTransactionSignatureSerializer() scans every script for OP_CODESEPARATOR.
> Scripts with and without OP_CODESEPARATOR should take exactly the same
> O(script-size) time (see https://github.com/bitcoin/bitcoin/pull/14786)
> Also, this is no longer a concern under segwit (BIP143), which
> CTransactionSignatureSerializer() is not used. Actually, OP_CODESEPARATOR
> under segwit is way simpler than the proposed OP_MASK. If one finds OP_MASK
> acceptable, there should be no reason to reject OP_CODESEPARATOR.
>

Even still, each call to OP_CODESEPARATOR / OP_CHECKSIG pair requires
recomputing a new #5. scriptCode from BIP 143, and hence computes a new
transaction digest. I understood that this issue was the main motivation
for wanting to deprecate OP_CODESEPARATOR and remove it from later versions
of script.

However, given that we are looking at a combinatorial explosion in SIGHASH
flag combinations already, coupled with existing SigOp limitations, maybe
the cost of recomputing scriptCode with OP_CODESEPARATOR isn't such a big
deal.

And even if we choose remove the behavior of OP_CODESEPARATOR in new
versions of Script, it seems more than 30 layers of sequential OP_IFs can
be MASTified, so there is no need to use OP_CODESEPARATOR within that limit.

>One suggestion I heard (I think I heard it from Pieter) to achieve the
above is to add an internal counter that increments on every control flow
operator,……...

> If I have to choose among OP_CODESEPARATOR and “flow operator counting”,
> I’d rather choose OP_CODESEPARATOR. At least we don’t need to add more
> lines to the consensus code, just for something that is mostly archivable
> with MAST.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181122/e7761aed/attachment.html>;

📅 Original date posted:2018-11-22 📝 Original message:I see, ...

2023-06-07T20:15:18+02:00

In reply to nevent1q…chvu
_________________________

📅 Original date posted:2018-11-22
📝 Original message:I see, so your suggestion is that a sequence of OP_IF ... OP_ENDIF can be
replaced by a Merklized Script tree of that depth in practice.

I'm concerned that at script creation time it takes exponential time to
complete a Merkle root of depth 'n'. Can anyone provide benchmarks or
estimates of how long it takes to compute a Merkle root of a full tree of
various depths on typical consumer hardware? I would guess things stop
becoming practical at a depth of 20-30.

On Thu, Nov 22, 2018 at 9:28 AM Johnson Lau <jl2012 at xbt.hk> wrote:

> With MAST in taproot, OP_IF etc become mostly redundant, with worse
> privacy. To maximise fungibility, we should encourage people to use MAST,
> instead of improve the functionality of OP_IF and further complicate the
> protocol.
>
>
> On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> So my question is whether anyone can see ways in which this introduces
>> redundant flexibility, or misses obvious use cases?
>>
>
> Hopefully my comment is on-topic for this thread:
>
> Given that we want to move away from OP_CODESEPARATOR, because each call
> to this operation effectively takes O(script-size) time, we need a
> replacement for the functionality it currently provides. While perhaps the
> original motivation for OP_CODESEPARTOR is surrounded in mystery, it
> currently can be used (or perhaps abused) for the task of creating
> signature that covers, not only which input is being signed, but which
> specific branch within that input Script code is being signed for.
>
> For example, one can place an OP_CODESEPARATOR within each branch of an IF
> block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG
> operation. By doing so, signatures created for one clause cannot be used
> as signatures for another clause. Since different clauses in Bitcoin
> Script may be enforcing different conditions (such as different time-locks,
> hash-locks, etc), it is useful to be able to sign in such a way that your
> signature is only valid when the conditions for a particular branch are
> satisfied. In complex Scripts, it may not be practical or possible to use
> different public keys for every different clause. (In practice, you will be
> able to get away with fewer OP_CODESEPARATORS than one in every IF block).
>
> One suggestion I heard (I think I heard it from Pieter) to achieve the
> above is to add an internal counter that increments on every control flow
> operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the signature cover
> the value of this counter. Equivalently we divide every Bitcoin Script
> program into blocks deliminated by these control flow operator and have the
> signature cover the index of the block that the OP_CHECKSIG occurs within.
> More specifically, we will want a SigHash flag to enables/disable the
> signature covering this counter.
>
> There are many different ways one might go about replacing the remaining
> useful behaviour of OP_CODESEPARATOR than the one I gave above. I would be
> happy with any solution.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181122/e50caccd/attachment-0001.html>;

📅 Original date posted:2018-11-21 📝 Original message:On ...

2023-06-07T20:15:18+02:00

In reply to nevent1q…cne5
_________________________

📅 Original date posted:2018-11-21
📝 Original message:On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>

Hopefully my comment is on-topic for this thread:

Given that we want to move away from OP_CODESEPARATOR, because each call to
this operation effectively takes O(script-size) time, we need a replacement
for the functionality it currently provides. While perhaps the original
motivation for OP_CODESEPARTOR is surrounded in mystery, it currently can
be used (or perhaps abused) for the task of creating signature that covers,
not only which input is being signed, but which specific branch within that
input Script code is being signed for.

For example, one can place an OP_CODESEPARATOR within each branch of an IF
block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG
operation. By doing so, signatures created for one clause cannot be used
as signatures for another clause. Since different clauses in Bitcoin
Script may be enforcing different conditions (such as different time-locks,
hash-locks, etc), it is useful to be able to sign in such a way that your
signature is only valid when the conditions for a particular branch are
satisfied. In complex Scripts, it may not be practical or possible to use
different public keys for every different clause. (In practice, you will be
able to get away with fewer OP_CODESEPARATORS than one in every IF block).

One suggestion I heard (I think I heard it from Pieter) to achieve the
above is to add an internal counter that increments on every control flow
operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the signature cover
the value of this counter. Equivalently we divide every Bitcoin Script
program into blocks deliminated by these control flow operator and have the
signature cover the index of the block that the OP_CHECKSIG occurs within.
More specifically, we will want a SigHash flag to enables/disable the
signature covering this counter.

There are many different ways one might go about replacing the remaining
useful behaviour of OP_CODESEPARATOR than the one I gave above. I would be
happy with any solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181121/785d31a4/attachment-0001.html>;

📅 Original date posted:2018-08-05 📝 Original message:Over ...

2023-06-07T20:13:56+02:00

In reply to nevent1q…8z3k
_________________________

📅 Original date posted:2018-08-05
📝 Original message:Over chat it has been pointed out to me that computing the non-quadratic
residue is not the same cost as computing a quadratic residue. As pointed
out in footnote 7 of the the proposed BIP, c^((p+1)/4) is always a
quadratic residue and must be negated to find the non-quadratic residue.

In light of this, I revise my proposed change to make the verification
equation

R + sG + eP = 0.

(by 0 in the equation above I mean the identity element for the (+)
operation, which is the point at infinity.)

This equation is suitable for batch verification. This equation is clearly
written as a linear combination that doesn't use negation. In most
implementations, equality comparison tests are implemented by subtraction
and a comparison with zero. By writing the verification equation this way,
we clearly see that only the comparison with zero test is needed.

For single signature verification the check becomes, compute Q := sG + eP.
Verify that Q isn't the point at infinity and Q.x = r. Verify that Q.y is
*not* a quadratic residue. (While I was incorrect earlier about the costs
of computing a non-residue, it is the case the *verifying* a value is a
quadratic residue is the same cost as verifying a value is a non-residue.)

Effectively in my first email I was suggesting that the 'e' value in a
signature be negated from the current BIP proposal. In this revision I am
effectively suggesting that the 's' value in a signature should be the one
that is negated instead.

On Sat, Aug 4, 2018 at 8:22 AM, Russell O'Connor <roconnor at blockstream.io>
wrote:

> I propose changing the verification equation from "Let *R = sG - eP*" to
>
> Let *R = sG + eP*
>
> This allows faster verification by avoiding negating a point (or a
> coefficient).
>
>
> If, instead of directly following the literal verification specification,
> one is instead reconstructing R from r by finding a y coordinate that is a
> quadratic residue, under the existing scheme one would verify
>
>
> *sG - eP = R*
>
> which is effectively verifying
>
> 0 = *sG - eP* - R or 0 = R - *sG + eP*
>
> Either way one needs to negate at least one point (or one coefficient)
> because of the opposite signs between sG and eP.
>
>
> Under my proposed revised verification scheme, one would instead verify
>
> 0 = sG + eP + (-R).
>
> While it seems that this requires negating R, it does not. Rather (-R)
> can be directly constructed from r by finding a y coordinate that is *not*
> a quadratic residue, which is precisely the same amount of work that
> construction R from r was.
>
> In either verification procedure, changing the verification equation to my
> proposal removes one negation operation from the cost of doing verification.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180805/08b47da6/attachment.html>;

📅 Original date posted:2018-08-04 📝 Original message:I ...

2023-06-07T20:13:55+02:00

In reply to nevent1q…hn2d
_________________________

📅 Original date posted:2018-08-04
📝 Original message:I propose changing the verification equation from "Let *R = sG - eP*" to

Let *R = sG + eP*

This allows faster verification by avoiding negating a point (or a
coefficient).

If, instead of directly following the literal verification specification,
one is instead reconstructing R from r by finding a y coordinate that is a
quadratic residue, under the existing scheme one would verify

*sG - eP = R*

which is effectively verifying

0 = *sG - eP* - R or 0 = R - *sG + eP*

Either way one needs to negate at least one point (or one coefficient)
because of the opposite signs between sG and eP.

Under my proposed revised verification scheme, one would instead verify

0 = sG + eP + (-R).

While it seems that this requires negating R, it does not. Rather (-R) can
be directly constructed from r by finding a y coordinate that is *not* a
quadratic residue, which is precisely the same amount of work that
construction R from r was.

In either verification procedure, changing the verification equation to my
proposal removes one negation operation from the cost of doing verification.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180804/2fc635e5/attachment.html>;

📅 Original date posted:2018-07-06 📝 Original message:Some ...

2023-06-07T20:13:37+02:00

In reply to nevent1q…8yhg
_________________________

📅 Original date posted:2018-07-06
📝 Original message:Some quick comments:

Signing
>
> To sign:
>
> - Let *k = int(hash(bytes(d) || m)) mod n*[8
> <https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki#cite_note-8>;
> ].
> - Let *R = kG*.
> - If *jacobi(y(R)) ≠ 1*, let *k = n - k*.
> - Let *e = int(hash(bytes(x(R)) || bytes(dG) || m)) mod n*.
> - The signature is *bytes(x(R)) || bytes(k + ex mod n)*.
>
> Can we avoid mutable variables in these specification? I know this is
commonly done in RFCs, but I think it is fairly confusing to have `k`
defined in two different ways within a single specification.
Let's let k' = k when jacobi(y(R)) = 1 and let k' = n - k when jacobi(y(R))
= -1. Note that this ensures that jacobi(y(k'G)) = 1.

Also you've sort of left it undefined what to do when k = 0. According to
the current specification, you will produce an invalid signature. The
expected result is that you should win a 1000 BTC prize.

One solution is to let k = *1 + int(hash(bytes(d) || m)) mod (n-1)*.
Alternatively you could let k' = 1 when k = 0. Or you could just make a
note that signature generation fails with this message and private key pair
when this happens.

Let *e = int(hash(bytes(x(R)) || bytes(dG) || m)) mod n*.
>

P = dG should probably be noted somewhere in the text. I.e. this signature
is generated for the public key P = dG.

If the inputs to hash were reordered as *hash(bytes(dG) || bytes(x(R)) ||
m)* then there is an opportunity for SHA256 expander to be partially
prefilled for a fixed public key. This could provide a little benefit,
especially when multiple signatures for a single public key need to be
generated and/or verified. If all things are otherwise equal, perhaps this
alternate order is better.

The signature is *bytes(x(R)) || bytes(k + ex mod n)*.

You haven't defined `x`. I'm guessing you mean `d` instead.

> Optimizations
>
> *Jacobian coordinates*
>
> - *oncurve(P)* can be implemented as *y2 = x3 + 7z6 mod p*.
>
> oncurve(P) requires that `P` be on the curve and not infinity. You need
another condition here to ensure that `P` is not infinity.

On Fri, Jul 6, 2018 at 2:08 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello everyone,
>
> Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> over the same curve as is currently used in ECDSA:
> https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
>
> It is simply a draft specification of the signature scheme itself. It
> does not concern consensus rules, aggregation, or any other
> integration into Bitcoin - those things are left for other proposals,
> which can refer to this scheme if desirable. Standardizing the
> signature scheme is a first step towards that, and as it may be useful
> in other contexts to have a common Schnorr scheme available, it is its
> own informational BIP.
>
> If accepted, we'll work on more production-ready reference
> implementations and tests.
>
> This is joint work with several people listed in the document.
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180706/46edd80f/attachment.html>;

📅 Original date posted:2018-01-22 📝 Original message:On ...

2023-06-07T20:09:34+02:00

In reply to nevent1q…w76y
_________________________

📅 Original date posted:2018-01-22
📝 Original message:On Thu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thu, Jan 18, 2018 at 4:59 PM, Ondřej Vejpustek
> <ondrej.vejpustek at satoshilabs.com> wrote:
> >> If being secure against partial share leakage is really part of your
> >> threat model the current proposal is gratuitously insecure against it.
> >
> > I don't think that is true. Shared secret is an input of KDF which
> > should prevent this kind of attack.
>
> My post provided a concrete example. I'd be happy to answer any
> questions about it, but otherwise I'm not sure how to make it more
> clear.
>
> > Actually, we've been considering something like that. We concluded that
> it is to much "rolling your own crypto". Instead of diffusion layer we
> decided to apply KDF on the shared secret.
>
>
> Quite the opposite-- a large block cipher is a standard
> construction... and the off-label application of a KDF that you've
> used here doesn't provide any protection against the example I gave.
>

At this point, is it better just to use GF(2^256+n)? Is GF(2^256+n) going
to be that much slower than GF(2^8) that we care to make things this
complicated? (I honestly don't know the answer.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/c8799a13/attachment.html>;

📅 Original date posted:2018-01-17 📝 Original message:Hi ...

2023-06-07T20:09:32+02:00

In reply to nevent1q…w5cj
_________________________

📅 Original date posted:2018-01-17
📝 Original message:Hi Ondřej,

1. There is no similarity between SSS and RSA or any other public-key or
symmetric crypto. SSS is effectively a one-time pad and is
information-theoretically secure.

2. Even if there were a problem (which there cannot be, due to (1)), using
error correcting codes and truncated hash functions create identical
amounts of information theoretic redundancy.

Let me repeat that SSS is "information-theoretically secure"! It isn't
only computationally infeasible to break SSS; it is impossible to break
SSS. If you have all but one necessary share of SSS, there is no
information leaked about the the hidden data, because for every possible
message that could be encoded, there exists some final share that would
decode to that message. Any of the possibilities for the missing final
share are equally as likely.

It is of no use to apply the precautionary principle against impossible
attacks, especially at the cost of losing the useful properties of a real
error correcting codes that would provide actual guarantees against likely
errors.

On Wed, Jan 17, 2018 at 6:39 AM, Ondřej Vejpustek via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The entropy argument is as follows:
>
> There is a rule of thumb which says it is safer plaintext to have low
> redundancy, see
> https://en.wikipedia.org/wiki/Redundancy_(information_theory), i. e.
> it's better to encrypt random or compressed data than natural language.
> This rule is based on Shannon's information theory which means that a
> breach of the rule usually doesn't induce a vulnerability (there is no
> known generic attack). This rule is application of a precautionary
> principle.
>
> Nevertheless, here are some examples of cryptographic attacks which may
> be considered as a consequence of the breach of the rule:
> * Related Message Attack by Coppersmith, Franklin, Patarin, Reiter
> (https://pdfs.semanticscholar.org/899a/4fdc048102471875e24f7fecb3fb89
> 98d754.pdf)
> - given RSA ciphertext of two plaintexts x and a*x + b, where a, b are
> known, it's possible to effectively compute x provided public exponent
> is three. From the informaton-theoretic point of view the second message
> is redundant, because it's determined by the first one. Which means that
> relative redundancy of both messages is at least one half.
> * Stereotyped Messages by Coppersmith
> (https://www.di.ens.fr/~fouque/ens-rennes/coppersmith.pdf, section 7) -
> given RSA ciphertext and (1-1/e) fraction of plaintext (where e is
> public exponent), it's possible to effectively compute x. Message is
> highly redundant, because only 1/e of the message is unknown. Relative
> redundancy of the message is at least (1-1/e).
>
> Consider a few notes:
> * Nowadays there exists more complicated variants of mentioned attacks
> which have weaker premisses.
> * There is a considerable similarity between RSA and SSS. Both schemes
> are algebraically-based (rather than boolean function based).
> * CRCs (and error-correcting codes generally) introduce redundancy
> into the message. Moreover the redundancy is induced by a linear
> relationship among message (compare with the premise of the Related
> Message Attack).
> * Related Message Attack wouldn't be possible if you had two
> plaintexts x and hash(x). The relationship between messages has to be
> (algebraically) uncomplicated. From the information-theoretic point of
> view the situation is the same, but from the practical point of view it
> is completely different.
>
> To sum it up, there is a precautionary principle which tells us not to
> increase redundancy of a message unless it is introduced in a
> complicated way (for example by a hash function). That's why we use SHA
> rather than CRC. One more reason why we stick to the principle is that
> there's no randomisation in our scheme (such as padding or
> initialisation vector). We understood advantages of error-correctings
> codes over hash functions (minimal codewords distance property,
> performance) and we considered it thoroughly.
>
> Ondřej Vejpustek
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180117/4ce36a81/attachment.html>;

📅 Original date posted:2018-01-09 📝 Original message:On ...

2023-06-07T20:09:31+02:00

In reply to nevent1q…xphr
_________________________

📅 Original date posted:2018-01-09
📝 Original message:On Mon, Jan 8, 2018 at 7:39 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On 08/01/18 05:22, Gregory Maxwell wrote:
> >> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>
>
> > The 16-bit "checksum" based on sha2 seems pretty poor since basing
> > small checksums on a cryptographic hash results in a fairly poor
> > checksum that is surprisingly likely to accept an errored string. Your
> > wordlist is 10 bits and you have much less than 1023*10 bits of input,
> > so you could easily have a 20 bit code (two words) which guaranteed
> > that up to two errored words would always be detected, and probably
> > could choose one which catches three words much more often 1:2^20
> > (sipa's crc tools can help find codes like this).
>
> Originally, we wanted to use 16-bit of CRC32 for checksum, but after the
> discussion with Daan Sprenkels we were suggested to change this for
> cryptographically strong function. The argument was that CRC32 contains
> less entropy and mixing high-entropy data (secret) with low-entropy data
> (checksum) is not a good idea.
>

This entropy argument seems confused. Ignoring constant factors, the
entropy of a checksum is the sum over all possible checksums, i, of
-n_i*log(n_i), where n_i is the number of times the ith checksum occurs
over the space of all possible data being checksummed. In this application
the checksum is being applied to a fixed m-bit blob of uniformly random
data.

The entropy is maximized when every possible checksum occurs equally as
frequently, that is we achieve maximum entropy when all the n_i values are
equal to each other. Any error correcting code worth it's salt will try to
achieve this property because the designers want every checksum value to
have as much error correcting power as every other checksum value. I'm
almost certain that the algebraic properties of your typical error
correcting codes allow you to prove that maximum entropy is perfectly
achieved whenever the data-blob size is at least as large as the checksum
size.

Meanwhile the truncated value of a cryptographic hash function is expected
to be slightly under the maximum entropy value, under the assumption that
the hash function it behaves like a random function.

The main properties of a "strong cryptographic hash function" is that it is
infeasible to find collisions and preimages. However these properties are
lost when you truncate the hash down to 16-bits. At this point is it
entirely feasible to find collisions and preimages.

So using a truncated cryptographic hash function doesn't provide you with
more entropy (and, in fact, probably a sliver less entropy), and doesn't
provide you with any of the befits of strong cryptographic hash function.

> Also, there is an argument between a checksum and ECC. We discussed that
> ECC might not be a good idea, because it helps the attacker to compute
> missing information, while we only want to check for integrity. Also the
> word mnemonic is itself a ECC, because if you see the word "acadornic"
> it is probably the word "academic".
>

Every checksum is error correcting. Given an failed checksum, all you have
to do is search around the space of edits to find the smallest set edits
that yield a valid checksum. With a 2^16 bit checksum one will expect to
find a nearby checksum within 2^16 trails, even when using a truncated hash
function.

What an error-correcting codes gives you isn't the ability to correct
errors, which we have seen is something that all short checksums provide,
rather they provide *guarantees* about the ability to detect (and correct)
certain common classes of errors. For example we can have an ECC that
guarantees to find the error where are word is accidentally written down
twice (see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015506.html
).

The advice you have been given will only result in losing any guarantees
about detecting common classes or errors; it won't stop attackers from
recovering missing information, and it won't provide a cryptographically
strong function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180109/5f03431f/attachment.html>;

📅 Original date posted:2017-10-02 📝 Original message:On ...

2023-06-07T20:06:47+02:00

In reply to nevent1q…pk73
_________________________

📅 Original date posted:2017-10-02
📝 Original message:On Sun, Oct 1, 2017 at 4:39 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:

>
> > On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor at blockstream.io>
> wrote:
> >
> > Creating a Bitcoin script that does not allow malleability is difficult
> and requires wasting a lot of bytes to do so, typically when handling
> issues around non-0-or-1 witness values being used with OP_IF, and dealing
> with non-standard-zero values, etc.
>
> Script validation flags of the correct place to do this. We already have
> policy validation flags that check for these things. They were not made
> consensus rules with Segwit v0 mainly due to concern over scope creep in an
> already large overhaul, of my memory is correct. Script versions and
> quadratic hashing fixes where the minimum necessary to allow segwit to
> activate safely while still enabling future upgrades that would otherwise
> have been hard forks. We knew that we would be later changing the EC
> signature scheme to be something that supported signature aggregation, and
> that would be more appropriate time to discuss such changes. As we are
> considering to do now (although witness versions means we don’t need to
> omnibus the script upgrade here either, so a v1 before signature
> aggregation is ready is fine IMHO).
>

Script validation isn't the correct place to do this. The reason is that
script operations are not aware of whether the stack items they are
processing are witness malleable items or Script computed values. Let me
take OP_IF as one example. When OP_IF operates directly on witness data,
it is subject to witness malleability, and therefore one needs to add extra
code around that to prevent witness malleability. On the other hand, when
OP_IF operates on computed data, it isn't subject to malleability and can
safely process non-zero-or-one values. If OP_IF were restricted to
requiring canonical inputs, then for the cases that OP_IF operates on
computed data, they will need to add extra code to canonicalize their
inputs. I don't think there is a correct answer here. That is because I
believe this isn't the correct place to aim to restrict witness
malleability.

OTOH, signatures are a fine place to aim to restrict witness malleability.
In fact, if signatures could securely cover all witness data, I think
everyone here would jump at the opportunity to implement that. However,
since that isn't known to be possible, we are left with doing the best we
can, which is to have signatures cover weight (or bytes). This prevents
the worst effects of witness malleability and does so without burdening
Script development. (This also requires signatures have a fixed size, so
it is understandable that signature-covers-weight wasn't included in Segwit
v0 scripts).

> In any case if there is any general witness malleability due to opcode
> semantics that it’s not fixed by one of our existing policy flags, that is
> a bug and I would encourage you to report it.
> > I'll argue that I don't want my counter-party going off and using a very
> deeply nested key in order to subvert the fee rate we've agreed upon after
> I've signed my part of the input. If we are doing multi-party signing of
> inputs we need to communicate anyways to construct the transaction. I see
> no problem with requiring my counter-party to choose their keys before I
> sign so that I know up front what our fee rate is going to be. If they
> lose their keys and need a backup, they should have to come back to me to
> resign in order that we can negotiate a new fee rate for the transaction
> and who is going to be covering how much of the fee and on which inputs.
>
> Arguing that every single user should be forced to restart an interactive
> signing session. That’s a very strong statement based on something that I
> would say is a preference that depends on circumstances.
>
> What about an optional commitment to witness size in bytes? The value zero
> meaning “I don’t care.” I would argue that it should be a maximum however,
> and therefor serialized as part of the witness. The serialization of this
> would be very compact (1 plus the difference between actual and maximum,
> with zero meaning not used.)

I would be fine your suggestion above, though I think Luke's suggestion of
having both SIGHASH_WITNESS_SIZE and SIGHASH_WITNESS_DEPTH flag is better
because it is simpler.

Those people worried about restarting interactive signing session in the
unlikely event of parties not knowing what keys they are planning to use
can use just the SIGHASH_WITNESS_DEPTH flag. Those people worried about
counterparties fiddling with fee rates can use both flags. The choice
doesn't even need to be made at script commitment time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171002/36c4797d/attachment.html>;

📅 Original date posted:2017-10-01 📝 Original message:On ...

2023-06-07T20:06:46+02:00

In reply to nevent1q…jwxe
_________________________

📅 Original date posted:2017-10-01
📝 Original message:On Sun, Oct 1, 2017 at 3:27 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:

> > On Oct 1, 2017, at 12:05 PM, Russell O'Connor <roconnor at blockstream.io>
> wrote:
> >
> > Given the proposed fixed signature size, It seems better to me that we
> create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.
>
> For what benefit? If your script actually uses all the items on the stack,
> and if your script is not written in such a way as to allow malleability
> (which cannot be prevented in general), then they’re equivalent. Using
> weight instead of depth only needlessly restricts other parties to select a
> witness size up-front.
>

Creating a Bitcoin script that does not allow malleability is difficult and
requires wasting a lot of bytes to do so, typically when handling issues
around non-0-or-1 witness values being used with OP_IF, and dealing with
non-standard-zero values, etc. Adding a witness weight flag cuts through
the worst of all this, and makes script design enormously simpler and makes
scripts smaller and cheaper.

> And to be clear, signing witness weight doesn’t mean the witness is not
> malleable. The signer could sign again with a different ECDSA nonce. Or if
> the signer is signing from a 2-of-3 wallet, a common scenario I hope, there
> are 3 possible key combinations that could be used. If using MBV, a
> 3-element tree is inherently unbalanced and the common use case can have a
> smaller proof size.
>
> Witnesses are not 3rd party malleable and we will maintain that property
> going forward with future opcodes.
>
> > Mark, you seem to be arguing that in general we still want weight
> malleability even with witness depth fixed, but I don't understand in what
> scenario we would want that.
>
> Any time all parties are not online at the same time in an interactive
> signing protocol, or for which individual parties have to reconfigure their
> signing choices due to failures. We should not restrict our script
> signature system to such a degree that it becomes difficult to create
> realistic signing setups for people using best practices (multi-key, 2FA,
> etc.) to sign. If I am a participant in a signing protocol, it would be
> layer violating to treat me as anything other than a black box, such that
> internal errors and timeouts in my signing setup don’t propagate upwards to
> the multi-party protocol.
>
> For example, I should be able to try to 2FA sign, and if that fails go
> fetch my backup key and sign with that. But because it’s my infrequently
> used backup key, it might be placed deeper in the key tree and therefore
> signatures using it are larger. All the other signers need care is that
> slot #3 in the witness is where my Merkle proof goes. They shouldn’t have
> to restart and resign because my proof was a little larger than anticipated
> — and maybe they can’t resign because double-spend protections!
>

I'll argue that I don't want my counter-party going off and using a very
deeply nested key in order to subvert the fee rate we've agreed upon after
I've signed my part of the input. If we are doing multi-party signing of
inputs we need to communicate anyways to construct the transaction. I see
no problem with requiring my counter-party to choose their keys before I
sign so that I know up front what our fee rate is going to be. If they
lose their keys and need a backup, they should have to come back to me to
resign in order that we can negotiate a new fee rate for the transaction
and who is going to be covering how much of the fee and on which inputs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171001/a587d6ba/attachment.html>;

📅 Original date posted:2017-10-01 📝 Original message:Given ...

2023-06-07T20:06:46+02:00

In reply to nevent1q…8j4m
_________________________

📅 Original date posted:2017-10-01
📝 Original message:Given the proposed fixed signature size, It seems better to me that we
create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.

Mark, you seem to be arguing that in general we still want weight
malleability even with witness depth fixed, but I don't understand in what
scenario we would want that.

It strikes me that is most scenarios all parties signing an input would do
so after an execution path through the script has been agreed upon by all
parties, in which case the witness weight can be fixed.
In rare cases where the smart contract requires that some parties sign in
advance of the decision about the execution path (for example, I'm thinking
about delegation here, but I want to keep my remarks general), we wouldn't
want to fix the witness depth either.

A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that would
modify the transaction's fee/weight priority (at least for that one input),
and greatly reduce the overall attack surface of witness malleability
issues.

On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Clean stack should be eliminated for other possible future uses, the most
> obvious of which is recursive tail-call for general computation capability.
> I’m not arguing for that at this time, just arguing that we shouldn’t
> prematurely cut off an easy implementation of such should we want to. Clean
> stack must still exist as policy for future soft-fork safety, but being a
> consensus requirement was only to avoid witness malleability, which
> committing to the size of the witness also accomplishes.
>
> Committing to the number of witness elements is fully sufficient, and
> using the number of elements avoids problems of not knowing the actual size
> in bytes at the time of signing, e.g. because the witness contains a merkle
> proof generated by another party from an unbalanced tree, and unbalanced
> trees are expected to be common (so that elements can be placed higher in
> the tree in accordance with their higher expected probability of usage).
> Other future extensions might also have variable-length proofs.
>
> > On Sep 30, 2017, at 7:47 PM, Luke Dashjr <luke at dashjr.org> wrote:
> >
> > Should it perhaps commit to the length of the serialised witness data
> instead
> > or additionally? Now that signatures are no longer variable-length,
> that'd be
> > possible...
> >
> > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been
> checked
> > until AFTER the tail-call in the first draft. But I suppose eliminating
> it for
> > other possible future purposes is still useful.
> >
> > Luke
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171001/61186661/attachment.html>;

📅 Original date posted:2017-09-07 📝 Original message:On ...

2023-06-07T20:05:43+02:00

In reply to nevent1q…54vf
_________________________

📅 Original date posted:2017-09-07
📝 Original message:On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:

> I've been puzzling over your email since receiving it. I'm not sure it
> is possible to perform the attack you describe with the tree structure
> specified in the BIP. If I may rephrase your attack, I believe you are
> seeking a solution to the following:
>
> Want: An innocuous script and a malign script for which
>
> double-SHA256(innocuous)
>
> is equal to either
>
> fast-SHA256(double-SHA256(malign) || r) or
> fast-SHA256(r || double-SHA256(malign))
>

or fast-SHA256(fast-SHA256(double-SHA256(malign) || r1) || r0)
or fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) || r0)
or ...

> where r is a freely chosen 32-byte nonce. This would allow the
> attacker to reveal the innocuous script before funds are sent to the
> MAST, then use the malign script to spend.
>
> Because of the double-SHA256 construction I do not see how this can be
> accomplished without a full break of SHA256.
>

The particular scenario I'm imagining is a collision between

double-SHA256(innocuous)

and

fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || r1)
|| r0).

where innocuous is a Bitcoin Script that is between 32 and 55 bytes long.

Observe that when data is less than 55 bytes then double-SHA256(data) =
fast-SHA256(fast-SHA256(padding-SHA256(data)) || 0x8000...100) (which is
really the crux of the matter).

Therefore, to get our collision it suffices to find a collision between

padding-SHA256(innocuous)

and

fast-SHA256(double-SHA256(malign) || r2) || r1

r1 can freely be set to the second half of padding-SHA256(innocuous), so it
suffices to find a collision between

fast-SHA256(double-SHA256(malign) || r2)

and the first half of padding-SHA256(innocuous) which is equal to the first
32 bytes of innocuous.

Imagine the first opcode of innocuous is the push of a value that the
attacker claims to be his 33-byte public key.
So long as the attacker doesn't need to prove that they know the discrete
log of this pubkey, they can grind r2 until the result of
fast-SHA256(double-SHA256(malign) || r2) contains the correct first couple
of bytes for the script header and the opcode for a 33-byte push. I
believe that is only about 3 or 4 bytes of they need to grind out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/724c4de6/attachment.html>;

📅 Original date posted:2017-09-07 📝 Original message:In ...

2023-06-07T20:05:42+02:00

In reply to nevent1q…h0c3
_________________________

📅 Original date posted:2017-09-07
📝 Original message:In that case, you may as well remove all references to leaves and double
SHA-256 from your BIP since your design has no method for distinguishing
between internal nodes and leaves.

I think that if this design stands, it will play a role in some future
CVEs. The BIP itself is too abstract about its data contents to
specifically say that it has a vulnerability; however, I believe it is
inviting vulnerabilities.
For example, I might agree with a counterparty to a design of some sort of
smart contract in the form of a MAST. My counterparty has shown me all the
"leaves" of our MAST and I can verify its Merkle root computation.
After being deployed, I found out that one of the leaves wasn't really a
leaf but is instead a specially crafted "script" with a fake pubkey chosen
by my couterparty so that this leaf can also be interpreted as a fake
internal node (i.e. an internal node with a right branch of 0x8000...100).
Because the Fast Merkle Tree design doesn't distinguish between leaves and
internal nodes my counter party gets away with building an Inclusion Proof
through this "leaf" to reveal the evil code that they had designed into the
MAST at a deeper level.

Turns out my counterparty was grinding their evil code to produce an
internal node that can also be parsed as an innocent script. They used
their "pubkey" to absorb excess random data from their grinding that they
cannot eliminate.
(The counterparty doesn't actually know the discrete log of this "pubkey",
they just claimed it was their pubkey and I believed them).

Having ambiguity about whether a node is a leaf or an internal node is a
security risk. Furthermore, changing the design so that internal node and
leaves are distinguishable still allows chained invocations.
Arbitrary data can be stored in Fast Merkle Tree leaves, including the
Merkle root of another Fast Merkle Tree.
Applications that are limited to proof with paths no longer than 32
branches can still circumvent this limit by staging these Fast Merkle Trees
in explicit layers (as opposed to the implicit layers with the current
design).

By storing a inner Fast Merkle Tree root inside the (explicit) leaf of an
outer Fast Merkle Tree, the application can verify a Inclusion Proof of the
inner Fast Merkle Tree Root in the outer Fast Merkle Tree Root, and then
verify a second Inclusion Proof of the desired data in the inner Faster
Merkle Tree Root. The application will need to tag their data to
distinguish between inner Fast Merkle Tree Roots and other application
data, but that is just part of the general expectation that applications
not store ambiguous data inside the leaves of Fast Merkle Trees.

On Wed, Sep 6, 2017 at 10:20 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:

> This design purposefully does not distinguish leaf nodes from internal
> nodes. That way it chained invocations can be used to validate paths longer
> than 32 branches. Do you see a vulnerability due to this lack of
> distinction?
>
> On Sep 6, 2017, at 6:59 PM, Russell O'Connor <roconnor at blockstream.io>
> wrote:
>
> The fast hash for internal nodes needs to use an IV that is not the
> standard SHA-256 IV. Instead needs to use some other fixed value, which
> should itself be the SHA-256 hash of some fixed string (e.g. the string
> "BIP ???" or "Fash SHA-256").
>
> As it stands, I believe someone can claim a leaf node as an internal node
> by creating a proof that provides a phony right-hand branch claiming to
> have hash 0x80000..0000100 (which is really the padding value for the
> second half of a double SHA-256 hash).
>
> (I was schooled by Peter Todd by a similar issue in the past.)
>
> On Wed, Sep 6, 2017 at 8:38 PM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Fast Merkle Trees
>> BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
>> Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/87bc87d5/attachment-0001.html>;

📅 Original date posted:2017-09-06 📝 Original message:The ...

2023-06-07T20:05:42+02:00

In reply to nevent1q…qncq
_________________________

📅 Original date posted:2017-09-06
📝 Original message:The fast hash for internal nodes needs to use an IV that is not the
standard SHA-256 IV. Instead needs to use some other fixed value, which
should itself be the SHA-256 hash of some fixed string (e.g. the string
"BIP ???" or "Fash SHA-256").

As it stands, I believe someone can claim a leaf node as an internal node
by creating a proof that provides a phony right-hand branch claiming to
have hash 0x80000..0000100 (which is really the padding value for the
second half of a double SHA-256 hash).

(I was schooled by Peter Todd by a similar issue in the past.)

On Wed, Sep 6, 2017 at 8:38 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Fast Merkle Trees
> BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
> Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/59d742fe/attachment-0001.html>;

📅 Original date posted:2017-05-13 📝 Original message:I ...

2023-06-07T20:01:09+02:00

In reply to nevent1q…jryp
_________________________

📅 Original date posted:2017-05-13
📝 Original message:I recall chatting about this idea recently and my conclusion was the same
as Peter Todd's conclusion: this will just encourage miners to false signal
readiness with undermines both BIP 9 and BIP 8.

I felt that rather than using script system for this construction, it would
be better to use the transaction version number instead by soft-forking in
a rule that says when the most significant bits of a transaction version
are 001 then the transaction can only be included in blocks whose lower 29
version bits are set at the same position as the lower 29 version bits set
in the transaction version.

That is to say, if we have block version blkVersion and transaction version
txVersion, we soft fork in a rule that requires that

(txVersion & 0xe0000000 != 0x020000000) || ((blkVersion & 0xe0000000 =
0x020000000) && (blkVersion & txVersion = txVersion))

While I think that making use of the transaction version number is superior
to adding an opcode, because it doesn't interfere with caching of script
validity and because it doesn't use any more transaction space by making
use of the otherwise useless transaction version number, I still think it
is a bad proposal.

On Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the
> community
> to put economic pressure on miners to deploy softforks without the extreme
> of
> a UASF.
>
> https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki
>
> Due to the potential for miners to maliciously block this softfork, it is
> suggested that we deploy it using BIP 8 to ensure it eventually activates
> even
> if encountering hostility.
>
> This is intended to be an alternative to BIP 8 in the long term.
> It is NOT intended to make BIP 148 obsolete, given the timeframes involved.
>
> An implementation is available (based on top of BIP 115's implementation):
>
> https://github.com/luke-jr/bitcoin/compare/cbah...luke-
> jr:checkblockversion
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170513/5ceec501/attachment-0001.html>;

📅 Original date posted:2017-05-09 📝 Original ...

2023-06-07T20:00:51+02:00

In reply to nevent1q…fp4g
_________________________

📅 Original date posted:2017-05-09
📝 Original message:I'm a bit amateur at this sort of thing, but let me try to argue that this
proposal is in fact horribly broken ;)

Suppose Alice has some UTXO with some money Bob wants to steal. Grant me
that the public key P0 protecting Alice's UTXO is public (say because the
public key has been reused elsewhere).

Bob going to spend Alice's UTXO by generating random values s0, k0 and R0
:= k0*G and thus creating a random signature for it, [R0, s0]. Now clearly
this signature isn't going to be valid by itself because it is just random.
Bob's goal will be to make a transaction with other inputs such that, while
the individual signatures are not valid, the aggregated signature will be
valid.

To do this Bob generates a set of random public keys P1 ... P_n of the form
P_i := P0 + r_i*G, and a bunch of random k1 ... k_n with R1 := k1*G ... R_n
:= k_n*G, such that

h(m1, R1, P1) + ... + h(m_n, R_n, P_n) = -h(m0, R0 P0) (modulo the
order of the elliptic curve)

I understand that this can be done efficiently with Wagner's Generalized
Birthday attack.

The RHS aggregated signature equation on the private side is

k0 + k1 + ... k_n - h(m0, R0, P0)x0 - h(m1, R1, P1)(x0 + r1) - ... -
h(m_n, R_n, P_n)(x0 + r_n)

with x0 unknown to Bob. Rearranging the terms we get

k0 + k1 + ... k_n - [h(m0, R0, P0) + h(m1, R1, P1) + ... + h(m_n, R_n,
P_n)]*x0 - [h(m1, R1, P1)*r1 + ... + h(m_n, R_n, P_n)*r_n]

However [h(m0, R0, P0) + h(m1, R1, P1) + ... + h(m_n, R_n, P_n)] is 0 so
cancelling that we are left with

k0 + k1 + ... k_n - [h(m1, R1, P1)*r1 + ... + h(m_n, R_n, P_n)*r_n]

which no longer depends on the unknown value x0, so that is good. Bob
knows what this value is.

Bob creates a set UTXOs by spending to the set of public keys P1 .. P_n.
Bob don't know what the private keys are for these public keys, but that is
going to be okay.

Bob creates a final transaction that takes as input the UTXO of Alice's
funds he wants to steal, with public key P0, and also his newly created
UTXOs with public keys P1 ... P_n.
For the signature on Alice's input he uses [R0,s0]. For the rest of the
signature he picks s1 ... s_n such that

s0 + s1 + ... + sn = k0 + k1 + ... k_n - [h(m1, R1, P1)*r1 + ... +
h(m_n, R_n, P_n)*r_n] (which is equal to k0 + k1 + ... k_n - h(m0, R0,
P0)x0 - h(m1, R1, P1)(x0 + r1) - ... - h(m_n, R_n, P_n)(x0 + r_n)).

and uses signatures [R1, s1] ... [R_n, s_n] on his other inputs.

Thus, while none of the individual signatures are valid, the aggregated
signature does validate.

One wrinkles in this argument is that Bob needs to pick m1 ... m_n before
he knows what the transaction will be. I think this can be mitigated by
using some combination of SIGHASH_ANYONECANPAY, but I'm not sure if that
works. Even if my argument doesn't actually work, I think it is close
enough to be pretty scary.

Thanks goes to Pieter Wuille for helping explain things to me; however any
errors above are my own.

On Sun, May 7, 2017 at 2:45 AM, adiabat via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If / when Schnorr signatures are deployed in a future witness version, it
> may be possible to have non-interactive partial aggregation of the
> signatures on a per-block basis. This could save quite a bit of space. It
> *seems* not to have any security problems but this mailing list is very
> good at finding vulnerabilities so that type of feedback is the main reason
> I'm writing :) (A quick explanation of why this is horribly broken could
> save me lots of time!)
> (also sorry if this has been discussed; didn't see anything)
>
> Quick recap / context of Schnorr sigs:
>
> There are a bunch of private keys x1, x2, x3...
> multiply by generator G to get x1G = P1, x2G = P2, x3G = P3
>
> Everyone makes their sighash m1, m2, m3, and their random nonces k1, k2,
> k3.
>
> To sign, people calculate s values:
>
> s1 = k1 - h(m1, R1, P1)x1
> s2 = k2 - h(m2, R2, P2)x2
>
> (adding the P2 into the e hash value is not in most literature /
> explanations but helps with some attacks; I beleive that's the current
> thinking. Anyway it doesn't matter for this idea)
>
> Signature 1 is [R1, s1]. Verifiers check, given P1, m1, R1, s1:
>
> s1G =? R1 - h(m1, R1, P1)P1
>
> You can *interactively* make aggregate signatures, which requires
> co-signers to build an aggregate R value by coming up with their own k
> values, sharing their R with the co-signers, adding up the R's to get a
> summed R, and using that to sign.
>
> Non-interactively though, it seems like you can aggregate half the
> signature. The R values are unique to the [m, P] pair, but the s's can be
> summed up:
>
> s1 + s2 = k1 + k2 - h(m1, R1, P1)x1 - h(m2, R2, P2)x2
>
> (s1 + s2)G = R1 + R2 - h(m1, R1, P1)P1 - h(m2, R2, P2)P2
>
> To use this property in Bitcoin, when making transactions, wallets can
> sign in the normal way, and the signature, consisting of [R, s] goes into
> the witness stack. When miners generate a block, they remove the s-value
> from all compatible inputs, and commit to the aggregate s-value in the
> coinbase transaction (either in a new OP_RETURN or alongside the existing
> witness commitment structure).
>
> The obvious advatage is that signatures go down to 32 bytes each, so you
> can fit more of them in a block, and they take up less disk and network
> space. (In IBD; if a node maintains a mempool they'll need to receive all
> the separate s-values)
>
> Another advatage is that block verification is sped up. For individual
> signatures, the computation involves:
>
> e = h(m1, R1, P1) <- hash function, super fast
> e*P <- point multiplication, slowest
> R - e*P <- point addidion, pretty fast
> s*G <- base point multiplication, pretty slow
>
> with s-aggregate verification, the first three steps are still carried out
> on each signature, but the s*G operation only needs to be done once.
> Instead another point addition per signature is needed, where you have some
> accumulator and add in the left side:
> A += R - e*P
> this can be parallelized pretty well as it's commutative.
>
> The main downside I can see (assuming this actually works) is that it's
> hard to cache signatures and quickly validate a block after it has come
> in. It might not be as bad as it first seems, as validation given chached
> signatures looks possible without any elliptic curve operations. Keep an
> aggregate s-value (which is a scalar) for all the txs in your mempool.
> When a block comes in, subtract all the s-values for txs not included in
> the block. If the block includes txs you weren't aware of, request them in
> the same way compact blocks works, and get the full signature for those
> txs. It could be several thousand operations, but those are all bigInt
> modular additions / subtractions which I believe are pretty quick in
> comparison with point additions / multiplications.
>
> There may be other complications due to the fact that the witness-txids
> change when building a block. TXIDs don't change though so should be
> possible to keep track of things OK.
>
> Also you can't "fail fast" for the signature verification; you have to add
> everything up before you can tell if it's correct. Probably not a big deal
> as PoW check comes first, and invalid blocks are pretty uncommon and quite
> costly.
>
> Would be interested to hear if this idea looks promising.
> Andrew Polestra mentioned something like this in the context of CT /
> mimblewimble transactions a while ago, but it seems it may be applicable to
> regular bitcoin Schnorr txs.
>
> -Tadge
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/75fc05c4/attachment.html>;

📅 Original date posted:2017-04-26 📝 Original message:On ...

2023-06-07T20:00:33+02:00

In reply to nevent1q…sluk
_________________________

📅 Original date posted:2017-04-26
📝 Original message:On Wed, Apr 26, 2017 at 4:01 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> There are things scriptSig can do that witness cannot today - specifically
> add
> additional conditions under the signature. We can always obsolete scriptSig
> later, after segwit has provided an alternative way to do this.
>

I'm not sure what you are referring to here. The data in the scriptSigs
are never signed. The scriptSigs are always stripped from the transaction
before the sigHash is made.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170426/f3cfa587/attachment.html>;

📅 Original date posted:2016-11-02 📝 Original message:Hi ...

2023-06-07T19:54:13+02:00

In reply to nevent1q…4w4y
_________________________

📅 Original date posted:2016-11-02
📝 Original message:Hi all,

It is possible to implement covenants using two script extensions: OP_CAT
and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already
available in the Elements Alpha sidechain, so it is possible to construct
covenants in Elements Alpha today. I have detailed how the construction
works in a blog post at <
https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html>;. As
an example, I've constructed scripts for the Moeser-Eyal-Sirer vault.

I'm interested in collecting and implementing other useful covenants, so if
people have ideas, please post them.

If there are any questions, I'd be happy to answer.

--
Russell O'Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161102/7ccba370/attachment.html>;