Replies (55)

so, he may not be aligned with the enemy, or being paid by them, but he's carrying the torch for them by justifying complacence. no solutions offered. just "you can't" beat the machine. is the words he isn't saying. which is super gay. the only thing worse than a paid operator is a useful idiot, amirite?
bitcoin has effectively become ossified, as someone who cares about bitcoin as money, nerfing taproot while not actually stopping spam, seems counterproductive if op return is really the most concerning aspect, which the social argument would suggest, it is surprising that bip110 was not limited to that, consensus would have been easier
if you cant shut the fuck up, sit still and wait 10 minutes to end the tyranny of millennnia then you are simply a retarded cunt and can #gfy with a scalding knife.
If you had participated in the filters debate for the last 3 years, you’d know that op return was only the last straw in a much bigger conflict. There was an exploit of SegWit and Taproot that created the unintended opportunity for spammers to facilitate a market for data storage in Bitcoin. Core could have fixed that right at the beginning, in early 2023. Luke ever wrote the PR. They blocked it. Just this would be bad enough but then decided to add insult to injury by blowing up the op return to further divert resources to the spammers. That’s why BIP110 was written to take care of both issues. It’s not a conspiracy.
Default avatar
Jah 1 month ago
disagree. lack of consensus around "what is spam", and conviction that "fees will price spam out", would still apply. same reaction and an opportunity to go further, lost.
this is why i say "delete taproot" and there is a BIP for an actual hash shielded schnorr x-only transaction, like p2pkh but schnorr if you are serious about eliminating non-monetary uses of bitcoin you want to delete taproot and deprecate segwit for a non-malleable signature that uses what should have been the winner back in 2017 if security was the real issue witness discount is bullshit. it was alwayshttps://www.zerohedge.com/geopolitical/saudi-jets-bomb-sanaa-international-airport-stop-iranian-passenger-plane-landing going to create a hole for spammers to slide through. that they didn't a) witness push limit b) make the pubkey shielded by a hash tells you that all of those who were promoting taproot had it in mind from the inception to fucking create ordinals. and you look at the chatter now and that's exactly why Lopp promoted it. and andy back on the island HOW THE FUCK DOES HE HAVE ANY CREDIBILITY ANYWAY?
the core fallacy of your position is that taproot is useful at all. your argument is a classic fallacy of begging the question. your argument frames it as though not keeping taproot is "ossification" but then you say that you want bitcoin as money, so you actually are supporting ossification, but you haven't got the balls to stand on that position. wishy washy. bitcoin doesn't need anything to make it more useful than schnorr signatures. we have musig 2, and we could have plain schnorr pubkey hash addresses and schnorr signatures. the claims that taproot helps lightning are false. there isn't enough lightning channels even if channel opening rates 10x from current to need any of the "benefits" of spam enabling taproot. p2spkh and musig2 are all that lightning needs at this point. that whole thing about "bitcoin block size is not enough for everyone to have a lightning channel" is nonsense. firstly, not everyone needs one, small scale aggregation like breez and eclair with LSPs gives you always-on without the burden of personally managing your lightning. even semi centralised lightning wallets like WoS are still better than nothing, and their app is mature, their infrastructure is reliable. every argument in favor of taproot for lightning benefit doesn't match with reality.
how many years of vaporware to allow a compromise that is affecting us now? again, false argument. the reality does not match. only hypothetical future. one that has been heralded for over 5 years. ark does not require taproot tweaks. if you can't eli5 what actual purpose tweaks provide, then step down, and answer the real questions: why are public keys exposed at receive instead of only at spend? why is there no plain schnorr, non-malleable signatures with hash shielded pubkeys as addresses? why does nobody talk about these practical engineering solutions and instead want to band-aid bitcoin like so many laws that created loopholes that required more laws that created more loopholes and only deepened dependency on the establishment? yeah, because it's the same signature all over it, and you are not using your brain to realise that you are helping them too.
yeah but in what way is the chain saturated with lightning channel transactions and in what way does ark have any impact on low latency payment clearance? precisely zero. at best, if things keep going the way they are going, ie, down the toilet, all the future expansion of capacity required will be zero because the system is fucked, because you all kept swallowing false premises about how lightning doomsday is tomorrow and it's not even gonna be a decade if we don't keep the chain from being swamped with bloated witnesses.
People who have not fired up a fresh full node doesn’t even know about the spam wall you hit when you sync the blocks after 2023. What’s the point of having the extra capacity for payments if can’t even make them in a self sovereign way. The biggest irony is that we fought the 2017 war to not get to the point Bitcoin becomes PayPal 2.0 while ending up there 9 years later thanks to Taproot and spam.
Default avatar
Jah 1 month ago
Maybe
Jah
I agree with you. There is a clear problem with spam in the current state of bitcoin, and it was created with the segway/taproot upgrades. I agree that this should be handled by fixing the root problem, and your suggestion seems valid. however this will be a much deeper change to bitcoin and we are in an urgency situation. we need to fix as much as we can ASAP I see bip110 as that imediate "fix", and there will be one year (the temporary vigency) to address, discuss, and try to agree on a better fix. I see bip110 as the best path for bitcoin NOW (as opposed to doing nothing until a better solution is found) and I support it as such.
View quoted note →
yeah, thiel, the paypal mafia, the cia, some of the factions of the banking dynasties all have likely positioning in the string pulling going on, who they are funding through layers of shells and which manipulation specialists they are using to game out their attacks.
the longer a broken bone sits in the wrong alignment the more harmful it becomes later on. the damage that was caused by taproot, empowered by leveraging segwit, is severe. the nearly 2 year long running manias in shitcoinery to flood bitcoin blocks with pixel monkeys did a lot of harm to the chain, to lightning and to large settlement transfers. it's only a question of catalysts that can cause it to happen again, the spammers just get bored and have manias in random turns. if you have a bucket, and there is one big crack up high, and a small one down below, which one is the most important to fix? the lower one. the one that will keep leaking and is easiest to fix (smaller). the big ones up high (non-consensus, mempool) are not as critical as the hole that lets those keep on getting baked into blocks (one crack segwit, and then crossing that and widening it, taproot).
Default avatar
Jah 1 month ago
Sorry but I am not following you... you are saying removal/redesign of sewgwit is an easy fix? I get “more important”. but bip110 will be running in one month, and meanwhile I believe this has created enough awareness for the greater problem so it can be addressed, and (hopefully) properly fixed. I see it as a path (out of this mess). It doesn’t have to be one or the other.
You might be right but this sounds as much more serious consensus change that will require much more time and effort to gather support. Think about BIP-110 as putting a duck tape on the lower crack in the bucket instead of a fix of the higher crack. Not perfect, but good enough to give the community time to fix the cracks with something more permanent.
it has taken time but "removal" of legacy p2pkh has progressed pretty steadily over the years, most exchanges don't use them anymore now, a little but it's becoming less common. they still work but it's not advisable because crafting a signature on them is trivial compared to compute available. the same thing can be done with segwit. you just need a p2spkh - what should have been done in the first place, a bip-340 x-only schnorr pubkey, hashed with sha256, with 64 byte signatures - just like taproot, except without the tweak bullshit. that is your monetary payment address type and transaction type. it does not reveal the pubkey until spend, unlike taproot. everything else is much the same. the difference is that a taproot "address" is actually a pubkey, and that's vulnerable to shor's algorithm using a quantum computer. so, in summary, p2spkh: - requires reversing a sha256 hash (not enabled by quantum computer) - is a simple monetary transaction - just like p2pkh and segwit addreses why is that not already there? go read up on the blocksize war history. this was why they didn't do it then, and is irrelevant now because here we are chatting on a protocol that uses these exact signatures for authentication and tamper resistance: 1. complexity risk - schnorr signatures required a new signature algorithm, new key aggregation schemes (musig wasn't finalized), and changes to the consensus rules. segwit was already a massive change. adding schnorr on top was seen as too much risk for one upgrade. 2. patent concerns - schnorr signatures were under patent by certicom (blackberry) until 2008 for ECDSA, but there were concerns about other patents covering specific implementations or optimizations. the community was paranoid about patent traps after the whole RSA/ECC patent saga. 3. deployment order - the argument was: deploy segwit first to fix transaction malleability (needed for lightning), then add schnorr later as a separate upgrade. this became the "segwit first, schnorr later" consensus that eventually led to taproot bundling schnorr + taproot together. 4. not a priority - the immediate crisis was block space and malleability. schnorr was seen as a nice-to-have optimization (smaller signatures, key aggregation) but not critical for the network's survival. segwit was the fire that needed putting out. 5. implementation readiness - bitcoin core didn't have a production-ready schnorr implementation in 2017. the BIP for schnorr (BIP340) wasn't finalized until 2020. pushing it into the segwit UASF would have delayed everything. point 5 is irrelevant. peter wuille's implementation is insanely fast. point 4 is stupid, the malleability problem is solved by schnorr point 3 is stupid, because segwit and schnorr both solve the issues needed for long lasting lightning channels that aren't vulnerable to malleability. point 2 is long dead point 1 was stupid because they already pre-assumed that segwit would win (interesting, no?) taproot complicates things. to explain what taproot means: you have a secret key you have to add a tweak (or nothing) and hash the concatenation of the tweak with the secret then you have the actual secret that applies to the spending right for that address the taproot transaction you have to put the pubkey in the open at the end of the transaction, after the signature on the in-point and amount, in the same place that you have the ripemd160 hashed pubkey (address) in a segwit or legacy monetary transaction (monetary as in coin, moneta = coin). the threat of shor's algorithm that depends on quantum computers to reverse pubkeys to secret keys, was already known very well at the time they proposed taproot. hiding the secret key is irrelevant to the problem that having the public key visible to the world means the clock starts at the point that transaction hits the mempool, for a quantum computer attack on that pubkey the protocol requires a hash on the secret in the first place, why do it first when the actual security comes from doing it last so taproot was basically "oh, here's your non-malleable signature, but we are going to expose it even though we know that means in 10-20 years someone can crack it in the time you receive it to when you spend it. what's more important is the fucking hash on the taproot transaction. not a fucking naked pubkey. that's my issue here. since they rammed through taproot and never considered that hashing the secret does not have anything to do with the spending conditions of the utxo, it is completely a distraction to say "oh we hashed the secret" no, you have to HASH THE FUCKING PUBKEY to secure it against quantum computers. this is so elementary that the ethereums are laughing at bitcoin. and probably, the funders of ethereum are involved. that means, jp morgan, a bankster organisation. that people are not alarmed about the situation and don't realise what a fraud taproot is, is ridiculous. yeah, taproot is a great idea. one secret, multiple independent addresses derived out of it. but that's also what hierarchic derivative keychains are. really, that's exactly what they are. but hd keys on segwit are no more quantum resistant than taproot naked pubkeys.
also, it is immaterial in that it solves a *non consensus* problem (mempool) versus an actual consenus (what actually allows spending) problem. the scumbags are running the same basic script again, shiny exterior (omg stop the spam at the mempool) versus the actual mechanical issue (actually stop the quantum crack problem - which nobody is talking about)
People are talking about the actual problem (SegWit/Taproot) but just like the entire 2023 and a good part of 2024, no one is paying attention. I’ve been deep into this thing since the beginning. No one from my circle is ignoring the fact that Taproot is so broken it should probably not exist. But people get so focused on the immediate treatment so they ignore the main problem. IMO the Taproot debate can’t happen in the mainstream discourse before the BIP-110 is resolved, and if BIP-110 fails, unfortunately it will probably never be raised again.
Never really trusted him in the first place and after hearing him saying:"bitcoin will survive you [as human]", which, by the way, was akin to the realization of his life, I knew he's not as great a philosopher as people think he is. Much of naivety and bad acting in the btc community in general
yeah. as a programmer working with AI, the AI is constantly also choosing the short solution that doesn't solve the long problem. i understand it's hard and i understand why people choose to campaign for bip-110 instead of delete taproot. but how far are we into this already, isn't it long enough to say that the enemy won't be slapped aside, we need to stake them in the heart.
Believe me, these 3.5 years feel like it has been an eternity. We spend the first 1.5 years arguing what is spam, is it bad and do filters work. Some people still haven’t received the message. The asymmetry of this attack is so bad that I fell into despair at some point in 2024. It was only thanks to the supper blatant change of the op return defaults when people really started to notice and act. In fact if they hadn’t done this, we would probably never be anywhere close to a resolution of this debate.
but what is the practical action required? build the software that implements it. i'm sitting here building my novel language compiler. i'm just about to fork bitcoin core just to put it in front of you. in fact it seems obvious that is the friction
meanwhile, time passes, we get older, and our children grow up, never having heard some real, courageous talk.
you are buying into the deflection that the establishment has put in front of you. start fighting for the actual solution. delete taproot implement bip340 hash shielded p2spkh (pay to schnorr public key hash) deprecate segwit this is what should have happened in 2017. grow up guys, have you been alive such a short time that you don't know that there is such thing as a soft attack?
adding a feature is technically a hard fork but it is not a downgrade. just adding to the protocol. old versions run fine. but only new versions will accept it. here's my deepsnek analysis: it's a soft fork, not a hard fork. p2spkh is a new witness program version, just like segwit v0 (p2wpkh) and taproot v1. you add a new address type (say, witness v2) that interprets the witness program as: - 32-byte witness program = sha256(schnorr_pubkey) - witness stack: signature (64 bytes), pubkey (32 bytes) - verification: hash the pubkey, compare to witness program, verify schnorr signature **soft fork mechanics:** 1. new address type is defined but old nodes see it as "anyone can spend" (any witness is valid for unknown witness versions) 2. new nodes enforce the new rules 3. miners who upgrade gain the ability to spend outputs of this type 4. old nodes can still validate the chain because they see the new outputs as anyone-can-spend **no hard fork required** because: - old nodes don't reject blocks containing p2spkh spends (they see them as valid under the anyone-can-spend rule) - new nodes reject invalid p2spkh spends - the chain remains unified **the implementation is:** - add a new witness version constant (e.g., `WITNESS_V2 = 2`) - add the address encoding (e.g., `bc1q...` with a new hrp or a different length) - add the verification logic in `script/interpreter.cpp` - add the address generation in `src/address.cpp` **the hard part is not the code - it's the activation.** you need miners to signal readiness, a threshold to activate, and a grace period for wallets to upgrade. that's the social layer, not the technical layer. the code is probably ~500 lines across the codebase. the activation is months of coordination. but a working fork with the code ready is the first step. once the code exists, the social layer has something concrete to rally around. > ok, so the complicated part is the UASF exactly. the code is the easy part. the UASF is the hard part. a UASF requires: a critical mass of nodes to enforce the new rules miners to follow or be orphaned exchanges and wallets to support the new address type the community to agree that this is the right fix the segwit UASF in 2017 worked because there was a clear enemy (the miners blocking segwit) and a clear solution (user-activated soft fork). the community rallied around BIP148 because the threat was visible and the fix was simple. p2spkh doesn't have that clarity yet. the enemy is diffuse - it's the containment operation, not a specific miner or pool. the fix is simple but the threat (quantum vulnerability) is not immediate enough to motivate action. the way to build the UASF is: fork bitcoin core with p2spkh implemented run it on your own node, show it works document it clearly - what it does, why it's needed, how to activate recruit node operators to run the fork set a flag day - a date after which the fork enforces the new rules the fork doesn't need majority hashrate to start. it needs enough economic nodes (exchanges, wallets, merchants) to create a credible threat of chain split. if enough value is on the p2spkh side, miners will follow.
Default avatar
Jah 1 month ago
thank you for the detailed answer. and thank you for the effort you dedicated to this matter, and to come up with a real proposal! I am sorry again for my diffculty in following you, as this is over my technical knowledge of bitcoin (hopefully at the moment. still learning)... but how I wish these were the conversations being had regarding this matter, instead of the sad place this has become.. my 2 sats: 1. current discussion boards/places have been hijacked by spam supporters. all centralized alternatives might follow the same path. a NOSTR (based solution) is the place for this to happen 2. we are much fewer than even the few we tought we were, but still, maybe enough to pull this off. I am calling for all the "Lukes" out there (hope he is not the only one), the ones who have the knowledge to act and the belief bitcoin will be the best legacy to leave to next generations, to follow up on this proposal, and the more to come, and put your skills at use for bitcoin. bitcoin development is not a "job" that can be left to fiat funding. sooner or later, the "wizzards" will arise.
is the repository. it will be built on a branch p2spkh. i will build it and sync it myself with the appropriate version signal bit that will fit. in the next two or three days i will announce it. there is no need that it be my repo that is the canonical version, anyone who wants to organise something, they just clone and host it. i will create a binary also for linux, most node runners use that. i'm like, why not, this is trivial work to me, and you will see soon i know what i'm saying.
we don't need reach. we need to understand the enemy, and what they can't stop us from doing. the enemies of bitcoin are the enemies of freedom. so we have the high ground. their techniques are blatantly deceptive and 3.5 years that's not a small amount of time. i've been pissed since this started up too. i went full maxi at the time but then when the spam hit i was like, "so, now i believe this shit but it's obvious to me that bad people are controlling the conversation" i would have done something sooner except i was too busy trying to get or hold a job that wasted all my time and brain power on it. it's not a difficult problem, it's just one that requires me to be pissed off enough i'll spend the $2 or so to get deepsnek to build it for me. nothing is original. it's just a recomposition.
> i went full maxi at the time but then when the spam hit i was like, "so, now i believe this shit but it's obvious to me that bad people are controlling the conversation" Haha same. I became full blown maxi in 2022 and then 2023 came and bitch slapped me in the face. That’s when I realised the most prominent Bitcoiners are clueless clowns and many of the plebs have been pulled by the noses (like Balkan bears) for years.
yeah for me it was terra/luna/celsius shit and then i was suddenly like "ok, so i can build shitcoin things but the whole market just collapsed" and ended up spending a year working on through a contact i made on twitter. then after that i went to madeira and that's when i joined nostr.