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

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] 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] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[Jeremy via bitcoin-dev]

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

Coinjoin benefits a lot I think.


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

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

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

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




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

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

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

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

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

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

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


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

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

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


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

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

Imagine the script at a leaf node:

Taproot([Alice, Bob], [OP_COSHV ]
where uncooperative script is:

Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV )

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

HASH160  EQUAL
IF

ELSE
"1 week" CHECKSEQUENCEVERIFY DROP

ENDIF
CHECKSIG

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

Does that not work?
___
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,

Some more comments.

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

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, May 22, 2019 1:11 PM, Jeremy  wrote:

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


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

Morning,

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

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

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

Best,

Jeremy

On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj  wrote:

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

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

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

Regards,
ZmnSCPxj
___
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]

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

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

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

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

On Tue, May 21, 2019, 12:41 PM Matt Corallo 
wrote:

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

[Matt Corallo via bitcoin-dev]

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

Matt

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