* [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
@ 2019-03-06 21:39 Matt Corallo
2019-03-07 10:44 ` Luke Dashjr
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Matt Corallo @ 2019-03-06 21:39 UTC (permalink / raw)
To: Bitcoin Protocol Discussion; +Cc: Luke Dashjr
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
2019-03-06 21:39 [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
@ 2019-03-07 10:44 ` Luke Dashjr
2019-03-07 19:44 ` Matt Corallo
2019-03-07 15:03 ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
2019-03-07 15:16 ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2 siblings, 1 reply; 29+ messages in thread
From: Luke Dashjr @ 2019-03-07 10:44 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
2019-03-07 10:44 ` Luke Dashjr
@ 2019-03-07 19:44 ` Matt Corallo
0 siblings, 0 replies; 29+ messages in thread
From: Matt Corallo @ 2019-03-07 19:44 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-06 21:39 [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 ` Luke Dashjr
@ 2019-03-07 15:03 ` Russell O'Connor
2019-03-07 19:50 ` Matt Corallo
2019-03-07 15:16 ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2 siblings, 1 reply; 29+ messages in thread
From: Russell O'Connor @ 2019-03-07 15:03 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 15:03 ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
@ 2019-03-07 19:50 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-08 19:12 ` Sjors Provoost
0 siblings, 2 replies; 29+ messages in thread
From: Matt Corallo @ 2019-03-07 19:50 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 19:50 ` Matt Corallo
@ 2019-03-08 15:57 ` Russell O'Connor
2019-03-08 18:35 ` Matt Corallo
2019-03-08 19:12 ` Sjors Provoost
1 sibling, 1 reply; 29+ messages in thread
From: Russell O'Connor @ 2019-03-08 15:57 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 15:57 ` Russell O'Connor
@ 2019-03-08 18:35 ` Matt Corallo
2019-03-09 18:29 ` Russell O'Connor
0 siblings, 1 reply; 29+ messages in thread
From: Matt Corallo @ 2019-03-08 18:35 UTC (permalink / raw)
To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion
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?!
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 18:35 ` Matt Corallo
@ 2019-03-09 18:29 ` Russell O'Connor
2019-03-10 3:25 ` Jacob Eliosoff
2019-03-12 21:08 ` Matt Corallo
0 siblings, 2 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-09 18:29 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-09 18:29 ` Russell O'Connor
@ 2019-03-10 3:25 ` Jacob Eliosoff
2019-03-11 17:49 ` Russell O'Connor
2019-03-12 21:08 ` Matt Corallo
1 sibling, 1 reply; 29+ messages in thread
From: Jacob Eliosoff @ 2019-03-10 3:25 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 3:25 ` Jacob Eliosoff
@ 2019-03-11 17:49 ` Russell O'Connor
0 siblings, 0 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-11 17:49 UTC (permalink / raw)
To: Jacob Eliosoff; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-09 18:29 ` Russell O'Connor
2019-03-10 3:25 ` Jacob Eliosoff
@ 2019-03-12 21:08 ` Matt Corallo
2019-03-12 22:39 ` Jacob Eliosoff
1 sibling, 1 reply; 29+ messages in thread
From: Matt Corallo @ 2019-03-12 21:08 UTC (permalink / raw)
To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion
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).
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 21:08 ` Matt Corallo
@ 2019-03-12 22:39 ` Jacob Eliosoff
2019-03-13 0:54 ` Gregory Maxwell
2019-03-13 1:34 ` Russell O'Connor
0 siblings, 2 replies; 29+ messages in thread
From: Jacob Eliosoff @ 2019-03-12 22:39 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 22:39 ` Jacob Eliosoff
@ 2019-03-13 0:54 ` Gregory Maxwell
2019-03-13 1:34 ` Russell O'Connor
1 sibling, 0 replies; 29+ messages in thread
From: Gregory Maxwell @ 2019-03-13 0:54 UTC (permalink / raw)
To: Jacob Eliosoff, Bitcoin Protocol Discussion
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 22:39 ` Jacob Eliosoff
2019-03-13 0:54 ` Gregory Maxwell
@ 2019-03-13 1:34 ` Russell O'Connor
1 sibling, 0 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-13 1:34 UTC (permalink / raw)
To: Jacob Eliosoff; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 19:50 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
@ 2019-03-08 19:12 ` Sjors Provoost
2019-03-08 20:14 ` Matt Corallo
` (2 more replies)
1 sibling, 3 replies; 29+ messages in thread
From: Sjors Provoost @ 2019-03-08 19:12 UTC (permalink / raw)
To: Matt Corallo, Russell O'Connor, Bitcoin Protocol Discussion
> (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
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 19:12 ` Sjors Provoost
@ 2019-03-08 20:14 ` Matt Corallo
2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-09 18:29 ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2 siblings, 1 reply; 29+ messages in thread
From: Matt Corallo @ 2019-03-08 20:14 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Protocol Discussion
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 20:14 ` Matt Corallo
@ 2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 ` Moral Agent
2019-03-10 18:28 ` Dustin Dettmer
0 siblings, 2 replies; 29+ messages in thread
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-03-10 14:25 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
@ 2019-03-10 18:24 ` Moral Agent
2019-03-12 7:34 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:28 ` Dustin Dettmer
1 sibling, 1 reply; 29+ messages in thread
From: Moral Agent @ 2019-03-10 18:24 UTC (permalink / raw)
To: LORD HIS EXCELLENCY JAMES HRMH, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 18:24 ` Moral Agent
@ 2019-03-12 7:34 ` LORD HIS EXCELLENCY JAMES HRMH
0 siblings, 0 replies; 29+ messages in thread
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-03-12 7:34 UTC (permalink / raw)
To: Moral Agent, Bitcoin Protocol Discussion, Moral Agent
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 ` Moral Agent
@ 2019-03-10 18:28 ` Dustin Dettmer
2019-03-11 19:15 ` Russell O'Connor
1 sibling, 1 reply; 29+ messages in thread
From: Dustin Dettmer @ 2019-03-10 18:28 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 18:28 ` Dustin Dettmer
@ 2019-03-11 19:15 ` Russell O'Connor
2019-03-12 2:23 ` Matt Corallo
0 siblings, 1 reply; 29+ messages in thread
From: Russell O'Connor @ 2019-03-11 19:15 UTC (permalink / raw)
To: Dustin Dettmer, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-11 19:15 ` Russell O'Connor
@ 2019-03-12 2:23 ` Matt Corallo
2019-03-13 1:38 ` Russell O'Connor
0 siblings, 1 reply; 29+ messages in thread
From: Matt Corallo @ 2019-03-12 2:23 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 2:23 ` Matt Corallo
@ 2019-03-13 1:38 ` Russell O'Connor
0 siblings, 0 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-13 1:38 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 19:12 ` Sjors Provoost
2019-03-08 20:14 ` Matt Corallo
@ 2019-03-09 18:29 ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2 siblings, 0 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-09 18:29 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread[parent not found: <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
@ 2019-03-10 15:22 ` Russell O'Connor
0 siblings, 0 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-10 15:22 UTC (permalink / raw)
To: LORD HIS EXCELLENCY JAMES HRMH; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-06 21:39 [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 ` Luke Dashjr
2019-03-07 15:03 ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
@ 2019-03-07 15:16 ` Russell O'Connor
2019-03-07 19:57 ` Matt Corallo
2 siblings, 1 reply; 29+ messages in thread
From: Russell O'Connor @ 2019-03-07 15:16 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 15:16 ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
@ 2019-03-07 19:57 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
0 siblings, 1 reply; 29+ messages in thread
From: Matt Corallo @ 2019-03-07 19:57 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 19:57 ` Matt Corallo
@ 2019-03-08 15:57 ` Russell O'Connor
2019-03-13 1:34 ` Russell O'Connor
0 siblings, 1 reply; 29+ messages in thread
From: Russell O'Connor @ 2019-03-08 15:57 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 15:57 ` Russell O'Connor
@ 2019-03-13 1:34 ` Russell O'Connor
0 siblings, 0 replies; 29+ messages in thread
From: Russell O'Connor @ 2019-03-13 1:34 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2019-03-13 1:38 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-06 21:39 [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 ` Luke Dashjr
2019-03-07 19:44 ` Matt Corallo
2019-03-07 15:03 ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
2019-03-07 19:50 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-08 18:35 ` Matt Corallo
2019-03-09 18:29 ` Russell O'Connor
2019-03-10 3:25 ` Jacob Eliosoff
2019-03-11 17:49 ` Russell O'Connor
2019-03-12 21:08 ` Matt Corallo
2019-03-12 22:39 ` Jacob Eliosoff
2019-03-13 0:54 ` Gregory Maxwell
2019-03-13 1:34 ` Russell O'Connor
2019-03-08 19:12 ` Sjors Provoost
2019-03-08 20:14 ` Matt Corallo
2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 ` Moral Agent
2019-03-12 7:34 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:28 ` Dustin Dettmer
2019-03-11 19:15 ` Russell O'Connor
2019-03-12 2:23 ` Matt Corallo
2019-03-13 1:38 ` Russell O'Connor
2019-03-09 18:29 ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2019-03-10 15:22 ` Russell O'Connor
2019-03-07 15:16 ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2019-03-07 19:57 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-13 1:34 ` Russell O'Connor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox