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 w
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 progr
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,
plu
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 t
Hi Luke,
> But none of this ST nonsense, please. That alone is a reason to oppose it.
Agree. Any soft fork that uses only speedy trial should be opposed. There are
few other reasons to oppose it as well:
- Premature idea
- Use cases are not interesting for all users
- We are still in research p
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 out
> 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
On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This vault design (https://github.com/jamesob/simple-ctv-vault)
> is a good benchmark for evaluating covenant proposals because it's (i)
> simple and (ii) has high utility for many use
> 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 add
There's no reason for before/after/in place. We have version bits specifically
so we can have multiple deployments in parallel.
But none of this ST nonsense, please. That alone is a reason to oppose it.
Luke
On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev wrote:
> I would like to kno
> 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 signi
> 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 i
>*A change that increases the number of use cases of Bitcoin affects all
users and is *not* non-invasive. More use cases means more blockchain usage
which increases the price of a transaction for *everyone*.*
This manages to be both incorrect and philosophically opposed to what
defines success of
Hi,
Richard Myers has an implementation of Eltoo using Bitcoin Core's functional
test framework:
https://github.com/remyers/bitcoin/blob/eltoo-anyprevout/test/functional/simulate_eltoo.py.
He blogged about it, too. https://yakshaver.org/2021/07/26/first.html
He seems to have something similar f
Good morning darosior,
Do you know if there is a working implementation of APO somewhere that people
can use to try out some of the proposed usecases? For example, it would be
great to see what eltoo would actually look like on an APO signet. Or to see
some working code for a vault using covena
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 s
I'm going to keep this short as I'm sure you are not interested in discussion
on supposedly "unhinged" takes. Plus I know you support this soft fork
activation attempt, you have heard the arguments from various people against
attempting it and if you don't believe by now that soft forks should h
On Fri, 22 Apr 2022 at 09:56, Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think that trying to find ways to activate non-invasive changes should
> be everyone's goal, *even if* they personally may not have an immediate use
> case
>
A change that increases
small note, it's a savings of 34 or 67 bytes *per histogram bucket* to have
bare CTV v.s. v0/v1, so the interesting thing is that by making it cheaper
bytes wise it might enable one to have, for the same byte budget, more
buckets, which would make the feerate savings for the user even greater.
E.g.
Good day Michael,
> and discuss working on an additional release that if run may ultimately
reject blocks that signal for CTV.
This seems silly to me.
The structure of CTV is imbuing an OP_NOP with script semantics. Resisting
changes that don't affect you is not consistent with the ideals of peo
> nobody's going to benefit from that possibility anyway.
James O'Beirne's simple-ctv-vault appears to be using bare CTV outputs:
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca2
22 matches
Mail list logo
