From: "Jorge Timón" <jtimon@jtimon.cc>
To: alicexbt <alicexbt@protonmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP Meeting #8 Notes
Date: Sat, 7 May 2022 15:22:49 +0200 [thread overview]
Message-ID: <CABm2gDqxOtrMrTu2Ovx32USJT2T+6DRpexct1-k3zwEEnsDPMA@mail.gmail.com> (raw)
In-Reply-To: <kbrvpw3Y5y3ko3Wf2VtcywN462JjMW6YjqecduPOXwrek2sR9FkWfSv6G2Fph22UTAAbgII88MtOn1AFo223jjryNAz8YNbbQlFRVQo_HMY=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 7356 bytes --]
I think people may be scared of potential attacks based on covenants. For
example, visacoin.
But there was a thread with ideas of possible attacks based on covenants.
To me the most scary one is visacoin, specially seeing what happened in
canada and other places lately and the general censorship in the west, the
supposed war on "misinformation" going on (really a war against truth imo,
but whatever) it's getting really scary. But perhaps someone else can be
more scared about a covenant to add demurrage fees to coins or something, I
don't know.
https://bitcointalk.org/index.php?topic=278122
For example, what if Justin Castro, sorry, Justin Trudeu mandated a
visacoin covenant for all withdrawals from canadian exchanges?
What if ursula von der mengele, sorry, von der leyen wants to do the same
in europe?
What if nina Nina Jankowicz decides visacoin covenants are the best way to
"stop misinformation"?
Covenants can enable many attacks on bitcoin, not just new cool features.
Now, perhaps I am crazy for thinking there's a war against truth going on,
I don't know.
Perhaps most devs and bitcoin users love those lying politicians I
mentioned.
Perhaps I'm too biased because my political views. Or perhaps the people
who don't consider Justin a criminal against humanity are biased.
I guess this goes beyond the scope of this mailing list though. Perhaps we
should go back to the bitcoin forums to discuss this kind of thing.
On Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,
>
> Summary for the last CTV meeting:
>
> Topics:
>
> 1)APO version of the simple vault
> 2)APO as alternative to CTV
> 3)fiatjaf's CTV spacechain demo
> 4)Compare CTV with other covenant proposals
> 5)Recursive covenants
> 6)Responding to FUD
>
> ===================================================
> APO version of the simple vault
> ===================================================
>
> - It is vulnerable to the half-spend problem, where multiple vaulted
> outputs (of the same denomination) can be spent together, burning all but
> the first to fees. Fixing this requires amending APOAS to cover the current
> input index.
> - The unvault transaction is third-party malleable (it can have more
> inputs added to it). One practical implication is that you can't hand a
> list of the unvault txids to a watchtower, you have to tell them which
> outpoints to watch which is less privacy-preserving. Fixing this requires
> amending APOAS to cover the number of inputs.
> Both of these issues are fixed by the BIP 118 changes suggested by
> darosior (although they still not officially spec'd afaik), which would
> basically make APO have a CTV-equivalent hash mode (minus scriptSig of
> other inputs)
> - simple-apo-vault could use APO-as-spec'd with
> SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend
> problem (but not malleability) and have some other interesting properties,
> like more natural dynamic fees (add inputs+change) and the ability spend
> multiple vaulted outputs together. This would, however, introduce a tx
> pinning attack vector and prevent rate-limited vaults.
>
> ===================================================
> APO as alternative to CTV
> ===================================================
>
> - Current APO is unusable as a CTV alternative, (revised)APO seems to be
> as useful as CTV is (plus some extra flexibility from existing sighash
> flags)
> - Main drawbacks being the additional witness satisfaction cost, the
> network-side full-node validation costs of checking a signature instead of
> just a hash, and not being segwit0-compatible (meaning, among others, not
> quantumphobic-friendly)
> - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and
> CTV-in-bare-spk get you even more savings
> - APO is far from being ready, let alone (revised)APO
> - APOv2 would be both better for Eltoo and better for CTV, since you can
> use a trick to make the signatures smaller
> - "layered commitments" is essential for eltoo to be usable or not is
> unclear. AJ Towns thinks it is required while Christian Decker thinks it is
> not.
>
> ===================================================
> fiatjaf's CTV spacechain demo
> ===================================================
>
> https://github.com/fiatjaf/simple-ctv-spacechain
>
> ===================================================
> Compare CTV with other covenant proposals
> ===================================================
>
> Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really
> actually a defined way to compare them. So one exercise of value would be
> if everyone tries to actually either agree to or come up with their own
> framework for comparing covenants.
>
> Billy Tetrud's email:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html
>
> - Prefers CTV for several reasons. Mainly because of being simple,
> documentation, code, tools, review and testing.
> - Everything else either introduces malleability, infinite recursion, or
> has interactions with other proposed opcodes that could introduce
> potentially undesirable effects like those.
> - Anything involving OP_CAT is out for the time being. There are so many
> things it can enable that it seems most people aren't comfortable adding it
> at the moment.
> - APO wallet vaults seem rather hacky, inefficient, and limited.
> - TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and
> OP_CHECKOUTPUTVERIFY allows recursive covenants
>
> ===================================================
> Recursive covenants
> ===================================================
>
> jamesob:
> I don't particularly understand the aversion to infinite recursion, which
> seems no different than the risk of potentially burning your coins. It's
> not like infinite recursion on bitcoin is some kind of DoS vector or poses
> execution overhead like an Ethereum VM bug might.
>
> rgrant:
> i think people who want recursion for cool stuff are worried that
> pedestrian stuff will prevent it.
>
> jeremyrubin:
> i think people are afraid of weird shit happening, less so of recursion in
> particular
>
> hsjoberg:
> "Recursive covenants" is the boogie man
>
> shesek:
> "recursion" translates to "complex black magic" for nondevs' -- recursion
> is the new turing completeness
>
> ===================================================
> Responding to FUD
> ===================================================
>
> - It could be a good idea to include showing a way to do blacklists in the
> bug bounty offer
> - The potential concerns about recursive covenants have to clearly
> explained so they can be properly examined.
> - An article about CTV myths similar to segwit: :
> https://blog.blockstream.com/en-segwit-myths-debunked/
> - Some users think CTV might delay eltoo
>
> TL;DR
> "The initial resistance came from the Speedy Trial proposal. Then later on
> rumors and FUD started spreading around regarding CTV and covenants."
> - hsjoberg
>
> https://gnusha.org/ctv-bip-review/2022-05-03.log
>
>
> /dev/fd0
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 9087 bytes --]
next prev parent reply other threads:[~2022-05-07 13:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 2:40 [bitcoin-dev] CTV BIP Meeting #8 Notes alicexbt
2022-05-07 13:22 ` Jorge Timón [this message]
2022-05-07 22:40 ` ZmnSCPxj
2022-05-08 16:32 ` Billy Tetrud
2022-05-09 15:23 ` Keagan McClelland
2022-05-10 15:09 ` Billy Tetrud
2022-05-12 11:46 ` Jorge Timón
2022-05-12 12:20 ` ZmnSCPxj
2022-05-12 17:28 ` Billy Tetrud
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=CABm2gDqxOtrMrTu2Ovx32USJT2T+6DRpexct1-k3zwEEnsDPMA@mail.gmail.com \
--to=jtimon@jtimon.cc \
--cc=alicexbt@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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