jeremyrubin / utxos.org Goto Github PK

I do appreciate all the work done concerning BIP-119 but, trying to activate it now is way too early in my opinion. More research and community feedback is needed and it shouldn't be rushed like it currently is. Not only that but Jeremy's will to activate it as soon as possible is very worrisome and suggest hidden motives that may be against Bitcoin's best interest.

I will be against BIP-119 activation until at least the next 2 years to give enough time to come up with a non-rush plan, community support, and enough research proving that BIP-119 is, not only worth adding but the best way to do it.

Seccour (a simple individual)

I appreciate all the hard work you have put into Bitcoin (CTV and otherwise) - (I sponsor you and will continue to do so :) ). So this is not personal but out of a desire to do what is best for Bitcoin.

You are not even close to gaining consensus on the proposal. You are the only Core dev in support of the proposal (and you are the author, so that is a given). Many devs have come out and spoken out against the proposal. There has not been sufficient time to research all the alternatives proposed, and new ones continue to be discovered. Once a new opcode is introduced, it must remain in Bitcoin's consensus forever, so this should not be a light decision we make.

I am very concerned that you have already proposed signalling.

I previously ACKed the proposal on your website, so would like to change my support to No.

Thank you.

I was hoping to avoid "soft signaling" No for CTV as I was looking forward to seeing progress in the coming months and years on various CTV related research topics: vaults, eltoo constructions, payment pools etc. I was also looking forward to exploring these topics in greater depth myself. But rather than doing that my thoughts are turning to what happens when what I believe will be a contentious soft fork activation is attempted most likely at some stage next year.

I fundamentally disagree that the research, experimentation and community understanding is sufficiently advanced to be attempting a soft fork to activate CTV in the coming months which the primary promoter (Jeremy Rubin) of CTV has indicated he will be attempting. This research and experimentation should mature before considering activation especially for new opcodes where all the potential value is in how useful they are for their speculated use cases. A long list of use cases with primitive proofs of concept is not the standard we should be expecting before considering the activation of an opcode (or multiple opcodes). Ignoring the risks of attempting a contentious soft fork, activating an opcode that could end up not being used if turns out alternatives are better is a colossal waste of community time. There is considerable uncertainty currently on whether CTV is the best tool for the job on any of its listed use cases. This work takes time as we are seeing with eltoo using ANYPREVOUT but the answer is not to skip this painstaking work and say we'll figure it out later post activation. This work could end up with changes to the initial soft fork proposal but if that work is left to after activation it is too late.

I also think attempting regular soft forks with single features is a disturbing pattern to get into having just activated Taproot. As I say in the linked post it means less and less community scrutiny of consensus changes, it becomes a full time job to monitor the regular soft forks being activated (or attempting to be activated) and only a tiny minority of the community can dedicate the time to do that.

Hence I'd like to register a "No" soft signal as I fundamentally disagree that a CTV soft fork should be attempted in the near future and my concerns over premature activation outweigh my enthusiasm for digging into the speculated real world use cases of CTV.

I pledge my allegiance to the BIP 119, and for the OP_CTV for which it stands, one BIP under the BIP document editors, indivisible with utxos, covenants, and neat stuff for all.

Name ZmnSCPxj jxPCSnmZ
Supports Yes
Affiliations Randomly-generated Internet People

🚀

As a merchant and user i expect features, that might open doors to restricting the use of bitcoin in unforeseable ways, to not end up being pushed that fast and I do not like the idea you talked about at MIT to involve the blockchain to support a lot of speciality use cases in the future as well.
So far not even taproot is fully implemented everywhere and it was integrated quite a while ago.
I see this as a distraction in focus on what the blockchain should be.

I do see a certain need for the features but I do not see any of them as urgent nor belonging where you want them.

Generally, I do not think Bitcoin is ready for any new soft forked features at all in the short term. Taproot just arrived and there is already so much work to be done to adopt and utilize it.

Any improvements CTV-eltoo may bring to LN are not significant enough to claim they are urgent for adoption or R&D for LN progress and adoption.

As a non-engineer, yet more expert than the average Bitcoiner, I feel that covenants are not widely understood and I worry deeply that encumbering Bitcoin in such ways could have unforeseen consequences to the network, supply, and incentive structure.

Since I am not qualified, nor are 99% of Bitcoiners, to evaluate this deeply, I feel much more time and scrutiny is required to accept CTV and the related projects Jeremy has prepared with it.

Furthermore, my position and lack of expertise, requires me to use trust signals to assess the situation, and Jeremy has been extremely aggressive in his promotion and persuasion to garner support for CTV, going so far as to frustrate Core devs during Taproot activation debates by trying to inject CTV into the conversation for consideration prematurely. This signaling tells me that, at best, his aggressive desire may even cause him to gloss over potential issues, and at worst, it tells me his incentives for including CTV may not have Bitcoiners' best interests at heart.

I am currently happy with what we have in Bitcoin, and would prefer Core development prioritize optimizations and cleanup work over more and more features that have no urgent need or chance of adoption anytime soon.

Therefore I cannot support CTV as a soft fork proposal in 2022, as a personal user, nor as CEO for Synonym.

Yes for support.

Dennis Porto (@pourteaux) - GP, Huat Ventures & early Bitcoiner

George (@George203BTC)
Yes
https://twitter.com/George203BTC/status/1724583791014855055?t=YN0Y4__1Wbdy1iu0KMzIcg&s=19
No affiliations.

Count me in.

Maybe I'm misunderstanding something but is there a mistake in the congestion control graphic?

Under "Batched Transactions" the "Option A" TX has 16 blue change UTXOs and 1 pink payment UTXO. Shouldn't that be the other way round? So 16 pink payment UTXOs and 1 blue change UTXO?

https://twitter.com/zndtoshi/status/1688457700504453120?t=8XaQGrz_pmqKczPjpjPUJw&s=19

Name: Yehuda "Jay" Berg
Supports: "Yes"
Affiliations: "Founder Protoblock, Inc."

@jaybny
@protoblock

I would like to be added as an individual supporter for BIP-119. No affiliation. Chris Kapilla

The work done in this area is in its beginning phases and it is unclear if CTV is the best method forward at this point. I do appreciate all of the work you've done and this may be the correct path to take in the future but I do not believe there is sufficient need, or demand, to push this through at this time.

We should never rush changes to Bitcoin.