public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] op_checktemplateverify and number of inputs
@ 2020-01-25  1:50 Billy
  2020-01-26 17:23 ` Jeremy
  0 siblings, 1 reply; 2+ messages in thread
From: Billy @ 2020-01-25  1:50 UTC (permalink / raw)
  To: bitcoin-dev

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

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

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [bitcoin-dev] op_checktemplateverify and number of inputs
  2020-01-25  1:50 [bitcoin-dev] op_checktemplateverify and number of inputs Billy
@ 2020-01-26 17:23 ` Jeremy
  0 siblings, 0 replies; 2+ messages in thread
From: Jeremy @ 2020-01-26 17:23 UTC (permalink / raw)
  To: Billy, Bitcoin Protocol Discussion

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-01-26 17:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-25  1:50 [bitcoin-dev] op_checktemplateverify and number of inputs Billy
2020-01-26 17:23 ` Jeremy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox