[bitcoin-dev] BIP Proposal: The Great Consensus Cleanup

[bitcoin-dev] BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

The following is a proposed BIP to soft-fork out some oddities in the 
current Bitcoin consensus rules, resolving several vulnerabilities, in 
addition to fixing the timewarp vulnerability. I'd like to ask the BIP 
editor to assign a BIP number.

The latest version of the BIP can be found at 
https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki 
(a text copy is included below).

Some things that may be worth discussing:

  * Note that the activation times in this BIP may result in the 
activation of the new soft-fork rules on the same block as the scheduled 
block-subsidy halving. Sadly, avoiding this either requires a 
significantly compressed BIP activation time (which may result in the 
rules not activating for benign reasons) or beginning the activation 
process significantly into the future.

  * The BIP proposes allowing timestamps on the difficulty-adjustment 
block to go backwards by 600 seconds which has the nice property of 
making the difficulty-adjustment algorithm target almost exactly one 
block per 600 seconds in the worst-case (where miners are attempting to 
exploit the timewarp attack), while avoiding any potential hardware 
bricking (assuming upgrades on the part of mining pools). Alternatively, 
some have proposed allowing the time to go backwards 7200 seconds, which 
introduces some small level of inflation in the case of a miner attack 
(though much less than we've had historically simply due to the rapidly 
growing hashrate) but avoids any requirements for upgrades as the 
existing 7200-second-in-the-future check implies miners will only ever 
build on blocks for which they can set the next timestamp to their 
current time.

  * The 4th change (making non-standard signature hash types invalid) 
may be worth discussing. In order to limit the number of potential 
signature hashes which could be used per-input (allowing us to cache 
them to avoid re-calculation), we can disable non-standard sighash 
types. Alternatively, however, most of the same effect could be achieved 
by caching the just-before-the-last-byte sighash midstate and hashing 
only the last byte when a checking signatures. Still, them having been 
non-standard for many years makes me doubt there is much risk involved 
in disabling them, and I don't see much potential use-case for keeping 
them around so I'd like to just remove them.

As for why the timewarp vulnerability should (IMO rather obviously) be 
fixed, it seems rather clear that the only potential use for exploiting 
it would be either to inflate the currency supply maliciously by miners 
or to fork in what amounts to extension blocks. As for why extension 
blocks are almost certainly not the right approach to such changes, its 
likely worth reading this old post: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510.html


<pre>
BIP: XXXX
Layer: Consensus (soft fork)
Title: The Great Consensus Cleanup
Author: Matt Corallo
Status: Draft
Type: Standards Track
Created: 2019-01-28
License: PD
</pre>

==Abstract==

This BIP defines a set of consensus changes which reduce the complexity 
of Bitcoin implementations and improve worst-case validation times, 
fixing a number of long-standing vulnerabilities.

==Motivation==

BIP 143 significantly improved certain aspects of Bitcoin's consensus 
rules, key to this being changes to the format of the data which is 
hashed and signed in CHECKSIG operations during script execution. 
However, several improvements were left for later forks to avoid 
bloating the original activation with unrelated changes. This BIP seeks 
to make some of these changes as well as a few other simplifications. 
Specifically, this BIP proposes the following changes:

* Worst-case validation time for non-BIP 143 transactions has long been 
considered a significant vulnerability. To address this, both 
OP_CODESEPARATOR in non-BIP 143 scripts and FindAndDelete fail script 
validation, among other cleanups. This drastically reduces worst-case 
validation time for non-BIP 143 transactions by enabling Signature Hash 
caching on a per-input basis. While validation time of large, simple 
non-BIP 143 transactions can still be excessively high on their own, 
removing these multipliers goes a long way towards resolving the issue.

* By further restricting nTime fields on difficulty adjustment blocks, 
we propose fixing the long-standing "timewarp" inflation vulnerability 
in Bitcoin's difficulty adjustment without risking existing mining 
hardware becoming unusable. This limits the worst-case difficulty 
adjustment target in case of attack from the current exponential growth, 
to once every roughly 600 seconds. Note that no change in default 
behavior is proposed, keeping the existing target of one block every 
~600.6 seconds[1] in the common case (ie we limit the attack scenario to 
about a 0.1% inflation rate, much smaller than the historical inflation 
rate due to rapid hashrate growth).

* Several vulnerabilities where Bitcoin clients needed to check for 
specific cases of malleation in the merkle tree construction are 
resolved by making certain transaction sizes invalid.

==Specification==

Upon activation, the following rules will be enforced on all new blocks:

* scriptSigs which contain non-push opcodes fail the script validation. 
Push opcodes are OP_0 - OP_1NEGATE and OP_1 - OP_16. Note that this 
implies any opcodes in scriptSigs greater than 0x60 will fail script 
validation, in addition to OP_RESERVED (0x50, which already fails script 
execution in executed branches, though all branches are now guaranteed 
to execute).

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

* When validating signatures in non-BIP 143 scripts, if the scriptPubKey 
being executed contains, pushed as a single element using minimal 
PUSHDATA, a signature stack element being validated, the script fails 
validation. For the avoidance of doubt, any FindAndDelete matches result 
in script execution failure.

* If the sighash type byte (ie last byte in a signature being evaluated 
during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY]) 
is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script 
execution fails. This does not apply to 0-length signature stack elements.

* Transactions smaller than 65 bytes when serialized without witness 
data are invalid.

* The nTime field of each block whose height, mod 2016, is 0 must be 
greater than or equal to the nTime field of the immediately prior block 
minus 600. For the avoidance of doubt, such blocks must still comply 
with existing Median-Time-Past nTime restrictions.

==Deployment==

This BIP will be deployed by "version bits" BIP9 with the name 
"cleanups" and using bit (0-indexed) 3.

For Bitcoin mainnet, the BIP9 starttime will be midnight August 1st, 
2019 UTC (Epoch timestamp 1564617600) and BIP9 timeout will be midnight 
August 1st, 2020 UTC (Epoch timestamp 1596240000).

For Bitcoin testnet, the BIP9 starttime will be midnight June 1st, 2019 
UTC (Epoch timestamp 1559347200) and BIP9 timeout will be midnight June 
1st, 2020 UTC (Epoch timestamp 1590969600).

==Discussion==

* There are very few known uses for OP_CODESEPARATOR and none for 
FindAndDelete. None of these uses enable new functionality, and any 
efficiency gains are better made by switching to BIP 141. Further, there 
is no known use of either on the chain today, and both have been 
non-standard in Bitcoin Core since version 0.16.1, making them much more 
difficult to have mined. Both changes, together, allow for signature 
hash caching within each input script in a non-BIP 143 transaction 
today. Note that due to their non-standardness, miners using Bitcoin 
Core version 0.16.1 or later will not mine blocks which violate these 
rules today.
* Reducing valid scriptSigs to the minimal set of operations which can 
generate any stack state removes the requirement that scriptCodes need 
to be generated for scriptSig execution, reducing the possible set of 
scriptCodes which must be cached per input by 2x. Because any stack 
state can be created using only push opcodes, this does not reduce 
spendability except for pessimal scriptPubKeys which require a 
significant number of identical stack elements (ie created using 
OP_DUP). Note that such transactions have been non-standard in Bitcoin 
Core since before git history (SVN 197) and thus miners running Bitcoin 
Core will not mine such transactions today.
* Further, disabling non-canonical sighash types allows caching of the 
sighash themselves instead of midstates (as the sighash type byte is 
included in the sighash itself). Avoiding applying this rule to 0-length 
signatures avoids breaking deliberate OP_CHECKSIG failures while still 
avoiding having to ever calculate such sighashes. Such sighashes have 
been non-standard and thus miners using Bitcoin Core version 0.8 or 
higher will not mine blocks containing such transactions today.
<br/>
* While there are no known attempts to exploit the "timewarp" 
vulnerability on Bitcoin's mainnet today, and the authors do not believe 
it is likely to occur in the immediate future, removing the possibility 
has long been on various wishlists and greatly simplifies potential 
attack analysis.
** Sadly, some deployed mining hardware relies on the ability to roll 
nTime forward by up to 600 seconds[3]. Thus, only requiring that the 
nTime field move forward during difficulty adjustment would allow a 
malicious miner to prevent some competitors from mining the next block 
by setting their timestamp to two hours in the future. Thus, we allow 
nTime to go backwards by 600 seconds, ensuring that even a block with a 
timestamp two hours in the future allows for 600 seconds of nTime 
rolling on the next block.
** Note that miners today only enforce increasing timestamps against the 
median-timestamp-of-last-11-blocks, so miners who do not upgrade may 
mine a block which violates this rule at the beginning of a difficulty 
window if the last block in a difficulty window has a timestamp in the 
future. Thus, it is strongly recommended that SPV clients enforce the 
new nTime rules to avoid following any potential forks which occur.
<br/>
* The issues involved in having leaf nodes in the transaction merkle 
tree which can be confused for inner nodes are well documented. 
[4][5][6] While there are workarounds for the pitfalls, there are many 
SPV-proof-validators which do not implement them. Further, the limited 
use-cases for very small transactions does not suffice as reason to 
force the added complexity onto clients. Note that any transactions 
smaller than 83 bytes have been considered non-standard since Bitcoin 
Core version 0.17.0, so miners will not mine blocks which validate this 
rule by default.
<br/>
* There are several early-stage proposals which may affect the execution 
of scripts, including proposals such as Schnorr signatures, Taproot, 
Graftroot, and MAST. These proposals are not expected to have any 
interaction with the changes in this BIP, as they are likely to only 
apply to SegWit scripts, which are not covered by any of the new rules 
except for the sighash type byte rule. Thus, the sighash type byte rule 
defined above only applies to *current* signature-checking opcodes, as 
any new signature-checking is likely to be implemented via the 
introduction of new opcodes.
<br/>
* In spite of some suggestion that other activation methods be used, BIP 
9 is proposed as ensuring miners have upgraded to enforce new rules is 
an important part of minimizing disruption. While previous BIP 9 
soft-forks have resulted in political contention, this 
comparatively-unimportant soft-fork provides a good opportunity to 
attempt to return to utilizing BIP 9 to ensure miner upgrade prior to 
activation, which the authors believe is a critical goal. However, if 
there is broad agreement to activate these rules when the BIP 9 expiry 
time is reached, and miners have not yet signaled sufficient level of 
readiness, a later flag-day activation may be merited. For this reason, 
implementations may wish to provide a compatibility option which allows 
flag-day enforcement of these rules without an update.

==Reference Implementation==

[https://github.com/bitcoin/bitcoin/pull/15482 Bitcoin Core Pull #15482]

==References==

[1] The difficulty adjustment algorithm in Bitcoin multiplies the 
previous difficulty by (2016 / time taken to mine the last 2015 blocks). 
Intuitively[2], this implies the actual Inter-Block-Time (IBT) target is 
2016/2015*600, or about 600.3 seconds. However, the expected value of 
the inverse of an Erlang distribution (which the above is effectively 
sampling from) is actually 1/(N-1), not 1/N. Thus, the above expression 
actually targets an IBT of 2016/2014*600, or about 600.6 seconds, ie 
E(2016*600/X) = 1 where X~ErlangDistribution(k=2015, λ=1/IBT) when IBT 
is 2016/2014*600. This is equivalent to 600*E(2016*600/X) where 
X~ErlangDistribution(k=2015, λ=1/600). In the case of a miner 
deliberately reducing timestamps by 600 seconds on the 
difficulty-retargeting block, we are effectively changing the difficulty 
multiplier to (2016 / (time taken to mine the last 2016 blocks + 600)), 
or 600*E(2016*600/(X + 600)) where X~Erlang Distribution(k=2016, 
λ=1/600), which is effectively targeting an inter-block time of 
~599.9999 seconds.

[2] See [https://twitter.com/pwuille/status/1098288749098795008] for 
most peoples' intuition. For more info see Pieter's writeup at 
[https://gist.github.com/sipa/1a70884abe6d0a7cddc340c99f741a41]

[3] While no official stratum specification exists, the btc.com pool 
server (one of the most popular pool servers today) rejects shares with 
timestamps more than 600 seconds in the future at 
[https://github.com/btccom/btcpool/blob/e7c536834fd6785af7d7d68ff29111ed81209cdf/src/bitcoin/StratumServerBitcoin.cc#L384]. 
While there are few resources describing hardware operation today, 
timestamp rolling can be observed on the chain (in some rare cases) as 
block timestamps go backwards when a miner rolled one block nTime 
forward and the next does not, but only incredibly rarely more than 600 
seconds.

[4] 
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html]

[5] 
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.pdf]

[6] 
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016697.html]

==Acknowledgments==

Thanks (in alphabetical order) to Suhas Daftuar, James Hilliard, Johnson 
Lau, Steve Lee, Greg Maxwell, John Newberry, and Pieter Wuille for their 
helpful feedback at various stages as well as the entire Bitcoin 
Protocol Development Community.

Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup

[Luke Dashjr]

On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
> I'd like to ask the BIP editor to assign a BIP number.

Needs a Backward Compatibility section, and should have a bips repo PR opened 
after discussion on the ML.

>   * The 4th change (making non-standard signature hash types invalid)
> may be worth discussing. In order to limit the number of potential
> signature hashes which could be used per-input (allowing us to cache
> them to avoid re-calculation), we can disable non-standard sighash
> types. Alternatively, however, most of the same effect could be achieved
> by caching the just-before-the-last-byte sighash midstate and hashing
> only the last byte when a checking signatures. Still, them having been
> non-standard for many years makes me doubt there is much risk involved
> in disabling them, and I don't see much potential use-case for keeping
> them around so I'd like to just remove them.

I don't understand what is being removed here.

> As for why the timewarp vulnerability should (IMO rather obviously) be
> fixed, it seems rather clear that the only potential use for exploiting
> it would be either to inflate the currency supply maliciously by miners
> or to fork in what amounts to extension blocks. As for why extension
> blocks are almost certainly not the right approach to such changes, its
> likely worth reading this old post:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
>.html

While I agree that extension blocks are typically a bad choice, I'm not sure 
the argument really applies to forward blocks. (That being said, I find 
forward blocks overcomplicated and probably not a reason to avoid this.)

> * Transactions smaller than 65 bytes when serialized without witness
> data are invalid.

Rationale should include the reason(s) why the size doesn't count the witness 
here.

> ** Note that miners today only enforce increasing timestamps against the
> median-timestamp-of-last-11-blocks, so miners who do not upgrade may
> mine a block which violates this rule at the beginning of a difficulty
> window if the last block in a difficulty window has a timestamp in the
> future. Thus, it is strongly recommended that SPV clients enforce the
> new nTime rules to avoid following any potential forks which occur.

This should probably be moved outside Discussion. (Perhaps to the missing 
Backward Compatibility section?)

> * There are several early-stage proposals which may affect the execution
> of scripts, including proposals such as Schnorr signatures, Taproot,
> Graftroot, and MAST. These proposals are not expected to have any
> interaction with the changes in this BIP, as they are likely to only
> apply to SegWit scripts, which are not covered by any of the new rules
> except for the sighash type byte rule. Thus, the sighash type byte rule
> defined above only applies to *current* signature-checking opcodes, as
> any new signature-checking is likely to be implemented via the
> introduction of new opcodes.

It's not clear that new opcodes will necessarily always be used. Probably 
would be good to clarify the "non-Segwit or witness v0 only" rule in the 
Specification section.

Luke

Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

Replies inline.

On 3/7/19 10:44 AM, Luke Dashjr wrote:
> On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
>> I'd like to ask the BIP editor to assign a BIP number.
> 
> Needs a Backward Compatibility section, and should have a bips repo PR opened
> after discussion on the ML.

Oops, I guess most of the "Discussion" section can just be moved into a 
"Backwards Compatibility" section. Will do before PR'ing.

>>    * The 4th change (making non-standard signature hash types invalid)
>> may be worth discussing. In order to limit the number of potential
>> signature hashes which could be used per-input (allowing us to cache
>> them to avoid re-calculation), we can disable non-standard sighash
>> types. Alternatively, however, most of the same effect could be achieved
>> by caching the just-before-the-last-byte sighash midstate and hashing
>> only the last byte when a checking signatures. Still, them having been
>> non-standard for many years makes me doubt there is much risk involved
>> in disabling them, and I don't see much potential use-case for keeping
>> them around so I'd like to just remove them.
> 
> I don't understand what is being removed here.

This refers to the following spec change:

If the sighash type byte (ie last byte in a signature being evaluated 
during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY]) 
is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script 
execution fails. This does not apply to 0-length signature stack elements.

>> As for why the timewarp vulnerability should (IMO rather obviously) be
>> fixed, it seems rather clear that the only potential use for exploiting
>> it would be either to inflate the currency supply maliciously by miners
>> or to fork in what amounts to extension blocks. As for why extension
>> blocks are almost certainly not the right approach to such changes, its
>> likely worth reading this old post:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
>> .html
> 
> While I agree that extension blocks are typically a bad choice, I'm not sure
> the argument really applies to forward blocks. (That being said, I find
> forward blocks overcomplicated and probably not a reason to avoid this.)

I agree they are somewhat separate ideas, but the arguments in that 
thread apply equally to timewarp-based inter-block-time reductions. If 
you want to discuss it further, I'd suggest a new thread.

>> * Transactions smaller than 65 bytes when serialized without witness
>> data are invalid.
> 
> Rationale should include the reason(s) why the size doesn't count the witness
> here.

Will add.

>> ** Note that miners today only enforce increasing timestamps against the
>> median-timestamp-of-last-11-blocks, so miners who do not upgrade may
>> mine a block which violates this rule at the beginning of a difficulty
>> window if the last block in a difficulty window has a timestamp in the
>> future. Thus, it is strongly recommended that SPV clients enforce the
>> new nTime rules to avoid following any potential forks which occur.
> 
> This should probably be moved outside Discussion. (Perhaps to the missing
> Backward Compatibility section?)
> 
>> * There are several early-stage proposals which may affect the execution
>> of scripts, including proposals such as Schnorr signatures, Taproot,
>> Graftroot, and MAST. These proposals are not expected to have any
>> interaction with the changes in this BIP, as they are likely to only
>> apply to SegWit scripts, which are not covered by any of the new rules
>> except for the sighash type byte rule. Thus, the sighash type byte rule
>> defined above only applies to *current* signature-checking opcodes, as
>> any new signature-checking is likely to be implemented via the
>> introduction of new opcodes.
> 
> It's not clear that new opcodes will necessarily always be used. Probably
> would be good to clarify the "non-Segwit or witness v0 only" rule in the
> Specification section.

Note that you inherently have to use a new opcode for such things - the 
non-standard type bytes *are* defined and define a sighash/signature, 
they can't be simply redefined to a new sighash/signature type in a soft 
fork.

[bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1356 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

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

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

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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 5399 bytes --]

On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@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.

[-- Attachment #2: Type: text/html, Size: 6567 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

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@mattcorallo.com 
> <mailto:lf-lists@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.


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

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.

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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 9368 bytes --]

Hi Matt,

On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists@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@mattcorallo.com
> > <mailto:lf-lists@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.

[-- Attachment #2: Type: text/html, Size: 11659 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Jacob Eliosoff]

[-- Attachment #1: Type: text/plain, Size: 11828 bytes --]

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

This principle was only ever a rule of thumb to protect users, not a
commandment from God.  It shouldn't be violated lightly, but that's why
Matt did the legwork to show that the tradeoffs around OP_CODESEPARATOR
justify removing it.

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.


On Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Matt,
>
> On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists@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@mattcorallo.com
>> > <mailto:lf-lists@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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 15211 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 3050 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4171 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

Note that even your carve-outs for OP_NOP is not sufficient here - if you were using nSequence to tag different pre-signed transactions into categories (roughly as you suggest people may want to do with extra sighash bits) then their transactions could very easily have become un-realistically-spendable. The whole point of soft forks is that we invalidate otherwise-unused bits of the protocol. This does not seem inconsistent with the proposal here.

> On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream.io> wrote:
> 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).

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Jacob Eliosoff]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

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?

I see questions like "Is it possible someone's existing tx relies on this?"
as overly black-and-white.  We all agree it's possible: the question is how
likely, vs the harms of continued support - including not just security
risks but friction on other useful changes, safety/correctness analyses,
etc.

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


Stepping back for a second here:  I dispute this framing.  My money *is* at
risk, because the value of my bitcoins depends on adoption and feature
growth.  And I've long viewed an absolutist, actual-known-user-indifferent
approach to backwards compatibility as the #1 impediment to Bitcoin's
adoption and growth.

Again, the point being not to throw caution to the wind, but that a case
like this where extensive research unearthed zero users, is taking caution
too far.


On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream.io>
> wrote:
> > 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).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3321 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Gregory Maxwell]

On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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?

It makes them infeasible to abuse without miner assistance... which
doesn't fix them, but in practice greatly reduces the risk they create
and allows efforts improving the system to be allocated to other more
pressing issues.

> I see questions like "Is it possible someone's existing tx relies on this?" as overly black-and-white.  We all agree it's possible: the question is how likely, vs the harms of continued support - including not just security risks but friction on other useful changes, safety/correctness analyses, etc.

Don't underestimate the value of taking a principled position that
*strongly* avoids confiscating user funds.  Among many other benefits
being cautious about this avoids creating a situation where people are
demanding human intervention to restore improperly lost funds and the
associated loss of effort that would come from the effort wasted
debating that.

It's true that most other cryptocurrencies proceed without any such
caution or care-- e.g. bcash recently confiscating all funds
accidentally sent to segwit using Bitcoin addresses because of their
reckless address aliasing as a result of promoting the standardness
rule that made those txn non-standard before segwit without
considering the implications--, but they're not the standard we should
hold Bitcoin to...

> Again, the point being not to throw caution to the wind, but that a case like this where extensive research unearthed zero users, is taking caution too far.

All things in balance: Codeseperator and its related costs are not an
especially severe problem. The arguments on both side of this point
have enough merit to be worth discussing, at least.

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Tue, Mar 12, 2019 at 6:39 PM Jacob Eliosoff <jacob.eliosoff@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.

>

[-- Attachment #2: Type: text/html, Size: 1008 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Sjors Provoost]

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

Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.

What if such a transaction:

1. must have one input; and
2. must be smaller than 400 vbytes; and
3. must spend from a UTXO older than fork activation

Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.

Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.


I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.

Sjors

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

Aside from the complexity issues here, note that for a user to be adversely affect, they probably have to have pre-signed lock-timed transactions. Otherwise, in the crazy case that such a user exists, they should have no problem claiming the funds before activation of a soft-fork (and just switching to the swgwit equivalent, or some other equivalent scheme). Thus, adding additional restrictions like tx size limits will equally break txn.

> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wrote:
> 
> 
>> (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.
>> 
>>> 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.
> 
> Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
> 
> What if such a transaction:
> 
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
> 
> Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
> 
> Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
> 
> 
> I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
> 
> Sjors
> 

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[LORD HIS EXCELLENCY JAMES HRMH]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]


Opinion: Lock in a blockheight to get rid of it 10 years in the future. Use it as press that Bitcoin is going to lose $1,000,000 if some mystery person does not put their transaction through by then, try for global presses. Use the opportunity to get rid of it while you are able. Once gazetted anything is public knowledge.

Regards,
LORD HIS EXCELLENCY JAMES HRMH

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Saturday, 9 March 2019 7:14 AM
To: Sjors Provoost
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

Aside from the complexity issues here, note that for a user to be adversely affect, they probably have to have pre-signed lock-timed transactions. Otherwise, in the crazy case that such a user exists, they should have no problem claiming the funds before activation of a soft-fork (and just switching to the swgwit equivalent, or some other equivalent scheme). Thus, adding additional restrictions like tx size limits will equally break txn.

> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wrote:
>
>
>> (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.
>>
>>> 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.
>
> Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
>
> Sjors
>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5318 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Moral Agent]

[-- Attachment #1: Type: text/plain, Size: 4253 bytes --]

>Lock in a blockheight to get rid of it 10 years in the future.

And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?

On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <
> bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wrote:
> >
> >
> >> (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.
> >>
> >>> 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.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6865 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[LORD HIS EXCELLENCY JAMES HRMH]

[-- Attachment #1: Type: text/plain, Size: 6062 bytes --]

I have not seen all of the emails in reply come through on the mailing list, I am sure it is always that way. There are a couple to reply to, replies indented>:

On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
What about putting it in a deprecated state for some time. Adjust the transaction weight so using the op code is more expensive (10x, 20x?) and get the word out that it will be removed in the future.

You could even have nodes send a reject code with the message “OP_CODESEPARATOR is depcrecated.”
>Yes, that sort of thing, widely publicised. Positive publicity is a good thing.


From: Moral Agent via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>>
Sent: Monday, 11 March 2019 5:24 AM
To: LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

>Lock in a blockheight to get rid of it 10 years in the future.

And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to the soft fork activation standard, with weight penalties as appropriate, so there would be no difficulty spending them before the cutoff?
>Yes, precisely that sort of thing so that there is no difficulty spending the UTXOs before the cutoff, preferably we would never prevent spending existing valid transactions in the blockchain, also not only to morally discourage the creation of new transactions with OP_CODESEAPRATOR but to physically prevent them if possible. At the minimum, 10 years of depreciated notifications should be enough for anyone but pre-signed lock-timed transactions may be a different matter. Do we currently allow them to be mined and the UTXO's not valid to be spent until n height/time? We should.

On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:

Opinion: Lock in a blockheight to get rid of it 10 years in the future. Use it as press that Bitcoin is going to lose $1,000,000 if some mystery person does not put their transaction through by then, try for global presses. Use the opportunity to get rid of it while you are able. Once gazetted anything is public knowledge.

Regards,
LORD HIS EXCELLENCY JAMES HRMH

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org> <bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org>> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>>
Sent: Saturday, 9 March 2019 7:14 AM
To: Sjors Provoost
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

Aside from the complexity issues here, note that for a user to be adversely affect, they probably have to have pre-signed lock-timed transactions. Otherwise, in the crazy case that such a user exists, they should have no problem claiming the funds before activation of a soft-fork (and just switching to the swgwit equivalent, or some other equivalent scheme). Thus, adding additional restrictions like tx size limits will equally break txn.

> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl<mailto:sjors@sprovoost.nl>> wrote:
>
>
>> (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.
>>
>>> 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.
>
> Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
>
> Sjors
>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 10602 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Dustin Dettmer]

[-- Attachment #1: Type: text/plain, Size: 4373 bytes --]

What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.

You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”

On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <
> bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wrote:
> >
> >
> >> (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.
> >>
> >>> 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.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6789 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size
limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few
more (overhead for varints) = 572ish bytes should be enough to completely
eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH
transactions without the need to remove it ever.  I think it is worth
attempting to be a bit more clever than such a blunt rule, but it would be
much better than eliminating OP_CODESEPARATOR within P2SH entirely.

Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal
is to eliminate the vulnerability associated with it.

On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What about putting it in a deprecated state for some time. Adjust the
> transaction weight so using the op code is more expensive (10x, 20x?) and
> get the word out that it will be removed in the future.
>
> You could even have nodes send a reject code with the message
> “OP_CODESEPARATOR is depcrecated.”
>

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

I think you may have misunderstood part of the motivation. Yes, part of the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the theoretical operation of checksig operations (thus somewhat simplifying the implementation but also simplifying analysis of future changes, such as sighash-caching code).

I think a key part of the analysis here is that no one I've spoken to (and we've been discussing removing it for *years*, including many attempts at coming up with reasons to keep it) is aware of any real proposals to use OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pubic keys is a long-discussed-and-implemented idea (despite it's discouragement, not to mention it appears on the chain in many places).

It would end up being a huge shame to have all the OP_CORESEPARATOR mess left around after all the effort that has gone into removing it for the past few years, especially given the stark difference in visibility of a fork when compared to a standardness change.

As for your specific proposal of increasing the weight of anything that has an OP_CODESEPARATOR in it by the cost of an additional (simple) input, this doesn't really solve the issue. After all, if we're assuming some user exists who has been using sending money, unspent, to scripts with OP_CODESEPARATOR to force signatures to commit to whether some other signature was present and who won't see a (invariably media-covered) pending soft-fork in time to claim their funds, we should also assume such a user has pre-signed transactions which are time-locked and claim a number of inputs and have several paths in the script which contain OP_CODESEPARATOR, rendering their transcription invalid.

Matt

> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (overhead for varints) = 572ish bytes should be enough to completely eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transactions without the need to remove it ever.  I think it is worth attempting to be a bit more clever than such a blunt rule, but it would be much better than eliminating OP_CODESEPARATOR within P2SH entirely.
> 
> Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulnerability associated with it.
> 
>> On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> What about putting it in a deprecated state for some time. Adjust the transaction weight so using the op code is more expensive (10x, 20x?) and get the word out that it will be removed in the future.
>> 
>> You could even have nodes send a reject code with the message “OP_CODESEPARATOR is depcrecated.”
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4246 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]

Hi Matt,

On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> I think you may have misunderstood part of the motivation. Yes, part of
> the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly
> simplifying the theoretical operation of checksig operations (thus somewhat
> simplifying the implementation but also simplifying analysis of future
> changes, such as sighash-caching code).
>

I see.  I was under the mistaken impression the concerns about of
OP_CODESEPARATOR was simply due to the vulnerability it induces.

I'll say it now then: Simplifying the theoretical operation of Bitcoin is
not a sufficient reason to make changes to the consensus rules, and it is
most certainly not a sufficient reason to remove usable op codes.

Had I understood that this was your motivation I would have presented my
opinion earlier. I understand that the OP_CODESEPARATOR vulnerability is
quite serious and making it non-standard while we address the problem is a
good idea (hence the reason why I never objected before now).

What I don't understand is why you feel that avoiding flushing the sigcache
is so critical that you are willing to go through a risky consensus change
just to achieve it?  The sigcache is effectively flushed for each input of
a transaction anyways, so what's the big deal about flushing it during
Script execution as well?


> I think a key part of the analysis here is that no one I've spoken to (and
> we've been discussing removing it for *years*, including many attempts at
> coming up with reasons to keep it) is aware of any real proposals to use
> OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in
> invalid pubic keys is a long-discussed-and-implemented idea (despite it's
> discouragement, not to mention it appears on the chain in many places).
>

Well you've spoken to me now, and I believe I have given you good reasons
to keep it.  We all used to think that OP_CODESEPARATOR was a useless
operation that no one in their right mind would ever use, but it turns out
that we were wrong.  Lesson learned.  We should be more humble about
considering these sorts of changes in the future because it seems we might
not understand Bitcoin as well as we think we do.  At the very least I was
caught by surprise by the utility of OP_CODESEPARATOR.

You misunderstand my point regarding invalid public keys.  My point is that
if no one has spoken up about the invalid public key issue on this mailing
list, something that we know really does affects people, why do you expect
that people would have spoken up about OP_CODESEPARATATOR affecting them?


> It would end up being a huge shame to have all the OP_CORESEPARATOR mess
> left around after all the effort that has gone into removing it for the
> past few years, especially given the stark difference in visibility of a
> fork when compared to a standardness change.
>
> As for your specific proposal of increasing the weight of anything that
> has an OP_CODESEPARATOR in it by the cost of an additional (simple) input,
> this doesn't really solve the issue. After all, if we're assuming some user
> exists who has been using sending money, unspent, to scripts with
> OP_CODESEPARATOR to force signatures to commit to whether some other
> signature was present and who won't see a (invariably media-covered)
> pending soft-fork in time to claim their funds, we should also assume such
> a user has pre-signed transactions which are time-locked and claim a number
> of inputs and have several paths in the script which contain
> OP_CODESEPARATOR, rendering their transcription invalid.
>

Agreed, that's why we will want to not simply count the OP_CODESEPARATORS,
but rather count the maximum number of OP_CODESEPARATORS that can be
executed through the any of the various possible OP_IF branches.  Adding
this sort of control-flow analysis is a pretty simple. It just requires a
small stack of pairs of numbers and linear traversal through the Script.
This sort of OP_IF control flow analysis ought to have been done for
counting CHECKSIG operations, but unfortunately it is too late for that
now.  I could prototype the sort of analysis I have in mind if you think
that would be helpful.

In fact, it is really alternating uses of OP_CODESEPARATOR and CheckSig
operations that is problematic, so it is probably worth attempting to count
these pairs rather than just OP_CODESEPARATORS.

[-- Attachment #2: Type: text/html, Size: 5502 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Hi Sjors,

On Fri, Mar 8, 2019 at 2:12 PM Sjors Provoost <sjors@sprovoost.nl> wrote:

> Transaction weight currently doesn't consider OP codes, it only considers
> if bytes are part of the witness. Changing that to something more akin to
> Ethereums gas pricing sounds too complicated to even consider.
>

I did say per executed OP_CODESEPARATOR, but upon reflection, I agree that
we'd like to know the weight without execution.  I think counting the
number of occurrences of OP_CODESEPARATOR (perhaps at the same time we
count OP_CHECKSIG operations?) is a reasonable compromise, and increasing
the weight according to my proposed formula based on that count (ideally
we'd take OP_IF branches into account).


> I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
>

I wish this were the case too, but I don't think it is reasonable to assume
that (even maaku isn't subscribed
<https://github.com/bitcoin/bitcoin/pull/15482#issuecomment-469836918>),
and I don't even think it is fair to assume such a someone necessarily even
speaks English.

[-- Attachment #2: Type: text/html, Size: 1666 bytes --]

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

I fear that we cannot simply wait 10 years to address the vulnerability
that OP_CODESEPARATOR has in its current form.

On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <
willtech@live.com.au> wrote:

> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
> ------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <
> bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 6:12 AM
> *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
>
> > (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.
> >
> >> 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.
>
> Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to
> nLockTime. Anything more specific than the above, e.g. counting the number
> of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers
> if bytes are part of the witness. Changing that to something more akin to
> Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
>
> Sjors
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4964 bytes --]

[bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

> * If the sighash type byte (ie last byte in a signature being evaluated
> during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY])
> is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
> execution fails. This does not apply to 0-length signature stack elements.
>

The sighash type byte is a "great" place to store a few bits of ancillary
data when making signatures.  Okay it isn't great, but it is good enough
that some misguided users may have been using it and have unbroadcast
transactions in cold storage (think sweeps) for UTXOs whose private keys
may have been lost.  I don't think that one's hunch that there isn't much
risk in disabling these sighashes is good enough to put people funds at
risk, especially given the alternative proposal of caching the
just-before-the-last-byte sighash midstate that is available.

-- 
Russell O'Connor

[-- Attachment #2: Type: text/html, Size: 1181 bytes --]

Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo]

I can't say I'm particularly married to this idea (hence the alternate 
proposal in the original email), but at the same time the lack of 
existing transactions using these bits (and the redundancy thereof - 
they don't *do* anything special) seems to be pretty strong indication 
that they are not in use. One could argue a similarity between these 
bits and OP_NOPs - no one is going to create transactions that require 
OP_NOP execution to be valid as they are precisely the kind of thing 
that may get soft-forked to have a new meaning. While the sighash bits 
are somewhat less candidates for soft-forking, I don't think "someone 
may have shoved random bits into parts of their 
locked-for-more-than-a-year transactions" is sufficient reason to not 
soft-fork something out. Obviously, actually *seeing* it used in 
practice or trying to fork them out in a fast manner would be 
unacceptable, but neither is being proposed here.

Matt

On 3/7/19 3:16 PM, Russell O'Connor wrote:
> 
>     * If the sighash type byte (ie last byte in a signature being evaluated
>     during the execution of OP_CHECKSIG[VERIFY] or
>     OP_CHECKMULTISIG[VERIFY])
>     is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
>     execution fails. This does not apply to 0-length signature stack
>     elements.
> 
> 
> The sighash type byte is a "great" place to store a few bits of 
> ancillary data when making signatures.  Okay it isn't great, but it is 
> good enough that some misguided users may have been using it and have 
> unbroadcast transactions in cold storage (think sweeps) for UTXOs whose 
> private keys may have been lost.  I don't think that one's hunch that 
> there isn't much risk in disabling these sighashes is good enough to put 
> people funds at risk, especially given the alternative proposal of 
> caching the just-before-the-last-byte sighash midstate that is available.

Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> I can't say I'm particularly married to this idea (hence the alternate
> proposal in the original email), but at the same time the lack of
> existing transactions using these bits (and the redundancy thereof -
> they don't *do* anything special) seems to be pretty strong indication
> that they are not in use. One could argue a similarity between these
> bits and OP_NOPs - no one is going to create transactions that require
> OP_NOP execution to be valid as they are precisely the kind of thing
> that may get soft-forked to have a new meaning. While the sighash bits
> are somewhat less candidates for soft-forking,


I don't think "somewhat less candidates for soft-forking" is a fair
description.  These bits essentially unsuitable for soft-forking within
legacy Script.

I don't think "someone
> may have shoved random bits into parts of their
> locked-for-more-than-a-year transactions" is sufficient reason to not
> soft-fork something out.


I disagree. It is sufficient.

When was the last time Bitcoin soft-forked out working transactions that
sent funds from securely held UTXOs to securely held UTXOs (aside from
those secured by Scripts using the reserved OP_NOP1-OP_NOP10)?  AFAIK it
has never occurred since the time of Satoshi, even for the most
hypothetical of transactions.  It is my understanding is that Bitcoin Core
would never do such a thing unless the security of Bitcoin protocol itself
was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
Core would only soft-fork out the minimal amount necessary to safely
diffuse such a threat.

Since the above soft-fork isn't addressing addressing any such threat (that
I'm aware of), and could hypothetically destroy other people money, it
crosses a line I thought we were never supposed to cross.

>
> Obviously, actually *seeing* it used in
> practice or trying to fork them out in a fast manner would be
> unacceptable, but neither is being proposed here.
>

Perhaps you don't see them in used in the blockchain because the users
trying to use them are caught up by the fact they they are not being
relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
difficulty redeeming them.
You cannot first make transactions non-standard and then use the fact that
you don't see them being used to justify a soft-fork.

I know of users who have their funds tied up due to other changes in
Bitcoin Core's default relay policy.  I believe they waiting for their
funds to become valuable enough to go through the trouble of having them
directly mined.  Shall we now permanently destroy their funds too, before
they have a chance to get their transactions mined?

[-- Attachment #2: Type: text/html, Size: 3656 bytes --]

Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 4666 bytes --]

Hi Matt,

(I moved your comment to this thread, where I think it is more relevant).

This is a fair point.  I concede that as far as Sighash Type Byte is
concerned, the type of change is fairly similar to BIP 68 (though I don't
think the argument applies to OP_CODESEPARATOR).
I might rephrase what you say as "invalidating otherwise-unusable bits of
the protocol".  I don't quite know the right phrasing that captures both
the insecure and redundant aspects of the protocol.  I'm willing to accept
that nSequence numbers (as they originally were), NOP1-NOP10 and these
extra sighash types can all be classified as redundant aspects of the
Bitcoin protocol.

I still think the alternative proposal of caching the sha256 midstate is
the better choice.  We should strive to avoid changing the consensus rules
when we have reasonable alternatives to achieve our goals. However, I now
see that this proposal isn't entirely unprecedented.

On Tue, Mar 12, 2019 at 5:08 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream.io>
> wrote:
> > 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).
>

On Fri, Mar 8, 2019 at 10:57 AM Russell O'Connor <roconnor@blockstream.io>
wrote:

> On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>
>> I can't say I'm particularly married to this idea (hence the alternate
>> proposal in the original email), but at the same time the lack of
>> existing transactions using these bits (and the redundancy thereof -
>> they don't *do* anything special) seems to be pretty strong indication
>> that they are not in use. One could argue a similarity between these
>> bits and OP_NOPs - no one is going to create transactions that require
>> OP_NOP execution to be valid as they are precisely the kind of thing
>> that may get soft-forked to have a new meaning. While the sighash bits
>> are somewhat less candidates for soft-forking,
>
>
> I don't think "somewhat less candidates for soft-forking" is a fair
> description.  These bits essentially unsuitable for soft-forking within
> legacy Script.
>
> I don't think "someone
>> may have shoved random bits into parts of their
>> locked-for-more-than-a-year transactions" is sufficient reason to not
>> soft-fork something out.
>
>
> I disagree. It is sufficient.
>
> When was the last time Bitcoin soft-forked out working transactions that
> sent funds from securely held UTXOs to securely held UTXOs (aside from
> those secured by Scripts using the reserved OP_NOP1-OP_NOP10)?  AFAIK it
> has never occurred since the time of Satoshi, even for the most
> hypothetical of transactions.  It is my understanding is that Bitcoin Core
> would never do such a thing unless the security of Bitcoin protocol itself
> was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
> Core would only soft-fork out the minimal amount necessary to safely
> diffuse such a threat.
>
> Since the above soft-fork isn't addressing addressing any such threat
> (that I'm aware of), and could hypothetically destroy other people money,
> it crosses a line I thought we were never supposed to cross.
>
>>
>> Obviously, actually *seeing* it used in
>> practice or trying to fork them out in a fast manner would be
>> unacceptable, but neither is being proposed here.
>>
>
> Perhaps you don't see them in used in the blockchain because the users
> trying to use them are caught up by the fact they they are not being
> relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
> difficulty redeeming them.
> You cannot first make transactions non-standard and then use the fact that
> you don't see them being used to justify a soft-fork.
>
> I know of users who have their funds tied up due to other changes in
> Bitcoin Core's default relay policy.  I believe they waiting for their
> funds to become valuable enough to go through the trouble of having them
> directly mined.  Shall we now permanently destroy their funds too, before
> they have a chance to get their transactions mined?
>
>

[-- Attachment #2: Type: text/html, Size: 6314 bytes --]