pull down to refresh

Its time to talk about something controversial. CheckTemplateVerify by Jeremy Rubin...is actually pretty good. Yes, the developer has a rotten personality, but his personality will not be merged with Bitcoin is his open source code is soft forked in. I'm getting ahead of myself though, lets start with TBDXXX
What does TBDXXX actually do?
TBDxxx presents an innovative approach to achieving Chaumian e-cash-like behavior without relying on a trusted mint. The current proposal uses APO, while APO can be used to synthesize CTV, CTV is more concise, it’s a 32 byte hash vs a signature, and it’s faster due to sha2 vs ecc operations. 1
I'm bringing this up for a few reasons:
  1. The community has shown interest in federated e-cash mints as a way to minimize trust
a. I believe multiple e-cash mints would result in Gresham's law wherein dishonest mints print e-cash (bad money) which is treated as though it has the same value as honest mints (good money). b. These mints being centralized entities means they serve as an easier point of attack for governments and advanced persistent threats
  1. People keep complaining about lightning a. Sure you can open a channel, but for someone who didn't feel the need to open a channel when fees were low, opening a channel suddenly costs $20 equivalent in sats b. You can't do cold storage with lightning, and if high fees were to become the norm, replacing the block subsidy, all cold storage users would have to pay high fees to take that little bit out of the emergency fund.
On the topic of the mempool, CTV could also help us with that
What this means practically is that by unbundling spending from redeeming we can serve a much greater number of users that if they were one aggregate product because we are taking the “expensive part” and letting it happen later than the “cheap part”. And if we do this cleverly, the “setting up the milk line” in the splitting of the spend allows all receivers to know they will get their fair share later. 2
We also know that we want to scale lightning using channel factories, however, since channel factories and TBDXXX both require either BIP 118 or BIP 119, its not really a choice between channel factories or TBDXXX, its rather a choice between BIP 118 or BIP 119
we can create a single Bitcoin tx that is n - of - n multisig which enables us to do multiparty channels with n participants in 1 transaction. So if you take n=40 we can onboard 8bn people in 1 year. If you choose n=480 we can do it in 1 month. So let's keep fingers crossed for that Bitcoin upgrade.
-Rene Pickhardt5
So how does CTV have your back with channel factories?
Now in the spirit of of not allowing for any surprises, people felt betrayed with Taproot because it allowed people to mint NFTs and outright shitcoin's using Bitcoin's blockspace. Shitcoiners have been doing this for a long time, whether it be RGB, color coins, Taro, Stamps, or Inscriptions. Yes, CTV (and APO because their use cases overlap so much) allow for the creation of new types of shitcoins and scams. The developer of CTV even goes so far as to promote them.
Jeremy Rubin is such a pain in the ass, the biggest roadblock to his own code. All I'm here to argue today, is that the massive benefits of this guy's code, outweigh the negatives (including his incredibly heavy ego as difficult as that may be to believe)
CTV was initially controversial because the developer suggested using speedy trial and pushed with his ego when the community pushed back on the idea. However, the activation method the developers desires is not a prerequisite for its implementation. We very well can soft fork CTV using an activation method that is against the developer's wishes because it is open source code after all.
I've bombarded you with enough information for now. Next time, lets do a deep dive into the technical differences between APO and CTV.
Sources:

Footnotes

Good write up. I know there's a lot of ways to skin the cat, but having something APO-like will be huge for lightning / layer 2 stuff. I know more about APO than any of the CTV or OP_VAULT stuff, but perhaps one of them can achieve similar end goals. It's all so hard to invest the effort in learning any of it when I've been waiting on APO since I heard of it in 2019.
I'm intrigued by TBDXXX, but relying on it and pushing for it is how we get into the push backs we have before. Same thing with all the imaginary chains off of bitcoin proposals.
If you're building a company or product that relies on a soft fork, you're simply NGMI. Might have worked on the early days of segwit which everyone knew we needed but it won't work again. Hopefully TBDXXX can do some things normally and unique before then and can take advantage of any softfork if and when one comes.
reply
I know where you're coming from Tony. I'm just looking forward and into the future. Bringing some things that are in the works to the community's attention. The hope being, if we have an informed Bitcoin community, that community will feel more comfortable about a soft fork.
reply
CTV was initially controversial because the developer suggested using speedy trial and pushed with his ego when the community pushed back on the idea. However, the activation method the developers desires is not a prerequisite for its implementation. We very well can soft fork CTV using an activation method that is against the developer's wishes because it is open source code after all.
We should delineate here. There were really two main points in time where CTV was (implicitly) rejected: once when Jeremy tried to get it into Bitcoin Core, and then again when he announced he would publish an alt client with CTV activation parameters implemented.
In the second instance, CTV was rejected not because of speedy trial (Taproot used speedy trial and did not get that same pushback) it was rejected because there were people either mistakenly or intentionally misrepresenting it, and that caused other people to be against its activation by any means.[1][2] In that context, speedy trial was just fuel on the fire and made it a hard no for even more people.
But that activation attempt only came after months of the CTV PR languishing in the Bitcoin Core repo. It was ready to be merged but the maintainers would not merge it. So prior to the outcry by misinformed, non-technically savvy plebs, we have to go back to the root of why was CTV not merged into Bitcoin Core in the first place. Why did Jeremy feel like he had to push for a speedy trial using his own alt client to get CTV activated? I haven't seen a good post mortem on this. I think we need to address whatever was the root cause blocking rough consensus among core devs for merging into Bitcoin Core before we can discuss new activation parameters.
Next time, lets do a deep dive into the technical differences between APO and CTV.
There has been some of this already.[3][4] What questions do you think remain unanswered? And there are still other covenant proposals, any reason for leaving those out?[5]
reply
There is a vocal percentage of Bitcoiners who are against speedy trial and that ran UASF clients during taproot. But remember, even though the average person didn't know a lot about taproot, they felt as though they were informed.
For most people, CTV came out of nowhere. They hadn't heard or read anything about it (not even a cartoon picture with its name on it like lol) so to those people, some dev was trying to pull a fast one. Andreas Antonopoulos when explaining why it was such a big deal, speculated on some things that it might do (because he hadn't read the BIP yet) and used those examples to say "so those things that we don't know yet are why we need more time to review it". His speculative examples, like that it might be recursive (it isn't) are the examples people use to misrepresent it and that's why I think he's actually the source of those misrepresentations.
So what I'm trying to do now is get the community to the point that it feels educated on the subject matter.
Why didn't I cover other proposals. Well for one I don't know about them lol. I'm focusing on how they apply to channel factories and with as little speculation as I can, tbdxxx and the sources I've linked are what I found on those subjects so far.
reply
Does the unbounding of spending from redeeming not lead to a total increase in block space compared to todays transaction sizes? Seems like discounting the size of the latter half makes for an unfair comparison.
reply
I don't know the answer to this and I'll have to look into more, but good question thank you
reply
I made an update :).
The Enigma Network
reply
Now in the spirit of of not allowing for any surprises, people felt betrayed with Taproot because it allowed people to mint NFTs and outright shitcoin's using Bitcoin's blockspace.
Please stop spreading this, it's really not true. Taproot makes, realistically at best a 15%ish change in the cost of using witness space in this way; segwit is what enables a lot of extra space usage, i.e. much larger blocks; that 15% difference would not stop people if they really wanted to do it.
I say that tangentially to this post, most of which is super-interesting and high quality but it's terrible that this meme has embedded itself (rather as, ironically, in 2017, the meme that segwit=still 1MB embedded itself, and everyone got upset about that!).
reply
Yes they could have done it with just segwit and Stamps does it without segwit as does color coins, but taproot did allow them to script them in using the manner that they do.
The larger point, is that shitcoiners are gonna shitcoin and that we should be upfront about all of the impacts a BIP might have when having community discussion about it.
Even larger point to me, we should not shut down a BIP purely on the basis of shitcoin enablement if that BIP has massive benefits to us. On the other hand, shutting down a BIP whose only use case is shitcoin enablement is understandable.
reply
Lets do APO and CTV
reply
I'm studying them both in depth right now. I'll be by with another article exploring how the use case overlaps work on each one and how each one works on a fundamental level.
reply
Why not? Because the simpler we keep the protocol the safer it is. Maybe adding one pays for itself though. Looking forward to your next article!
reply