Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

yes, log2work is already computed and would be a strictly increasing value, 
like time. Thank you for this suggestion. I think attempting an implementation 
will give further clues it this more suitable to express the same.

Tamas Blummer

> On May 24, 2019, at 10:36, Natanael  wrote:
> 
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev 
>  > wrote:
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
> 
> To deal with potentially wildly varying difficulty, could the value exposed 
> be the sum of accumulated PoW, or in other words the sum of each block's 
> difficulty value in the entire chain? This should be a value that will only 
> rise unless a reorg happens after a difficulty drop happens (only likely to 
> be the result of users manually blacklisting an otherwise valid block that is 
> several blocks back in the chain).
> 
> This mimics the effect of the block number which only grows. So if you're 
> starting at time A with difficulty X, then you'd estimate what you think the 
> accumulated PoW ought to be at time B with expected difficulty Y (as compared 
> to the current value at time A), and put that value into the script.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

On Wed, May 22, 2019 at 5:01 PM Russell O'Connor 
wrote:

> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
>

Jonas informs me that I've misunderstood how discreet log contracts work.
The DLC signatures are not directly checked by Script and do not rely on
CHECKSIGFROMSTACK.  I apologize for my hasty literature review.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Natanael via bitcoin-dev]

On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.


To deal with potentially wildly varying difficulty, could the value exposed
be the sum of accumulated PoW, or in other words the sum of each block's
difficulty value in the entire chain? This should be a value that will only
rise unless a reorg happens after a difficulty drop happens (only likely to
be the result of users manually blacklisting an otherwise valid block that
is several blocks back in the chain).

This mimics the effect of the block number which only grows. So if you're
starting at time A with difficulty X, then you'd estimate what you think
the accumulated PoW ought to be at time B with expected difficulty Y (as
compared to the current value at time A), and put that value into the
script.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Johnson Lau via bitcoin-dev]

A gamble like this, decentralised or not, is easy to manipulate since 
difficulty is determined entirely by the last block in a cycle

> On 24 May 2019, at 1:42 AM, Tamas Blummer via bitcoin-dev 
>  wrote:
> 
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
> 
> I think we could do much better than them natively within Bitcoin.
> 
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into. 
> The output script may then decide comparing that value with a strike which 
> key can spend it. 
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet. 
> The winner would broadcast. 
> 
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
> 
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
> 
> Do you see a fault in this proposal or want to contribute?
> 
> Tamas Blummer 
> 
> ___
> 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

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[ZmnSCPxj via bitcoin-dev]

> For better or for worse, without an OP_PUBKEYTWEEK operation available, the 
> more interesting recursive-covenants remain largely out of reach, with the 
> exception of a recursive covenant that is only able to send back to its own 
> address, possibly abusing its own TXO value as a state variable.

After some thinking, I may have devised a way to achieve the more interesting 
Turing-complete system (where each "loop through" requires paying a fee to 
miners, akin to Ethereum Gas, and thus a good way to build new footguns) even 
without `OP_PUBKEYTWEAK`.

I observe the following:

1.  `OP_CHECKSIGFROMSTACK` can introspect into the transaction *doing the 
spend* by giving the transaction (minus witness) as part of the witness (i.e. 
quining).
2.  The above can be leveraged to introspect into the transaction *being spent* 
by giving that transaction *being spent* (minus witness) as part of the witness 
stack.
This is because the transaction *doing the spend* commits to the 
transaction *being spent* by referring to its txid.
We can concatenate the bits of the previous transaction and confirm that it 
is indeed the transaction *being spent* by hashing and comparing that to the 
txid in the input of the transaction *doing the spend*.
3.  The transaction *being spent* can contain an `OP_RETURN` output that 
contains the previous state (or a commitment to the previous state if it is too 
large to fit in an `OP_RETURN`, again requiring that the previous state be 
given as part of the witness).
Since it can be introspected, a script can acquire a "previous state" data.
4.  The transaction *doing the spend* can also contain an `OP_RETURN` with the 
next state (or commitment to next state).
5.  The rest of the script can then determine if the transition from "previous 
state" to "next state" is valid.
6.  The script can impose that the same script is paid to by introspecting the 
transaction *being spent* to get at a commitment to itself.

The above seems enough to create a potentially unbound loop, bound only by the 
amount of money you are willing to spend on fees operating that loop.
The "state" would be the memory of your virtual machine, and the SCRIPT 
validates the execution of one iteration of the interpreter loop, and that 
would be enough to create a Turing-complete system within Bitcoin.
With MAST, you can compress branches not taken, reducing the number of 
operations you have to expose at each iteration.

I admit *creating* this by hand will probably be very difficult, but that 
should be doable with an army of lower-level cognition agents.
(disclaimer: I am not an AI with an army of lower-level cognition agents and I 
can completely and totally pass the Turing test)


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[ZmnSCPxj via bitcoin-dev]

Good morning Jimmy,

‐‐‐ Original Message ‐‐‐
On Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev 
 wrote:

> Hi Russell,
>
> This is probably a dumb question, but I'd like to get some clarity on your 
> proposal.
>
> OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey. 
> Presumably, the message would then have to get constructed as part of the 
> Script execution. What would such a message look like? What, in other words, 
> would you be signing and would that be similar to what signatures sign now? 
> Would it be a single blob that incorporates all the input/output information 
> in some hashed manner (like BIP143)? Or would you need separate signatures 
> for different parts of the transaction? Or is it something more complicated 
> like aggregating multiple signatures over different parts of the transaction?

In order to use `OP_CHECKSIGFROMSTACK` work to allow transaction introspection, 
the message to be signed would be the equivalent of the sighash digest using 
`SIGHASH_ALL`.

As a general pattern, if you want a SCRIPT that imposes some rule on some field 
in the sighash digest of the transaction:

1.  You would require that the transaction be split into three parts, with 
those parts provided in the witness stack.
One would be "data before the field", then "the field", then "data after 
the field".
2.  In addition, you would require a signature for the transaction in addition 
to the transaction parts above.
3.  You would ensure that "data before the field" is the correct size, so that 
you know "the field" is at the correct location in the transaction.
Alternately you might need to also introspect some other fields in order to 
ensure other details like number of inputs, number of outputs, value of inputs 
etc. etc. are what you expect.
4.  You would check that the given signature is `SIGHASH_ALL` (most easily by 
checking its size --- proposed Schnorr signatures have a fixed size, and the 
lack of an extra sighash flags byte means `SIGHASH_ALL` by default, so if the 
signature is exactly the fixed Schnorr signature size, it is `SIGHASH_ALL`).
5.  You would use normal `OP_CHECKSIGVERIFY` to ensure that the signature signs 
the actual transaction.
6.  You would concatenate the supposed parts of the transaction together and 
use `OP_CHECKSIGFROMSTACKVERIFY` to ensure that the signature *also* is valid 
for that.
Since you know the signature is valid for the transaction itself, if it 
*also* is valid for this, then the concatenation of the input "data before the 
field", "the field", and "data after the field" is exactly the same sighash 
digest as the actual transaction, and thus is accurate to the transaction.
7.  Finally, you would actually validate the field you want to impose some rule 
on.

`SIGHASH_ALL` is suggested since it allows you to introspect all fields, but 
also because ensuring that the signature is indeed a `SIGHASH_ALL` signature is 
easier (just do the size check).
Alternately you can use some other flag, but you would require the signature on 
the stack to be flagless and concat the flag yourself before using 
`OP_CHECKSIGVERIFY`.

This mechanism is very general and allows SCRIPT to introspect *any* field of 
the transactions.
Indeed, one can argue that `OP_CHECKLOCKTIMEVERIFY` and 
`OP_CHECKSEQUENCEVERIFY` are both superfluous in a system with `OP_CAT` and 
`OP_CHECKSIGFROMSTACK`.
OF course, these operations are significantly more optimized since they do not 
require that you quine the transaction.

Regards,
ZmnSCPxj


>
> Best,
>
> Jimmy
>
> On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev 
>  wrote:
>
> > Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and 
> > OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for 
> > Bitcoin via new Script operations.  However, I think that these proposals 
> > miss the mark when it comes to how they approach Bitcoin Script and 
> > language features.
> >
> > Bitcoin Script appears designed to be a flexible programmable system that 
> > provides generic features to be composed to achieve various purposes.  
> > Thus, when we design new language features for Script, we should be 
> > striving, as much as possible, to similarly build general purpose tools 
> > which can in turn be used for a variety of purposes.
> >
> > I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail 
> > to achieve these design goals.  They are both are designed with very narrow 
> > applications in mind, while also going out of their way to extend the 
> > semantic domain of the interpretation of Bitcoin operations in new ways 
> > that complicate their specification.  In the case of SIGHASH_ANYPREVOUT, 
> > the semantic domain is extended by adding new counters to track the use of 
> > various v0 and v2 signature types.  In the case of 
> > OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that 
> > peeks at the value of 

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

Hello ZmnSCPxj,

I agree that adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts
such as `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree
we ought to support such operations directly, especially if we see
widespread use of these constructions in practice.

I think it is desirable to add OP_CHECKSIGFROMSTACK for its direct purposes
of enabling oracle verification and discreet log contracts.  Moreover, it
would be better decide if we do or do not want to do this first, because
whether or not we chose to implement a general OP_CHECKSIGFROMSTACK will
influence the design of these other proposals.

For example, if we choose to deploy OP_CHECKSIGFROMSTACK, then the design
of OP_CHECKOUTPUTSHASHVERIFY ought to be simplified to OP_PUSHOUTPUTHASH
and OP_PUSHNUMINPUTS (etc.) because the proposal would no longer be
extending the expressiveness of Bitcoin Script.  And while
OP_CHECKSIGFROMSTACK doesn't directly address whether SIGHASH_ANYPREVOUT
should be with or without a chaperone (as the simulated version with
OP_CHECKSIGFROMSTACK is necessarily chaperoned), we might get an
opportunity to learn if users are willing to take advantage of the
chaperone, or whether they rather bypass it by using a short well-known
pubkey: (e.g.
0x02003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63)
and/or similar short signatures if we deploy OP_CHECKSIGFROMSTACK first.

Since most of the "scary" recursive convents are not available with
OP_CHECKSIGFROMSTACK within taproot (without further extensions), the
OP_CHECKSIGFROMSTACK proposal now has quite different consequences than
before.

On Thu, May 23, 2019 at 12:59 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> While I am sympathetic to this argument from first principles, as I
> understand it, it requires that provided witness inputs will become larger,
> compared to "shortcuts" like `SIGHASH_ANYPREVOUT` and
> `OP_CHECKOUTPUTSHASHVERIFY`.
>
> For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and
> `OP_CHECKSIGFROMSTACK`, I would effectively split the unsigned transaction
> into its "inputs" and "outputs" part, concat them and use
> `OP_CHECKSIGFROMSTACK` on the chaperone signature, and also use a normal
> `OP_CHECKSIGVERIFY` on that same chaperone signature, then dup the
> "outputs" part and use `OP_CHECKSIGFROMSTACK` on the "any
> prevout"/"noinput" signature.
> I would effectively give the transaction to itself as part of the witness,
> and further, I would also have to very carefully write the script
> (admittedly the writing of the template could be done once, but it would
> require far more review than simple usages of the "limited" operations like
> `SIGHASH_ANYPREVOUT`).
> So my witness stack would contain two signatures, and a duplicate of the
> transaction itself, plus a very much complicated script, whereas use of
> `SIGHASH_ANYPREVOUT` just requires two signatures and a script not much
> longer than pre-Schnorr multisig scripts.
>
>
> It seems to me desirable, to try to reduce bandwidth consumption on the
> Bitcoin blockchain, including witness data.
> Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK`
> in a federated sidechain (Elements/Liquid) was to try to identify common
> patterns of usage for that opcode, and *then* to propose those common
> patterns as specific "optimized" opcodes as a sort of "jet" for Bitcoin
> itself (but not `OP_CHECKSIGFROMSTACK` itself).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

Hi Jimmy,

The message could really be anything.  For example, in discreet log
contracts, AFAIU, you might have a specific public key from a trusted third
party (the Oracle) that is signs the closing price of corn in BTC on
2019-05-23 with a particular nonce dedicated to that product-date pair, in
which case the message would be the price expressed in binary.  In the case
of amortized secure multiparty computations, the message is protocol
specific binary data that consists of a counter (or counters), concatenated
with shares of secret data that is used to construct the result of the
multiparty computation.  In the case of transaction reflection, the message
would be a duplicate copy of the tapscript signed transaction data (about
244 bytes of data plus a 64 byte prefix).

As you note, the message is likely to constructed from a value computed
from a mix of witness and committed data, though the message might be pure
witness data, as in the discreet log contract example.  In that the
discreet log contract example, you'd probably duplicate the integer value
and do further processing (e.g. compare it to some other committed value).

On Thu, May 23, 2019 at 1:36 PM Jimmy Song  wrote:

> Hi Russell,
>
> This is probably a dumb question, but I'd like to get some clarity on your
> proposal.
>
> OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.
> Presumably, the message would then have to get constructed as part of the
> Script execution. What would such a message look like? What, in other
> words, would you be signing and would that be similar to what signatures
> sign now? Would it be a single blob that incorporates all the input/output
> information in some hashed manner (like BIP143)? Or would you need separate
> signatures for different parts of the transaction? Or is it something more
> complicated like aggregating multiple signatures over different parts of
> the transaction?
>
> Best,
>
> Jimmy
>
> On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and
>> OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for
>> Bitcoin via new Script operations.  However, I think that these proposals
>> miss the mark when it comes to how they approach Bitcoin Script and
>> language features.
>>
>> Bitcoin Script appears designed to be a flexible programmable system that
>> provides generic features to be composed to achieve various purposes.
>> Thus, when we design new language features for Script, we should be
>> striving, as much as possible, to similarly build general purpose tools
>> which can in turn be used for a variety of purposes.
>>
>> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail
>> to achieve these design goals.  They are both are designed with very narrow
>> applications in mind, while also going out of their way to extend the
>> semantic domain of the interpretation of Bitcoin operations in new ways
>> that complicate their specification.  In the case of SIGHASH_ANYPREVOUT,
>> the semantic domain is extended by adding new counters to track the use of
>> various v0 and v2 signature types.  In the case of
>> OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that
>> peeks at the value of surrounding opcodes.
>>
>> Instead, I propose that, for the time being, we simply implement OP_CAT
>> and OP_CHECKSIGFROMSTACKVERIFY.  OP_CAT pops two byte arrays off the stack
>> and pushes their concatenation back onto the stack.
>> OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the
>> stack and performs a bip-schnorr verification on the SHA256 hash of the
>> message.
>>
>> In concert, these two operations enable:
>>
>> * Oracle signature verification, including discrete log contracts.
>> * Amortized secure multiparty computations (see "Amortizing Secure
>> Computation with Penalties" by Kumaresan and Bentov).
>> * Transaction introspection including:
>> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply
>> by the nature of the construction.
>> + Decide if a transaction has exactly one input or not. (etc.)
>> + Weak covenants, which can verify output scripts to see if they are
>> among a set of predefined values or verify the output hash.
>>
>> and presumably more applications as well.
>>
>> For better or for worse, without an OP_PUBKEYTWEEK operation available,
>> the more interesting recursive-covenants remain largely out of reach, with
>> the exception of a recursive covenant that is only able to send back to its
>> own address, possibly abusing its own TXO value as a state variable.
>>
>> All this is accomplished by two straightforward opcodes whose semantics
>> are pure computational operations on stack values.  The only semantic
>> side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the
>> existing 'sigops_passed' count.  Moreover, I fe

[bitcoin-dev] Safety of committing only to transaction outputs

[Johnson Lau via bitcoin-dev]

This is a meta-discussion for any approach that allows the witness committing 
to only transaction outputs, but not inputs.

We can already do the following things with the existing bitcoin script system:
* commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with 
optional SIGHASH_ANYONECANPAY
* commit to only inputs but not outputs: SIGHASH_NONE with optional 
SIGHASH_ANYONECANPAY
* not commit to any input nor output: not using any sigop; using a trivial 
private key; using the SIGHASH_SINGLE bug in legacy script

The last one is clearly unsafe as any relay/mining node may redirect the 
payment to any output it chooses. The witness/scriptSig is also replayable, so 
any future payment to this script will likely be swept immediately

SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but the 
signature is not replayable

But it’s quite obvious that not committing to outputs are inherently insecure

The existing system doesn’t allow committing only to outputs, and we now have 3 
active proposals for this function:

1. CAT and CHECKSIGFROMSTACK (CSFS): 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.html 

2. ANYPREVOUT (aka NOINPUT): 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.html 

3. CHECKOUTPUTSHASHVERIFY (COHV): 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html 


With outputs committed, redirecting payment is not possible. On the other hand, 
not committing to any input means the witness is replayable without the consent 
of address owner. Whether replayability is acceptable is subject to 
controversy, but the ANYPREVOUT proposal fixes this by requiring a chaperone 
signature that commits to input. However, if the rationale for chaperone 
signature stands, it should be applicable to all proposals listed above.

A more generic approach is to always require a “safe" signature that commits to 
at least one input. However, this interacts poorly with the "unknown public key 
type” upgrade path described in bip-tapscript 
(https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki 
), since 
it’d be a hardfork to turn an “unknown type sig” into a “safe sig”. But we 
could still use a new “leaf version” every time we introduce new sighash types, 
so we could have a new definition for “safe sig”. I expect this would be a rare 
event and it won’t consume more than a couple leaf versions. By the way, 
customised sighash policies could be done with CAT/CSFS.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev