From: "Russell O'Connor" <roconnor@blockstream•io>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
Date: Fri, 8 Mar 2019 10:57:14 -0500 [thread overview]
Message-ID: <CAMZUoKnrUENVwSLJd6HEprqrjmU_Em5LFL4o+UW1-nOBKADVUw@mail.gmail.com> (raw)
In-Reply-To: <eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com>
[-- 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 --]
next prev parent reply other threads:[~2019-03-08 15:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 21:39 [bitcoin-dev] " 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 [this message]
2019-03-13 1:34 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMZUoKnrUENVwSLJd6HEprqrjmU_Em5LFL4o+UW1-nOBKADVUw@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox