From: Jeremy <jlrubin@mit•edu>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
Date: Wed, 22 May 2019 01:10:23 -0700 [thread overview]
Message-ID: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com> (raw)
In-Reply-To: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 4444 bytes --]
> * I do not think CoinJoin is much improved by this opcode.
> Typically, you would sign off only if one of the outputs of the
CoinJoin transaction is yours, and this does not really improve this
situation.
Coinjoin benefits a lot I think.
Coinjoin is improved because you can fit more users into the protocol and
create many more outputs at lower cost or include more participants.
Ideally a coinjoin creates a lot of outputs so that the ownership is
smeared more, but this has a cost at the time of the coinjoin.
Coinjoin is also improved because you don't reveal the outputs created by
the coinjoin until some time, perhaps very far in the future, when you need
the coin. In fact, you only need to reveal where you're moving the coins to
participants in your subtree because participants need only verify their
branch.
It also makes the protocol more stable with respect to input choice. This
is because, similar to how NOINPUT may work, OP_COSHV outputs are spendable
without knowing what the TXID will be. Therefore if someone changes their
input or non segwit spend script, it won't break the presigned txns. This
also means that all the inputs can be ANYONECANPAY, so there is no need to
reveal your inputs before anyone else.
This culminates in being able to open channels from a coinjoin safely, I
believe this is difficult/impossible to do currently.
> * Using this for congestion control increases blockchain usage by one TXO
and one input, ending up with *more* bytes onchain, and a UTXO that will be
removed later in (we hope) short time.
> I do not know if this is a good idea, to increase congestion by making
unnecessary intermediate transaction outputs, at times when congestion is a
problem.
This is a good idea because it improves QoS for most users.
For receiving money pending spendable but confirmed payment (i.e. certified
checks) is superior to having unconfirmed funds.
For sending money, being able to clear all liabilities in a single txn
decreases business exposure to fee variance and confirmation time variance.
E.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day
late. If I have 10,000 employees this might be painful if fees are
currently up.
It also helps to have a backlog of low priority txns to support the fee
market.
Overall block bandwidth utilization is fairly spikey, so having long term
well known outputs that are not time sensitive can be used to better
utilize bandwidth.
The total extra bandwidth btw is really small given the expansion factor
optimizations available.
> * I cannot find a way to implement Decker-Russell-Osuntokun (or any
offchain update mechanism) on top of this opcode, so I cannot support
replacing `SIGHASH_NOINPUT` with this opcode.
> In particular, while the finite loop support by this opcode appears (at
first glance) to be useable as the "stepper" for an offchain update
mechanism, I cannot find a good way to short-circuit the transaction chain
without `SIGHASH_NOINPUT` anyway.
I'm not deeply familiar with DRO channels. This opcode isn't a replacement
for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contrast
using SIGHASH_NOINPUT for the uses presented in this BIP.
Lastly there's no 'replacing'. Neither NOINPUT nor COSHV are accepted by
the community at large yet, and they do different things.
> * Channel factories created by this opcode do not, by themselves, support
updates to the channel structure.
> But such simple "close only" channel factories can be done using n-of-n
and a pre-signed offchain transaction (especially since the entities
interested in the factory are known and enumerable, and thus can be induced
to sign in order to enter the factory).
I'm not really an expert at Bitcoin Lightning, but this basic mechanism
should work.
Imagine the script at a leaf node:
Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]
where uncooperative script is:
Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV <H(H(Pay
alice 2 coins))>)
Cooperative closing skips the extra transactions. Updates are signed
against the uncooperative script with repudation. E.g.:
HASH160 <revokehash> EQUAL
IF
<Bob's pubkey>
ELSE
"1 week" CHECKSEQUENCEVERIFY DROP
<Alice's pubkey>
ENDIF
CHECKSIG
It can even be optimized by letting the uncooperative script branches in
the leaf be blaming Alice or Bob.
Does that not work?
[-- Attachment #2: Type: text/html, Size: 9788 bytes --]
next prev parent reply other threads:[~2019-05-22 8:10 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
2019-05-22 8:10 ` Jeremy [this message]
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=CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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