[bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy]

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

Hello bitcoin-devs,

Below is a link to a BIP Draft for a new opcode, OP_CHECKOUTPUTSHASHVERIFY.
This opcode enables an easy-to-use trustless congestion control techniques
via a rudimentary, limited form of covenant which does not bear the same
technical and social risks of prior covenant designs.

Congestion control allows Bitcoin users to confirm payments to many users
in a single transaction without creating the UTXO on-chain until a later
time. This therefore improves the throughput of confirmed payments, at the
expense of latency on spendability and increased average block space
utilization. The BIP covers this use case in detail, and a few other use
cases lightly.

The BIP draft is here:
https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki

The BIP proposes to deploy the change simultaneously with Taproot as an
OPSUCCESS, but it could be deployed separately if needed.

An initial reference implementation of the consensus changes and  tests
which demonstrate how to use it for basic congestion control is available
at https://github.com/JeremyRubin/bitcoin/tree/congestion-control.  The
changes are about 74 lines of code on top of sipa's Taproot reference
implementation.

Best regards,

Jeremy Rubin

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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Matt Corallo]

If we're going to do covenants (and I think we should), then I think we
need to have a flexible solution that provides more features than just
this, or we risk adding it only to go through all the effort again when
people ask for a better solution.

Matt

On 5/20/19 8:58 PM, Jeremy via bitcoin-dev wrote:
> Hello bitcoin-devs,
> 
> Below is a link to a BIP Draft for a new opcode,
> OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless
> congestion control techniques via a rudimentary, limited form of
> covenant which does not bear the same technical and social risks of
> prior covenant designs.
> 
> Congestion control allows Bitcoin users to confirm payments to many
> users in a single transaction without creating the UTXO on-chain until a
> later time. This therefore improves the throughput of confirmed
> payments, at the expense of latency on spendability and increased
> average block space utilization. The BIP covers this use case in detail,
> and a few other use cases lightly.
> 
> The BIP draft is here:
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki
> 
> The BIP proposes to deploy the change simultaneously with Taproot as an
> OPSUCCESS, but it could be deployed separately if needed.
> 
> An initial reference implementation of the consensus changes and  tests
> which demonstrate how to use it for basic congestion control is
> available at
> https://github.com/JeremyRubin/bitcoin/tree/congestion-control.  The
> changes are about 74 lines of code on top of sipa's Taproot reference
> implementation.
> 
> Best regards,
> 
> Jeremy Rubin
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy]

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

I agree a little bit, but I think that logic is somewhat infectious. If
we're going to do covenants, we should also do it as a part of a more
comprehensive new scripting system that gives us other strong benefits for
our ability to template scripts. And so on. I'm excited to see what's
possible!

Given that this is very simple to implement and has obvious deployable big
wins with few controversial drawbacks, it makes more sense to streamline
adoption of something like this for now and work on a more comprehensive
solution without urgency.

The design is also explicitly versioned so short of an eventual full
redesign it should be easy enough to add more flexible features piecemeal
as they come up and their use cases are strongly justified as I have shown
here for certified post dated utxo creation.

Lastly I think that while these are classifiable as covenants in
implementation, they are closer in use to multisig pre-signed scripts,
without the requirement of interactive setup. We should think of these as
'certified checks' instead, which can also describe a pre-signed design
satisfactorily. With true covenants we don't want require the satisfying
conditions to be 'computationally enumerable' (e.g. we can't in
computational limits enumerate all public keys if the covenant expresses a
spend must be to a public key). And if the covenant is computationally
enumerable, then we should use this construct and put the spending paths
into a Huffman encoded taproot tree.

On Tue, May 21, 2019, 12:41 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> If we're going to do covenants (and I think we should), then I think we
> need to have a flexible solution that provides more features than just
> this, or we risk adding it only to go through all the effort again when
> people ask for a better solution.
>
> Matt
>
> On 5/20/19 8:58 PM, Jeremy via bitcoin-dev wrote:
> > Hello bitcoin-devs,
> >
> > Below is a link to a BIP Draft for a new opcode,
> > OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless
> > congestion control techniques via a rudimentary, limited form of
> > covenant which does not bear the same technical and social risks of
> > prior covenant designs.
> >
> > Congestion control allows Bitcoin users to confirm payments to many
> > users in a single transaction without creating the UTXO on-chain until a
> > later time. This therefore improves the throughput of confirmed
> > payments, at the expense of latency on spendability and increased
> > average block space utilization. The BIP covers this use case in detail,
> > and a few other use cases lightly.
> >
> > The BIP draft is here:
> >
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki
> >
> > The BIP proposes to deploy the change simultaneously with Taproot as an
> > OPSUCCESS, but it could be deployed separately if needed.
> >
> > An initial reference implementation of the consensus changes and  tests
> > which demonstrate how to use it for basic congestion control is
> > available at
> > https://github.com/JeremyRubin/bitcoin/tree/congestion-control.  The
> > changes are about 74 lines of code on top of sipa's Taproot reference
> > implementation.
> >
> > Best regards,
> >
> > Jeremy Rubin
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[ZmnSCPxj]

Good morning Jeremy,

>If a sender needs to know the recipient can remove the covenant before spending, they may request a signature of an challenge string from the recipients

The recipients can always choose to destroy the privkey after providing the above signature.
Indeed, the recipients can always insist on not cooperating to sign using the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIFY`.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy]

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

Morning,

Yes, in general, Bitcoin does not do anything to prevent users from
discarding their keys.

I don't think this will be fixed anytime soon.

There are some protocols where, though, knowing that a key was once known
to the recipients may make it legally valid to inflict a punitive measure
(e.g., via HTLC), whereas if the key was never known that might be a breach
of contract for the payment provider.

Best,

Jeremy

On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Jeremy,
>
> >If a sender needs to know the recipient can remove the covenant before
> spending, they may request a signature of an challenge string from the
> recipients
>
> The recipients can always choose to destroy the privkey after providing
> the above signature.
> Indeed, the recipients can always insist on not cooperating to sign using
> the taproot branch and thus force spending via the
> `OP_CHECKOUTPUTSHASHVERIFY`.
>
> Regards,
> ZmnSCPxj
>

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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[ZmnSCPxj]

Good morning,

Some more comments.

* I do not think CoinJoin is much improved by this opcode.
  Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation.
* Using this for congestion control increases blockchain usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time.
  I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem.
* I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so I cannot support replacing `SIGHASH_NOINPUT` with this opcode.
  In particular, while the finite loop support by this opcode appears (at first glance) to be useable as the "stepper" for an offchain update mechanism, I cannot find a good way to short-circuit the transaction chain without `SIGHASH_NOINPUT` anyway.
* Channel factories created by this opcode do not, by themselves, support updates to the channel structure.
  But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory).
  More complex channel factories that can update the division of the factory to channels cannot be done without a multiparty offchain update mechanism such as Decker-Wattenhofer or Decker-Russell-Osuntokun.
  So, similarly to CoinJoin, I do not think it is much improved by this opcode.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 22, 2019 1:11 PM, Jeremy <jlrubin@mit.edu> wrote:

> Morning,
>
> Yes, in general, Bitcoin does not do anything to prevent users from discarding their keys.
>
> I don't think this will be fixed anytime soon.
>
> There are some protocols where, though, knowing that a key was once known to the recipients may make it legally valid to inflict a punitive measure (e.g., via HTLC), whereas if the key was never known that might be a breach of contract for the payment provider.
>
> Best,
>
> Jeremy
>
> On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > Good morning Jeremy,
> >
> > >If a sender needs to know the recipient can remove the covenant before spending, they may request a signature of an challenge string from the recipients
> >
> > The recipients can always choose to destroy the privkey after providing the above signature.
> > Indeed, the recipients can always insist on not cooperating to sign using the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIFY`.
> >
> > Regards,
> > ZmnSCPxj

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy]

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

> * I do not think CoinJoin is much improved by this opcode.
>   Typically, you would sign off only if one of the outputs of the
CoinJoin transaction is yours, and this does not really improve this
situation.

Coinjoin benefits a lot I think.


Coinjoin is improved because you can fit more users into the protocol and
create many more outputs at lower cost or include more participants.
Ideally a coinjoin creates a lot of outputs so that the ownership is
smeared more, but this has a cost at the time of the coinjoin.

Coinjoin is also improved because you don't reveal the outputs created by
the coinjoin until some time, perhaps very far in the future, when you need
the coin. In fact, you only need to reveal where you're moving the coins to
participants in your subtree because participants need only verify their
branch.

It also makes the protocol more stable with respect to input choice. This
is because, similar to how NOINPUT may work, OP_COSHV outputs are spendable
without knowing what the TXID will be. Therefore if someone changes their
input or non segwit spend script, it won't break the presigned txns. This
also means that all the inputs can be ANYONECANPAY, so there is no need to
reveal your inputs before anyone else.

This culminates in being able to open channels from a coinjoin safely, I
believe this is difficult/impossible to do currently.




> * Using this for congestion control increases blockchain usage by one TXO
and one input, ending up with *more* bytes onchain, and a UTXO that will be
removed later in (we hope) short time.
>   I do not know if this is a good idea, to increase congestion by making
unnecessary intermediate transaction outputs, at times when congestion is a
problem.

This is a good idea because it improves QoS for most users.

For receiving money pending spendable but confirmed payment (i.e. certified
checks) is superior to having unconfirmed funds.

For sending money, being able to clear all liabilities in a single txn
decreases business exposure to fee variance and confirmation time variance.
E.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day
late. If I have 10,000 employees this might be painful if fees are
currently up.

It also helps to have a backlog of low priority txns to support the fee
market.

Overall block bandwidth utilization is fairly spikey, so having long term
well known outputs that are not time sensitive can be used to better
utilize bandwidth.

The total extra bandwidth btw is really small given the expansion factor
optimizations available.


> * I cannot find a way to implement Decker-Russell-Osuntokun (or any
offchain update mechanism) on top of this opcode, so I cannot support
replacing `SIGHASH_NOINPUT` with this opcode.
>   In particular, while the finite loop support by this opcode appears (at
first glance) to be useable as the "stepper" for an offchain update
mechanism, I cannot find a good way to short-circuit the transaction chain
without `SIGHASH_NOINPUT` anyway.

I'm not deeply familiar with DRO channels. This opcode isn't a replacement
for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contrast
using SIGHASH_NOINPUT for the uses presented in this BIP.

Lastly there's no 'replacing'. Neither NOINPUT nor COSHV are accepted by
the community at large yet, and they do different things.


> * Channel factories created by this opcode do not, by themselves, support
updates to the channel structure.
>   But such simple "close only" channel factories can be done using n-of-n
and a pre-signed offchain transaction (especially since the entities
interested in the factory are known and enumerable, and thus can be induced
to sign in order to enter the factory).

I'm not really an expert at Bitcoin Lightning, but this basic mechanism
should work.

Imagine the script at a leaf node:

Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]
where uncooperative script is:

Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV <H(H(Pay
alice 2 coins))>)

Cooperative closing skips the extra transactions. Updates are signed
against the uncooperative script with repudation. E.g.:

    HASH160 <revokehash> EQUAL
    IF
        <Bob's pubkey>
    ELSE
        "1 week" CHECKSEQUENCEVERIFY DROP
        <Alice's pubkey>
    ENDIF
    CHECKSIG

It can even be optimized by letting the uncooperative script branches in
the leaf be blaming Alice or Bob.

Does that not work?

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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Anthony Towns]

On Wed, May 22, 2019 at 06:04:27AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> * I do not think CoinJoin is much improved by this opcode.

I think (especially with cross-input sig aggregation) it makes it easier
to do a coinjoin during a high fee period -- if you're willing to wait
'til fees are lower to claim your funds you can still do that, despite
participating now.

Otherwise, I don't think it makes coordination that much easier. 

If the coinjoin groups stays around in a Layer 2-ish protocol, and
coordinates to cut-through transactions, that could be a scaling and
privacy benefit, but comes with much harder coordination problems. ie:

   A,B,C,D do a coinjoin with outputs of 1 BTC each
   tx on chain looks like:
     in: 1 A
         1 B
         1 C
         1 D
     out: 4 to muSig(A,B,C,D) or COHV(1 A, 1 B, 1 C, 1 D)

but then A wants to spend 0.2 BTC to E, and B wants to spend 0.1 BTC to
F, so they agree to update the state and publish:

     in: (above, signed by A+B+C+D)
     out: 
         0.1 F
	 0.2 E
	 3.7 to muSig(A,B,C,D) or COHV(0.8 A, 0.9 B, 1 C, 1 D)

and they continue the protocol.

> * I cannot support replacing `SIGHASH_NOINPUT` with this opcode.

(I don't think this in any way replaces ANYPREVOUT or similar)

I think lightning is improved by this in that it makes it cheaper to
create lightning channels during a high fee period. If you're creating
1000 channels you can do that via a single output with this opcode, and
then wait until either there's a low fee period to publish the funding
tx cheaply; or until the channel fails and you need to extract the funds
which always has the risk of happening during a high fee period.

You might be able to slightly simplify eltoo (or conceivably some parts of
current lightning); if your eltoo update tx has as it's output [musig(A,B)
or (n+1 cltv checksig) or (d CSV COHV(balances))] then your settlement
transaction only needs to reveal the 40B script, rather than needing a
65B ANYPREVOUT signature.

Cheers,
aj

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[ZmnSCPxj]

Good morning Jeremy,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 22, 2019 4:10 PM, Jeremy <jlrubin@mit.edu> wrote:

> > * I do not think CoinJoin is much improved by this opcode.
> >   Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation.
>
> Coinjoin benefits a lot I think.
>
> Coinjoin is improved because you can fit more users into the protocol and create many more outputs at lower cost or include more participants. Ideally a coinjoin creates a lot of outputs so that the ownership is smeared more, but this has a cost at the time of the coinjoin.

But the separate outputs still need to be published at some point in the future.
Further, ideally CoinJoin should be as indistinguishable from normal transactions as possible.
(admittedly, the equal-sized outputs often recommended for CoinJoin tend to blatantly signal "this is a CoinJoin!!", but in any case that "should" be fixed with some kind of future Confidential Transactions)

>
> Coinjoin is also improved because you don't reveal the outputs created by the coinjoin until some time, perhaps very far in the future, when you need the coin. In fact, you only need to reveal where you're moving the coins to participants in your subtree because participants need only verify their branch.

The same technique of congestion control can still be used with only an "ordinary" MuSig of all participant keys on the output of the "funding" transaction, forming a sort of very tiny CoinJoinXT.
This has the advantage that the MuSig is indistinguishable from 1-of-1 spends, which is important for a privacy technique like CoinJoin.
Even in the future and we have published the output-side transaction of the CoinJoin, the transaction chain *could* be interpreted as "one person consolidated all his coins in an ordinary 1-of-1 UTXO, then spent on several things at once" whereas use of the `OP_CHECKOUTPUTSHASHVERIFY` is a blatant "several people agreed to put in their coins provided these outputs were on the second transaction, i.e. some kind of attempt at hiding their coins".

>
> It also makes the protocol more stable with respect to input choice. This is because, similar to how NOINPUT may work, OP_COSHV outputs are spendable without knowing what the TXID will be. Therefore if someone changes their input or non segwit spend script, it won't break the presigned txns. This also means that all the inputs can be ANYONECANPAY, so there is no need to reveal your inputs before anyone else.
>
> This culminates in being able to open channels from a coinjoin safely, I believe this is difficult/impossible to do currently.

This is already *technically* possible, though no software exists to do so (sorry, we have bugs between interop of c-lightning and lnd that take up our debugging time already, we cannot spare it for this *yet*).

SegWit by itself already allows child transactions to be signed before parent transactions are signed.
This safety underlies *all* offchain protocols.
See: https://zmnscpxj.github.io/offchain/generalized.html
This is sufficient to ensure that channels can be opened from whatever transactions you want, though having to interop with other software that *also* has to coordinate with other participants in a different protocol is much more difficult than having to interop with other software using the same protocol.

Finally, `SIGHASH_ANYPREVOUT` can *also* do this, since the txid becomes mooted.
And `SIGHASH_ANYPREVOUT` *also* enables a better offchain update mechanism (Decker-Russell-Osuntokun, more commonly known as "eltoo") whereas I am unable to derive a similar offchain update mechanism using `OP_CHECKOUTPUTSHASHVERIFY` (though possibly for lack of trying).

>
> > * Using this for congestion control increases blockchain usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time.
> >   I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem.
>
> This is a good idea because it improves QoS for most users.
>
> For receiving money pending spendable but confirmed payment (i.e. certified checks) is superior to having unconfirmed funds.
>
> For sending money, being able to clear all liabilities in a single txn decreases business exposure to fee variance and confirmation time variance. E.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day late. If I have 10,000 employees this might be painful if fees are currently up.
>
> It also helps to have a backlog of low priority txns to support the fee market.
>
> Overall block bandwidth utilization is fairly spikey, so having long term well known outputs that are not time sensitive can be used to better utilize bandwidth.
>
> The total extra bandwidth btw is really small given the expansion factor optimizations available.

Okay, you have convinced me regarding this point, at least.

> > * Channel factories created by this opcode do not, by themselves, support updates to the channel structure.
> >   But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory).
>
> I'm not really an expert at Bitcoin Lightning, but this basic mechanism should work.
> Imagine the script at a leaf node:
>
> Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]
>
> where uncooperative script is:
>
> Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP  OP_COSHV <H(H(Pay alice 2 coins))>)
>
> Cooperative closing skips the extra transactions. Updates are signed against the uncooperative script with repudation. E.g.:
>
>     HASH160 <revokehash> EQUAL
>     IF
>         <Bob's pubkey>
>     ELSE
>         "1 week" CHECKSEQUENCEVERIFY DROP
>         <Alice's pubkey>
>     ENDIF
>     CHECKSIG
>
> It can even be optimized by letting the uncooperative script branches in the leaf be blaming Alice or Bob.
>
> Does that not work?

Possibly, but the point is that an n-of-n MuSig will work just as well and we would not need to reveal the Taproot key (33 bytes) and the specific script containing the output hash (1+32 bytes) we want, we just have to reveal a single 64-byte signature.

My objection here is simply that n-of-n already exists, it will work already using that (and it is much more likely to be assured of getting into base layer).

Again, we only need to use SegWit and sign transactions in reverse order to ensure proper operation.
This is already what is done for normal channel opens (the initial commitment transactions are signed first, then the funding transaction is signed and confirmed onchain).

Regards,
ZmnSCPxj

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

[Tamas Blummer]

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 

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

[Jorge Timón]

The complains I could imagine about this, (apart from being a very
specific use case) are the same complains I heard about op_expiry.
Namely, that in a reorg, the same tx, having been valid in a given
block could potentially become invalid in some other block mining it.
I guess in this case the situation is less likely in this case than
with op_expiry, but it is still possible.
Another complain I could imagine is this kind of forces the
implementation to break some existing encapsulations, but I guess
those are just implementation details not that relevant here.
I personally don't have strong feelings towards this proposal one way
or the other, I'm just imagining what other people may complain about.

On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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

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

[Nathan Cook]

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

You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
and
the ensuing thread.

Nathan Cook


On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
>

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

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

[Tamas Blummer]

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

The parameter used is property of the block just like the block height is a property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.

The transaction itself was not invalid in a re-org but evtl. others spending it if the difficulty on that fork is different,
this is however intended as then on that fork the other was the winner.

Tamas Blummer

> On May 23, 2019, at 21:03, Jorge Timón <jtimon@jtimon.cc> wrote:
> 
> The complains I could imagine about this, (apart from being a very
> specific use case) are the same complains I heard about op_expiry.
> Namely, that in a reorg, the same tx, having been valid in a given
> block could potentially become invalid in some other block mining it.
> I guess in this case the situation is less likely in this case than
> with op_expiry, but it is still possible.
> Another complain I could imagine is this kind of forces the
> implementation to break some existing encapsulations, but I guess
> those are just implementation details not that relevant here.
> I personally don't have strong feelings towards this proposal one way
> or the other, I'm just imagining what other people may complain about.
> 
> On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 2423 bytes --]

That opcode would not help as it fetches block hash and not the content of the header.

> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
> 
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki <https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki>) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html> and the ensuing thread.
> 
> Nathan Cook
> 
> 
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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 <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>


[-- Attachment #1.2: Type: text/html, Size: 3755 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Nathan Cook]

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

It's true that it fetches the block hash; the idea is to compare the block
hash's numeric value to the desired (uncompressed) difficulty directly,
using a 256-bit version of OP_LESSTHAN.

Nathan Cook


On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gmail.com> wrote:

> That opcode would not help as it fetches block hash and not the content of
> the header.
>
> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
>
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
> if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
> See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and
> the ensuing thread.
>
> Nathan Cook
>
>
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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
>>
>
>

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

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

[Pieter Wuille]

On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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.

For things like block time/height, this is solved by not having the
script itself observe the context state directly, but instead having
an assertion on the state outside of script (nLockTime for absolute
time/height and nSequence for relative), and then having opcodes
inside script that observe the assertion (OP_CLTV and OP_CSV). By
doing so, script validity is a single context-free yes or not that can
be evaluated once, and the variable part is just transaction-level
reasoning that doesn't involve a full script interpreter.
Additionally, the supported assertions are restricted in such a way
that if they are true within a particular block, they're also true in
any descendant, removing the complexity of reasoning about validity
(apart from the inevitable reasoning about possible double-spend
before confirmation).

I feel a similar construction is needed for observing block
difficulty. This can be done by either having an opcode that as a side
effect of execution "posts" an assertion (e.g. "difficulty at block
height X is at least Y"), instead of putting the difficulty on the
stack. An alternative is having the assertion be part of the
transaction structure (for example in the annex we propose in
bip-taproot), and having an opcode that observes the difficulty
assertion inside script.

I don't have a strong opinion either way on the usefulness of having
difficulty-dependent transaction/scripts.

Cheers,

-- 
Pieter

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

[Tamas Blummer]

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

I see. The uncompressing needs to be done either to compare. How are chances for that BIP?

This BIP would be explicitly offering risk managment of miners biggest risk.
Doing so without relying on external markets or oracle, self cointained would be an impressive and adequate feature.

Tamas Blummer

> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook@gmail.com> wrote:
> 
> It's true that it fetches the block hash; the idea is to compare the block hash's numeric value to the desired (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTHAN.
> 
> Nathan Cook
> 
> 
> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gmail.com> wrote:
> That opcode would not help as it fetches block hash and not the content of the header.
> 
>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
>> 
>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and the ensuing thread.
>> 
>> Nathan Cook
>> 
>> 
>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Tamas Blummer]

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

Block hash can suggest much higher difficulty than what is in effect, so OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the level of the bet.

> On May 23, 2019, at 21:45, Tamas Blummer <tamas.blummer@gmail.com> wrote:
> 
> I see. The uncompressing needs to be done either to compare. How are chances for that BIP?
> 
> This BIP would be explicitly offering risk managment of miners biggest risk.
> Doing so without relying on external markets or oracle, self cointained would be an impressive and adequate feature.
> 
> Tamas Blummer
> 
>> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook@gmail.com> wrote:
>> 
>> It's true that it fetches the block hash; the idea is to compare the block hash's numeric value to the desired (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTHAN.
>> 
>> Nathan Cook
>> 
>> 
>> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gmail.com> wrote:
>> That opcode would not help as it fetches block hash and not the content of the header.
>> 
>>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
>>> 
>>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and the ensuing thread.
>>> 
>>> Nathan Cook
>>> 
>>> 
>>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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
>> 
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Nathan Cook]

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

You're right, I didn't remember the whole procedure. You provide the
80-byte header in the spend script, duplicate it on the stack, hash it, and
compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on
the header with OP_AND to extract the difficulty. You can compare two
compressed difficulties directly by using more bit masking to separate the
exponent and mantissa.

On Thu, 23 May 2019 at 22:54, Tamas Blummer <tamas.blummer@gmail.com> wrote:

> Block hash can suggest much higher difficulty than what is in effect, so
> OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the
> level of the bet.
>
> > On May 23, 2019, at 21:45, Tamas Blummer <tamas.blummer@gmail.com>
> wrote:
> >
> > I see. The uncompressing needs to be done either to compare. How are
> chances for that BIP?
> >
> > This BIP would be explicitly offering risk managment of miners biggest
> risk.
> > Doing so without relying on external markets or oracle, self cointained
> would be an impressive and adequate feature.
> >
> > Tamas Blummer
> >
> >> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook@gmail.com> wrote:
> >>
> >> It's true that it fetches the block hash; the idea is to compare the
> block hash's numeric value to the desired (uncompressed) difficulty
> directly, using a 256-bit version of OP_LESSTHAN.
> >>
> >> Nathan Cook
> >>
> >>
> >> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gmail.com>
> wrote:
> >> That opcode would not help as it fetches block hash and not the content
> of the header.
> >>
> >>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
> >>>
> >>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by
> Luke Dashjr (
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you
> also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
> and the ensuing thread.
> >>>
> >>> Nathan Cook
> >>>
> >>>
> >>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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
> >>
> >
>
>

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

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

[Tamas Blummer]

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


> On May 23, 2019, at 21:45, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> 
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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.
> 
> 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.
> 
> For things like block time/height, this is solved by not having the
> script itself observe the context state directly, but instead having
> an assertion on the state outside of script (nLockTime for absolute
> time/height and nSequence for relative), and then having opcodes
> inside script that observe the assertion (OP_CLTV and OP_CSV). By
> doing so, script validity is a single context-free yes or not that can
> be evaluated once, and the variable part is just transaction-level
> reasoning that doesn't involve a full script interpreter.
> Additionally, the supported assertions are restricted in such a way
> that if they are true within a particular block, they're also true in
> any descendant, removing the complexity of reasoning about validity
> (apart from the inevitable reasoning about possible double-spend
> before confirmation).
> 
> I feel a similar construction is needed for observing block
> difficulty. This can be done by either having an opcode that as a side
> effect of execution "posts" an assertion (e.g. "difficulty at block
> height X is at least Y"), instead of putting the difficulty on the
> stack. An alternative is having the assertion be part of the
> transaction structure (for example in the annex we propose in
> bip-taproot), and having an opcode that observes the difficulty
> assertion inside script.

Thanks for these suggestions I will follow up while preparing the BIP.

> 
> I don't have a strong opinion either way on the usefulness of having
> difficulty-dependent transaction/scripts.
> 

This is the best reception I could have hoped for :)

> Cheers,
> 
> --
> Pieter


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Johnson Lau]

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 <bitcoin-dev@lists.linuxfoundation.org> 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

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

[Natanael]

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

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.

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

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

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1599 bytes --]

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 <natanael.l@gmail.com> wrote:
> 
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto: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.


[-- Attachment #1.2: Type: text/html, Size: 2489 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Johnson Lau]

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

Functionally, COHV is a proper subset of ANYPREVOUT (NOINPUT). The only justification to do both is better space efficiency when making covenant.

With eltoo as a clear usecase of ANYPREVOUT, I’m not sure if we really want a very restricted opcode like COHV. But these are my comments, anyway:

1. The “one input” rule could be relaxed to “first input” rule. This allows adding more inputs as fees, as an alternative to CPFP. In case the value is insufficient to pay the required outputs, it is also possible to rescue the UTXO by adding more inputs.

2. While there is no reason to use non-minimal push, there is neither a reason to require minimal push. Since minimal push is never a consensus rule, COHV shouldn’t be a special case.

3. As I suggested in a different post (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.html>), the argument for requiring a prevout binding signature may also be applicable to COHV

> On 21 May 2019, at 4:58 AM, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Hello bitcoin-devs,
> 
> Below is a link to a BIP Draft for a new opcode, OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless congestion control techniques via a rudimentary, limited form of covenant which does not bear the same technical and social risks of prior covenant designs.
> 
> Congestion control allows Bitcoin users to confirm payments to many users in a single transaction without creating the UTXO on-chain until a later time. This therefore improves the throughput of confirmed payments, at the expense of latency on spendability and increased average block space utilization. The BIP covers this use case in detail, and a few other use cases lightly.
> 
> The BIP draft is here:
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki <https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki>
> 
> The BIP proposes to deploy the change simultaneously with Taproot as an OPSUCCESS, but it could be deployed separately if needed.
> 
> An initial reference implementation of the consensus changes and  tests which demonstrate how to use it for basic congestion control is available at https://github.com/JeremyRubin/bitcoin/tree/congestion-control <https://github.com/JeremyRubin/bitcoin/tree/congestion-control>.  The changes are about 74 lines of code on top of sipa's Taproot reference implementation.
> 
> Best regards,
> 
> Jeremy Rubin
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy]

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

Hi Johnson,

Thanks for the review. I do agree that OP_COSHV (note the pluralization --
it would also be possible to do a OP_COHV <index> <hash> to do specific
outputs).

I think the point of OP_COSHV is that something like ANYPREVOUT is much
more controversial. OP_COSHV is a subset by design. The IF on ANYPREVOUT is
substantial, discussion I've seen shows that the safety of ANYPREVOUT is
far from fully agreed. (I'll respond to your other email on the subject
too). OP_COSHV is also proposed specifically as a congestion control
mechanism, and so keeping it very easy to verify and minimal data
(optimizations allow reducing it to just OP_COSHV with no 32 byte argument)
suggest this approach is preferable.

In an earlier version, rather than have it be the first input restriction,
I had implemented it an an only one input restriction. This makes it easier
to work with SIGHASH_SINGLE. This works by having the PrecomputedData have
a atomic test_flag. However I felt that the statefulness between
verifications was not great and so I simplified it.

There actually is a reason to require minimal push -- maybe we can change
the rule to be non-minimal pushes are ignored, because we can later extend
it with a different rule. This seems a little error prone. There's also no
reason to not just treat OP_COSHV as a pushdata 32 itself, and drop the
extra byte if we don't care about versioning later.

Requiring a signature actually makes COSHV less useful. So I'm against that
-- such a signature prevents using OP_COSHV for non-interactive
setups/uncoordinated setups where the txids are unstable. It also makes
building the trees more expensive. If you want this feature, a better thing
to do would be to always tweak leaf nodes of the tx tree entropy so that
it's unique per key and doesn't impose extra data at every node, only the
leafs of the expansion tree.


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, May 24, 2019 at 12:13 PM Johnson Lau <jl2012@xbt.hk> wrote:

> Functionally, COHV is a proper subset of ANYPREVOUT (NOINPUT). The only
> justification to do both is better space efficiency when making covenant.
>
> With eltoo as a clear usecase of ANYPREVOUT, I’m not sure if we really
> want a very restricted opcode like COHV. But these are my comments, anyway:
>
> 1. The “one input” rule could be relaxed to “first input” rule. This
> allows adding more inputs as fees, as an alternative to CPFP. In case the
> value is insufficient to pay the required outputs, it is also possible to
> rescue the UTXO by adding more inputs.
>
> 2. While there is no reason to use non-minimal push, there is neither a
> reason to require minimal push. Since minimal push is never a consensus
> rule, COHV shouldn’t be a special case.
>
> 3. As I suggested in a different post (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.html),
> the argument for requiring a prevout binding signature may also be
> applicable to COHV
>
> On 21 May 2019, at 4:58 AM, Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello bitcoin-devs,
>
> Below is a link to a BIP Draft for a new opcode,
> OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless
> congestion control techniques via a rudimentary, limited form of covenant
> which does not bear the same technical and social risks of prior covenant
> designs.
>
> Congestion control allows Bitcoin users to confirm payments to many users
> in a single transaction without creating the UTXO on-chain until a later
> time. This therefore improves the throughput of confirmed payments, at the
> expense of latency on spendability and increased average block space
> utilization. The BIP covers this use case in detail, and a few other use
> cases lightly.
>
> The BIP draft is here:
>
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki
>
> The BIP proposes to deploy the change simultaneously with Taproot as an
> OPSUCCESS, but it could be deployed separately if needed.
>
> An initial reference implementation of the consensus changes and  tests
> which demonstrate how to use it for basic congestion control is available
> at https://github.com/JeremyRubin/bitcoin/tree/congestion-control.  The
> changes are about 74 lines of code on top of sipa's Taproot reference
> implementation.
>
> Best regards,
>
> Jeremy Rubin
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy]

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

ZmnSCIPxj,

I think you're missing the general point, so I'm just going to respond to
one point to see if that helps your understanding of why OP_COSHV is better
than just pre-signed.

The reason why MuSig and other distributed signing solutions are not
acceptable for this case is they all require interaction for guarantee of
payout.

In contrast, I can use a OP_COSHV Taproot key to request a withdrawal from
an exchange which some time later pays out to a lot of people, rather than
having to withdraw multiple times and then pay. The exchange doesn't have
to know this is what I did. They also don't have to tell me the exact
inputs they'll spend to me or if I'm batched or not (batching largely
incompatible with pre-signing unless anyprevout)

The exchange can take my withdrawal request and aggregate it to other
payees into a tree as well, without requiring permission from the
recipients.

They can also -- without my permission -- make the payment not directly
into me, but into a payment channel between me and the exchange, allowing
me to undo the withdrawal by routing money back to the exchange over
lightning.

The exchange can take some inbound payments to their hot wallet and move
them into cold storage with pre-set spending paths. They don't need to use
ephemeral keys (how was that entropy created?) nor do they need to bring on
their cold storage keys to pre-sign the spending paths.

None of this really works well with just pre-signing because you need to
ask for permission first in order to do these operations, but with OP_COSHV
you can, just as the payer without talking to anyone else, or just as the
recipient commit your funds to a complex txn structure.

Lastly, think about this in terms of DoS. You have a set of N users who
request a payment. You build the tree, collect signatures, and then at the
LAST step of building the tree, one user drops out. You restart, excluding
that user. Then a different user drops. Meanwhile you've had to keep your
funds locked up to guarantee those inputs for the txn when it finalizes.

In contrast, once you receive the requests with OP_COSHV, there's nothing
else to do. You just issue the transaction and move on.


Does that make sense as to why a user would prefer this, even if there is
an emulation with pre-signed txns?

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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[ZmnSCPxj]

Good morning Jeremy,

I believe I have caught the general point.
Indeed, I agree that this is useful, but it is *not* useful for these cases:

1.  CoinJoin - the initial funding transaction must be signed by the participants anyway after checking that the output is correct.
    Further any spend that is not a signature spend is going to defeat the purpose of CoinJoin trying to be private by imitating "typical" spends: if `OP_CHECKOUTPUTSHASHVERIFY` path is used, you have just lost the CoinJoin privacy by reducing anonymity set.
2.  Channel Factories - the initial funding transaction must be signed by the participants anyway after each initial sub-channel initial commitment / initial update+state transaction is signed.

In both above cases, the issue of users dropping out during the step of signing the initial funding transaction is unavoidable even with `OP_CHECKOUTPUTSHASHVERIFY`.

For congestion control, and for general "I promise to set this up later" as in c*stodial-service-directly-to-channel etc., I already agree this is useful.

My objection lies *only* with the above two cases, wherein `OP_CHECKOUTPUTSHASHVERIFY` does not really improve things, as you *still* need to coordinate multiple signers anyway.

You have convinced me already that the other cases are good example usages of this opcode.

Regards,
ZmnSCPxj




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, May 25, 2019 5:15 AM, Jeremy <jlrubin@mit.edu> wrote:

> ZmnSCIPxj,
>
> I think you're missing the general point, so I'm just going to respond to one point to see if that helps your understanding of why OP_COSHV is better than just pre-signed.
>
> The reason why MuSig and other distributed signing solutions are not acceptable for this case is they all require interaction for guarantee of payout.
>
> In contrast, I can use a OP_COSHV Taproot key to request a withdrawal from an exchange which some time later pays out to a lot of people, rather than having to withdraw multiple times and then pay. The exchange doesn't have to know this is what I did. They also don't have to tell me the exact inputs they'll spend to me or if I'm batched or not (batching largely incompatible with pre-signing unless anyprevout)
>
> The exchange can take my withdrawal request and aggregate it to other payees into a tree as well, without requiring permission from the recipients.
>
> They can also -- without my permission -- make the payment not directly into me, but into a payment channel between me and the exchange, allowing me to undo the withdrawal by routing money back to the exchange over lightning.
>
> The exchange can take some inbound payments to their hot wallet and move them into cold storage with pre-set spending paths. They don't need to use ephemeral keys (how was that entropy created?) nor do they need to bring on their cold storage keys to pre-sign the spending paths.
>
> None of this really works well with just pre-signing because you need to ask for permission first in order to do these operations, but with OP_COSHV you can, just as the payer without talking to anyone else, or just as the recipient commit your funds to a complex txn structure.
>
> Lastly, think about this in terms of DoS. You have a set of N users who request a payment. You build the tree, collect signatures, and then at the LAST step of building the tree, one user drops out. You restart, excluding that user. Then a different user drops. Meanwhile you've had to keep your funds locked up to guarantee those inputs for the txn when it finalizes.
>
> In contrast, once you receive the requests with OP_COSHV, there's nothing else to do. You just issue the transaction and move on.
>
> Does that make sense as to why a user would prefer this, even if there is an emulation with pre-signed txns?