Re: [bitcoin-dev] What to expect in the next few weeks

[Jeremy Rubin via bitcoin-dev]

The reason there was not a mailing list post is because that's not a
committed plan, it was offered up for discussion to a public working group
for feedback as a potential plan. You've inaccurately informed the list on
something no one has communicated committed intent for. This was an
alternative discussed in the telegram messaging app but did not seem to
strike the correct balance so was not furthered.

I was hoping to be able to share something back to this list sooner rather
than later, but I have not been able to get, among those interested to
discuss in that venue, coherence on a best next step. I communicated
inasmuch on the bird app
https://twitter.com/JeremyRubin/status/1518347793903017984
https://twitter.com/JeremyRubin/status/1518477022439247872, but do not have
a clear next step and am pouring over all the fantastic feedback I
received so far.

Further, you're representing the state of affairs as if there's a great
need to scramble to generate software for this, whereas there already are
scripts to support a URSF that work with the source code I pointed to from
my blog. This approach is a decent one, even though it requires two things,
because it is simple. I think it's important that people keep this in mind
because that is not a joke, the intention was that the correct set of check
and balance tools were made available. I'd be eager to learn what,
specifically, you think the advantages are of a separate binary release
rather than a binary + script that can handle both cases? I'm asking
sincerely because I would make the modifications to the release I prepared
to support that as well, if they do not entail substantial technical risk.
Personally, were I aligned with your preferences, I'd be testing the
forkd script and making sure it is easy to use as the simplest and most
effective way to achieve your ends.

regards,

Jeremy

--
@JeremyRubin 

On Mon, Apr 25, 2022 at 3:44 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The latest I'm hearing (this mailing list appears to be being bypassed in
> favor of personal blogs and messaging apps) is that Speedy Trial miner
> signaling for the contentious CTV soft fork is no longer going to start on
> May 5th (as previously communicated [1]) and may instead now start around
> August 1st 2022.
>
> Hence for now the drama seems to have been averted. I am deeply skeptical
> that in the next 3 months this soft fork activation attempt will obtain
> community consensus and will no longer be contentious (although I guess
> theoretically it is possible). As a result I suspect we'll be in the exact
> same situation with a URSF effort required 2-3 months down the line.
>
> If we are I'll try to keep the mailing list informed. It is important
> there is transparency and ample time to research and prepare before making
> decisions on what software to run. Obviously I have no control over what
> others choose to do. Please don't be rushed into running things you don't
> understand the implications of and please only signal for a soft fork if
> you are convinced it has community consensus (what should precede signaling
> as it did for Taproot) and you are ready to activate a soft fork.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev
>  wrote:
>
> As I said in my post:
>
> "If you care about Bitcoin's consensus rules I'd request you pay
> attention so you can make an informed view on what to run and what to
> support."
>
> Ideally everyone would come to an informed view independently.
> Unfortunately many people don't have the time to follow Bitcoin drama 24/7
> and hence struggle to separate noise from signal. In this case simple
> heuristics are better than nothing. One heuristic is to listen to those in
> the past who showed good judgment and didn't seek to misinform. Of course
> it is an imperfect heuristic. Ideally the community would be given
> sufficient time to come to an informed view independently on what software
> to run and not be rushed into making decisions. But it appears they are not
> being afforded that luxury.
>
> >  I fear you risk losing respect in the community
>
> I appreciate your concern.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <
> billy.tet...@gmail.com> wrote:
>
> > assuming people pay attention and listen to the individuals who were
> trusted during that period
>
> Bitcoin is not run by a group of authorities of olde. By asking people to
> trust "those.. around in 2015-2017" you're asking people 

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via bitcoin-dev 
wrote:
> > Semi-mandatory in that only "threshold" blocks must signal, so if
> only 4% or 9% of miners aren't signalling and the threshold is set
> at 95% or 90%, no blocks will be orphaned.
> How do nodes decide on which blocks are orphaned if only some of them have
> to signal, and others don't? Is it just any block that would cause the
> whole threshold period to fail?

Yes, exactly those. See [0] or [1].

[0] 
https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling

[1] https://github.com/bitcoin/bips/pull/1021
(err, you apparently acked that PR)

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What to expect in the next few weeks

[Michael Folkson via bitcoin-dev]

The latest I'm hearing (this mailing list appears to be being bypassed in favor 
of personal blogs and messaging apps) is that Speedy Trial miner signaling for 
the contentious CTV soft fork is no longer going to start on May 5th (as 
previously communicated [1]) and may instead now start around August 1st 2022.

Hence for now the drama seems to have been averted. I am deeply skeptical that 
in the next 3 months this soft fork activation attempt will obtain community 
consensus and will no longer be contentious (although I guess theoretically it 
is possible). As a result I suspect we'll be in the exact same situation with a 
URSF effort required 2-3 months down the line.

If we are I'll try to keep the mailing list informed. It is important there is 
transparency and ample time to research and prepare before making decisions on 
what software to run. Obviously I have no control over what others choose to 
do. Please don't be rushed into running things you don't understand the 
implications of and please only signal for a soft fork if you are convinced it 
has community consensus (what should precede signaling as it did for Taproot) 
and you are ready to activate a soft fork.

[1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev 
 wrote:

> As I said in my post:
>
> "If you care about Bitcoin's consensus rules I'd request you pay attention so 
> you can make an informed view on what to run and what to support."
>
> Ideally everyone would come to an informed view independently. Unfortunately 
> many people don't have the time to follow Bitcoin drama 24/7 and hence 
> struggle to separate noise from signal. In this case simple heuristics are 
> better than nothing. One heuristic is to listen to those in the past who 
> showed good judgment and didn't seek to misinform. Of course it is an 
> imperfect heuristic. Ideally the community would be given sufficient time to 
> come to an informed view independently on what software to run and not be 
> rushed into making decisions. But it appears they are not being afforded that 
> luxury.
>
>> I fear you risk losing respect in the community
>
> I appreciate your concern.
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud 
>  wrote:
>
>>>  assuming people pay attention and listen to the individuals who were 
>>> trusted during that period
>>
>> Bitcoin is not run by a group of authorities of olde. By asking people to 
>> trust "those.. around in 2015-2017" you're asking people to blindly trust 
>> authorities. This, in my strong opinion, goes against the bitcoin ethos, and 
>> is an incredibly harmful way to push for your agenda. I'd very much 
>> recommend you reassess the way you're going about what you're trying to do. 
>> I fear you risk losing respect in the community by implying without any 
>> evidence that certain people are "taking advantage" of some situation and 
>> attempting "to confuse".
>>
>> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev 
>>  wrote:
>>
>>> If the next few weeks go how I fear they will it could get messy. If you 
>>> care about Bitcoin's consensus rules I'd request you pay attention so you 
>>> can make an informed view on what to run and what to support. For those of 
>>> you who were around in 2015-2017 you'll know what to expect. The right 
>>> outcome endured in 2017 and I'm sure the right outcome will endure here 
>>> assuming people pay attention and listen to the individuals who were 
>>> trusted during that period. There are always a large number of motivated 
>>> parties who are incentivized to break nodes off from Bitcoin and may seek 
>>> to take advantage of a contentious soft fork activation attempt.
>>>
>>> Remember that if all the information is presented to users in a clear way 
>>> well ahead of time then they can make their own mind up. I fear that things 
>>> will be made as convoluted as possible in a way intended to confuse and 
>>> information will be withheld until the last minute. When in doubt it is 
>>> generally better to rely on the status quo and tried and trusted. In this 
>>> case that would be Bitcoin Core. Alternative releases such as those seeking 
>>> to attempt to activate CTV or indeed those seeking to resist the activation 
>>> of CTV really should only be considered if you are informed on exactly what 
>>> you are running.
>>>
>>> If you are interested in the effort to resist the contentious soft fork 
>>> activation attempt of CTV please join ##ursf on Libera IRC.
>>>
>>> Have a good 

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor via bitcoin-dev]

On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud  wrote:

> @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).
>

So my understanding is that the COV proposal in MES lets you check that the
output's scriptPubKey matches the corresponding script item from the stack,
but the script item's value additionally allows some wildcard values.  In
particular, it makes use of the otherwise reserved opcodes OP_PUBKEY, and
OP_PUBKEYHASH as wildcards representing any, let's say, 32-byte or 20-byte
push value.

If you just used COV by itself, then these wildcards would be third-party
malleable, but you also have to sign the transaction with the hot wallet
key, which removes the malleability.

No need to rotate anything into place.

I hope this makes sense.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Nadav Ivgi via bitcoin-dev]

On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@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@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
> ,
> 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 

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland via bitcoin-dev]

> BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.

Thanks for the clarification.

> Semi-mandatory in that only "threshold" blocks must signal, so if
only 4% or 9% of miners aren't signalling and the threshold is set
at 95% or 90%, no blocks will be orphaned.

How do nodes decide on which blocks are orphaned if only some of them have
to signal, and others don't? Is it just any block that would cause the
whole threshold period to fail?

Keagan

On Mon, Apr 25, 2022 at 11:00 AM Anthony Towns  wrote:

> On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Under *any* other circumstance, when they're used to activate a bad
> soft
> > > fork, speedy trial and bip8 are the same. If a resistance method works
> > > against bip8, it works against speedy trial; if it fails against speedy
> > > trial, it fails against bip8.
> > IIRC one essential difference between ST (which is a variant of BIP9) and
> > BIP8 is that since there is no mandatory signaling during the lockin
> > period,
>
> BIP8 doesn't have mandatory signaling during the lockin period, it has
> semi-mandatory [0] signalling during the must_signal period.
>
> > you can't do a counter soft fork as easily.
>
> The "counter" for bip8 activation is to reject any block during either
> the started or must_signal phases that would meet the threshold. In that
> case someone running bip8 might see blocks:
>
>   [elapsed=2010, count=1813, signal=yes]
>   [elapsed=2011, count=1813, signal=no]
>   [elapsed=2012, count=1814, signal=yes]
>   [elapsed=2013, count=1815, signal=yes, will-lockin!]
>   [elapsed=2014, count=1816, signal=yes]
>   [elapsed=2015, count=1816, signal=no]
>   [elapsed=2016, count=1816, signal=no]
>   [locked in!]
>
> But running software to reject the soft fork, you would reject the
> elapsed=2013 block, and any blocks that build on it. You would wait for
> someone else to mine a chain that looked like:
>
>   [elapsed=2013, count=1814, signal=no]
>   [elapsed=2014, count=1814, signal=no]
>   [elapsed=2015, count=1814, signal=no]
>   [elapsed=2016, count=1814, signal=no]
>   [failed!]
>
> That approach works *exactly* the same with speedy trial.
>
> Jeremy's written code that does exactly this using the getdeploymentinfo
> rpc to check the deployment status, and the invalidateblock rpc to
> reject a block. See: https://github.com/JeremyRubin/forkd
>
> The difference to bip8 with lot=true is that nodes running speedy trial
> will reorg to follow the resisting chain if it has the most work. bip8
> with lot=true nodes will not reorg to a failing chain, potentially
> creating an ongoing chain split, unless one group or the other gives up,
> and changes their software.
>
> Cheers,
> aj
>
> [0] Semi-mandatory in that only "threshold" blocks must signal, so if
> only 4% or 9% of miners aren't signalling and the threshold is set
> at 95% or 90%, no blocks will be orphaned.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev 
wrote:
> > Under *any* other circumstance, when they're used to activate a bad soft
> > fork, speedy trial and bip8 are the same. If a resistance method works
> > against bip8, it works against speedy trial; if it fails against speedy
> > trial, it fails against bip8.
> IIRC one essential difference between ST (which is a variant of BIP9) and
> BIP8 is that since there is no mandatory signaling during the lockin
> period, 

BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period. 

> you can't do a counter soft fork as easily.

The "counter" for bip8 activation is to reject any block during either
the started or must_signal phases that would meet the threshold. In that
case someone running bip8 might see blocks:

  [elapsed=2010, count=1813, signal=yes]
  [elapsed=2011, count=1813, signal=no]
  [elapsed=2012, count=1814, signal=yes]
  [elapsed=2013, count=1815, signal=yes, will-lockin!]
  [elapsed=2014, count=1816, signal=yes]
  [elapsed=2015, count=1816, signal=no]
  [elapsed=2016, count=1816, signal=no]
  [locked in!]

But running software to reject the soft fork, you would reject the
elapsed=2013 block, and any blocks that build on it. You would wait for
someone else to mine a chain that looked like:

  [elapsed=2013, count=1814, signal=no]
  [elapsed=2014, count=1814, signal=no]
  [elapsed=2015, count=1814, signal=no]
  [elapsed=2016, count=1814, signal=no]
  [failed!]

That approach works *exactly* the same with speedy trial.

Jeremy's written code that does exactly this using the getdeploymentinfo
rpc to check the deployment status, and the invalidateblock rpc to
reject a block. See: https://github.com/JeremyRubin/forkd

The difference to bip8 with lot=true is that nodes running speedy trial
will reorg to follow the resisting chain if it has the most work. bip8
with lot=true nodes will not reorg to a failing chain, potentially
creating an ongoing chain split, unless one group or the other gives up,
and changes their software.

Cheers,
aj

[0] Semi-mandatory in that only "threshold" blocks must signal, so if
only 4% or 9% of miners aren't signalling and the threshold is set
at 95% or 90%, no blocks will be orphaned.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi via bitcoin-dev]

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@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

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi via bitcoin-dev]

darosior via bitcoin-dev wrote:

> 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.

Some potential vault users looking to store funds for long time periods
(say of decades) might have quantumphobia and prefer to avoid Taproot for
that reason.

One of the arguments presented for not using pubkey hashes in Taproot is
that quantumphobic people could choose to continue using non-Taproot
outputs. Making a feature that's targeted for long-term cold-storage vaults
available on Taproot only might be less ideal in that view.

Cheers
shesek

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

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior via bitcoin-dev]

Just a correction to my previous mail. Sorry for the non-attribution, i didn't 
recall APO covenants had been discussed in the context of CTV.

> > a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in 
> the CTV hash are very close to what

The comparison was already done by Anthony Towns.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017036.html

Jeremy Rubin already pointed out that it missed committing to the nSequences 
hash and number of inputs (and optionally scriptSigs).
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html


--- Original Message ---
Le lundi 25 avril 2022 à 3:35 PM, darosior via bitcoin-dev 
 a écrit :


> Hi Richard,
>
> > Sounds good to me. Although from an activation perspective it may not be 
> > either/or, both proposals do
>
> compete for scarce reviewer time
>
> Yes, of course. Let's say i was more interested in knowing if people who 
> oppose CTV would oppose
> SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this 
> point is premature.
>
> > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be 
> > optional to emulate CTV? Is there
>
> a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in 
> the CTV hash are very close to what
> ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV 
> commits to that APO_AS does not are
> the number of inputs and the hash of the inputs' sequences [1].
> Not committing to the number of inputs and other inputs' data is today's 
> behaviour of ANYONECANPAY that can
> be combined with other signature hash types [1]. Thus APO_AS makes ACP 
> mandatory, and to emulate CTV
> completely it should be optional.
>
>
> Antoine
>
> [0] 
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
> [1] 
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> [2] 
> https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327,
>  
> https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522
>
>
> --- Original Message ---
> Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers remy...@yakshaver.org a 
> écrit :
>
>
>
> > Hi darosior,
> >
> > Thanks for sharing your thoughts on this.
> >
> > > I would like to know people's sentiment about doing (a very slightly 
> > > tweaked version of) BIP118 in place of
> > > (or before doing) BIP119.
> >
> > Sounds good to me. Although from an activation perspective it may not be 
> > either/or, both proposals do compete for scarce reviewer time so their 
> > ordering will necessarily be driven by reviewer's priorities. My priority 
> > is eltoo which is why I focus on BIP-118.
> >
> > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made 
> > > optional [0], can emulate CTV just fine.
> >
> > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be 
> > optional to emulate CTV? Is there a write-up that explains how APO-AS w/out 
> > ANYONECANPAY approximates CTV?
> >
> > In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to 
> > late-bind fees; that means ANYONECANPAY will always be paired with APO-AS 
> > for eltoo. Settlement txs in eltoo use just APO and do not necessarily need 
> > to be paired with ANYONECANPAY.
> >
> > I would guess making ANYONECANPAY the default for APO-AS was a way to 
> > squeeze in one more sighash flag. Perhaps there's another way to do it?
> >
> > Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically 
> > so the counter-party who commits a settlement tx can use for fees their 
> > settled to_self balance. How to rejigger the sighash flags to accommodate 
> > both APO and GROUP may be worth some discussion.
> >
> > The BIP-118 proposal will certainly benefit from having input from 
> > reviewers looking at other protocols than eltoo.
> >
> > -- Richard
>
> ___
> 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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)

[Buck O Perley via bitcoin-dev]

Just a couple of comments re-CTV vault security concerns.


1. One way to assuage the concern of the hot wallet vulnerability
is pre-program the spends such that the hot wallet can only
spend a certain amount from the hot wallet spend and the rest would
kind of be "recursive" in that it would be sent back to a
new instantiation of the CTV vault. I believe kanzure's vaults
does this w/ the non-covenant version using pre-signed transactions
(https://github.com/kanzure/python-vaults). While this doesn't
prevent the theft it caps off the total risk. I would argue that
this is strictly better than a multisig because you can also use
multisig as you normally would if you want but you have the option
if you think your hot key is secure to use that spending path.
You also get the nice benefit of learning about compromised
keys without having to risk all funds associated with that key.


2. As to how to improve UX for CTV with other proposals, I think
you get a lot of benefits when using with taproot because you can
use CTV in tapleaves to secure specific spend conditions, but can
always fall back to other off-ramps (e.g. a musig key path spend or
other script path conditions). Of course you can do this without
taproot but taproot makes this more space efficient. This idea has
been used to some effect in some recent exploration of how CTV can
help improve UX around DLCs. You could even do this to help with
the problems of not sending the right amount such that you have a
really really cold key or set of keys for example such that if you
have UTXOs that have values that can't be spent with the given CTV
commitment, then you just use that other branch.

- Buck

--- Original Message ---

> Date: Sun, 24 Apr 2022 18:03:52 -0500
> From: Billy Tetrud billy.tet...@gmail.com
> 

> To: "Russell O'Connor" rocon...@blockstream.com, Bitcoin Protocol
> 

> Discussion bitcoin-dev@lists.linuxfoundation.org
> 

> Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> ("transitory") soft forks)
> Message-ID:
> cagppwdaekyabkk+stfxoxgwehvgzqy02kpgofjott9w8upr...@mail.gmail.com
> 

> Content-Type: text/plain; charset="utf-8"
> 

> @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 

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland via bitcoin-dev]

Hi AJ,

> Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.

IIRC one essential difference between ST (which is a variant of BIP9) and
BIP8 is that since there is no mandatory signaling during the lockin
period, you can't do a counter soft fork as easily. This is one of the
points that Luke mentioned to me that made clear the benefits of the
mandatory signaling. A variant of ST that does require mandatory signaling
may actually be something that can improve the process and give users a
more effective means of forking away from SF changes that they reject.

Keagan

On Sun, Apr 24, 2022 at 12:58 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns  wrote:
>
>> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
>> > You're not even considering user resistance in your cases.
>>
>> Of course I am. Again:
>>
>
> No, you're relying on miners to stop bad proposals.
>
>
>> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
>> > > attempting activation via bip8 is *never* superior to speedy trial,
>> > > and in some cases is worse.
>> > >
>> > > If I'm missing something, you only need to work through a single
>> example
>> > > to demonstrate I'm wrong, which seems like it ought to be easy... But
>> > > just saying "I disagree" and "I don't want to talk about that" isn't
>> > > going to convince anyone.
>>
>> The "some cases" where bip8 with lot=true is *worse* than speedy trial
>> is when miners correctly see that a bad fork is bad.
>>
>> Under *any* other circumstance, when they're used to activate a bad soft
>> fork, speedy trial and bip8 are the same. If a resistance method works
>> against bip8, it works against speedy trial; if it fails against speedy
>> trial, it fails against bip8.
>>
>
> You're wrong.
>
>
>> > Sorry for the aggressive tone, but I when people ignore some of my
>> points
>> > repeteadly, I start to wonder if they do it on purpose.
>>
>> Perhaps examine the beam in your own eye.
>>
>
> Yeah, whether you do that yourself or not: sorry, it's over.
>
>
>> Cheers,
>> aj
>>
> ___
> 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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[alicexbt via bitcoin-dev]

Hi Peter and Zac,

> I like the maxim of Peter Todd: any change of Bitcoin must benefit all
> users. This means that every change must have well-defined and transparent
> benefits. Personally I believe that the only additions to the protocol that
> would still be acceptable are those that clearly benefit layer 2 solutions
> such as LN and do not carry the dangerous potential of getting abused by
> freeloaders selling commercial services on top of “free” eternal storage on
> the blockchain.
>
> To strengthen your point: benefiting "all users" can only be done by 
> benefiting layer 2 solutions in some way, because it's inevitable that the 
> vast majority of users will use layer 2 because that's the only known way 
> that Bitcoin can scale.

- CTV does not allow bitcoin blockchain to be used as storage
- CTV will benefit layer 2 solutions: lightning, sidechains, spacechain etc.
- Every L2 is dependent on L1 and soft forks could improve things that benefit 
both

There are a few emails with information that could be interpreted in a wrong 
way on this mailing list related to CTV or creating contentious environment. I 
had expected better things from bitcoin developers. This is not just the 
opinion of someone who supports CTV but even people who are trying to read 
things and form an opinion: 
https://nitter.net/NicolasDorier/status/1518407535480705024

I am sure there are lot of positives if we look at things differently and will 
end the email on a good note:

You might like Jeremy or hate him, however he took some real efforts in working 
on CTV, Sapio etc. and even if BIP 119 never gets activated his contribution in 
bitcoin covenants will always be appreciated.

/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

[bitcoin-dev] Bitcoin Core 23.0 released

[W. J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 23.0 is now available from:

  

Or through BitTorrent:

   
magnet:?xt=urn:btih:32bc317cce76b966a26bdb53d42f64d66d595954=bitcoin-core-23.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.15+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

Notable changes
===

P2P and network changes
- ---

- - A bitcoind node will no longer rumour addresses to inbound peers by default.
  They will become eligible for address gossip after sending an ADDR, ADDRV2,
  or GETADDR message. (#21528)

- - Before this release, Bitcoin Core had a strong preference to try to connect 
only to peers that listen on port 8333. As a result of that, Bitcoin nodes 
listening on non-standard ports would likely not get any Bitcoin Core peers 
connecting to them. This preference has been removed. (#23542)

- - Full support has been added for the CJDNS network. See the new option 
`-cjdnsreachable` and 
[doc/cjdns.md](https://github.com/bitcoin/bitcoin/tree/23.x/doc/cjdns.md) 
(#23077)

Fee estimation changes
- --

- - Fee estimation now takes the feerate of replacement (RBF) transactions into
  account. (#22539)

Rescan startup parameter removed
- 

The `-rescan` startup parameter has been removed. Wallets which require
rescanning due to corruption will still be rescanned on startup.
Otherwise, please use the `rescanblockchain` RPC to trigger a rescan. (#23123)

Tracepoints and Userspace, Statically Defined Tracing support
- -

Bitcoin Core release binaries for Linux now include experimental tracepoints 
which
act as an interface for process-internal events. These can be used for review,
debugging, monitoring, and more. The tracepoint API is semi-stable. While the 
API
is tested, process internals might change between releases requiring changes to 
the
tracepoints. Information about the existing tracepoints can be found under
[doc/tracing.md](https://github.com/bitcoin/bitcoin/blob/23.x/doc/tracing.md) 
and
usage examples are provided in 
[contrib/tracing/](https://github.com/bitcoin/bitcoin/tree/23.x/contrib/tracing).

Updated RPCs
- 

- - The `validateaddress` RPC now returns an `error_locations` array for invalid
  addresses, with the indices of invalid character locations in the address (if
  known). For example, this will attempt to locate up to two Bech32 errors, and
  return their locations if successful. Success and correctness are only 
guaranteed
  if fewer than two substitution errors have been made.
  The error message returned in the `error` field now also returns more specific
  errors when decoding fails. (#16807)

- - The `-deprecatedrpc=addresses` configuration option has been removed.  RPCs
  `gettxout`, `getrawtransaction`, `decoderawtransaction`, `decodescript`,
  `gettransaction verbose=true` and REST endpoints `/rest/tx`, `/rest/getutxos`,
  `/rest/block` no longer return the `addresses` and `reqSigs` fields, which
  were previously deprecated in 22.0. (#22650)
- - The `getblock` RPC command now supports verbosity level 3 containing 
transaction inputs'
  `prevout` information.  The existing `/rest/block/` REST endpoint is modified 
to contain
  this information too. Every `vin` field will contain an additional `prevout` 
subfield
  describing the spent output. `prevout` contains the following keys:
  - `generated` - true 

[bitcoin-core-dev] Bitcoin Core 23.0 released

[W. J. van der Laan via bitcoin-core-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 23.0 is now available from:

  

Or through BitTorrent:

   
magnet:?xt=urn:btih:32bc317cce76b966a26bdb53d42f64d66d595954=bitcoin-core-23.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.15+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

Notable changes
===

P2P and network changes
- ---

- - A bitcoind node will no longer rumour addresses to inbound peers by default.
  They will become eligible for address gossip after sending an ADDR, ADDRV2,
  or GETADDR message. (#21528)

- - Before this release, Bitcoin Core had a strong preference to try to connect 
only to peers that listen on port 8333. As a result of that, Bitcoin nodes 
listening on non-standard ports would likely not get any Bitcoin Core peers 
connecting to them. This preference has been removed. (#23542)

- - Full support has been added for the CJDNS network. See the new option 
`-cjdnsreachable` and 
[doc/cjdns.md](https://github.com/bitcoin/bitcoin/tree/23.x/doc/cjdns.md) 
(#23077)

Fee estimation changes
- --

- - Fee estimation now takes the feerate of replacement (RBF) transactions into
  account. (#22539)

Rescan startup parameter removed
- 

The `-rescan` startup parameter has been removed. Wallets which require
rescanning due to corruption will still be rescanned on startup.
Otherwise, please use the `rescanblockchain` RPC to trigger a rescan. (#23123)

Tracepoints and Userspace, Statically Defined Tracing support
- -

Bitcoin Core release binaries for Linux now include experimental tracepoints 
which
act as an interface for process-internal events. These can be used for review,
debugging, monitoring, and more. The tracepoint API is semi-stable. While the 
API
is tested, process internals might change between releases requiring changes to 
the
tracepoints. Information about the existing tracepoints can be found under
[doc/tracing.md](https://github.com/bitcoin/bitcoin/blob/23.x/doc/tracing.md) 
and
usage examples are provided in 
[contrib/tracing/](https://github.com/bitcoin/bitcoin/tree/23.x/contrib/tracing).

Updated RPCs
- 

- - The `validateaddress` RPC now returns an `error_locations` array for invalid
  addresses, with the indices of invalid character locations in the address (if
  known). For example, this will attempt to locate up to two Bech32 errors, and
  return their locations if successful. Success and correctness are only 
guaranteed
  if fewer than two substitution errors have been made.
  The error message returned in the `error` field now also returns more specific
  errors when decoding fails. (#16807)

- - The `-deprecatedrpc=addresses` configuration option has been removed.  RPCs
  `gettxout`, `getrawtransaction`, `decoderawtransaction`, `decodescript`,
  `gettransaction verbose=true` and REST endpoints `/rest/tx`, `/rest/getutxos`,
  `/rest/block` no longer return the `addresses` and `reqSigs` fields, which
  were previously deprecated in 22.0. (#22650)
- - The `getblock` RPC command now supports verbosity level 3 containing 
transaction inputs'
  `prevout` information.  The existing `/rest/block/` REST endpoint is modified 
to contain
  this information too. Every `vin` field will contain an additional `prevout` 
subfield
  describing the spent output. `prevout` contains the following keys:
  - `generated` - true 

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior via bitcoin-dev]

Hi Richard,

> Sounds good to me. Although from an activation perspective it may not be 
> either/or, both proposals do
compete for scarce reviewer time

Yes, of course. Let's say i was more interested in knowing if people who oppose 
CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this 
point is premature.


> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be 
> optional to emulate CTV? Is there
a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?

I'm not aware of any specific to CTV. It's just that the fields covered in the 
CTV hash are very close to what
ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV 
commits to that APO_AS does not are
the number of inputs and the hash of the inputs' sequences [1].
Not committing to the number of inputs and other inputs' data is today's 
behaviour of ANYONECANPAY that can
be combined with other signature hash types [1]. Thus APO_AS makes ACP 
mandatory, and to emulate CTV
completely it should be optional.


Antoine

[0] 
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
[1] 
https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
[2] 
https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327,
 
https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522


--- Original Message ---
Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers  a 
écrit :


> Hi darosior,
>
> Thanks for sharing your thoughts on this.
>
> > I would like to know people's sentiment about doing (a very slightly 
> > tweaked version of) BIP118 in place of
> > (or before doing) BIP119.
>
>
> Sounds good to me. Although from an activation perspective it may not be 
> either/or, both proposals do compete for scarce reviewer time so their 
> ordering will necessarily be driven by reviewer's priorities. My priority is 
> eltoo which is why I focus on BIP-118.
>
> > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made 
> > optional [0], can emulate CTV just fine.
>
>
> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be 
> optional to emulate CTV? Is there a write-up that explains how APO-AS w/out 
> ANYONECANPAY approximates CTV?
>
> In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to 
> late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for 
> eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be 
> paired with ANYONECANPAY.
>
> I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze 
> in one more sighash flag. Perhaps there's another way to do it?
>
> Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so 
> the counter-party who commits a settlement tx can use for fees their settled 
> to_self balance. How to rejigger the sighash flags to accommodate both APO 
> and GROUP may be worth some discussion.
>
> The BIP-118 proposal will certainly benefit from having input from reviewers 
> looking at other protocols than eltoo.
>
> -- Richard
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Hampus Sjöberg via bitcoin-dev]

Hi pushd.
Would you mind clarifying what you mean by BIP118 being a premature idea?
SIGHASH_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was
first proposed in the original Lightning Network whitepaper back in 2015.
It has been discussed on and off for many years now. I would not call it a
premature idea.

Now, the revised "Taprooted" version called ANYPREVOUT is a couple of years
old, so going with the NOINPUT version could be a safer bet (though that's
a bit ridiculous in my opinion).

Regarding that you do not find use-cases interesting. That's all fine I
suppose, but in the Lightning Network scene, I think it's fair to say that
there's widespread enthusiasm in getting a working eltoo solution, which
necessitates something like NOINPUT/ANYPREVOUT.
And even if eltoo wouldn't happen, enabling spacechains, covenants and
blind statechains seem like sufficient use-cases to me.

Cheers
Hampus

On Fri, Apr 22, 2022 at 9:32 PM pushd 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.
>
>
> NACK for the below reasons:
>
> - Premature idea
> - I do not find use cases interesting
> - We are still in research phase of implementing covenants in bitcoin and
> looking for the best proposal
> - Taproot soft fork was recently activated and its too soon
> - Not enough documentation available
> - Could not find any pull request in core for BIP 118 that can be reviewed
> - Not enough tools available for testing
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> --- Original Message ---
> On Friday, April 22nd, 2022 at 5:30 PM,
> bitcoin-dev-requ...@lists.linuxfoundation.org wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> --
>
> Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +
> From: darosior daros...@protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev@lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
>
> p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com
>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
> --
>
> Subject: Digest Footer
>
> 

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Zac Greenwood via bitcoin-dev]

On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj  wrote

CTV *can* benefit layer 2 users, which is why I switched from vaguely
> apathetic to CTV, to vaguely supportive of it.


Other proposals exist that also benefit L2 solutions. What makes you
support CTV specifically?

Centrally documenting the implications of each side by side and point by
point might be a useful next step. This would enable a larger part of the
community to understand each proposal and may reduce repetition and
misunderstandings on this list.

Once a common understanding of the implications of each proposal is in
place, their tradeoffs can be considered, facilitating creating consensus
on which proposal benefits a maximum of users.

Zac
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Erik Aronesty via bitcoin-dev]

>
>
> 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.
>

makes sense that byte-efficiency would be likely less important to vault
users vs lightning noninteractive channel users


>
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>

a smaller code change that seems much less controversial
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Billy Tetrud via bitcoin-dev]

@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
,
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@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 

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[ZmnSCPxj via bitcoin-dev]

Good morning Zac,

> On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj  wrote
>
> > CTV *can* benefit layer 2 users, which is why I switched from vaguely 
> > apathetic to CTV, to vaguely supportive of it.
>
>
> Other proposals exist that also benefit L2 solutions. What makes you support 
> CTV specifically?

It is simple to implement, and a pure `OP_CTV` SCRIPT on a P2WSH / P2SH is only 
32 bytes + change on the output and 32 bytes + change on the input/witness, 
compared to signature-based schemes which require at least 32 bytes + change on 
the output and 64 bytes + change on the witness ***IF*** they use the Taproot 
format (and since we currently gate the Taproot format behind actual Taproot 
usages, any special SCRIPT that uses Taproot-format signatures would need at 
least the 33-byte internal pubkey revelation; if we settle with the old 
signature format, then that is 73 bytes for the signature).
To my knowledge as well, hashes (like `OP_CTV` uses) are CPU-cheaper (and 
memory-cheaper?) than even highly-optimized `libsecp256k1` signature 
validation, and (to my knowledge) you cannot use batch validation for 
SCRIPT-based signature checks.
It definitely does not enable recursive covenants, which I think deserve more 
general research and thinking before we enable recursive covenants.

Conceptually, I see `OP_CTV` as the "AND" to the "OR" of MAST.
In both cases, you have a hash-based tree, but in `OP_CTV` you want *all* these 
pre-agreed cases, while in MAST you want *one* of these pre-agreed cases.

Which is not to say that other proposals do not benefit L2 solutions *more* 
(`SIGHASH_ANYPREVOUT` when please?), but other proposals are signature-based 
and would be larger in this niche.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev