Interesting point.
The script is under your control, so you should be able to ensure that you
are always using a correctly constructed midstate, e.g., something like:
scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2>
OP_SHA256STREAM
OP_EQUALVERIFY
would hash all the elements on the
On Sun, Oct 06, 2019 at 08:46:59AM +, ZmnSCPxj wrote:
> > Obviously with care you can get the computation right. But at that point
> > what's
> > the actual advantage over OP_CAT?
> >
> > We're limited by the size of the script anyway; if the OP_CAT output size
> > limit
> > is comparable to
Good morning Peter, Jeremy, and lists,
> On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote:
>
> > Interesting point.
> > The script is under your control, so you should be able to ensure that you
> > are always using a correctly constructed midstate, e.g., something like:
> > scriptPubKey:
On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote:
> Interesting point.
>
> The script is under your control, so you should be able to ensure that you
> are always using a correctly constructed midstate, e.g., something like:
>
> scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2>
On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:
> Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
> function to allow concatenation of an unlimited amount of data, provided
> the only
