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

[Jeremy via bitcoin-dev]

What do you think about having it be OP_CHECK_TXID_TEMPLATE_DATA where the
hash checked is the TXID of the transaction with the inputs set to ...
(maybe appended to the fee paid)?

This allows for a variable number of inputs to be allowed (e.g., one, two,
etc). This also fixes potential bugs around TXID malleability for lightning
like setups (Greg and I discussed in wizards about version malleability).

Allowing multiple inputs is great for structuring more complex contracts
with multiple nodes paying into the same covenantted transaction.

Also I personally prefer a RISC+CISC approach -- we should enable the
common paths easily as they are known (didn't you come up with jets?) and
improve security for API users, but also piecemeal enable features in
script to allow for experimentation or custom contracts.
--
@JeremyRubin 



On Fri, May 24, 2019 at 4:15 PM Russell O'Connor 
wrote:

> In order of escalating scope of amendments to OP_COSHV, I suggest
>
> 1) Peeking at surrounding data surrounding data should definitely be
> replaced by a pushdata-like op-code that uses the subsequent 32-bytes
> directly.  The OP_SUCCESSx upgrade path specifically allows for this, and
> avoids complicating the semantics Bitcoin Script.
> 2) Furthermore, the number-of-input-verification and the
> outputhash-verification operations ought to be split into different opcodes
> as they are logically unrelated.
> 3) Better still, we should instead implement the transaction reflection
> operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash
> and number of inputs respectively onto the stack.  Recursive covenants
> appear to be effectively impossible without either an OP_TWEEKPUBKEY or an
> OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard
> against placing an arbitrary outputhash onto the stack appears to be wasted
> effort to me.
> 4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most
> definitely prefer (3) instead of OP_COSHV, if we still feel the need to do
> anything at all.  It is probably best to have both
> OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of
> OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just
> OP_CHECKSIGFROMSTACKVERIFY as well.
>
> On the other hand, if we are serious about preferring less per-block
> bandwidth over reusable primitive opcodes for programming, then we should
> instead abandon the RISC-style Bitcoin Script and instead add an
> alternative CISC-style taproot leaf type that directly provides (a
> conjunction of) the various popular common policies: channel opening,
> channel factories, coinjoins, hashlocks, timelocks, congestion control
> etc.  Segwit v0 already implements this CISC-style for the single most
> popular policy: single signature verification.
>
> On Fri, May 24, 2019 at 4:51 PM Jeremy  wrote:
>
>> Hi Russell,
>>
>> Thanks for this detailed comparison. The COSHV BIP does include a brief
>> comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
>> detailed.
>>
>>
>> I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
>> clearly one of the more flexible options available and would enable a
>> multitude of new use cases.
>>
>> When I originally presented my work on congestion control at Jan 2017
>> BPASE, I also discussed it as an option for covenants. Unfortunately I
>> think it may be on the edge of too powerful -- there are a lot of use cases
>> and implications from having a potentially recursive covenant. If you see
>> my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
>> non-computationally enumerable set of restrictions.
>>
>> I think also from a developer point of view working with OP_COSHV is much
>> much simpler (maybe this can be abstracted) which will lead to increased
>> adoption. OP_COSHV also uses less per-block bandwidth which also makes it
>> preferable for a measure intended to decongest blocks. Do you know the
>> exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
>> changes to taproot, can be a single byte. OP_COSHV also has less potential
>> to have a negative interaction with future opcodes we may want like
>> OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
>> want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
>> unless there's an exact specification which makes us confident we're
>> hitting all the points.
>>
>> If the main complaint about OP_COSHV is that it peeks at surrounding
>> data, it's also possible to implement it more closely to a multi-byte
>> pushdata opcode or do the template optimization.
>>
>> Lastly, as I have previously noted, OP_LEFT is probably safer to
>> implement than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK
>> scripts.
>>
>>
___
bitcoin-dev mailing list

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

[Jeremy via bitcoin-dev]

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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

Hi Johnson,

As noted on the other thread, witness replay-ability can be helped by
salting the taproot key or the taproot leaf script at the last stage of a
congestion control tree.

I also think that chaperone signatures should be opt-in; there are cases
where we may not want them. OP_COSHV is compatible with an additional
checksig operation.

There are also other mechanisms that can improve the safety. Proposed below:

OP_CHECKINPUTSHASHVERIFY -- allow checking that the hash of the inputs is a
particular value. The top-level of a congestion control tree can check that
the inputs match the desired inputs for that spend, and default to
requiring N of N otherwise. This is replay proof! This is useful for other
applications too.

OP_CHECKFEEVERIFY -- allowing an explicit commitment to the exact amount of
fee limits replay to txns which were funded with the exact amount of the
prior. If there's a mismatch, an alternative branch can be used. This is a
generally useful mechanism, but means that transactions using it must have
all inputs/outputs set.

Best,

Jeremy
--
@JeremyRubin 



On Fri, May 24, 2019 at 7:40 AM Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a meta-discussion for any approach that allows the witness
> committing to only transaction outputs, but not inputs.
>
> We can already do the following things with the existing bitcoin script
> system:
> * commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with
> optional SIGHASH_ANYONECANPAY
> * commit to only inputs but not outputs: SIGHASH_NONE with optional
> SIGHASH_ANYONECANPAY
> * not commit to any input nor output: not using any sigop; using a trivial
> private key; using the SIGHASH_SINGLE bug in legacy script
>
> The last one is clearly unsafe as any relay/mining node may redirect the
> payment to any output it chooses. The witness/scriptSig is also replayable,
> so any future payment to this script will likely be swept immediately
>
> SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but the
> signature is not replayable
>
> But it’s quite obvious that not committing to outputs are inherently
> insecure
>
> The existing system doesn’t allow committing only to outputs, and we now
> have 3 active proposals for this function:
>
> 1. CAT and CHECKSIGFROMSTACK (CSFS):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.html
> 2. ANYPREVOUT (aka NOINPUT):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.html
> 3. CHECKOUTPUTSHASHVERIFY (COHV):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html
>
> With outputs committed, redirecting payment is not possible. On the other
> hand, not committing to any input means the witness is replayable without
> the consent of address owner. Whether replayability is acceptable is
> subject to controversy, but the ANYPREVOUT proposal fixes this by requiring
> a chaperone signature that commits to input. However, if the rationale for
> chaperone signature stands, it should be applicable to all proposals listed
> above.
>
> A more generic approach is to always require a “safe" signature that
> commits to at least one input. However, this interacts poorly with the
> "unknown public key type” upgrade path described in bip-tapscript (
> https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki),
> since it’d be a hardfork to turn an “unknown type sig” into a “safe sig”.
> But we could still use a new “leaf version” every time we introduce new
> sighash types, so we could have a new definition for “safe sig”. I expect
> this would be a rare event and it won’t consume more than a couple leaf
> versions. By the way, customised sighash policies could be done with
> CAT/CSFS.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
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

[Jeremy via bitcoin-dev]

Hi Russell,

Thanks for this detailed comparison. The COSHV BIP does include a brief
comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
detailed.


I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
clearly one of the more flexible options available and would enable a
multitude of new use cases.

When I originally presented my work on congestion control at Jan 2017
BPASE, I also discussed it as an option for covenants. Unfortunately I
think it may be on the edge of too powerful -- there are a lot of use cases
and implications from having a potentially recursive covenant. If you see
my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
non-computationally enumerable set of restrictions.

I think also from a developer point of view working with OP_COSHV is much
much simpler (maybe this can be abstracted) which will lead to increased
adoption. OP_COSHV also uses less per-block bandwidth which also makes it
preferable for a measure intended to decongest blocks. Do you know the
exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
changes to taproot, can be a single byte. OP_COSHV also has less potential
to have a negative interaction with future opcodes we may want like
OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
unless there's an exact specification which makes us confident we're
hitting all the points.

If the main complaint about OP_COSHV is that it peeks at surrounding data,
it's also possible to implement it more closely to a multi-byte pushdata
opcode or do the template optimization.

Lastly, as I have previously noted, OP_LEFT is probably safer to implement
than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.
___
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 via bitcoin-dev]

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



On Fri, May 24, 2019 at 12:13 PM Johnson Lau  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
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Johnson Lau via bitcoin-dev]

> On 25 May 2019, at 4:59 AM, Jeremy  wrote:
> 
> Hi Johnson,
> 
> As noted on the other thread, witness replay-ability can be helped by salting 
> the taproot key or the taproot leaf script at the last stage of a congestion 
> control tree.
> 

The salt will be published when it is first spent. Salting won’t help if the 
address is reused.

> I also think that chaperone signatures should be opt-in; there are cases 
> where we may not want them. OP_COSHV is compatible with an additional 
> checksig operation.
> 
> There are also other mechanisms that can improve the safety. Proposed below:
> 
> OP_CHECKINPUTSHASHVERIFY -- allow checking that the hash of the inputs is a 
> particular value. The top-level of a congestion control tree can check that 
> the inputs match the desired inputs for that spend, and default to requiring 
> N of N otherwise. This is replay proof! This is useful for other applications 
> too.

It is circular dependent: the script has to commit to the txid, and the txid is 
a function of script


> 
> OP_CHECKFEEVERIFY -- allowing an explicit commitment to the exact amount of 
> fee limits replay to txns which were funded with the exact amount of the 
> prior. If there's a mismatch, an alternative branch can be used. This is a 
> generally useful mechanism, but means that transactions using it must have 
> all inputs/outputs set.
> 

This restricts replayability to input with same value, but is still 
replay-able, just like ANYPREVOUT committing to the input value


> Best,
> 
> Jeremy
> --
> @JeremyRubin  
> 
___
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

[ZmnSCPxj via bitcoin-dev]

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


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

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

[Russell O'Connor via bitcoin-dev]

In order of escalating scope of amendments to OP_COSHV, I suggest

1) Peeking at surrounding data surrounding data should definitely be
replaced by a pushdata-like op-code that uses the subsequent 32-bytes
directly.  The OP_SUCCESSx upgrade path specifically allows for this, and
avoids complicating the semantics Bitcoin Script.
2) Furthermore, the number-of-input-verification and the
outputhash-verification operations ought to be split into different opcodes
as they are logically unrelated.
3) Better still, we should instead implement the transaction reflection
operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash
and number of inputs respectively onto the stack.  Recursive covenants
appear to be effectively impossible without either an OP_TWEEKPUBKEY or an
OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard
against placing an arbitrary outputhash onto the stack appears to be wasted
effort to me.
4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most
definitely prefer (3) instead of OP_COSHV, if we still feel the need to do
anything at all.  It is probably best to have both
OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of
OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just
OP_CHECKSIGFROMSTACKVERIFY as well.

On the other hand, if we are serious about preferring less per-block
bandwidth over reusable primitive opcodes for programming, then we should
instead abandon the RISC-style Bitcoin Script and instead add an
alternative CISC-style taproot leaf type that directly provides (a
conjunction of) the various popular common policies: channel opening,
channel factories, coinjoins, hashlocks, timelocks, congestion control
etc.  Segwit v0 already implements this CISC-style for the single most
popular policy: single signature verification.

On Fri, May 24, 2019 at 4:51 PM Jeremy  wrote:

> Hi Russell,
>
> Thanks for this detailed comparison. The COSHV BIP does include a brief
> comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
> detailed.
>
>
> I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
> clearly one of the more flexible options available and would enable a
> multitude of new use cases.
>
> When I originally presented my work on congestion control at Jan 2017
> BPASE, I also discussed it as an option for covenants. Unfortunately I
> think it may be on the edge of too powerful -- there are a lot of use cases
> and implications from having a potentially recursive covenant. If you see
> my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
> non-computationally enumerable set of restrictions.
>
> I think also from a developer point of view working with OP_COSHV is much
> much simpler (maybe this can be abstracted) which will lead to increased
> adoption. OP_COSHV also uses less per-block bandwidth which also makes it
> preferable for a measure intended to decongest blocks. Do you know the
> exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
> changes to taproot, can be a single byte. OP_COSHV also has less potential
> to have a negative interaction with future opcodes we may want like
> OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
> want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
> unless there's an exact specification which makes us confident we're
> hitting all the points.
>
> If the main complaint about OP_COSHV is that it peeks at surrounding data,
> it's also possible to implement it more closely to a multi-byte pushdata
> opcode or do the template optimization.
>
> Lastly, as I have previously noted, OP_LEFT is probably safer to implement
> than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.
>
>
___
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

[Johnson Lau via bitcoin-dev]

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

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