[bitcoin-dev] PSA: Upcoming disclosure of pre-v0.17.1 vulnerabilities

[Luke Dashjr via bitcoin-dev]

Two relatively minor vulnerabilities will likely be disclosed sometime soon.

The first vulnerability, CVE-2017-18350, was introduced in v0.7.0 (released in 
2012 September), and affects all versions released until the fix was included 
in v0.15.1 (released in 2017 November). No versions prior to v0.15.1 are 
expected to be fixed.

The second vulnerability, CVE-2018-20586, was introduced in v0.12.0 (released 
in 2016 February), and affects all versions released until the fix was 
included in v0.17.1 (released in 2018 December). As of today, this fix has 
NOT been backported to older versions. When/if v0.15.3 and v0.16.4 are 
released, they may also include a fix, but due to the minor severity of this 
vulnerability, it does not merit a dedicated release on its own. (The git 
branches are also NOT fixed at this time.)

Please be sure you have upgraded to a fixed version no later than August 1st.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[ZmnSCPxj via bitcoin-dev]

Good morning Jeremy,

While `OP_SECURETHEBAG` commits to the desired output script of the spending 
TX, what is being referred to here is the ability to verify the output script 
being spent, i.e. the script that actually contains the `OP_SECURETHEBAG`.
By this, we are able to create a contract that ensures that it is paid again 
(covenants), which in combination with a little more introspection of TX data, 
allows us to verify the execution of steps of a Turing-complete program.

It is surprisingly easy to make a language inadvertently Turing-complete, which 
is basically the argument here,
That is, with just a little more power and some additional operations that 
would appear reasonable to add by themselves (`OP_CAT`, `OP_LEFT`, 
`OP_TWEAKPUBKEY`) on top of some form of requiring a particular output script, 
it is possible to validate the execution of Turing-complete programs on the 
Bitcoin blockchain.

Thus, with quining (a script which gets the text of its own code as part of the 
static data it has), `OP_TWEAKPUBKEY`, and a `OP_SECURETHEBAG` that gets its 
argument from the stack, it will be possible to make Turing-complete Bitcoin 
SCRIPT.

I would mildly suggest that we might very well want to consider creating a 
well-designed way of injecting Turing-completeness into Bitcoin SCRIPT 
(requiring it to be behind a Taproot, so that bugs in Turing-complete code at 
least have a chance to be bugfixed by agreement of the Taproot signing set) 
since we might eventually find ourselves introducing it inadvertently later in 
any case.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, June 23, 2019 6:41 AM, Jeremy Rubin  wrote:

> Can you clarify this comment?
>
> We do in fact commit to the script and scriptsig itself (not the witness 
> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>
> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev 
>  wrote:
>
> > Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of 
> > covenants if it pulled data from the stack, the OP_SECURETHEBAG probably 
> > cannot create covenants even if it were to pull the data from the stack 
> > unless some OP_TWEEKPUBKEY operation is added to Script because the 
> > "commitment of the script itself" isn't part of the OP_SECURETHEBAG.
> >
> > So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason 
> > to complicate the spec to ensure the digest is precommitted as part of the 
> > opcode."
> >
> > On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev 
> >  wrote:
> >
> > > Good morning aj,
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev 
> > >  wrote:
> > >
> > > > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:
> > > >
> > > > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> > > >
> > > > I think you could generalise that slightly and make it fit in
> > > > with the existing opcode naming by calling it something like
> > > > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
> > > > consisting of a sha256 hash and a sighash-byte, and adding a new sighash
> > > > value corresponding to the set of info you want to include in the hash,
> > > > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | 
> > > > SIGHASH_ALL"
> > > >
> > > > FWIW, I'm not really seeing any reason to complicate the spec to ensure
> > > > the digest is precommitted as part of the opcode.
> > > >
> > >
> > > I believe in combination with `OP_LEFT` and `OP_CAT` this allows 
> > > Turing-complete smart contracts, in much the same way as 
> > > `OP_CHECKSIGFROMSTACK`?
> > >
> > > Pass in the spent transaction (serialised for txid) and the spending 
> > > transaction (serialised for sighash) as part of the witness of the 
> > > spending transaction.
> > >
> > > Script verifies that the spending transaction witness value is indeed the 
> > > spending transaction by `OP_SHA256  OP_SWAP OP_CAT 
> > > OP_CHECKTXDIGESTVERIFY`.
> > > Script verifies the spent transaction witness value is indeed the spent 
> > > transaction by hashing it, then splitting up the hash with `OP_LEFT` into 
> > > bytes, and comparing the bytes to the bytes in the input of the spending 
> > > transaction witness value (txid being the bytes in reversed order).
> > >
> > > Then the Script can extract a commitment of itself by extracting the 
> > > output of the spent transaction.
> > > This lets the Script check that the spending transaction also pays to the 
> > > same script.
> > >
> > > The Script can then access a state value, for example from an `OP_RETURN` 
> > > output of the spent transaction, and enforce that a correct next-state is 
> > > used in the spending transaction.
> > > If the state is too large to fit in a standard `OP_RETURN`, then the 
> > > current state can be passed in as a 

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Jeremy via bitcoin-dev]

This is insufficient: sequences must be committed to because they affect
TXID. As with scriptsigs (witness data fine to ignore). NUM_IN too.

Any malleability makes this much less useful.
--
@JeremyRubin 



On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:
> > So with regards to OP_SECURETHEBAG, I am also "not really seeing any
> reason to
> > complicate the spec to ensure the digest is precommitted as part of the
> > opcode."
>
> Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
> (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if
> it's been spelled out anywhere); ie instead of constructing
>
>   X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in )
>
> and having the script be " OP_SECURETHEBAG" you calculate an
> ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:
>
>   Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
>amount, sequence)
>
> and calculate a signature sig = Schnorr(P,m) for some pubkey P, and
> make your script be "  CHECKSIG".
>
> That loses the ability to commit to the number of inputs or restrict
> the nsequence of other inputs, and requires a bigger script (sig and P
> are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the
> same as far as I can tell. Both scripts are automatically satisfied when
> revealed (with the correct set of outputs), and don't need any additional
> witness data.
>
> If you wanted to construct "X" via script instead of hardcoding a value
> because it got you generalised covenants or whatever; I think you could
> get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much
> the same way you construct X, but you'd then need to turn that into a
> signature. You could do so by using pubkey P=G and nonce R=G, which
> means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash
> part is easy, multiplying it by 1 is easy, and to add 1 you can probably
> do something along the lines of:
>
> OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT
>
> (ie, take the last 4 bytes, increment it using 4-byte arithmetic,
> then cat the first 28 bytes and the result. There's overflow issues,
> but I think they can be worked around either by allowing you to choose
> different locktimes, or by more complicated script)
>
> Cheers,
> aj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev