From: Jeremy <jlrubin@mit•edu>
To: Billy <fresheneesz@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] op_checktemplateverify and number of inputs
Date: Sun, 26 Jan 2020 09:23:57 -0800 [thread overview]
Message-ID: <CAD5xwhg9848ptvGS-tct4Ofpcucef3Qi9XhDQEYzEpM+-ydZMw@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDYYYYEeuQVL6d97_OwN_f8ektdqv-5zXVT9fEqiS6qtoQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
Hi Billy,
Restricting the number of inputs is necessary to preclude TXID
malleability. Committing to all of the information required necessitates
that the number of inputs be committed.
This allows us to build non-interactive layer 2 protocols which depend on
TXID non-malleability (most of them at writing).
You raise a good point that allowing *any number* of inputs is an
interesting case, which I had discussed offline with a few different
people. I think the conclusion was that that flexibility is better left
outside of the OP directly.
If you want an any number of inputs template, and we enable something like
OP_CAT (e.g., OP_CAT, OP_SHA256STREAM) then you can spend to something like:
<hash data before # inputs> OP_SWAP OP_CAT OP_SWAP OP_CAT <data post #
inputs> OP_CAT OP_SHA256 OP_CTV
And then pass in the # of inputs and sequences hash as arguments to the
function.
I can respond separately to your bitcointalk post as you ask a different
set of questions there.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Jan 26, 2020 at 8:59 AM Billy via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I have a question about op_ctv related to the requirement to specify the
> number of inputs. I don't quite see why its necessary, but most
> importantly, I don't see why we want to *require* the user of the op to
> specify the number of inputs, tho I see the reasoning why one would want to
> specify it. If the op allowed both cases (specifying a number of inputs and
> allowing any number), it seems like the best of both worlds. I started a
> discussion on bitcointalk.org:
>
> https://bitcointalk.org/index.php?topic=5220520
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4876 bytes --]
prev parent reply other threads:[~2020-01-26 17:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-25 1:50 Billy
2020-01-26 17:23 ` Jeremy [this message]
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=CAD5xwhg9848ptvGS-tct4Ofpcucef3Qi9XhDQEYzEpM+-ydZMw@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=fresheneesz@gmail$(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