Hi Peter,
> that current lacks compelling use-cases clearly beneficial to all users
All the use cases shared in below links look compelling enough to me and we can
do anything that a programmer could think of using such restrictions:
https://utxos.org/uses/
https://rubin.io/archive/
> I don'
> Since scriptpubkeys/scriptsigs continue to run ephemerally at validation
time full turing completeness is much less dangerous than people fear.
The covenant proposals I've seen that might give bitcoin turing
completeness require a turing complete process to be stepped such that each
step is a t
I agree with you Michael, there is a risk to soft forks and we shouldn't do
them too often. We should do them as infrequently as practical. We should
strive to one day get to a point where the bitcoin consensus isn't updating
at all.
Perhaps we should come to a consensus as a consensus as a commun
Do you have any back-of-the-napkin math on quantifying how much this would
improve the situation vs existing methods (eg cpfp)?
On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Happy new years devs,
>
> I figured I would share some thoughts
I agree removing any ambiguity would be good. I'd also like to see removal
of words that are a strict subset of another word. Words like add (which is
a subset of addict and address).
As far as entropy loss, I think even with an 1000 word list and a 12 word
seed, it would be unlikely in a time far
Can you clarify what you mean by "improve the situation"?
There's a potential mild bytes savings, but the bigger deal is that the API
should be much less vulnerable to pinning issues, fix dust leakage for
eltoo like protocols, and just generally allow protocol designs to be fully
abstracted from p
On Tue, Jan 18, 2022 at 7:10 AM Billy Tetrud wrote:
> > Since scriptpubkeys/scriptsigs continue to run ephemerally at
> validation time full turing completeness is much less dangerous than people
> fear.
>
> The covenant proposals I've seen that might give bitcoin turing
> completeness require a
@vjudeu
> If you introduce signing into mining, then you will have cases, where
someone is powerful enough to produce blocks, but cannot, because signing
is needed.. your consensus is no longer "the heaviest chain"
You've misunderstood my suggestion. This would not be possible with what I
sugges
> We should strive to one day get to a point where the bitcoin consensus isn't
> updating at all.
That day is nowhere near IMO and maybe we won't see it in my lifetime.
> Perhaps we should come to a consensus as a consensus as a community what the
> minimum time between soft forks should be, an
tl;dr: I don't think CTV is ready yet (but probably close), and in any case
definitely not worth reviving BIP 9 with its known flaws and vulnerability.
My review here is based solely on the BIP, with no outside context (aside from
current consensus rules, of course). In particular, I have _not_
I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.
The only material distinction between BIP9 and BIP8 is that the latter may
activate without signaled support of hash power enforcement.
As unenforced soft forks are n
On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote:
> The only material distinction between BIP9 and BIP8 is that the latter may
> activate without signaled support of hash power enforcement.
>
> As unenforced soft forks are not "backward compatible" they produce a chain
> split.
Enforceme
> -Original Message-
> From: Luke Dashjr
> Sent: Tuesday, January 18, 2022 2:10 PM
> To: e...@voskuil.org
> Cc: 'Bitcoin Protocol Discussion'
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote:
> > The only material distinction betw
Hi Luke,
This is the first competent review for CTV based on my understanding. I would
not mention controversial things in this email but nobody cares about scammers
and we will review everything irrespective of personal or legal attacks on
developers because some people are prepared for it and
Thanks for the detailed review.
I'll withhold comment around activation logic and leave that for others to
discuss.
w.r.t. the language cleanups I'll make a PR that (I hope) clears up the
small nits later today or tomorrow. Some of it's kind of annoying because
the legal definition of covenant is
The issue with sighash flags is that because you make transactions third
party malleable it becomes possible to bundle and unbundle transactions.
This means there are circumstances where an attacker could e.g. see your
txn, and then add a lot of junk change/inputs + 25 descendants and strongly
anc
Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE like
proposals.
For what you're discussing, I previously proposed
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
which is similar.
The benefit of the OP_VER output is that SIGHASH_EXTERNAL h
17 matches
Mail list logo
