📅 Original date posted:2022-05-07
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220507/dfa8dc5b/attachment.html>;
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 23:09:23
in reply to nevent1q…9yq3
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 23:09:23Event JSON
{
"id": "4fdf5f478cb940712999c990feb294ce481d07f2c54492a9e54c225ec5b33db1",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179363,
"kind": 1,
"tags": [
[
"e",
"9498a0956cd7ed540de62769fd19e9aee2f070dfada9963d2c7f54c717224327",
"",
"root"
],
[
"e",
"4ccb20de91a36020a2cd1360b394b1e4faf9a00ae463d74f7d0eb74013b74b2f",
"",
"reply"
],
[
"p",
"745e2723e72d7ded3f0dd293d710b706cd302ab8476983c292d4bdb7f9c5d366"
]
],
"content": "📅 Original date posted:2022-05-07\n📝 Original message:I think people may be scared of potential attacks based on covenants. For\nexample, visacoin.\nBut there was a thread with ideas of possible attacks based on covenants.\nTo me the most scary one is visacoin, specially seeing what happened in\ncanada and other places lately and the general censorship in the west, the\nsupposed war on \"misinformation\" going on (really a war against truth imo,\nbut whatever) it's getting really scary. But perhaps someone else can be\nmore scared about a covenant to add demurrage fees to coins or something, I\ndon't know.\n\nhttps://bitcointalk.org/index.php?topic=278122\n\nFor example, what if Justin Castro, sorry, Justin Trudeu mandated a\nvisacoin covenant for all withdrawals from canadian exchanges?\nWhat if ursula von der mengele, sorry, von der leyen wants to do the same\nin europe?\nWhat if nina Nina Jankowicz decides visacoin covenants are the best way to\n\"stop misinformation\"?\n\nCovenants can enable many attacks on bitcoin, not just new cool features.\n\nNow, perhaps I am crazy for thinking there's a war against truth going on,\nI don't know.\nPerhaps most devs and bitcoin users love those lying politicians I\nmentioned.\nPerhaps I'm too biased because my political views. Or perhaps the people\nwho don't consider Justin a criminal against humanity are biased.\n\nI guess this goes beyond the scope of this mailing list though. Perhaps we\nshould go back to the bitcoin forums to discuss this kind of thing.\n\n\n\n\n\nOn Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Bitcoin Developers,\n\u003e\n\u003e Summary for the last CTV meeting:\n\u003e\n\u003e Topics:\n\u003e\n\u003e 1)APO version of the simple vault\n\u003e 2)APO as alternative to CTV\n\u003e 3)fiatjaf's CTV spacechain demo\n\u003e 4)Compare CTV with other covenant proposals\n\u003e 5)Recursive covenants\n\u003e 6)Responding to FUD\n\u003e\n\u003e ===================================================\n\u003e APO version of the simple vault\n\u003e ===================================================\n\u003e\n\u003e - It is vulnerable to the half-spend problem, where multiple vaulted\n\u003e outputs (of the same denomination) can be spent together, burning all but\n\u003e the first to fees. Fixing this requires amending APOAS to cover the current\n\u003e input index.\n\u003e - The unvault transaction is third-party malleable (it can have more\n\u003e inputs added to it). One practical implication is that you can't hand a\n\u003e list of the unvault txids to a watchtower, you have to tell them which\n\u003e outpoints to watch which is less privacy-preserving. Fixing this requires\n\u003e amending APOAS to cover the number of inputs.\n\u003e Both of these issues are fixed by the BIP 118 changes suggested by\n\u003e darosior (although they still not officially spec'd afaik), which would\n\u003e basically make APO have a CTV-equivalent hash mode (minus scriptSig of\n\u003e other inputs)\n\u003e - simple-apo-vault could use APO-as-spec'd with\n\u003e SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend\n\u003e problem (but not malleability) and have some other interesting properties,\n\u003e like more natural dynamic fees (add inputs+change) and the ability spend\n\u003e multiple vaulted outputs together. This would, however, introduce a tx\n\u003e pinning attack vector and prevent rate-limited vaults.\n\u003e\n\u003e ===================================================\n\u003e APO as alternative to CTV\n\u003e ===================================================\n\u003e\n\u003e - Current APO is unusable as a CTV alternative, (revised)APO seems to be\n\u003e as useful as CTV is (plus some extra flexibility from existing sighash\n\u003e flags)\n\u003e - Main drawbacks being the additional witness satisfaction cost, the\n\u003e network-side full-node validation costs of checking a signature instead of\n\u003e just a hash, and not being segwit0-compatible (meaning, among others, not\n\u003e quantumphobic-friendly)\n\u003e - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and\n\u003e CTV-in-bare-spk get you even more savings\n\u003e - APO is far from being ready, let alone (revised)APO\n\u003e - APOv2 would be both better for Eltoo and better for CTV, since you can\n\u003e use a trick to make the signatures smaller\n\u003e - \"layered commitments\" is essential for eltoo to be usable or not is\n\u003e unclear. AJ Towns thinks it is required while Christian Decker thinks it is\n\u003e not.\n\u003e\n\u003e ===================================================\n\u003e fiatjaf's CTV spacechain demo\n\u003e ===================================================\n\u003e\n\u003e https://github.com/fiatjaf/simple-ctv-spacechain\n\u003e\n\u003e ===================================================\n\u003e Compare CTV with other covenant proposals\n\u003e ===================================================\n\u003e\n\u003e Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really\n\u003e actually a defined way to compare them. So one exercise of value would be\n\u003e if everyone tries to actually either agree to or come up with their own\n\u003e framework for comparing covenants.\n\u003e\n\u003e Billy Tetrud's email:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html\n\u003e\n\u003e - Prefers CTV for several reasons. Mainly because of being simple,\n\u003e documentation, code, tools, review and testing.\n\u003e - Everything else either introduces malleability, infinite recursion, or\n\u003e has interactions with other proposed opcodes that could introduce\n\u003e potentially undesirable effects like those.\n\u003e - Anything involving OP_CAT is out for the time being. There are so many\n\u003e things it can enable that it seems most people aren't comfortable adding it\n\u003e at the moment.\n\u003e - APO wallet vaults seem rather hacky, inefficient, and limited.\n\u003e - TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and\n\u003e OP_CHECKOUTPUTVERIFY allows recursive covenants\n\u003e\n\u003e ===================================================\n\u003e Recursive covenants\n\u003e ===================================================\n\u003e\n\u003e jamesob:\n\u003e I don't particularly understand the aversion to infinite recursion, which\n\u003e seems no different than the risk of potentially burning your coins. It's\n\u003e not like infinite recursion on bitcoin is some kind of DoS vector or poses\n\u003e execution overhead like an Ethereum VM bug might.\n\u003e\n\u003e rgrant:\n\u003e i think people who want recursion for cool stuff are worried that\n\u003e pedestrian stuff will prevent it.\n\u003e\n\u003e jeremyrubin:\n\u003e i think people are afraid of weird shit happening, less so of recursion in\n\u003e particular\n\u003e\n\u003e hsjoberg:\n\u003e \"Recursive covenants\" is the boogie man\n\u003e\n\u003e shesek:\n\u003e \"recursion\" translates to \"complex black magic\" for nondevs' -- recursion\n\u003e is the new turing completeness\n\u003e\n\u003e ===================================================\n\u003e Responding to FUD\n\u003e ===================================================\n\u003e\n\u003e - It could be a good idea to include showing a way to do blacklists in the\n\u003e bug bounty offer\n\u003e - The potential concerns about recursive covenants have to clearly\n\u003e explained so they can be properly examined.\n\u003e - An article about CTV myths similar to segwit: :\n\u003e https://blog.blockstream.com/en-segwit-myths-debunked/\n\u003e - Some users think CTV might delay eltoo\n\u003e\n\u003e TL;DR\n\u003e \"The initial resistance came from the Speedy Trial proposal. Then later on\n\u003e rumors and FUD started spreading around regarding CTV and covenants.\"\n\u003e - hsjoberg\n\u003e\n\u003e https://gnusha.org/ctv-bip-review/2022-05-03.log\n\u003e\n\u003e\n\u003e /dev/fd0\n\u003e Sent with ProtonMail \u003chttps://protonmail.com/\u003e secure email.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220507/dfa8dc5b/attachment.html\u003e",
"sig": "525394b6d9e3f869180b9be47f24824c139becdcd1751498a2aab0c11834f536d80e6e31384fece94df9fa592773afabcf2fd17eb147d1776d4dd195afa040b9"
}