Good morning Dave, et al.,
I have not read through *all* the mail on this thread, but have read a fair
amount of it.
I think the main argument *for* this particular idea is that "it allows the use
of real-world non-toy funds to prove that this feature is something actual
users demand".
An
On April 21, 2022 5:10:02 AM GMT+02:00, alicexbt via bitcoin-dev
wrote:
>@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
>
Hi Dave,
I think the transitory idea is interesting, though I would say it would
take far more thinking to capture the implications.
> 1. It creates a big footgun. Anyone who uses CTV without adequately
preparing for the reversion could easily lose their money.
I think that downside should be
Hi TheBlueMatt,
>> There are at least three or four separate covenants designs that have
>>> been posted to this list, and I don't see why we're even remotely
>>> talking about a specific one as something to move forward with at
>>> this point.
>>
>>> To my knowledge none of these other proposals
If none of the alternative proposals have been developed as much as CTV, it
seems reasonable to interpret that as a lack of interest in those
alternative proposals themselves.
That should not be interpreted as lack of interest in covenants. Perhaps if
CTV didn't exist, we would have seen more
On 4/21/22 6:20 PM, David A. Harding wrote:
[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,
On 4/22/22 9:28 AM, James O'Beirne wrote:
> There are at least three or four separate covenants designs that have
> been posted to this list, and I don't see why we're even remotely
> talking about a specific one as something to move forward with at
> this point.
To my knowledge none of
> The enumeration of covenants uses here excludes vaulting,
> which I see as far and away the highest utility use for covenants
Apologies for the double post, but I need to caveat this.
To be more accurate, I see "coin pools" as the most potentially
valuable use of covenants, since we need to
> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> certain usecases (respectively: Eltoo, congestion control, and
> joinpools)
The enumeration of covenants uses here excludes vaulting,
which I see as far and away the highest utility use for covenants given
that it allows
> There are at least three or four separate covenants designs that have
> been posted to this list, and I don't see why we're even remotely
> talking about a specific one as something to move forward with at
> this point.
To my knowledge none of these other proposals (drafts, really) have
actual
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
[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
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
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
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
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
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
> 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
@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
On Thursday 21 April 2022 06:20:15 Jeremy Rubin wrote:
> > While reverting Segwit wouldn't be possible, it IS entirely possible to
> > do an additional softfork to either weigh witness data at the full 4
> > WU/Byte rate (same as other data), or to reduce the total weight limit so
> > as to extend
> While reverting Segwit wouldn't be possible, it IS entirely possible to
do an
> additional softfork to either weigh witness data at the full 4 WU/Byte
rate
> (same as other data), or to reduce the total weight limit so as to extend
the
> witness discount to non-segwit transactions (so scriptSig
On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?
Generally, no. Reverting a softfork without a built-in expiry would be a
hardfork.
> Example: Some
1-2 can be mitigated to some extent by encoding an expiry height in the
address (and pubkey?), and honouring CTV for UTXOs during the active period.
It might take longer to remove CTV code post-deactivation, but that's simply
a tradeoff to consider.
The bigger issue with CTV is the
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
2. An unused CTV will need to be supported forever, creating
25 matches
Mail list logo
