From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
Date: Wed, 22 May 2019 06:04:27 +0000 [thread overview]
Message-ID: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
Good morning,
Some more comments.
* I do not think CoinJoin is much improved by this opcode.
Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation.
* Using this for congestion control increases blockchain usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time.
I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem.
* I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so I cannot support replacing `SIGHASH_NOINPUT` with this opcode.
In particular, while the finite loop support by this opcode appears (at first glance) to be useable as the "stepper" for an offchain update mechanism, I cannot find a good way to short-circuit the transaction chain without `SIGHASH_NOINPUT` anyway.
* Channel factories created by this opcode do not, by themselves, support updates to the channel structure.
But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory).
More complex channel factories that can update the division of the factory to channels cannot be done without a multiparty offchain update mechanism such as Decker-Wattenhofer or Decker-Russell-Osuntokun.
So, similarly to CoinJoin, I do not think it is much improved by this opcode.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 22, 2019 1:11 PM, Jeremy <jlrubin@mit•edu> wrote:
> Morning,
>
> Yes, in general, Bitcoin does not do anything to prevent users from discarding their keys.
>
> I don't think this will be fixed anytime soon.
>
> There are some protocols where, though, knowing that a key was once known to the recipients may make it legally valid to inflict a punitive measure (e.g., via HTLC), whereas if the key was never known that might be a breach of contract for the payment provider.
>
> Best,
>
> Jeremy
>
> On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> > Good morning Jeremy,
> >
> > >If a sender needs to know the recipient can remove the covenant before spending, they may request a signature of an challenge string from the recipients
> >
> > The recipients can always choose to destroy the privkey after providing the above signature.
> > Indeed, the recipients can always insist on not cooperating to sign using the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIFY`.
> >
> > Regards,
> > ZmnSCPxj
next prev parent reply other threads:[~2019-05-22 6:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 20:58 Jeremy
2019-05-21 19:41 ` Matt Corallo
2019-05-22 1:47 ` Jeremy
2019-05-22 2:51 ` ZmnSCPxj
2019-05-22 5:11 ` Jeremy
2019-05-22 6:04 ` ZmnSCPxj [this message]
2019-05-22 8:10 ` Jeremy
2019-05-23 3:45 ` ZmnSCPxj
2019-05-24 21:15 ` Jeremy
2019-05-25 3:56 ` ZmnSCPxj
2019-05-22 20:49 ` Anthony Towns
2019-05-23 17:42 ` [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party Tamas Blummer
2019-05-23 19:03 ` Jorge Timón
2019-05-23 19:10 ` Tamas Blummer
2019-05-23 19:05 ` Nathan Cook
2019-05-23 19:18 ` Tamas Blummer
2019-05-23 19:21 ` Nathan Cook
2019-05-23 19:45 ` Tamas Blummer
2019-05-23 19:54 ` Tamas Blummer
2019-05-23 20:07 ` Nathan Cook
2019-05-23 19:45 ` Pieter Wuille
2019-05-23 20:26 ` Tamas Blummer
2019-05-24 8:36 ` Natanael
2019-05-24 16:23 ` Tamas Blummer
2019-05-24 8:15 ` Johnson Lau
2019-05-24 19:12 ` [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal Johnson Lau
2019-05-24 20:36 ` Jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox