The worst thing for bitcoin over the past 5 years has been a lack of decent enemies. Which attack is best for bitcoin in the long term?

Trump didn't start any new wars.

Dishwashers use 1-2 gallons of water for a full load. About as much as running your sink for 1 minute. They also use less energy than heating even a couple more gallons. They are among the most efficient appliances imaginable. It's wasteful not to use one.

I see that you have elected to ban Hamas affiliated accounts, but not those of the IDF. How can you be confident that one is a terrorist organization and the other is not. To my eye, they both seem to violate international law and murder civilians.

You're too smart for this. Knots is maintained and signed by one dude who pushes code straight to master and has previously failed to secure his secret keys. Also the filters in knots do nothing but slow your node down unless 99% of the network adopts them. Don't be a fool.

₿ 0.00,283,947 Fade the leading 0s, but show them to help people develop comfort with the relationship between sats and bitcoin. I find it really helpful to have the fixed-precision representation - always 8 digits after the decimal.

I wrote about the history of bitcoin incentive improvements, including the witness discount. bitcoinmagazine.com/technica…

When will people stop giving non-technical, ignorant folks like Mechanic airtime about nuanced technical issues?

BIP352 Silent Payments addresses are amazing. I know we're all used to BIP32 extended public keys and extended private keys (xpub and xpriv), but hear me out. With an xpub/xpriv setup, you have exactly 2 levels of disclosure for your keys. You give anyone who wants to send you bitcoin the same information and you use that information in your watch-only wallet. Only your spend wallet has the secret that allows it to spend all of those coins. With Silent Payments, you disclose to senders (or the world) something which lets them pay you, but gives them no other information about you whatsoever. Your watch-only wallet has one a secret that lets it find all of your coins. Your spending wallet has a secret that lets it spend all of those coins. Splitting the wallet 3-ways like this is a fundamental improvement. It also 100% resolves the issues of gap limits with BIP32 wallets. BIP352 wallets scan each eligible transaction in each block since their birth and can cryptographically locate any payment they can spend. Study BIP352. Implement BIP352.

Dude. Have the grace to come back to bitcoin with some humility after the market has proven you wrong for years.

I'd like to publicly say a big thank you to @coryswan, @skwp and everyone at @Swan for the opportunity to work with the team on Swan Vault for the past year. We had a great year and launched an amazing product for Swan customers who are ready to enter the world of assisted self sovereign custody. As many already know, I've moved on from Swan and am aiming to pursue bitcoin education and development going forward. My main goals for the next year are to write more long form articles explaining various bitcoin topics, especially about bitcoin script and upgrades thereto, and to get more involved in the development of bitcoin node software. I'll also put at least a bit more effort into my weekly spaces and hosting local bitcoin events. If anyone wants to directly support my efforts, here's a silent payments address. Please keep in mind that I might suck at this. sp1qqwkt0aetchmm5gzucxych7l7kxaevetpx7npe54e236zqv73jevr5qucy5pgnut9fm7syjmlqv9ykm3qzzpfc0v3j737plzvvuy8k08a4scn62wl

Saylor pretending he has actual bitcoin is hilarious.

Listening to Luke and Mechanic is literally the greatest number of lies per minute I've ever heard. I almost cannot believe this level of dishonesty exists in the world.

Running a bitcoin node doesn't give you power. It gives you sovereignty. Sovereignty to choose whether to be in consensus or not. Sovereignty to have a reliable view of the open relay network or not. Not power to force your rules on others.

CTV+CSFS is the consensus path for bitcoin. LNHANCE may end up being the activation path for CTV+CSFS because it reduces waste of both sigops and bytes (otherwise, a next step). CCV a year or two later will be a great next step. CAT is the fallback fatalist option.

Truer words have rarely been spoken.

Enjoy your fork coin.

Always remember Satoshi's Law. If they say bitcoin dies unless <thing>, they are trying to scam you.

Would be hilarious if one of these blue stranglehold states goes Trump. Vote just in case :)

Listening the the recently ended @BitcoinMagazine spaces conversation between @brian_trollz and @LynAldenContact really hammered home the need for a new way of talking about upgrades for bitcoin. Lyn repeatedly brought up a difference between "more expressive" and "less expressive" script improvements and claimed a connection between "less expressive" and conservatism or caution or safety. This, however, nearly entirely incorrect. First, let's address the idea that less expressive is safer. As Shinobi pointed out, we have a less expressive script system on bitcoin right now, which has led us to build risky systems such as Lightning Penalty rather than safer ones such as Lightning Symmetry. The limited expressiveness is leading people to invest resources in risky pegs like BitVM rather than pursuing safer ones such as CatVM. Whether "less expressive" is more cautious than "more expressive", I think this is the strongest argument and aligns well with @ajtowns's post about team slow and steady. The more locking conditions are available in bitcoin script, the more analysis must be done to ensure against node DOS or block verification time attacks and similar. My objection to Lyn's approach here is more in the presumption that anyone proposing any change to bitcoin isn't being cautious. Literally everyone making any serious push toward improving bitcoin's scripting is starting with caution, but for some reason Lyn and others (who are not themselves professional programmers) make an odd presumption to the contrary. Regarding conservatism, I'll echo Hans Herman Hoppe (when discussing modern political conservatism): any meaningful definition of conservatism must be aimed at conserving something meaningful and worth conserving. Therefore, conservatism can require significant deviation from current. For bitcoin, the Script Restoration Project is the most conservative change one could possibly pursue because it aims to conserve the ideals of self custody and user sovereignty over their locking conditions. Ossification is the antithesis of conservatism because it throws away the original ideals of bitcoin in favor of trusted third parties and centralized dictat over user behavior. In light of all of this, I think we should shift our way of talking about upgrades to bitcoin from how "expressive" they are to how much "freedom of locking" they provide to users. Bitcoin users should have access to nearly any locking condition they desire for their bitcoin. Much like I refuse to participate in politics, I don't think that bitcoin protocol developers should be in the business of telling users how they can lock their bitcoin. We must, of course, defend bitcoin's decentralization and nodes foremost, but if a change to user locking behavior doesn't negatively impact those, they should have that freedom. That is the message of the Script Restoration Project - "Freedom of Locking".

Sounds like a W! Keep it up :)

He's showing the institution more respect than it deserves.

Ouch. UTXO management matters. Accepting tiny deposits on chain is expensive. Hey @coinbase, you considered using Lightning network instead of losing millions of dollars?

I will be running Libre Relay (possibly with my own patches) v30. Thus nullifying literally everyone else not running v30.

Bitcoin University is in the dictionary as the defining example of pleb slop.

Commercial gear is the only answer.

Satoshi's law: In any debate, the side claiming that bitcoin will die if you don't follow them is wrong. I've fallen prey to this law in the past, thankfully I have good friends who keep me grounded.

Received Bitcoin on Ark in seconds!

If you think bitcoin is going to usher in your personal fantasy of an idealized culture, you're wrong. Bitcoin is fuck you money, and that includes you, personally.

Today I flew solo for the first time. Lotta work to get here and plenty still ahead. Big milestone toward achieving something I've long dreamed about but didn't truly expect to come true. Learned a ton about myself and about living through learning to fly, highly recommended.

Luke's recent comments and actions represent an unacceptable risk to bitcoin users at this point. Cc @achow101 @fanquake

I very nearly cannot believe they flipped and landed softly using that flap. Frankly, this test flight makes me extremely optimistic about the future safety and re-usability of the vehicle.

ROFL. Just got 900 of the 1000 USD that MtGox owed me. Nearly a decade later. Had to give trashpal my SSN so they can snitch to the feds that I might owe income tax on my $100 loss over 10 years.

Some personal opinions on the relative power and risk of various things being proposed for bitcoin's future: Risk of a bug in the code itself (low to high): CAT CTV APO LNHANCE (CTV+CSFS+INTERNALKEY) VAULT MATT (CCV/CHECKCONTRACTVERIFY) TXHASH Risk of an undesirable script behavior (low to high): CTV LNHANCE APO VAULT MATT (CCV) TXHASH CAT Total expressiveness of resulting scripts: CAT MATT (CCV) VAULT TXHASH LNHANCE APO CTV Ease of scripting with: CTV LNHANCE VAULT APO TXHASH MATT (CCV) CAT (for covenants, it's easy for normal CAT things) #LNHANCE

Thank you, bitcoin core maintainers. @glozow @achow101 and the rest

I've appreciated the feedback that I can sometimes come across as FUDing when I say that bitcoin will die if it ossifies. Let's be perfectly clear (and I said most of this on @stephanlivera): If bitcoin ossifies as it is, I think it'll be good money for a decade or two before being captured by central bankers and governments through their regulatory processes. It may continue to help folks in the worst countries, and in the worst situations; but it will not transform the world through better money. If your goal for bitcoin is to be good money for 1 generation then ossify. Mine is for it to be good money for a century or more. If your goal is for bitcoin to be a better wealth preservation method for the 1% then ossify. Mine is for it to be better wealth preservation for everyone. If your goals align with mine, show me how a protocol that supports only 10-100 million key holders can resist state capture; or show me how CTV is not the best next step in growing the number of potential key holders.

piped.video/watch?v=lsp8sdGG… This vidja makes some interesting arguments about drum brakes for everyday EVs. Obv. not for high performance track capable machines.

Heading home from @TheBitcoinConf. Optimistic about the future of bitcoin. Pessimistic about the future of usgov.

Just a guess here: With the larger satellite, they can afford to carry more propellant. They'll therefore target the same ~5y replacement rate that they do on the current satellites. That cycle is very sustainable with the revenue of the business (I did the math a couple years ago) and lets them refresh the tech on the satellites on a normal tech cycle.

What's it called when one side thinks it's a war and the other is unaffected?

This. is. huge. We've been talking about this as a possibility since the very beginning of Ark, but seeing it in code already is well beyond my most optimistic expectations. Huge. Massive. Enormous. Congrats!

Your ex girlfriend.

CTV, APO, LNHANCE, TXHASH, CCV, VAULT, etc. have failed to gain consensus because they are variously framed by both what they do enable and what they deliberately avoid enabling (e.g. CTV and LNHANCE avoid enabling Drivechains, but do enable coinpools and lightning symmetry respectively). This has resulted in in-fighting with everyone wanting to enable their thing, but still trying to avoid enabling some other thing. As part of the discussion in ATX, I asked the group what specifically we want to avoid enabling. Within that group, at least, there were only two answers: we want to avoid enabling turing complete scripts (to ensure that we can statically analyze all scripts), and we want to avoid enabling anything that can increase validation costs for nodes. With that change in framing, there was further discussion about not only what is enabled but how, which was part of Rusty's presentation: If we enable hashrate escrows via BIP300, we're kinda boxing ourselves into that way of doing pegs because it's in the protocol. If we enable hashrate escrows as part of a broader improvement in script, we are also enabling much better ways of doing pegs that are more use friendly. The how matters, not only the what. Now we can talk about how we want to enable things, and this is where the Great Script Restoration comes in. How we improve bitcoin is by engineering the best version of script that we can. What this enables is any developer to validate their contracts on bitcoin as long as they don't unfairly burden nodes (i.e. their validation cost per byte doesn't exceed that of checksig). ---- So, what are the pros and cons? Pros: * Much more useful script, able to express user intents more clearly and with less trust (e.g. a user can directly encode spend size limits or vault-delays in their UTXO). * Enabling 2nd layer protocols such as Ark, CatVM, Lightning Symmetry and more. * Avoiding the horse trading and pork barrelling of different smaller proposals * More efficient taproot contracts when no internal public key is needed * (probably) Simplified off chain signature aggregation thanks to x+parity keys Cons: * More work due to the larger scope * (probably) New address type will split the taproot anonymity set * Enables some types of protocols which have historically concerned some people (e.g. hashrate escrows) You can kinda see why this idea has many feeling very enthusiastic. Rather than fighting over whether this or that protocol is best for Ark or BitVM or Lightning, the Great Script Restoration makes them all great, and many more that we haven't even thought of yet. All we have to do is accept those 3 fairly small (IMO) downsides (and the last one many of the other proposals had any way).

Fortunately, the case is simple: - CTV cuts many DLC signing costs by 10x - CTV cuts Ark signing cost from n+logn to n - CSFS makes statechains immortal - CTV+CSFS enables rebindable channels (Eltoo/Lightning Symmetry/etc) - CTV+CSFS simplifies PTLCs - both are well understood conceptually - CTV improves on current vaults - CSFS enables delegation - CTV simplifies payment pools - both compose cleanly with any future upgrades but also stand alone - both can be extended with additional key types (CSFS) or hash modes (CTV) Due to their simplicity, there is little opportunity for unexpected negative outcomes. Each enables one capability in the simplest way. (h/t @not_nothingmuch)

New PFP. Shadowy Super Sandwich. #LNHANCE #RubinsReubens

People who never understood what fuck you money meant tryna tell bitcoin what it is.

New favorite hat and shirt. Make money great again! #freeross

What is this I see? Dropping some BIPs and code this fine Sunday morning. delvingbitcoin.org/t/lnhance…

Since we're going to add OP_CAT to bitcoin, we owe it to ourselves to enable better vaults than @rot13maxi's abomination. With CAT, CTV, and TWEAKADD, ergonomic vaults are possible with simple scripts. With CSFS too, post-signed (in contrast to pre-signed) vaults are possible.

Briefly, here's the definition of restored script: * Restore all opcodes from bitcoin 0.3.4 (with L/RSHIFT renamed to UP/DOWNSHIFT) * Protect from DOS by using a varops validation budget that ensures that scripts cannot have a worse worst case validation time than today * Convert all script number handling to variable length whole numbers * Remove all opcodes dealing with negative numbers * Add opcodes to better introspect the transaction than CAT and Schnorr tricks (TX, TXHASH, TXHASHVERIFY for bare) * Replace sighash with TXHASH's TxFieldSelector to provide efficient access to the same hashing modes for signed and unsigned commitments * Add an opcode to support mandatory prefix validation with OP_SUCCESS semantics (SEGMENT) * Add opcodes to interact with Taproot (TWEAKADD, BYTEREV) * Add opcodes for checking signatures on data from the stack (CHECKSIGFROMSTACK(VERIFY,ADD?)) * Remove the penalty for using taproot without an internal key, and restore parity to keys (most likely using segwit v1 with 33-byte keys with the lowest bit being parity and the 2nd to lowest being set to indicate the absence of an internal key - the other 6 bits, if set, act as anyone can spend) This set of improvements restores bitcoin to being programmable money, without horse trading between various minimal things none of which solve the fundamental problems of working with script. Open work on this project: * Finish the work on the varops budget * Benchmarking * TX vs. input vs. witness bytes for the budget * Work out a few details of TXHASH * Implement variable length whole number division * Decide whether CHECKSIGADD and/or CHECKSIGFROMSTACKADD deserve a place in restored script * Write a reference script interpreter for Restored Script (either within the existing interpreter or cleanly separated) * Write updates to BIPs (340, 341, 327, 346, CSFS) * Write new BIPs (Restored Script validation rules) * Write documentation for Restored Script * Implement restored script support in various tools cc @rusty_twit how'd I do?

Big thanks to @achow101 for taking the time to go through the history of the BIP119 (CTV) validation logic PR on bitcoin core with me today. Some of what I've said about CTV is not totally accurate. The code has had some changes within the past 2 years to resolve important an issue with IBD performance and the issue that earned the bug bounty. The main hashing logic has not changed, but some of the details of how it interacts with the overall core codebase has. This means that a new PR for the validation logic with all of the earlier issues resolved should be opened to begin gathering reviews as a first step toward potentially activating CTV.

My proposal to provide CTV+APO with high quality upgrade paths, no additional cost for APO or Tapscript CTV, and in a clear unified structure. Thanks to Russel O'Connor for the earlier OP_TXHASH+CSFS proposal, and everyone who gave me feedback. gist.github.com/reardencode/…

As the Thanksgiving brisket smokes, I'm thankful to be a part of the bitcoin community and to be building products that help protect our hard earned wealth. Looking forward to many more years of absolutely lit happenings. Happy Thanksgiving y'all!

> you cannot change Bitcoin, only adapt to its reality This cannot be repeated enough. People who bitcoin flushes out over the many years are those who develop a fixed view of what bitcoin is (or should be) and are unable to adapt to its reality. Vitalik: Bitcoin is a computer Roger: Bitcoin is payments Zooko: Bitcoin is for privacy Jihan: Bitcoin is controlled by miners (?? soon): Bitcoin is only for money Staying in bitcoin requires a level of mental flexibility that has rarely been required by new technology. Each time something new happens in bitcoin (rejection of Turing completeness, full blocks, chain analysis, UASF, ordinals/inscriptions) you are forced to reevaluate your preconceptions, your reasoning, your emotional attachments. If you cannot, bitcoin will reject you. Exercise your brain, push your boundaries, stay uncomfortable, retain your flexibility. This is a marathon, not a sprint.

Bitcoiners will be forced to think adversarially either by other bitcoiners or by world governments. It is far better for it to be other bitcoiners.

Yes. With 5 bitcoin, I could buy a nice airplane and stay busy flying instead of Xing.

Y'all have no idea how much bitcoin can do without soft forks. Kudos to the team at @ArkLabsHQ for doing the real engineering work to build a bright orange future! Also, bitcoin can be better, faster, easier, safer with soft forks. Cc @bergealex4

Do you think it would be productive for @real_vijay and me to debate ossification vs progress for bitcoin publicly? @stephanlivera as moderator?

We have a moral imperative to improve bitcoin as much as we can to improve access to self custody. The strength and nature of this moral imperative depends on our specific relationships, skills, and other resources. For example, I have some level of skill in writing software and in teaching. I also have children and access to resources. As a result, I have a strong moral imperative to do what I can to improve bitcoin. If bitcoin fails to remain sufficiently decentralized, it is my children's generation who will suffer the consequences. The idea that bitcoin as it is right now is guaranteed to remain sufficiently decentralized is a truly bizarre form of hubris.

Seriously. Why would Luke's DNS seed be included in a software package that he maintains a competing fork of and claims is compromised? Luke's seed should remain in knots and be removed from core.

Mechanic wants to give everyone options to reduce their own nodes' functionality. I'm fine with him providing this, but do not support it being part of core. Bitcoin core should aim to best integrate with the bitcoin network. Reminder: on any dimension, the 95th percentile of permissive relay determines which transactions get mined. Unless you are extremely confident that nearly everyone else will filter the same as you, your node works best by being permissive on relay rules.

This is a disingenuous framing, insulting to the many engineers, cryptographers, and thinkers thoughtfully and with utmost care designing potential upgrades to bitcoin. It is a denial of bitcoin's history of remarkable moonshots that got us where we are today. And it is a rejection of the very concept of what bitcoin is. Bitcoin is not resilient because the current consensus rules were somehow imbued by their creators with magical properties. Instead it is the result of the exact same careful and thoughtful engineering process, including execution of some moonshot ideas, that people are trying to engage in today as the likes of Hugo take misinformed potshots from the sidelines.

Jeff's analogy of TCP/IP as bitcoin and the internet as bitcoin layered scaling is interesting, but he discounts how much TCP/IP changed over its first 15 years and continued to change for nearly 40 years through today. Also worth noting that TCP is declining vs. UDP/QUIC today.

"By ossifying today when it’s so difficult to build permissionless second layers, we are hamstringing developers and significantly limiting experimentation to find the most valuable uses of block space." ☝️☝️☝️☝️

Thank God for all these nocoiner tears. We can use them to fill our swimming pools and make transactions.

Many good points from an irritating source. One important counterpoint is that many who use and enjoy lightning (myself included) do so with eyes open to the limitations of channel based scaling. Which is not the same as it being a failure. Channel based scaling works great for enthusiasts and commercial entities to pay each other. That's a huge scaling improvement in itself. Much like other networks, that still leaves the last mile unsolved. Direct run terrestrial fiber networks do not and likely will not bring the Internet to everyone. Starlink can, with trade-offs. That absolutely does not mean that terrestrial fiber is a failure! So what is the Starlink of bitcoin scaling? Eric thinks it's zk-rollups. I'm skeptical of those. I think it's likely some combination of covenant tree variants, and various ecash ideas. These, combined with meat space insurance for exit fees to manage the risk of being forced onto l1, provide a user experience that sucks less than lightning and IMO less than zk-rollups. It's entirely possible that the future of bitcoin includes all of these things and more, competing to offer compelling money experiences on the last mile. Similar to how mpesa, wechat pay, and banks complete in legacy last mile services.

I voted once, to free Ross. Ross is free. I think I'll keep my record 1 for 1. Take care of yourself @RealRossU. If you need anything don't hesitate to ask.

Take a moment to appreciate that we are living in the transition period between the age of democratic republics and the age of Snow Crash style franculates. Yesterday a private company launched the most powerful rocket ever. The launch was heralded by a flyby of privately owned jets. The local government leader pretended it didn't happen. The government will keep pretending it's relevant for decades to come, but we will progressively ignore it more and more effectively.

I finally made time to read John Law's lightning scaling with simple covenants paper: github.com/JohnLaw2/ln-scali… The structures he proposes have remarkable similarity to Ark, but with some twists. Long and short CTV or APO-based covenants are sufficient to build highly scalable UTXO-sharing lightning protocols. This is the most fleshed out (that I have seen) protocol design based specifically on CTV covenants and which is able to efficiently bring lightning and bitcoin to all of humanity.

Just to be clear, we're all Satoshi Nakamoto. Except Craig Wright.

Update on LNHANCE vs APO for LN-Symmetry(Eltoo): Thanks @4moonsettler for pointing this out and sending me to do more research. As noted by @theinstagibbs, using CTV(ish) in LN-Symmetry can eliminate round-trips from parts of the resulting payment protocol, but this has further implications! delvingbitcoin.org/t/ln-symm… Up to today, I've been saying that LNHANCE costs 8vBytes more than APO for LN-Symmetry force closes, but because the protocol uses CTVish in its resolution scripts, it actually ends up being 8vB smaller to do LN-Symmetry with LNHANCE than with APO. Update transactions are 8vB larger (+1 32-byte hash), but resolution transactions are 16vB smaller (-1 64-byte signature). Of course if we had CTV+APO that would be even another 8vB smaller, but I think this is sufficient to demonstrate that for LN-Symmetry purposes LNHANCE is a suitable substitute for APO. cc @murchandamus

If you think that any relay policy change could possibly kill bitcoin then bitcoin is a failed project. Bitcoin is fully dependent on the ability of its consensus rules (backed by proof of work and the difficulty adjustment) to sufficiently align the incentives of network participants. Relay policy was a misguided attempt by Satoshi and other early bitcoin contributors to shape the usage of the network and has been proven over and over again not to be effective in shaping behavior (in fact it has only proven its ability to shift behavior to more harmful solutions and not to shift behavior in desired directions). Over the past 15 years policy went from nothing to only allowed script templates to any script matching certain standardness rules and those standardness rules have been progressively relaxed for the balance of bitcoin's history. OP_RETURN's original standardization in 2013 was a step toward aligning relay policy with consensus because the over-strict standardness policy without OP_RETURN was pushing users to abuse the network with fake unspendable outputs. Standardizing RBF by signal was another step. Standardizing full RBF another, followed by sub 1 sat/vB fee rates, larger and more OP_RETURNS. Core has been dragged along with these changes as they are relayed first by the tolerant minority on the network. In the fullness of time if any convergency of relay policy with consensus can kill bitcoin then we must make a consensus change to protect the network. Please help the protocol by proposing appropriate consensus changes!

> What is my experience like? Do I receive "Bitcoin"? Or Lightning? Or something different? You receive bitcoin in a shared UTXO. Just like you currently receive bitcoin in a lightning channel if you're a lightning user. > Do I write down a seed phrase that can be used to recover funds if I lose my phone? If I were offering a product like this, I would make it a 1-sig with encrypted cloud backup at first sign-up. So you can recover your funds in the system as long as you have access to your (say) iCloud account and the service provider. This is where one of the huge benefits of the (so far) proposed UTXO sharing schemes comes into play - because they _require_ periodic rotation to new shared UTXOs, there is a regular opportunity to upgrade or restore the user's key security. For example, a user whose balance has increased to 1 million sats might be advised to create a physical backup of their seed instead of needing the service provider to recover. > How can my ownership be violated? Similar to lightning, but with somewhat higher on chain enforcement costs - although see Salvatoshi's delving post for more there delvingbitcoin.org/t/aggrega… A properly designed coordinator will not be able to steal user funds, but only to donate them to miners. This may seem like a small difference "but the user is out the money either way" but it does fundamentally change the equation of how likely that scenario is. Furthermore, as I've said elsewhere, I'd expect coordinators to facilitate or purchase insurance to make their users whole in some or all such scenarios because it will be part of what prevents them from being treated as a custodian both socially and legally. > I assume the goal here is to reduce the cost of being self-custodial Bitcoin user. What would the trade-offs be, specifically? Compared to on chain self-custody: * Requirement to be periodically online to roll funds over * Ability to recover funds if keys are lost and the coordinator is cooperative * Higher cost to spend unilaterally (~10x) * Lower cost to spend cooperatively (~100x) Compared to lightning self-custody: * No requirement to be online to receive (depends on the specific implementation) * No requirement for pre-allocated inbound liquidity to receive * Ability to recover funds if keys are lost and the coordinator is cooperative * Higher cost to spend unilateraly (~5x) * Similar cost to spend cooperatively > So is it UTXO sharing or fee sharing that we should be targeting? These are literally the same thing - this may be a key insight. To share fees for on chain bitcoin transactions one must share UTXOs. As explained elsewhere signatures make up only a minority of the fee cost of bitcoin transactions, so even if we could entirely eliminate them and the transaction overhead, a typical 2-2 transaction would only save 20% in fees.

I've been a bitcoin maximalist since it meant only one public blockchain money makes sense and all other "crypto" should just be anchored to bitcoin. Not sure what this new wave of bitcoin purity maximalism is about, but it's definitely not what I'm here for.

Always happy to have a high bandwidth conversation on the topic, but here it is: * Updates to the bitcoin ledger are largely secured by public keys and signatures. * Public keys and signatures are data. * It is possible to craft public keys and/or signatures so that they represent additional data beyond their obvious authorization. * Therefore it is impossible to filter additional data from the bitcoin network without filtering updates to the ledger. * Bitcoin also includes scripting to enable more advanced ways of securing ledger updates (e.g. miniscript inheritance / degrading multisig / hash locks / lighting / etc.) * Scripts can include pushes of non-public key, non-signature bytes for use in many of these scripts. * There are infinite ways to encode data in these data pushes. * Therefore it is impossible to filter additional data (not in public keys and signatures) without removing lightning, atomic swaps, etc. So, those promoting "fix the filters" are necessarily forced to disable all ledger updates to remove all possible additional data from the network; or to disable lightning, atomic swaps, etc. to remove a subcategory of easy ways to put additional data on the network. There is no alternative conclusion. FORTUNATELY, bitcoin comes with a built-in spam filter, the only one that actually works: Fees. And they work beautifully. There's more we can do here by increasing the economic density of ledger updates to reduce the relative proportion of block space that those wanting to store additional data on the network can afford. We argue against filters because we don't like to see people's valuable time wasted in tilting at windmills. There's so much work to do to increase economic density of bitcoin transactions, increase decentralization of mining, improve self-custody, etc. etc. etc. LITERALLY ANYTHING that can actually work, unlike filters.

Thanks to the Trump family for launching memecoins and educating millions of people about pumpenomics, rug pulls, premines, buying tops, and more. With their guidance, millions can speedrun the road to saving in bitcoin!

If you say "CTV lets government make permanent whitelists" in 2024, your opinion of any and all upgrades to bitcoin will be ignored. We need to evaluate whether to take someone's opinion seriously on these important questions and this a fair minimum bar.

Some thoughts about this article: - On the idea that we can support hundreds of millions of users on lightning: the ability to onboard 1.1 billion users OR modify the channels of 470 million users assuming no other uses of blockspace and near perfect use of batch transactions doesn't translate to supporting 100s of millions of users. Optimistically it means supporting 100 million. Realistically maybe 50 million. - LN Symmetry doesn't specifically need SIGHASH_ANYPREVOUT. It can be built with CTV+CSFS, CAT+CSFS, APO, or best by APO+CTV or CTV+IKEY+CSFS+CAT. - Love the term "Sufficiently Advanced™️ Covenant" - CAT does not need CSFS to build covenants at all. That's what Poelstra's old post showed. - It is not possible to implement Drivechains using CAT. It is possible to implement hashrate escrows with CAT, or APO, or VAULT, or TXHASH+CSFS, or CCV. Drivechains are a unique combination of features specified in BIPs 300 and 301, one of which is hashrate escrows. - The proposed on chain CAT token proposals that I'm aware of offer significantly worse UX than Runes or TapAss. Can you link to one that is better? Conclusion: I'm broadly in agreement with Peter here. I'd encourage him to consider shifting his recommendation to CTV+CSFS to enable rebindable channels as a low risk higher reward step after consensus cleanup. Solid article.

Here's a comparison of some covenant proposals for bitcoin and which of 3 (relatively) near term features they support. TXHASH/TX+CSFS lack BIPs or code (+bikeshed) APO+CTV or APO+github.com/bitcoin/bips/pull… open up design space for bitcoiners and are ~ready now

This question is what is wrong with bitcoin.

Reasons to soft fork bip119/CTV (over APO) are piling up: CTV enables Ark and other protocols immediately. @ajtowns thinks the lightning devs should focus on Taproot channels and other features: nitter.app/ajtowns/status/1… APO cannot emulate CTV: nitter.app/robin_linus/stat… But (for Eltoo/LN-Symmetry purposes) CTV+CSFS can emulate APO. CTV is also a building block for OP_VAULT which is another popular proposal. CTV now!

There will never be an AI supremacy. Why? Power efficiency. A human requires ~15MWh of energy to develop adult level intelligence (including a college degree). Tesla's 2023 training cluster uses that much energy in 2 hours. According to Tesla's site, it takes 70,000 GPU hours to train a task-specific (driving) AI. At least 3 times as much energy as it takes to fuel a general purpose human AI. So currently AI training takes 3x the energy to train a single-task intelligence than it takes human brains to train general intelligence. Now let's look at inference. The brain consumes ~20W and can use those 20W to make continuous general inferences, including switching task contexts as needed. Tesla has the most power efficient inference system on earth and (again) consumes > 3x the power (72w) for a task-specific AI. Why does any of this matter? It tells us a lot about the future of AI. Task-specific AIs will (like other tools that humans have developed over the millennia) enable us to increase the power density possible for completing specific tasks. This is what factories, cars, etc. do. AI will never be as cost efficient as humans are for general purpose thinking. The more general a task is the more humans will dominate in thinking, exactly as it is currently in physical tasks. Tools free humans from drudgery, they always have and always will. Those peddling a future AI supremacy fail to understand that an AI which requires orders of magnitude more energy to train, and orders of magnitude more power for inference than a human is not supremacy. It cannot out-think us.

Honestly, I can't deal with this fact. Installing a 2TB single sided M.2 SSD in a laptop yesterday nearly broke my brain.

I never thought I'd be saying this, but bitcoiners: Get out and vote like Ross's life depends on it. Because it does.

Have I mentioned that there's infinite work to do in bitcoin, and we need more developers, writers, cryptographers, etc.?

I'm ... I'm not sure what to say to this.

Ossifiers are an endangered species.

Were you too late to get Gox'd? Couldn't get rekt by BlockFi or Celsius? Never fear! You too can get rekt with Brad's simple plan!

Lightning scaled by packing more payments into each update to the base ledger. Output covenants will scale by packing more balances into each UTXO. These lower fees for making payments and holding balances without increasing block size or validation cost.

Don't be average, raise the bar.

You're as bad as Cramer at this point.

I ate the entire meal this way. Thanks @TaprootWizards

Ordered a Passport Prime. Wasn't gonna, but the combination of hardware silent payments sooner than later and the cope and seethe from the haters made it irresistible. Also interested in writing my own app for my own fun wallet things :)

I ain't here for OP_CHECKTEMPLATEVERIFY. I'm here for scalable self custody!

Bitcoin must be money. What is necessary to fulfill that mandate? Bitcoin must validate and store txs moving money. Nobody can be able to censor anyone, nor change the rules of the network. (First principle analysis of bitcoin changes, re. OP_RETURN drama)

Here's my talk from Adopting Bitcoin 2023. Does bitcoin need covenants? piped.video/watch?v=eUr6gpMm… Slides: docs.google.com/presentation…

Running bitcoin v30 ... to death.