Nostr notes by Nadav Ivgi [ARCHIVE]

📅 Original date posted:2022-04-29 📝 Original ...

2023-06-07T23:08:03Z

In reply to nevent1q…jr5n
_________________________

📅 Original date posted:2022-04-29
📝 Original message:Here's a summary of the trade-offs I see for using APO as a CTV alternative:

1. The resulting txids are not stable.

CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire transaction graph descending from it).

This property could be important for some of the proposed CTV use-cases,
like channel factories.

2. APO will only be available on Taproot, which some people might prefer to
avoid for long-term multi-decade vault storage due to QC concerns. (also
see my previous post on this thread [0])

3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
branch*, for the taproot control block. with more branches CTV-in-taproot
eventually becomes preferable).

4. Higher network-wide full-node validation costs (checking a signature is
quite more expensive than hashing, and the hashing is done in both cases).

5. As APO is currently spec'd, it would suffer from the half-spend problem:
if you have multiple outputs encumbered under an APO covenant that requires
the same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.

If I'm not mistaken, I believe this makes the simple-apo-vault
implementation [1] vulnerable to spending multiple vaulted outputs of the
same denomination together and burning all but the first one. I asked the
author for a more definitive answer on twitter [2].

Fixing this requires amending BIP 118 with some new sigmsg flags (making
the ANYONECANPAY behaviour optional, as mentioned in the OP).

This is definitely possible but also means that APO as-is isn't a
CTV-replacement candidate, without first going through some more design and
review iterations.

shesek

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
[1] https://github.com/darosior/simple-anyprevout-vault
[2] https://twitter.com/shesek/status/1519874493434544128

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> 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/20220429/08486216/attachment.html>;

📅 Original date posted:2022-04-25 📝 Original ...

2023-06-07T23:08:02Z

In reply to nevent1q…lv38
_________________________

📅 Original date posted:2022-04-25
📝 Original message:darosior via bitcoin-dev wrote:
> i doubt CTV is necessary nor sufficient for this

I would be interested to hear more on this.

Is it not necessary because you can exchange and store pre-signed
transactions instead?

What purpose is it not sufficient for? There are some vault designs out
there that are able to achieve interesting properties with CTV, like James
O'Beirne's simple-ctv-vault:

https://github.com/jamesob/simple-ctv-vault
(the basic design expressed in Minsc:
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> 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/20220425/cd6fa22e/attachment-0001.html>;

📅 Original date posted:2022-04-25 📝 Original message:On ...

2023-06-07T23:07:46Z

In reply to nevent1q…f2ym
_________________________

📅 Original date posted:2022-04-25
📝 Original message:On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If you unvault an output to your hot wallet, the thief could be lying in
wait, ready to steal those funds upon them landing.

One way to mitigate some of the risk is to split up your UTXOs so that your
hot wallet exposure is limited.

> However, if you compare it against a multisig wallet (eg 2 of 3), you can
see that while theft of a single key would never result in any theft in
that setup, it could in a CTV vault.

These are two orthogonal things though. You can have a CTV vault where the
hot key signer is a multisig to get the advantages of both. In this case
the addition of a CTV-based unvaulting procedure is an improvement compared
to not using it.

shesek

On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> @Matt
> > both of which are somewhat frustrating limitations, but not security
> limitations, only practical ones.
>
> So I think the first limitation you mentioned (that if your hot wallet's
> key gets stolen you need) can be legitimately considered a security
> limitation. Not because you need to rotate your keys, but because you might
> *not know* your hot wallet key has been stolen. If you unvault an output to
> your hot wallet, the thief could be lying in wait, ready to steal those
> funds upon them landing. At that point, you would then know your hot wallet
> key was compromised and could rotate your vault keys in order to prevent
> further theft. However, the fact that there is a clear theft vulnerability
> is something I would say should be considered a "security limitation".
>
> As you mentioned, this is of course also a security limitation of a hot
> wallet, so this setup definitely has a lot of advantages over a simple hot
> wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> you can see that while theft of a single key would never result in any
> theft in that setup, it could in a CTV vault. The other trade offs there
> are ones of practicality and convenience.
>
> This isn't to say a CTV vault wouldn't be useful. Just that it has
> significant trade offs.
>
> @Russel
> > the original MES vault .. commits to the destination address during
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> *might* do that.
>
> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
>
> I can imagine instead that the definition of the pattern could be
> specified as a number indicating the number of stack items in the pattern,
> followed by that number of stack items. If that's how it is done, I can see
> the user inputting an intended destination script (corresponding to the
> intended destination address) which would then be somehow rotated in to the
> right spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
>
> However, my assumptions might be incorrect. If you think OP_COV would be a
> useful opcode, I would encourage you to write up a complete specification.
>
> > What ways can we build a secured vault that commits to the destination
> address?
>
> Some kind of passed-through state allows doing this. With OP_COV (if my
> assumptions above are correct), the intended destination can be passed
> through the output script pattern(s). With my own proposed
> op_pushoutputstack
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>;,
> state is passed as an attachment on the output more directly. Curious what
> you think about that proposal.
>
> > Are there elegant ways of building secure vaults by using CTV plus
> something else.
>
> Since CTV predefines all the transactions that can happen under its
> control, passed state like this can't help because any dynamic state would
> change the template and render the CTV transaction invalid. I don't see any
> way of solving this problem for CTV.
>
> I'm curious how you think op_cat could enable this with CTV (other than
> the cat+schnorr tricks that don't require CTV at all).
>
>
>
> On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Okay, Matt explained to me the intended application of CTV vaults off
>> list, so I have a better understanding now.
>>
>> The CTV vault scheme is designed as an improvement over the traditional
>> management of hot-wallets and cold-wallets. The CTV vault is logically on
>> the "cold-side" and lets funds be sent from the "cold" side to *one's own*
>> the hot wallet after the unvaulting delay. In this case, the hot wallet
>> funds are always at risk, so it isn't unexpected that those funds could be
>> stolen. After all, that is how hot wallets are today. The advantage is
>> that funds can be moved from the "cold" side without needing to dig out the
>> cold keys.
>>
>> The MES vault scheme applies to a different scenario. In the MES case it
>> is the hot funds are inside the vault, and it is the hot key that unvaults
>> the funds and sends them to *customer's addresses* after a delay. If the
>> hot-key is used in any unauthorised way, then funds can be sent to the
>> address of the cold key (the MES vault actually does something fancy in
>> case of recovery, but it could be adapted to simply send funds to a cold
>> wallet).
>>
>> The MES vault lie somewhere between "better" and "different" when
>> compared to the CTV vault. If one is unwilling to use the MES vault on the
>> hot side and have every withdrawl vetted, then, while you could use the MES
>> design on the cold side like the CTV vault, it wouldn't really offer you
>> any advantages over a CTV vault. However, if you are interested in
>> managing all your payments through a vault (as I've been imagining) then
>> the CTV vault comes across as ineffective when compared to an MES style
>> vault.
>>
>> On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists at mattcorallo.com>
>> wrote:
>>
>>> Still trying to make sure I understand this concern, let me know if I
>>> get this all wrong.
>>>
>>> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
>>> > It's not the attackers *only choice to succeed*. If an attacker
>>> steals the hot key, then they have
>>> > the option to simply wait for the user to unvault their funds of their
>>> own accord and then race /
>>> > outspend the users transaction with their own. Indeed, this is what
>>> we expect would happen in the
>>> > dark forest.
>>>
>>> Right, a key security assumption of the CTV-based vaults would be that
>>> you MUST NOT EVER withdraw
>>> more in one go than your hot wallet risk tolerance, but given that your
>>> attack isn't any worse than
>>> simply stealing the hot wallet key immediately after a withdraw.
>>>
>>> It does have the drawback that if you ever get a hot wallet key stole
>>> you have to rotate all of your
>>> CTV outputs and your CTV outputs must never be any larger than your hot
>>> wallet risk tolerance
>>> amount, both of which are somewhat frustrating limitations, but not
>>> security limitations, only
>>> practical ones.
>>>
>>> > And that's not even mentioning the issues already noted by the
>>> document regarding fee management,
>>> > which would likely also benefit from a less constrained design for
>>> covenants.
>>>
>>> Of course I've always been in favor of a less constrained covenants
>>> design from day one for ten
>>> reasons, but that's a whole other rabbit hole :)
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20220425/4fb056eb/attachment-0001.html>;

📅 Original date posted:2020-06-25 📝 Original message:Hi ...

2023-06-07T18:25:39Z

In reply to nevent1q…wc0e
_________________________

📅 Original date posted:2020-06-25
📝 Original message:Hi ZmnSCPxj,

You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.

You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
her transaction confirmed in order to have a valid bribery fraud. This
seems workable if the time frame was long enough (over a few hours should
be sufficient, assuming we consider reorgs of over 3-4 blocks to be
unlikely), but could indeed be problematic if the time frame is already
short to begin with.

Nadav

On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Nadav,
>
> > > I and some number of Lightning devs consider this to be sufficient
> disincentive to Bob not attacking in the first place.
> >
> > An additional disincentive could be introduced in the form of bribery
> proofs for failed attempts.
> >
> > If we assume that "honest" users of the LN protocol won't reveal their
> timelocked transactions before reaching the timelock expiry (they shouldn't
> anyway because standard full node implementations won't relay them), we can
> prove that Bob attempted bribery and failed to an outside observer by
> showing Bob's signed timelocked transaction, spending an output that was in
> reality spent by a different transaction prior to the locktime expiry,
> which should not be possible if Bob had waited.
>
>
> Unfortunately this could be subject to an inversion of this attack.
>
> Alice can wait for the timelock to expire, then bribe miners to prevent
> confirmation of the Bob timelocked transaction, getting the Alice
> hashlocked transaction confirmed.
>
> Now of course you do mention "prior to the locktime expiry" but there is
> now risk at around locktime.
>
> Particularly, "natural" orphaned blocks and short-term chainsplits can
> exist.
> Bob might see that the locktime has arrived and broadcast the signed
> timelocked transaction, then Alice sees the locktime has not yet arrived
> (due to short-term chainsplits/propagation delays) and broadcast the signed
> hashlocked transaction, then in the end the Alice side of the short-term
> chainsplit is what solidifies into reality due to random chance on which
> miner wins which block.
> Then Bob can now be accused of bribery, even though it acted innocently;
> it broadcasted the timelock branch due to a natural chainsplit but Alice
> hashlocked branch got confirmed.
>
> Additional complications can be added on top to help mitigate this edge
> case but more complex == worse in general.
> For example it could "prior to locktime expiry" can ignore a few blocks
> before the actual timelock, but this might allow Bob to mount the attack by
> initiating its bribery behavior earlier by those few blocks.
>
> Finally, serious attackers would just use new pseudonyms, the important
> thing is to make pseudonyms valuable and costly to lose, so it is
> considered sufficient that LN nodes need to have some commitment to the LN
> in the form of actual channels (which are valuable, potentially
> money-earning constructs, and costly to set up).
>
> Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris
> Belcher, could use similar disincentivizing; I know Chris is planning a
> fidelity bond system for SwapMarket makers, for example, which would mimic
> the properties of LN channels (costly to set up, money-earning).
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200625/b7933c5a/attachment-0001.html>;