path: root/58/8efcec396562b71647506b022271453d9d05bc

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 529DEC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 23:35:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 4842440260
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 23:35:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level: 
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.975,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3iG0ai8baQmc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 23:35:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com
 [IPv6:2607:f8b0:4864:20::532])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4EAAE40185
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 23:35:26 +0000 (UTC)
Received: by mail-pg1-x532.google.com with SMTP id q76so7478108pgq.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 01 May 2022 16:35:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=DttCcq9pZMES+1g5Mi5bc8nfWPTxLqBwQOgvLvb/iOA=;
 b=fJDouQbo0yz+m+rg8a1z9U0iJLOoIJrYwNDxknY4lz4qi6UEN5NH0RieeWZJw55UNe
 WwR4UmLMsuRNbBAC2Ld6Utf5MQmuZJ/LxE6A6I9l9zEkjMNjd2KmvkRPs4kJC5TR/g5a
 7xGVE3SrUe/rY6HgrGIFsIL+OpDi+FbUV2qjmXruOUHuYhwfdH+RvcBYBrh0okuYh+MR
 mgIlfMAUtQTR5t6XsNjoTuD8s6+11T+gKl3Gm//vdM9oP98D9IzI0DQUOp0E4m/UcMD7
 kYsUX7TNE1n18SqJGGht/4N0rSwD0ySH/P9IFTASYj5SmFIimM1C5Kq3br5kG4QU/XBF
 suTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=DttCcq9pZMES+1g5Mi5bc8nfWPTxLqBwQOgvLvb/iOA=;
 b=iZCtH/N6xGhrW6+FmUoF3WvyvBFo16fCGYmBwFrzCqXpzGefkNzUjY+OMd+jW5SajL
 WSghwFQbTR5sVJYyg6m0+wVt6YdGN1j8lfGTVozV6t3qqp14+WcCX4DLqfHLqNQOpW6B
 Yunpj9/q5s5ZkJr2e3yUi+sB67DLQ5sBx/n4ivlzMVYUwwTtgAunDHeuhjSoSd42xIBx
 YRJz87ss/dOSDrp3bRWid0dCwZET/gkPZDCMChnt0TYclRPLS6wkSQEnFcN8srT0xuyy
 dbV0lpggCKK6zaU/HmuANCUnZIysg6I5RStjyTvIPU1gyli7EmzgCVji20n1majuEpMr
 ohKA==
X-Gm-Message-State: AOAM533JpERoWP7B8S3WHxOIw+q40cs7vgufoERQ34rrcbgK1yuQiwf/
 Tf0PB9FF4jM3WLd7kSv2lxC2fbH6biZGbQiiFbo=
X-Google-Smtp-Source: ABdhPJyKwuGPc6JAEZVMj49vm9g7XPSj4KV4utyuHyzoTXvdcBLU9N/pdXJ9/Tybg1zHLRlNaALW8R58S5Npkk33LhI=
X-Received: by 2002:a63:814a:0:b0:3ab:71d0:1a05 with SMTP id
 t71-20020a63814a000000b003ab71d01a05mr7508032pgd.599.1651448125483; Sun, 01
 May 2022 16:35:25 -0700 (PDT)
MIME-Version: 1.0
References: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
 <CAGXD5f3CyoRytWi4rsTUJocBS3Kqb=T2z6fOe+eORc-uxALrDg@mail.gmail.com>
 <u_rOSYZh92yALI9zZLk2M7DwQEccOLpQpCQrWN3Sz2HrH8M4WNvTtyp17ByfWhee3d1Ler62Wi3PmlM7AZduC4G8_qRRJAUIB0Bw3UP9q2M=@protonmail.com>
 <CAGXD5f3z9q1ggUemHUvEkDhRDQa9Xb04=zPzzKdX=hLGNBadVQ@mail.gmail.com>
 <CAGXD5f1Tu4o9e_-JtBgAs81NezYkM8X8AAqm=T9vjda4=3WFig@mail.gmail.com>
In-Reply-To: <CAGXD5f1Tu4o9e_-JtBgAs81NezYkM8X8AAqm=T9vjda4=3WFig@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 1 May 2022 18:35:08 -0500
Message-ID: <CAGpPWDbSS6QucG8dZz4jURaA2f9xMqnCDoLXg0hbGaTuE4q59Q@mail.gmail.com>
To: Nadav Ivgi <nadav@shesek.info>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e270ff05ddfbbaed"
X-Mailman-Approved-At: Mon, 02 May 2022 08:57:23 +0000
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 01 May 2022 23:35:28 -0000

--000000000000e270ff05ddfbbaed
Content-Type: text/plain; charset="UTF-8"

>   If a QC is able overnight to spend a large fraction of the supply, your
coins in your super non-QC vulnerable-bare-CTV-covenant (that would
eventually become vulnerable when trying to use it) are worthless.[1]

I know this has been debated to death, but I really don't think this
argument is very convincing. First of all, why are we assuming that if for
example, "satoshi's hoard" of 5+ million bitcoins was stolen, that it would
mean bitcoin becomes worthless? To me this is an absurd assumption to make.
The thief almost certainly wouldn't want to just destroy bitcoin. But even
if they did and put it all up for sale overnight, yes it would tank
bitcoin's price *temporarily*. But in the long run, this is less than 1/3
of the supply, and it at worst could be considered monetary inflation of <
30%, and so that's the amount that the price should take a hit of: less
than 30%. Plenty of fiat currencies have survived worse.

Second of all, its incredibly unlikely that someone is suddenly going to be
able to do QC so well that they jump straight to being able to find "a
large fraction" of the private keys out there, or enough private keys to
make up a large fraction of the supply. Its far more likely that the first
quantum computers that are able to derive *any* private keys will still
take a long time (weeks? months?) to do one. If you have your bitcoins in a
segwit address, you know that they can't be stolen by a quantum computer.
You can sit back calmly, and figure out what to do next. By contrast, if
your life savings is in a taproot address, you have to drop everything with
your underwear on fire and recklessly move that stuff ASAP. Chances for
hasty mistakes is high.

But lets say someone *does* jump to being able to derive 1 private key per
minute (pretty darn fast if you ask me). It would currently take such a
machine 152 years to crack all the 80 million UTXOs in existence. By the
time there are practical quantum machines, it'll probably be at least
double that many UTXOs. If it was trying to crack revealed private keys
from mempool transactions, it could only really hit 10 out of 2000
transactions. Hashing the public key is I think is quite an effective
protection to a quantum computing attack in the vast majority of likely QC
emergence scenarios. I honestly don't understand how someone could come to
a different conclusion.

It makes a lot of sense in a world where quantum computers are now a very
real thing, to store large amounts of bitcoin in a possibly slightly less
efficient way in order to ensure that those funds can't be snatched in a QC
disaster scenario. I would be very interested to see a proposal to add the
option of having a taproot address type that doesn't expose the bare public
key.


On Fri, Apr 29, 2022 at 6:53 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Correction: thinking about this some more, you can't actually expect to
> have a stable txid if you allow additional inputs at all...
>
> So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
> commits to the number of inputs) as proposed in the OP should be sufficient
> to get stable txids for single-input transactions.
>
> (I initially thought that APO has to cover some additional tx parts for
> this, but it seems that it's really just the scriptSig which is guarrnated
> to be empty if you have a single input that is known to be the taproot APO
> spend.)
>
> So in overall, my (1) and (5) points are only applicable to
> APO-as-currently-spec'd and not to the suggested APO revision.
>
> On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi <nadav@shesek.info> wrote:
>
>> > This is *literally* what the post you are replying to is proposing to
>> solve.
>>
>> I thought the changes mentioned in the OP (+ committing to the spent
>> input index) only solves the half-spend problem, but not the stable txids
>> one?
>>
>> There can be other inputs with a scriptSig, which doesn't get committed
>> to in the APO hash. I guess this isn't too common, but there might be some
>> cases where you would want to spend some (pre-selected) non-segwit inputs
>> alongside your covenant, maybe for fees. With CTV you would pre-commit to
>> the scriptSig which makes it non-malleable even if the script itself is.
>>
>> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
>> theory but good luck.)
>> > Maybe you are refering to non-interactive channel creation?
>>
>> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
>> which is a sort of a channel factory construction under a broader
>> definition (and in fact was previously called that in the BIP [1]).
>>
>> > The case for stable txids is less strong if we have APO (and therefore
>> Eltoo).
>>
>> There's merit in using these factory constructs for Poon-Dryja channels
>> even if Eltoo was available.
>> I don't foresee Eltoo taking over the penalty approach entirely, but
>> rather the two living side by side.
>>
>> (It could theoretically be possible to use APO to open Poon-Dryja
>> channels on top of unstable funding txids, but having stable txids makes
>> this much more easily integratable with existing lightning implementations,
>> without the invasive changes that unstable txids would bring.)
>>
>> > This has been addressed over and over and over again. If a QC is able
>> overnight to spend a large fraction of
>> > the supply, your coins in your super
>> non-QC-vulnerable-bare-CTV-covenant (that would eventually become
>> > vulnerable when trying to use it) are worthless.
>>
>> It might be the case that a sufficient fraction of supply does switch
>> over to QC-protected outputs in time, with only some small minority that
>> didn't actively switch over *and* with revealed bare pubkeys losing
>> their funds, which wouldn't make BTC entirely worthless. It makes sense not
>> to want to be in that minority, ideally without requiring further
>> time-sensitive active action (esp if considering long-term deep cold
>> storage for inheritance etc).
>>
>> (This of course assumes a safe post-QC mechanism to later spend these
>> funds; IIUC there are some viable approaches for that using a two-step
>> spending procedure, where you prove knowledge of the pubkey/script preimage
>> while commiting to a future tx.)
>>
>> > Sorry for being sarcastic, but at this point it's not fair to use
>> quantum-computer FUD to justify the
>> > activation of CTV over APO, or encourage the use of legacy transactions
>> over Taproot ones.
>>
>> Sorry if it came off as FUDing. I don't know enough to hold a strong
>> opinion on whether the fear of QCs is justified or not. I know that many
>> people on this list don't think so, but I also think that this fear is
>> prevalent enough to warrant taking it into consideration (at least for
>> features that target long-term SoV use cases; less so for features
>> targeted at L2 MoE applications like lightning spacechains paypools etc).
>>
>> > you can also use the internal key optimization .. you can't have
>> NUMS-ness then
>>
>> Right, which makes this unsuitable for the vaulting use case.
>>
>> > Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>> witness units* (8.25 vbytes).
>>
>> Ugh yes sorry about that! I realized after hitting send and meant to
>> clarify that it should've been s/vbyte/WU/ in my next reply.
>>
>> > Are APO signatures more expensive to verify? .. the cost for the
>> network of validating signatures already exists today
>>
>> Not compared to existing signature verifications, but compared to a
>> CTV/TXHASH-like construction.
>>
>> Can anyone quantify how much of a difference this makes in practice?
>>
>> > i appreciate your reply and your efforts to explore the tradeoffs
>> between the two approaches.
>>
>> Thank you, I appreciate your efforts on this too :-)
>>
>> shesek
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
>> [1] https://github.com/bitcoin/bips/pull/1273
>>
>> On Fri, Apr 29, 2022 at 11:31 AM darosior <darosior@protonmail.com>
>> wrote:
>>
>>> Hi Shesek,
>>>
>>> 1. The resulting txids are not stable.
>>>
>>>
>>> This is *literally* what the post you are replying to is proposing to
>>> solve.
>>>
>>>
>>> This property could be important for some of the proposed CTV use-cases,
>>> like channel factories.
>>>
>>>
>>> Hmm? You can't have channel factories without Eltoo. (Well, you can in
>>> theory but good luck.)
>>> Maybe you are refering to non-interactive channel creation? The case for
>>> stable txids is less strong if we
>>> have APO (and therefore Eltoo). [0]
>>>
>>>
>>> 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])
>>>
>>>
>>> This has been addressed over and over and over again. If a QC is able
>>> overnight to spend a large fraction of
>>> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
>>> (that would eventually become
>>> vulnerable when trying to use it) are worthless.[1]
>>>
>>> Sorry for being sarcastic, but at this point it's not fair to use
>>> quantum-computer FUD to justify the
>>> activation of CTV over APO, or encourage the use of legacy transactions
>>> over Taproot ones.
>>>
>>>
>>> 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).
>>>
>>>
>>> Again, this is what my post discusses. Here are the arguments from my
>>> post about why i don't think it's a big deal:
>>>
>>>     1. You can in this case see CTV as an optimization of (tweaked)
>>> APOAS. A lot of us are doubtful about CTV
>>>        usecases for real people. So much that it was even proposed to
>>> temporarily activate it to see if it would
>>>        ever have any real traction! [2]
>>>        My point with this post was: what if we do (a slightly tweaked)
>>> BIP118, that is otherwise useful. And
>>>        if this use of covenants is really getting traction then we can
>>> roll out an optimization in the form of
>>>        CTV (or better covenants, as we'd have had more research put into
>>> it by this time).
>>>     2. CTV is mainly sold for its usage inside vaults. While i'm not
>>> convinced, a few more vbytes should not
>>>        matter for this usecase.
>>>
>>> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>>> witness units* (8.25 vbytes).
>>> Aside, you can also use the internal key optimization with APO. But i
>>> don't think it's desirable just to save
>>> 32 WU, as you can't have NUMS-ness then. [3]
>>>
>>>
>>> 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).
>>>
>>>
>>> Are APO signatures more expensive to verify? If not i don't think this
>>> should be a reason to constrain us to a
>>> much less useful construction, as the cost for the network of validating
>>> signatures already exists today. Even
>>> if it didn't, the tradeoff of cost/usefulness needs to be considered.
>>>
>>>
>>> 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).
>>>
>>>
>>> Yes! And as i mentioned on Twitter also committing to the input index
>>> which i forgot to add in the OP here.
>>>
>>>
>>> While i don't think the specific points are valid, i appreciate your
>>> reply and your efforts to explore the
>>> tradeoffs between the two approaches.
>>>
>>> Thanks,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
>>> [1] https://bitcoin.stackexchange.com/a/91050/101498
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
>>> [3]
>>> https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
>>>
>>>
>>> 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@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@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000e270ff05ddfbbaed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0

=C2=A0If a QC is able overnight to spend a large fraction of the supply, yo=
ur coins in your super non-QC vulnerable-bare-CTV-covenant (that would even=
tually become vulnerable when trying to use it) are worthless.[1]<div><br><=
/div><div>I know this has been debated to death, but I really don&#39;t thi=
nk this argument is very convincing. First of all, why are we assuming that=
 if for example, &quot;satoshi&#39;s hoard&quot; of 5+ million bitcoins was=
 stolen, that it would mean bitcoin becomes worthless? To me this is an abs=
urd assumption to make. The thief almost certainly wouldn&#39;t want to jus=
t destroy bitcoin. But even if they did and put it all up for sale overnigh=
t, yes it would tank bitcoin&#39;s price *temporarily*. But in the long run=
, this is less than 1/3 of the supply, and it at worst could be considered =
monetary inflation of &lt; 30%, and so that&#39;s the amount that the price=
 should take a hit of: less than 30%. Plenty of fiat currencies have surviv=
ed worse.=C2=A0</div><div><br></div><div>Second of=C2=A0all, its incredibly=
 unlikely that someone is suddenly going to be able to do QC so well that t=
hey jump straight to being able to find &quot;a large fraction&quot; of the=
 private keys out there,=C2=A0or enough private keys to make up a large fra=
ction of the supply. Its far more likely that the first quantum computers t=
hat are able to derive *any* private keys will still take a long time (week=
s? months?) to do one. If you have your bitcoins in a segwit address, you k=
now that they can&#39;t be stolen by a quantum computer.=C2=A0 You can sit =
back calmly, and figure out what to do next. By contrast, if your life savi=
ngs is in a taproot address, you have to drop everything with your underwea=
r on fire and recklessly move that stuff ASAP. Chances for hasty mistakes i=
s high.=C2=A0</div><div><br></div><div>But lets say someone *does* jump to =
being able to derive 1 private key per minute (pretty darn fast if you ask =
me). It would currently take such a machine 152 years to crack all the 80 m=
illion UTXOs in existence. By the time there are practical quantum machines=
, it&#39;ll probably be at least double that many UTXOs. If it was trying t=
o crack revealed private keys from mempool transactions, it could only real=
ly hit 10 out of 2000 transactions. Hashing the public key is I think is qu=
ite an effective protection to a quantum computing attack in=C2=A0the vast =
majority of likely QC emergence scenarios. I honestly don&#39;t understand =
how someone could come to a different conclusion.=C2=A0</div><div><br></div=
><div>It makes a lot of sense in a world where quantum computers are now a =
very real thing, to store large amounts of bitcoin in a possibly slightly l=
ess efficient way in order to ensure that those funds can&#39;t be snatched=
 in a QC disaster scenario. I would be very interested to see a proposal to=
 add the option of having a taproot address type that doesn&#39;t expose th=
e bare public key.=C2=A0<br><div><br></div></div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 29, 2022 at 6:=
53 AM Nadav Ivgi via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>Correction: thinking about this some more, you can&#39=
;t actually expect to have a stable txid if you allow additional inputs at =
all...</div><div><br></div><div>So yes, amending BIP 118 to commit to sha_s=
equences (which indirectly also commits to the number of inputs) as propose=
d in the OP should be sufficient to get stable txids for single-input trans=
actions.</div><div><br></div><div>(I initially thought that APO has to cove=
r some additional tx parts for this, but it seems that it&#39;s really just=
 the scriptSig which is guarrnated to be empty if you have a single input t=
hat is known to be the taproot APO spend.)</div><div><br></div><div>So in o=
verall, my (1) and (5) points are only applicable to APO-as-currently-spec&=
#39;d and not to the suggested APO revision.<br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 29, 2022=
 at 1:21 PM Nadav Ivgi &lt;<a href=3D"mailto:nadav@shesek.info" target=3D"_=
blank">nadav@shesek.info</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><span><div><span>&gt; This is *lit=
erally* what the post you are replying to is proposing to solve.</span></di=
v><div><span><br></span></div></span><div><span>I
 thought the changes mentioned in the OP (+ committing to the spent=20
input index) only solves the half-spend problem, but not the stable=20
txids one?<br></span></div><div><span><br></span></div><div><span></span></=
div><div><span>There
 can be other inputs with a scriptSig, which doesn&#39;t get committed to i=
n
 the APO hash. I guess this isn&#39;t too common, but there might be some c=
ases=20
where you would want to spend some (pre-selected) non-segwit inputs=20
alongside your covenant, maybe for fees. With CTV you would pre-commit=20
to the scriptSig which makes it non-malleable even if the script itself=20
is.</span></div><div><span><br></span></div><span><div><span>&gt; Hmm? You =
can&#39;t have channel factories without Eltoo. (Well, you can in theory bu=
t good luck.)</span></div><div><span>&gt; Maybe you are refering to non-int=
eractive channel creation?</span></div><div><span><br></span></div></span><=
div><span>I
 was referring to what BIP 119 calls &#39;Batched Channel Creation&#39; [0]=
,=20
which is a sort of a channel factory construction under a broader=20
definition (and in fact was previously called that in the BIP [1]).</span><=
/div><span><div><span><br></span></div><div><span>&gt; The case for stable =
txids is less strong if we have APO (and therefore Eltoo).</span></div><div=
><span><br></span></div></span><div><span>There&#39;s merit in using these =
factory constructs for Poon-Dryja channels even if Eltoo was available.</sp=
an></div><div><span>I don&#39;t foresee Eltoo taking over <span>the penalty=
 approach entirely, but rather the two living side by side.<br></span></spa=
n></div><div><span><span><br></span></span></div><div><span><span>(It could=
 theoretically be possible to use APO to open <span>Poon-Dryja channels on =
top of unstable funding txids, but</span>
 having stable txids makes this much more easily integratable with=20
existing lightning implementations, without the invasive changes that=20
unstable txids would bring.)<br></span></span></div><div><span><span><br></=
span></span></div><div><span><span><span><span>&gt; This has been addressed=
 over and over and over again. If a QC is able overnight to spend a large f=
raction of</span></span></span><div><span>&gt; the supply, your coins in yo=
ur super non-QC-vulnerable-bare-CTV-covenant (that would eventually become<=
/span></div><div><span>&gt; vulnerable when trying to use it) are worthless=
.</span></div><div><span><br></span></div></span><div><span>It
 might be the case that a sufficient fraction of supply does switch over
 to QC-protected outputs in time, with only some small minority that=20
didn&#39;t actively switch over <i>and</i> with revealed bare pubkeys losin=
g
 their funds, which wouldn&#39;t make BTC entirely worthless. It makes sens=
e
 not to want to be in that minority, ideally without requiring further=20
time-sensitive active action (esp if considering long-term deep cold=20
storage for inheritance etc).</span></div><div><span><br></span></div><div>=
<span>(This of course assumes a safe<span> post-QC</span>
 mechanism to later spend these funds; IIUC there are some viable=20
approaches for that using a two-step spending procedure, where you prove
 knowledge of the pubkey/script preimage while commiting to a future=20
tx.)<br></span></div><span><div><br></div><div><span>&gt; Sorry for being s=
arcastic, but at this point it&#39;s not fair to use quantum-computer FUD t=
o justify the</span></div><span>&gt; activation of CTV over APO, or encoura=
ge the use of legacy transactions over Taproot ones.</span></span></div><di=
v><span><br></span></div><div><span>Sorry if it came off as FUDing. I don&#=
39;t know enough to hold a strong <span>opinion</span>
 on whether the fear of QCs is justified or not. I know that many people
 on this list don&#39;t think so, but I also think that this fear is=20
prevalent enough to warrant taking it into consideration (at least for=20
features that target <span>long-term </span>SoV use cases; less so for feat=
ures targeted at L2 MoE applications like lightning spacechains paypools et=
c).<br></span></div><div><span><br></span></div><div><span>&gt; <span><span=
> you can also use the internal key optimization .. </span>you can&#39;t ha=
ve NUMS-ness then<br><br></span></span></div><div><span><span>Right, which =
makes this unsuitable for the vaulting use case.<br></span></span></div><sp=
an><div><span><br></span></div><div><span>&gt;</span><span> Also, it&#39;s =
not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness units* (8.25=
 vbytes).</span></div><div><span><br></span></div></span><div><span>Ugh yes=
 sorry about that! I realized after hitting send and meant to clarify that =
it should&#39;ve been <span style=3D"font-family:monospace">s/vbyte/WU/</sp=
an> in my next reply.<br></span></div><div><span><br></span></div><div><spa=
n>&gt; <span>Are APO signatures more expensive to verify? .. <span>the cost=
 for the network of validating signatures already exists today</span></span=
></span></div><div><span><span><br></span></span></div><div><span><span>Not=
 compared to existing signature verifications, but compared to a CTV/TXHASH=
-like construction.</span></span></div><div><span><span><br></span></span><=
/div><div><span><span>Can anyone quantify how much of a difference this mak=
es in practice?<br></span></span></div><span><div><span><br></span></div><d=
iv><span>&gt; <span><span>i appreciate your reply and your efforts to explo=
re the</span><span> tradeoffs between the two approaches.</span></span></sp=
an></div><div><span><span><span><br></span></span></span></div></span><div>=
<span><span><span>Thank you, I appreciate your efforts on this too :-)<br><=
/span></span></span></div><div><span><span><span><br></span></span></span><=
/div><div><span><span><span>shesek<br></span></span></span></div><div><span=
><br></span></div><div><span>[0] <a href=3D"https://github.com/bitcoin/bips=
/blob/master/bip-0119.mediawiki#Batched_Channel_Creation" target=3D"_blank"=
>https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Cha=
nnel_Creation</a></span></div><div><span>[1] <a href=3D"https://github.com/=
bitcoin/bips/pull/1273" target=3D"_blank">https://github.com/bitcoin/bips/p=
ull/1273</a></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Fri, Apr 29, 2022 at 11:31 AM darosior &lt;<a h=
ref=3D"mailto:darosior@protonmail.com" target=3D"_blank">darosior@protonmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div>Hi Shesek,</div><div><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>1. The resulting txids are not stable.</d=
iv></div></blockquote><div><br></div><div>This is *literally* what the post=
 you are replying to is proposing to solve.</div><div><br></div><div><br></=
div><blockquote type=3D"cite"><div dir=3D"ltr"><div>This property could be =
important for some of the proposed CTV use-cases, like channel factories.</=
div></div></blockquote><div><br></div><div></div><span>Hmm? You can&#39;t h=
ave channel factories without Eltoo. (Well, you can in theory but good luck=
.)</span><div><span>Maybe you are refering to non-interactive channel creat=
ion? The case for stable txids is less strong if we</span></div><span>have =
APO (and therefore Eltoo). [0]</span><div><br></div><div><br></div><blockqu=
ote type=3D"cite"><div dir=3D"ltr"><div><div><div>2. APO will only be avail=
able on Taproot, which some people might prefer
 to avoid for long-term multi-decade vault storage due to QC concerns. (als=
o see my previous post on this thread [0])<br></div></div></div></div></blo=
ckquote><div><br></div><div></div><span></span><span>This has been addresse=
d over and over and over again. If a QC is able overnight to spend a large =
fraction of</span><div><span>the supply, your coins in your super non-QC-vu=
lnerable-bare-CTV-covenant (that would eventually become</span></div><div><=
span>vulnerable when trying to use it) are worthless.[1]</span></div><div><=
br></div><div><span>Sorry for being sarcastic, but at this point it&#39;s n=
ot fair to use quantum-computer FUD to justify the</span></div><span>activa=
tion of CTV over APO, or encourage the use of legacy transactions over Tapr=
oot ones.</span><span></span><div></div><div><br></div><div><br></div><bloc=
kquote type=3D"cite"><div dir=3D"ltr"><div><div><div>3. Higher witness sati=
sfaction cost of roughly 3x vbytes vs CTV-in-Taproot (plus 33 extra vbytes =
vs CTV-in-segwitv0 <i>in the case of a single CTV branch</i>, for the tapro=
ot control block. with more branches CTV-in-taproot eventually becomes pref=
erable).</div></div></div></div></blockquote><div><br></div><div></div><spa=
n></span><span>Again, this is what my post discusses. Here are the argument=
s from my post about why i don&#39;t think it&#39;s a big deal:</span><div>=
<br></div><div><span>=C2=A0 =C2=A0 1. You can in this case see CTV as an op=
timization of (tweaked) APOAS. A lot of us are doubtful about CTV</span></d=
iv><div><span>=C2=A0 =C2=A0 =C2=A0 =C2=A0usecases for real people. So much =
that it was even proposed to temporarily activate it to see if it would</sp=
an></div><div><span>=C2=A0 =C2=A0 =C2=A0 =C2=A0ever have any real traction!=
 [2]</span></div><div><span>=C2=A0 =C2=A0 =C2=A0 =C2=A0My point with this p=
ost was: what if we do (a slightly tweaked) BIP118, that is otherwise usefu=
l. And</span></div><div><span>=C2=A0 =C2=A0 =C2=A0 =C2=A0if this use of cov=
enants is really getting traction then we can roll out an optimization in t=
he form of</span></div><div><span>=C2=A0 =C2=A0 =C2=A0 =C2=A0CTV (or better=
 covenants, as we&#39;d have had more research put into it by this time).</=
span></div><div><span>=C2=A0 =C2=A0 2. CTV is mainly sold for its usage ins=
ide vaults. While i&#39;m not convinced, a few more vbytes should not</span=
></div><div><span>=C2=A0 =C2=A0 =C2=A0 =C2=A0matter for this usecase.</span=
></div><div><br></div><div><span>Also, it&#39;s not 33 extra vbytes vs CTV-=
in-segwitv0, but 33 extra * witness units* (8.25 vbytes).</span></div><div>=
<span>Aside, you can also use the internal key optimization with APO. But i=
 don&#39;t think it&#39;s desirable just to save</span></div><span>32 WU, a=
s you can&#39;t have NUMS-ness then. [3]</span><div><br></div><div><br></di=
v><blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div>4. Higher netwo=
rk-wide full-node validation costs (checking a signature is quite more expe=
nsive than hashing, and the hashing is done in both cases).</div></div></di=
v></div></blockquote><div><br></div><div><span>Are APO signatures more expe=
nsive to verify? If not i don&#39;t think this should be a reason to constr=
ain us to a</span><div><span>much less useful construction, as the cost for=
 the network of validating signatures already exists today. Even</span></di=
v><span>if it didn&#39;t, the tradeoff of cost/usefulness needs to be consi=
dered.</span><br></div><div><br></div><div><br></div><blockquote type=3D"ci=
te"><div dir=3D"ltr"><div><div>5. As APO is currently spec&#39;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.</div><div><br></div><div><div>If I&#39;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].</div><div><br></div><div>Fixing this=
 requires amending BIP 118 with some new sigmsg flags (making the ANYONECAN=
PAY behaviour optional, as mentioned in the OP).</div></div></div></div></b=
lockquote><div><br></div><div>Yes! And as i mentioned on Twitter also commi=
tting to the input index which i forgot to add in the OP here.</div><div><b=
r></div><div><br></div><div></div><span><span>While i don&#39;t think the s=
pecific points are valid, i appreciate your reply and your efforts to explo=
re the</span><br><span>tradeoffs between the two approaches.</span><br></sp=
an></div><div><br></div><div><div>Thanks,<br>Antoine</div><div><br><span>[0=
] <span><a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-January/019813.html" target=3D"_b=
lank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/=
019813.html</a><br></span></span></div><div>[1] <span><a rel=3D"noreferrer =
nofollow noopener" href=3D"https://bitcoin.stackexchange.com/a/91050/101498=
" target=3D"_blank">https://bitcoin.stackexchange.com/a/91050/101498</a></s=
pan></div><div><span>[2] <span><a rel=3D"noreferrer nofollow noopener" href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/0202=
42.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2022-April/020242.html</a></span></span><br><span>[3] <span><a rel=
=3D"noreferrer nofollow noopener" href=3D"https://twitter.com/darosior/stat=
us/1518979155362254849?s=3D20&amp;t=3DmGkw7K8mcyQwdLImFvdebw" target=3D"_bl=
ank">https://twitter.com/darosior/status/1518979155362254849?s=3D20&amp;t=
=3DmGkw7K8mcyQwdLImFvdebw</a></span></span><br></div><div><br></div><div><b=
r></div><blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div>This is d=
efinitely possible but also means that APO as-is isn&#39;t a CTV-replacemen=
t candidate, without first going through some more design and review iterat=
ions.</div><div><br></div><div>shesek</div><div><br></div></div></div><div>=
<br></div><div>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2022-April/020326.html" rel=3D"noreferrer nofollow noopener" tar=
get=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-April/020326.html</a></div><div></div><div>[1] <a href=3D"https://github.c=
om/darosior/simple-anyprevout-vault" rel=3D"noreferrer nofollow noopener" t=
arget=3D"_blank">https://github.com/darosior/simple-anyprevout-vault</a></d=
iv><div>[2] <a href=3D"https://twitter.com/shesek/status/151987449343454412=
8" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://twitter.c=
om/shesek/status/1519874493434544128</a></div><div><br></div><div><br></div=
></div><br><div class=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"ltr"=
>On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer nofollow noop=
ener" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">I would like t=
o know people&#39;s sentiment about doing (a very slightly tweaked version =
of) BIP118 in place of<br>
(or before doing) BIP119.<br>
<br>
SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for ove=
r 6 years. It presents proven and<br>
implemented usecases, that are demanded and (please someone correct me if i=
&#39;m wrong) more widely accepted than<br>
CTV&#39;s.<br>
<br>
SIGHASH_ANYPREVOUTANYSCRIPT, if its &quot;ANYONECANPAY&quot; behaviour is m=
ade optional [0], can emulate CTV just fine.<br>
Sure then you can&#39;t have bare or Segwit v0 CTV, and it&#39;s a bit more=
 expensive to use. But we can consider CTV<br>
an optimization of APO-AS covenants.<br>
<br>
CTV advocates have been presenting vaults as the flagship usecase. Although=
 as someone who&#39;ve been trying to<br>
implement practical vaults for the past 2 years i doubt CTV is necessary no=
r sufficient for this (but still<br>
useful!), using APO-AS covers it. And it&#39;s not a couple dozen more virt=
ual bytes that are going to matter for<br>
a potential vault user.<br>
<br>
If after some time all of us who are currently dubious about CTV&#39;s stat=
ed usecases are proven wrong by onchain<br>
usage of a less efficient construction to achieve the same goal, we could r=
oll-out CTV as an optimization.  In<br>
the meantime others will have been able to deploy new applications leveragi=
ng ANYPREVOUT (Eltoo, blind<br>
statechains, etc..[1]).<br>
<br>
<br>
Given the interest in, and demand for, both simple covenants and better off=
chain protocols it seems to me that<br>
BIP118 is a soft fork candidate that could benefit more (if not most of) Bi=
tcoin users.<br>
Actually i&#39;d also be interested in knowing if people would oppose the A=
PO-AS part of BIP118, since it enables<br>
CTV&#39;s features, for the same reason they&#39;d oppose BIP119.<br>
<br>
<br>
[0] That is, to not commit to the other inputs of the transaction (via `sha=
_sequences` and maybe also<br>
`sha_amounts`). Cf <a rel=3D"noreferrer nofollow noopener" href=3D"https://=
github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message" t=
arget=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0118.media=
wiki#signature-message</a>.<br>
<br>
[1] <a rel=3D"noreferrer nofollow noopener" href=3D"https://anyprevout.xyz/=
" target=3D"_blank">https://anyprevout.xyz/</a> &quot;Use Cases&quot; secti=
on<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a><br>
<a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

        </blockquote><br>
    </div></blockquote></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000e270ff05ddfbbaed--