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: Fri, 24 May 2019 14:15:07 -0700 [thread overview]
Message-ID: <CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@mail.gmail.com> (raw)
In-Reply-To: <vbL4Nj9knpm6GMzS3wfTOcDPz9F6RoStna3mDwgJmmvYa1mPWa62x_atF3kBXjajlTDIxerTsYRr5pzI3xC3eSM_ssffsrXESqoNqMSg2h4=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]
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?
[-- Attachment #2: Type: text/html, Size: 4890 bytes --]
next prev parent reply other threads:[~2019-05-24 21:15 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
2019-05-23 3:45 ` ZmnSCPxj
2019-05-24 21:15 ` Jeremy [this message]
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=CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@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