Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-09 📝 Original message:Hi Matt, On Fri, Mar 8, ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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

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

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