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

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

Re: [bitcoin-dev] Speedy Trial

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

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

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

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

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

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

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

Re: [bitcoin-dev] Speedy Trial

> 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

Re: [bitcoin-dev] Speedy Trial

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

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

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

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

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

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

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

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

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

Re: [bitcoin-dev] Speedy Trial

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

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

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

[bitcoin-dev] Bitcoin Core 23.0 released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Bitcoin Core version 23.0 is now available from: Or through BitTorrent:

[bitcoin-core-dev] Bitcoin Core 23.0 released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Bitcoin Core version 23.0 is now available from: Or through BitTorrent:

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

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

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

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

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

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

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

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

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

@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

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

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?