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

[Tamas Blummer via bitcoin-dev]

> On May 23, 2019, at 21:45, Pieter Wuille  wrote:
> 
> On Thu, 23 May 2019 at 11:33, 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.
> 
> 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



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] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Nathan Cook via bitcoin-dev]

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  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 
> 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  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 
> 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  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
> >>
> >
>
>
___
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.

[Tamas Blummer via bitcoin-dev]

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



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] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

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



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] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Pieter Wuille via bitcoin-dev]

On Thu, 23 May 2019 at 11:33, 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.

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
___
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 via bitcoin-dev]

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  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  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
>>
>
>
___
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.

[Tamas Blummer via bitcoin-dev]

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



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] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

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



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] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Nathan Cook via bitcoin-dev]

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
>
___
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.

[Jorge Timón via bitcoin-dev]

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

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

[Tamas Blummer via bitcoin-dev]

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] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Jimmy Song via bitcoin-dev]

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 feel that adding these
> operations does not preclude adding more specialized opcodes in the future
> as an optimization for whatever popular constructions come up, once we know
> what those are.
>
> I feel that this style of generic building blocks truly embodies what is
> meant by "programmable money".
> ___
> 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]

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.

‐‐‐ Original Message ‐‐‐
On Thursday, May 23, 2019 5:01 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 
> 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 feel that adding these operations does 
> not preclude adding more specialized opcodes in the future as an optimization 
> for whatever popular constructions come up, once we know what those are.
>
> I feel 

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

[ZmnSCPxj via bitcoin-dev]

Good morning Jeremy,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, May 22, 2019 4:10 PM, Jeremy  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 
> 

Re: [bitcoin-dev] Taproot proposal

[Russell O'Connor via bitcoin-dev]

On Wed, May 22, 2019 at 10:06 PM Pieter Wuille 
wrote:

> On Tue, 21 May 2019 at 10:20, Russell O'Connor 
> wrote:
> >
> > Regarding Tapscript, the specification calls for the final value of the
> stack being a single non-false value:
> >
> >> The tapscript is executed according to the rules in the following
> section, with the initial stack as input
> >> II. If the execution results in anything but exactly one element on
> the stack which evaluates to true with CastToBool(), fail.
> >
> > Perhaps it is worth taking this opportunity here to remove a minor wart
> of the Script language and instead require the stack to be exactly empty
> upon completion.
> >
> > In addition to removing a potential malleability vector, I expect it
> would simplify development of Bitcoin Script.  A rule requiring an empty
> stack means that the conjunction (logical and) of two policies can be
> implemented by the simple concatenation of Bitcoin Scripts.  This combined
> with the taproot ability to form the disjunction (logical or) of policies
> by having multiple Merkle branches, means that the translation of a policy
> written in disjunctive normal form (the logical ors of logical ands of
> primitive policies) can be straightforwardly translated to a taproot of
> tapscript.
> >
> > That said, I think the developers of miniscript <
> http://bitcoin.sipa.be/miniscript/miniscript.html> are in a much better
> position to comment on whether my above intuition is correct given that
> they've had to implement a host of various calling conventions.  I
> understand that at least some of this complexity is due to Bitcoin Script's
> one element stack rule.
>
> IIRC I looked into this a few months ago, and found that the spending
> cost (script size + expected witness size) of the optimal script for
> every Miniscript policy at most changes by 1 WU (in either direction)
> by requiring an empty stack rather than a true value, though in a
> (admittedly very arbitrarily biased) distribution, more policies were
> improved by it than degraded. This is not taking Taproot into account
> (as many of those policies in a Taproot-supporting world should
> optimally make use of the internal key and Merkle tree, rather than
> turning everything into a monolithic script). I expect that this may
> make the impact somewhat larger, but still never more than a 1 WU
> gain.
>
> I don't think the spending cost changes justify this change, so the
> remaining criteria are complexity ones. In my view, the main benefit
> would be to authors of hand-written scripts where the consistency
> benefits matter, but this needs to be weighed against the mental cost
> of learning the new semantics. For Miniscript itself, this doesn't
> make much difference - the top level calling convention would become
> 'V' instead of 'T', but 'T' would still exist as a calling convention
> that may be used internally; it's a few lines change.
>
> So overall this feels like something with marginal costs, but also at
> most marginal benefits. Perhaps other people have stronger opinions.
>

Thanks for the info.  I'm surprised to learn that 'T' would still exist
internally.  That does make my proposed ammendment a somewhat more marginal
than I expected.  I still think it would be an improvement, but I guess it
is acceptable the way it is if that is what other people prefer.


> > Even if we choose not to implement the empty stack rule, we should at
> least require that the last element be 0x01 to remove a potential
> malleability vector and bring it in line with MINIMAL_IF semantics.
>
> This feels like the right thing to do; as we're making MINIMALIF part
> of consensus for Tapscript it would make sense to apply the same rule
> to the "return" value of the script. There is a downside though,
> namely that in some places where you'd use "
> OP_CHECKSEQUENCEVERIFY" or " OP_CHECKLOCKTIMEVERIFY" you now need
> to add an additional OP_0NOTEQUAL to convert the left-over element n
> into an exact 0x01. I also can't come up with any practical benefits
> that this would have; if the top stack element in a particular code
> path comes directly from the input, it's insecure regardless; if there
> isn't, it'll generally be a a boolean (or an intentional non-boolean
> true value) computed by the script.
>

That is a very good argument.  If we were to go with an empty stack we'd
probably also want modify to have CSV and CLTV pop their inputs off the
stack.  But at that point perhaps we'd want to change their opcode values
to avoid confusion with old style script.  I guess I'm getting more
convinced to not touch this stuff just and just bear with the somewhat
unfortunate legacy behaviour.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Pieter Wuille via bitcoin-dev]

On Tue, 21 May 2019 at 10:20, Russell O'Connor  wrote:
>
> Regarding Tapscript, the specification calls for the final value of the stack 
> being a single non-false value:
>
>> The tapscript is executed according to the rules in the following section, 
>> with the initial stack as input
>> II. If the execution results in anything but exactly one element on the 
>> stack which evaluates to true with CastToBool(), fail.
>
> Perhaps it is worth taking this opportunity here to remove a minor wart of 
> the Script language and instead require the stack to be exactly empty upon 
> completion.
>
> In addition to removing a potential malleability vector, I expect it would 
> simplify development of Bitcoin Script.  A rule requiring an empty stack 
> means that the conjunction (logical and) of two policies can be implemented 
> by the simple concatenation of Bitcoin Scripts.  This combined with the 
> taproot ability to form the disjunction (logical or) of policies by having 
> multiple Merkle branches, means that the translation of a policy written in 
> disjunctive normal form (the logical ors of logical ands of primitive 
> policies) can be straightforwardly translated to a taproot of tapscript.
>
> That said, I think the developers of miniscript 
>  are in a much better 
> position to comment on whether my above intuition is correct given that 
> they've had to implement a host of various calling conventions.  I understand 
> that at least some of this complexity is due to Bitcoin Script's one element 
> stack rule.

IIRC I looked into this a few months ago, and found that the spending
cost (script size + expected witness size) of the optimal script for
every Miniscript policy at most changes by 1 WU (in either direction)
by requiring an empty stack rather than a true value, though in a
(admittedly very arbitrarily biased) distribution, more policies were
improved by it than degraded. This is not taking Taproot into account
(as many of those policies in a Taproot-supporting world should
optimally make use of the internal key and Merkle tree, rather than
turning everything into a monolithic script). I expect that this may
make the impact somewhat larger, but still never more than a 1 WU
gain.

I don't think the spending cost changes justify this change, so the
remaining criteria are complexity ones. In my view, the main benefit
would be to authors of hand-written scripts where the consistency
benefits matter, but this needs to be weighed against the mental cost
of learning the new semantics. For Miniscript itself, this doesn't
make much difference - the top level calling convention would become
'V' instead of 'T', but 'T' would still exist as a calling convention
that may be used internally; it's a few lines change.

So overall this feels like something with marginal costs, but also at
most marginal benefits. Perhaps other people have stronger opinions.

> Even if we choose not to implement the empty stack rule, we should at least 
> require that the last element be 0x01 to remove a potential malleability 
> vector and bring it in line with MINIMAL_IF semantics.

This feels like the right thing to do; as we're making MINIMALIF part
of consensus for Tapscript it would make sense to apply the same rule
to the "return" value of the script. There is a downside though,
namely that in some places where you'd use "
OP_CHECKSEQUENCEVERIFY" or " OP_CHECKLOCKTIMEVERIFY" you now need
to add an additional OP_0NOTEQUAL to convert the left-over element n
into an exact 0x01. I also can't come up with any practical benefits
that this would have; if the top stack element in a particular code
path comes directly from the input, it's insecure regardless; if there
isn't, it'll generally be a a boolean (or an intentional non-boolean
true value) computed by the script.

On Tue, 21 May 2019 at 13:05, John Newbery  wrote:
>
> Hi,
>
> > A Taproot output is a SegWit output [...]  with
> > version number 1, and a 33-byte witness program whose first byte is 0 or 1.
>
> Given a secret key k and public key P=(x,y), a signer with the knowledge of k
> can sign for -P=(x,p-y) since -k is the secret key for that point. Encoding 
> the
> y value of the public key therefore adds no security.

That's a good point; without security benefit there's no reason to
make pay-to-taproots more expensive. Making them the same cost as
P2WSH is nice in any case.

> As an alternative to
> providing the y value of the taproot output key Q when constructing the 
> taproot
> output, the signer can provide it when signing. We can also restrict the y 
> value
> of the internal key P to be even (or high, or a quadratic residue). That gives
> us 4 options for how to set the y signs for P and Q.
>
> 1. Q sign is explictly set in the witness program, P sign is explicitly set 
> in the control block
> => witness program is 33 bytes, 32 possible leaf versions (one for each 
> pair of 0xc0..0xff)
> 2. Q sign is 

[bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

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 feel that adding these
operations does not preclude adding more specialized opcodes in the future
as an optimization for whatever popular constructions come up, once we know
what those are.

I feel that this style of generic building blocks truly embodies what is
meant by "programmable money".
___
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

[Anthony Towns via bitcoin-dev]

On Wed, May 22, 2019 at 06:04:27AM +, 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

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

Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal

[Anthony Towns via bitcoin-dev]

On Wed, May 22, 2019 at 12:17:31PM +0930, Rusty Russell wrote:
>I prefer to
>change the bip introduction to expliclty shout "THESE SIGNATURE
>HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it
>SIGHASH_UNSAFE_ANYPREVOUT.

> 4. "Rebinding is a new power in bitcoin, and it makes me uncomfortable".
>I have a degree of sympathy for this view, but objections must be
>backed in facts.  If we don't understand it well enough, we should
>not do it.

Yeah, that's where I'm at: if we think something is UNSAFE enough to
need a warning, then I think it's too unsafe to include in the consensus
layer. I would like to find a way of making ANYPREVOUT safe enough that
it doesn't need scary warnings; a week or two ago, chaperone sigs were
my best idea for that.

> Finally, it seems to me that chaparones can be opt-in, and don't need to
> burden the protocol.

Eltoo (and perhaps lightning more generally) seem like the most obvious
use case for ANYPREVOUT, so if it isn't going to opt-in (or is going
to opt-out in any way it can, as you suggest) then they're not a good
solution.

I'm not going to argue about any of that here, though I do reserve the
right to do so later. :)

So here's something I almost think is an argument that ANYPREVOUT is safe
(without chaperone sigs or output tagging, etc).

#1. I'm assuming funds are "safe" in Bitcoin if they're (a) held in
a cryptographically secured UTXO, (b) under "enough" proof of work
that a reorg is "sufficiently" unlikely. If you don't have both those
assumptions, your money is not safe in obvious ways; if you do have them
both, your money is safe.

#2. My theory is that as long as you, personally, only use ANYPREVOUT
to sign transactions that are paying the money back to yourself, your
funds will remain safe.

If you follow this rule, then other people replaying your signature is
not a problem -- the funds will just move from one of your addresses, to
a different address.

If other people *fail* to follow this rule, you might receive funds
directly authorised by an ANYPREVOUT signature. But those funds are only
secure if they're "sufficiently" buried in confirmations anyway, and
once they are, they won't disappear. You might be able to reuse that
signature against some different UTXO, but that's only to your benefit:
they lose funds after violating the rule, but you gain funds.

Eltoo naturally meets this requirement, as long as you consider "paying
to yourself" to cover both "paying to same multisig address" (for update
transactions) and "splitting funds between members of a group who owned
the funds". If you consider the "split" to be "you get 50% of our funds,
you get 20%, you get 30%", even if the signature gets replayed later
against a different utxo, the percentage split remains true it just
unexpectedly applies to more funds.

#3. Making ANYPREVOUT only available via script is aligned with this;
if you'repaying to yourself you probably want complicated rules that
you have to encode in script, and there's a mild economic incentive to
try to avoid that because the key path is cheaper.

#4. I think this covers the major security property for bitcoin (your
funds are yours to decide what to do with), but maybe there are other
ways in which ANYPREVOUT is scary that could be formalised and addressed?

#5. It's probably not compatible with luke's "malleability proof" wallet
idea [0]. Malleability is only a concern for funds that aren't already
"sufficiently" buried, and if you're only spending it to yourself that
doesn't help with burying, and if you're spending it to someone else
immediately after, doesn't help with making that transaction less
malleable. But if the line of argument above's correct, that just
recognises that a wallet like that risks losing funds if someone else
reuses its addresses; it doesn't add any systemic risk. And "wallet X
isn't safe" is a risk category we already deal with.

[0] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012463.html

Cheers,
aj

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