On 21.04.2022 14:28, Anthony Towns wrote:
But, if [it's true that "many [...] use cases [...] to use CTV for
are very long term in nature"], that's presumably incompatible
with any sort of sunset that's less than many decades away, so doesn't
seem much better than just having it be available on a
[Rearranging Matt's text in my reply so my nitpicks come last.]
On 21.04.2022 13:02, Matt Corallo wrote:
I agree, there is no universal best, probably. But is there a concrete
listing of a number of use-cases and the different weights of things,
plus flexibility especially around forward-looking
On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev wrote:
> I can probably make some show up sometime soon. Note that James' vault uses
> one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> think the second use of it (since it's not segwit wrapped) wouldn't
On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev
wrote:
> The main criticisms I'm aware of against CTV seem to be along the following
> lines: [...]
> Could those concerns be mitigated by making CTV an automatically reverting
> consensus change with an option to renew?
On 4/21/22 3:28 PM, David A. Harding wrote:
On 21.04.2022 08:39, Matt Corallo wrote:
We add things to Bitcoin because (a) there's some demonstrated
use-cases and intent to use the change (which I think we definitely
have for covenants, but which only barely, if at all, suggests
favoring one co
On 21.04.2022 08:39, Matt Corallo wrote:
We add things to Bitcoin because (a) there's some demonstrated
use-cases and intent to use the change (which I think we definitely
have for covenants, but which only barely, if at all, suggests
favoring one covenant design over any other)
I'm unconvinced
I think I've discussed this type of concept previously somewhere but cannot
find a link to where.
Largely, I think the following:
1) This doesn't reduce burden of maintenance and risk of consensus split,
it raises it:
A) as we now have a bunch of tricky code around reorgs and mempool
around th
On 4/21/22 11:06 AM, David A. Harding wrote:
On 21.04.2022 04:58, Matt Corallo wrote:
On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
The main criticisms I'm aware of against CTV seem to be along the following
lines:
1. Usage, either:
a. It won't receive significant real-worl
Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy
thought that there would be a Speedy Trial signaling period for a CTV soft fork
planned to start on May 5th [1]. That is two weeks away.
(I have to take what he says at face value. I can understand why one would be
On 21.04.2022 04:58, Matt Corallo wrote:
On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
The main criticisms I'm aware of against CTV seem to be along the
following lines:
1. Usage, either:
a. It won't receive significant real-world usage, or
b. It will be used but we'll end
Hi Russell,
Thank you for your feedback here.
> However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
> that bare-CTV hasn't even appeared on the CTV signet). Unlike the general
> smart-contracting case, bare-CTV does not have any branches. All it can do
> is commit to a
On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
Hi all,
The main criticisms I'm aware of against CTV seem to be along the following
lines:
1. Usage, either:
a. It won't receive significant real-world usage, or
b. It will be used but we'll end up using something better later
Ironically assumptions of bad faith are going to kill any proposal,
resulting in the status quo.
Let's keep the assumption of good faith, unless you are actually accusing
people of being a NSA-adjacent asset.
On Thu, Apr 21, 2022 at 10:08 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfound
> There are a number of individuals who have stated opposition to attempting to
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
sheshek found some issues with the list and some of them are not really an
opposition for CTV.
On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> - is there really any benefit to doing it as a NOP vs a taproot-only
>opcode like TXHASH? Theoretically, sure, that saves some bytes; but as
>was pointed out on #bitcoin-wizar
> You'd be confiscating your own funds by making an absurd spending
condition.
> By this argument, ALL softforks would have to be ruled out.
The argument is that transactions which can be relayed and in the mempool
and then confirmed should not ever be restricted.
This is so that old node's mempo
On Wed, 20 Apr 2022 at 15:49, Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries
Hi Michael,
Sorry, if my critique of your opinions feels too personal to you. This is
nothing personal. As you probably know, one of the most effective attack
vectors on Bitcoin is to target the social layer by sabotaging the protocol
development[1]. Bike shedding is an easy way to cause a lot
Hi Michael,
I'm sympathetic to the idea of allowing time for the community to absorb,
review, analyze, discuss, etc any new substantial change to bitcoin,
especially consensus changes. I certainly think that over time the
frequency of soft forks should generally go down on average, with
ossificati
@DavidHarding
Interesting proposal to revert consensus changes. Is it possible to do this for
soft forks that are already activated?
Example: Some users are not okay with witness discount in segwit transactions
https://nitter.net/giacomozucco/status/1513614380121927682
@LukeDashjr
> The bigge
20 matches
Mail list logo
