Not to dispute your post overall, but a cool thing about science and especially mathematics is that it's rare that any two subjects are really unrelated.  That's especially true here.

Digital signatures with elliptic curves (and many other asymmetric schemes) can be understood as an example of encryption, it's easiest to see using a schnorr signature (which Bitcoin uses) but the point applies to ECDSA as well.

First, I'll describe the Schnorr identification protocol as an application of encryption:

Alice and Bob have access to an encryption algorithm that is additive homomorphic, meaning that enc(A+B) = enc(A)+enc(B)  (this also necessarily means that you can multiply ciphertexts by integers).  For this scheme decryption will never be needed, so it doesn't have to support decryption (though it could be done with schemes that could be decrypted too).  It's not absurd for additive homomorphic schemes to not allow decryption in general, it's the case for the additively homomorphic version of elgamal encryption (it can't be decrypted without solving a discrete log problem).

Alice picks a secret value z and encrypts it to produce a public value P that she publishes.

Later Alice meets Bob and Bob wants to validate Alice's identity.  To do this Alice constructs a random line based on her secret by picking a random value k,  so that the line is k + xz.   Alice encrypts k to get the value R which she sends to Bob.

After getting R, Bob picks a random point x and can compute an encrypted evaluation of the line at x using the encrypted coefficients sent by Alice:  enc_s = R + xP.  He sends x to Alice.

Since Alice has the unencrypted values k and z Alice can compute the unencrypted evaluation s = k + xz.  Alice sends this to Bob.

Bob now encrypts the s he got from Alice and compares it to the one he computed himself.  If it matches Alice had to know the unencrypted versions of k and z.

Now this is not yet a signature, because it requires Bob's cooperation, only convinces Bob, and doesn't involve a message.

The first step to fixing that is to eliminate Bob's active role in the protocol.  All bob is doing is picking a random number!  You might think one random number is is as good as any other, so Alice can pick the random number x.    But the problem is that x must be picked after k/R is chosen.  Otherwise anyone could pick a random s and x then compute R = xP - enc(x) and claim that {R,s} is a valid identification for P-- they don't need to know the secret for P (z).

So bob's real purpose in the identification protocol was just making sure Alice picked k/R first.

So to accomplish that without Bob, we can use a one way function to pick the random value based on R.  The usual way is with a hash function, though if you wanted to overdue the theme here encryption could be used (but in this case, it needs to be one where no one involved can decrypt).

So Alice sets:

k = random()
R = enc(k)
s = k + H(R)z

And publishes R,s;  which will convince anyone that she's the holder of P's secret when they check if enc(s) == R + H(R)P.

And we're almost to a signature, to get a signature we just need to make the choice of H() depend on a message, the easiest way to do that is to just concatenate it and replace H(R) in the protocol with H(R || message).   Tada: this is a standard schnorr signature, but just described as an application of additively homomorpic encryption (and a hash).

Beyond just making a weird point about encryption, this perspective could potentially help people understand on the signature works other than "magic":   The signer computes a secret line using their private key as the slope and a secret random value as the intercept. They evaluate the line at a random location determined by a hash of the encryption of their intercept and a message. They disclose the evaluation and the encryption of their intercept.  The verifier can check that the evaluation is correct because they have the evaluation location and encryption of the coefficients.  The common attacks on signatures e.g. using nonce reuse are just high school linear algebra on solving for a line giving evaluations.

With a little elaboration can even use this scheme to securely communicate a secret message which is indistinguishable from a signature too!  Lets imagine Alice has pubkey W (encryption of z1) and Bob has pubkey Q (encryption of z2) and wants to send the (short) encrypted message m to bob over a channel that only lets Alice communicate valid signatures.

Alice picks a cover message c that she's signing. Care must be taken to not ever reuse the same cover message with the same two parties and a different secret message.

Alice generates a new secret z that she'll use as her fake 'pubkey' for this signature:

z1 = H(W || Q || z1 * Q)   # (c could be included in this hash for better privacy if you want)
W = enc(z1)


Then signs:

k =  H(c || z1) + m
R = enc(k)
s = k + H(R||c)z


The result {W, R, s} is a valid signature for message c and can be transmitted over the signature only channel.  There are simpler ways of doing this (just set K to your message and have alice and bob share z) but they have more security footguns other than the requirement that c can't be reused.

Bob can use his knowledge of z2 to recover m from W, R, s, c. (exercise left for reader). Third parties can't distinguish this from an ordinary signature.

Well lets see, in a whole day right the entire LTC and DOGE networks bring in a total of $1.58 million dollars combined from fees and inflation (fees being utterly insignificant).

Bitcoin, from *fees alone* without any inflation brings in $1.72million dollars/day.

This means that even with inflation completely gone in Bitcoin, Bitcoin already brings in enough in fees pay for significantly more security than those two altcoins achieve essentially entirely from inflation.  (You could, for whatever it's worth substitute or even add other semi-popular altcoins to that and still be less than Bitcoin, I just used the two you suggest)

"Merged mining" is significantly undermined by the central game theory argument for mining:  The game theory argument for mining is that to mine you expend costly energy, and if your work won't end up in the longest chain (or you manage to blow up the thing you're mining) then that effort is wasted so it is in your best interest to mine honestly.  It gets some participation advantage because you can just add it on, but as we saw with namecoin the low income quickly causes parties to either no bother or not maintain their infrastructure.

In the case of merge mining if one asset has meaningful income (like dogecoin maybe has with its perpetual inflation) and the other asset does not-- like litecoin once is subsidy is depleted (unless something changes). Then only the income side has meaningful security, the non-income side does not because the attacker isn't losing much if his blocks don't end up on the longest chain or if he sets the whole thing on fire.

Maybe you can see why many Bitcoiners really dislike altcoiners.  It's usually not that they have any issue with the altcoin itself, it's because people with some kind of investment in the altcoin glibly spread misleading claims about Bitcoin in order to rationalize, justify, and promote their altcoins.  The points are seldom well justified or considered.  I'd say that a simple majority of altcoin centric arguments about Bitcoin are actually points against the altcoins if considered with a bit of care, like this one.

There may well be reasons that you could advocate ltc+doge,  but fudding Bitcoin about its ability to fund security with fees is not one of them.  If Bitcoin's *current* fee-only income isn't enough security income for your taste than you should conclude that these other coins are *currently* insecure and lack any kind of trajectory to allow them to achieve even their current level of security in the future (after all, even doges perpetual inflation effectively dilutes the mining income down to nothing over time too; just at the cost of also debasing everyone's holdings at the same time).

Argues? Where? AFAICT noise, toxicity, and attacks got so bad the discussion just *stopped*, except a bit of chatter among gadflies and navel gazers that won't ever do the work and can't manage the navigate the public politics.  Maybe you've seen some arguments among  those people, but they were only ever there to argue.  Or it's just unoriginal repetition of ideas that were thoroughly explored in 2012 (like "lets switch to scrypt and merge mine with litecoin!"), getting the responses that could have been copy and pasted from the last three times. If there was real activity you probably wouldn't notice those noise discussions arguing amongst themselves.

When I looked recently the developer chat channel logs, they now regularly go days without any comments at all, yet back in 2013 they averaged 1866 messages per day-- a day without activity would have been a shock.  That isn't argument-- argument would mean activity.  The mailing lists have been widely unsubscribed, most posts are people who've never been extensively involved in development, and just haven't received the message about how dead things are in terms of meaningful change.

Of course, (reinvoking the prior offtopic diversion) bitcoin development "dead" is still significantly more activity than most altcoins get-- so altcoiners don't get any ideas from this comment.  Just about a year ago or so the entire doge network was completely unable to bring up a single new node for *weeks*  until a bitcoin developer friend had a friend that wanted to dump their doge (the outage actually drove up prices because it limited the supply of old coins).  He had to fix some gross incompetence that was preventing nodes from syncing  (such as completely re-validating the defectively expensive scrypt POW and the gigant MM proofs every time it read one off the disk to give it to a peer) then used his fixed node to fix the other nodes, and brought their essentially failed (but hardly noticed failure since pools and exchanges were still running) network back to life.  Maybe next time no family member of a real developer will have doge to dump and it will just stay dead?  who knows!

Why do you take that for granted? Bitcoin fee income levels (even the sustained ones outside of the recent traffic) are many times the entire fees PLUS subsidy of several competing altcoins combined.  Are they currently screwed?

Guess you don't live in an area where comcast has a monopoly. In many places they have a "100Mbps" which rarely performs, but lets them claim that they provide broadband for the purpose of government reports.

What "use case" are you referring to?  A description of a use case should not mention Bitcoin-- it should mention a problem people have which Bitcoin might be a solution.

I'll give some examples:

"My bank (and ANY conventional bank I can find) is only open for international wire transfers from (say) 10am to 3pm M-F or other such limited hours and I want to be able to send money internationally *at any time*, 365 days a year, because I don't know when a good opportunity will happen or an emergency will come up" Bitcoin solves this.

"I tried using online payments but Paypal froze my account randomly with no explanation and wouldn't give me my money back for a year" Bitcoin solves this.

"I wanted to hold on to money but my government keeps printing it like its going out of style, debasing its value" Bitcoin solves this.

"To escape inflation I kept wealth at home as silver but it took up an enormous amount of space and was easily stolen by thieves because it was hard to secure in a way that was impossible for others to access". Bitcoin solves this.

"To escape inflation AND theft risk, I stored wealth in gold bars in a safe deposit box, but because I didn't visit for two years the bank auctioned off the content (or alternatively the FBI came and took it all because some OTHER customers were suspected of drug dealing)". Bitcoin fixes this.

"I wanted to buy a telescope but they required 20 minutes of invasive security questions that a scammer could have answered anyways and I couldn't convince my bank it wasn't fraud and they froze my account and it took me three days and a dozen phone calls to fix it" Bitcoin solves this.

"I wanted to buy provocative comic books, but even though they are unambiguously legal where I live, the government leaned on payment providers to deplatform the vendor" Bitcoin solves this.

"I'm concerned that years down the line my country might be taken over by a theocracy and they'll get all the payment company records and start executing people who purchased birth control or subject them to some less dire punishment." Bitcoin can help here too.

Each of these cases Bitcoin can help with because it removes trusted third parties from the process of either transacting or storing your wealth, trusted third parties which fail to deliver a stable system, can capriciously interfere with your right to associate with others, or otherwise act against your best interest.  These are examples of the use cases Bitcoin set out to solve, which its fundamental properties are designed to satisfy and are mostly difficult to impossible for other systems to solve (except to the extent that they imitate Bitcoin's design).

Use cases which aren't exclusive-- that any old alternative will also do are fine, but they don't provide a reason for someone to use Bitcoin when they otherwise wouldn't-- instead Bitcoin will get used for those based on other factors like existing usage for the exclusive reasons or because Bitcoin is less expensive (but that is a pretty unlikely case for cases where a centralized alternative works, because centralized alternatives can always be cheaper if they choose to be).

What is that supposed to mean?

Those stats are boarderline lies, they're provided by ISPs trying to juice government mandates and incentives.  Beyond the bulk misrepresentations they don't really expose how bad upload bandwidth is or how poor delivered performance is.   It's pretty common to have 100 Mbit down which seldom does more then 8mbit, and only offers 5mbit up (but usually at least delivers close to it).

There is no they buddy, only you.

The big inscriptions are non-standard still today, too.  The maximum weight of a standard transaction wasn't changed by taproot. ... but parties can and do pay miners to bypass those rules, and clearly have here.  So I think taproot is also pretty irrelevant for the huge ones too.

I don't think anyone can seriously deny that miners will accept payment to attack the network,  so I think the general skepticism for standardness as anything but a tool to protect forward compatibility mechanisms is probably well founded.

That's called a timewarp attack, there is an example I put into the testnet chain back whenever this edition of testnet started. An attack chain can advance time at a rate of about 1 sec per 6 blocks while keeping difficulty going DOWN (or at the minimum).

FWIW the timewarp attack can be prevented with a simple and fairly conservative constraint on the timestamp of one block during the interval-- a constraint that last time I checked had never been violated on mainnet.   Bluematt had a proposal introduce a softfork to fix it, but by the time he started on that the bitcoin ecosystem had started turning too toxic for people to want to pursue proposals --- so even years after it was realized that it could be fixed with a ~1 LOC change and deployed in a softfork this vulnerability remains unfixed and the mining code hasn't been changed to obey the rule to make a fix safer to deploy (there were no violations in the chain last I checked but in theory a miner could innocently violate the rule, so it would be safer to first get miners on code that won't violate the rule).

With no timewarp attack the comparison *still* needs to be on work rather than length, because an attacker could still gain an advantage over the honest chain on a fork that has lower difficulty but it's closer to a boundary effect e.g. relating to the fact that the honest chain may not be as far in he future as it was allowed to be or the honest boundary block wasn't as far in the future as it could have been (keep in mind the last difficulty interval of the attack can advance the clock at the minimum rate-- they don't care that the difficulty will go back up again, they just want to be able to produce more blocks than the honest network in spite having somewhat less hashpower before the difficulty does go back up)...

The input to a hash is arbitrary size, while the input to the pubkey generating function hast to be 256 bits or smaller.

The ECC key function is additively homomorphic:   PUBKEY(x) + PUBKEY(y) = PUBKEY(x + y)  while  HASH(x+y) is unrelated to HASH(x)+HASH(y).

This structure would be considered a vulneablity for a hash in the applications where hashes are used, but it's what makes ECC digital signatures possible.

Someone could use ECC to create a hash function, but they would need to produce a way to handle larger inputs and modify the output destroy the homomorphic property.  It would also be slow.   The NSA did this once, as part of a deterministic random bit generator. DRBGs usually use hash functions, in DualEC the NSA built one out of elliptic curve cryptography ... specifically so they could engineer a backdoor into it the special properties of ECC.     The DRBG was so slow and complicated that most people paid it little attention and assumed no one would use it,  but then the NSA paid RSA $10 million dollars to make it the default RNG in RSA's bsafe library.  RSA also use to use the threat of patent litigation to force people to use BSAFE for many years, so it wasn't an obscure library.

I've been away from development for a long time, so it's likely I'm out of sync and it's possible I'm confused--- I only looked into the discussions around this stuff when I learned about who's been funding the BRC-20 floods, and my interest is mostly limited to figuring how it plans into the overall attacks on Bitcoin developers by these parties.  That said, XKCD-386 applies and I can at least offer some historical context.

I don't think that's an accident.  Luke (like a dozen other current&former developers; including me) is being sued for billions of dollars with an allegation that we specifically and no one else control the Bitcoin network, and so we're obligated to institute a backdoor for Wright wright to "recover" billions of dollars worth of Bitcoin where he claims to have lost the keys.  You're not (currently!) on the list of defendants, and so bringing up you would actually undermine their argument that having opinions on blocking the spam was evidence of that control.


Not just a hardfork, it seems to be fundamentally *impossible* even with a hardfork: because attackers could just burn capacity with chains of transactions that look nearly indistinguishable (as they actually did in 2016/2017-- some of the flooding attacks are only obvious with retrospective blockchain analysis).

I'm mindful of the point pooya87 has made in another thread here that part of the attack is enlisting idiots to participate, which can actually be dampened by standardness rules to inhibit specific forms of spam.  I think he's right but I don't think it matters, the enlistment is only a small constant factor on the attack cost.  Sure-- the attacker will use enlistment to lower their costs and/or prolong their attack some if they can, but if they can't enlist they'll still attack.

There has been some more blatant attempted enlistment on reddit that the r/bitcoin mods have been pretty good about nuking.  E.g. posts claiming that "taproot" has an inflation bug that user can exploit by making a lot of transactions... their inability to get away with *that* kind of enlistment hasn't stopped the attack.  The attackers are just going to use whatever is available to attack, but removing those things won't stop the attack unless the things being removed are the only ways to accomplish it.   And to the extent that the attack is *specifically* to drive fees up, the actual structure of how they do it is completely irrelevant to the attacker, so blocking any particular one won't work.

I think its also absolutely guaranteed that anyone that successfully deploys standardness rules to inhibit this attack is going to be saddled with hundreds of thousands of dollars in legal fees defending lawsuits--- either because they get sucked into the "you must backdoor bitcoin for me" litigation somehow or because proxy entities will claim that blocking their spam destroyed their oh-so-legitimate business which was goona make billions.  It's happened before, see "United American Corp vs Amaury Sechet, Shamma Chancellor, and Jason Cox"-- bcash developers were sued by some shell company because they added a checkpoint that blocked a reorg attack Wright was threatening to perform on social media.  They defeated the lawsuit and the shell just declared bankruptcy and vanished, but even though they won they took on large costs that can't be recovered (cause the entity just vanished).

It's also the case that any specific spam filtering can't really stop enlistment..  like these BRC-20 transactions could be encoded in a way that makes it extremely difficult to filter them (as they only embed <90 bytes or so), they aren't now but that's because the attack is just really lazy.  It would at best be a bunch of wack-a-mole, and particularly hard to the extent that there exists any earnest usage at all (even if it's just a tiny fraction of a percent)-- since those earnest users will be useful fools for the attackers in opposing the bandaids.

If it was clear that it would work then the costs of trying it might be justifiable, but if it'll just delay or shift the form of the attack? ::meh::  I mean, feel free to put your own neck out, but I think that would be a pyrrhic victory.  I'm sure that in some attacks people would expose themselves to personal bankruptcy to defend even a non-guaranteed defense, but "an attacker is bankrupting themselves making fees elevated" is probably just not one of them.  Though anyone who disagrees is free to try!

All that said, I do think that the overall trend ... really since 2013 or 2014 has been to avoid having standardness restrictions except where it's needed to preserve the ability to introduce new features or protect hard-to-fix soft spots (like script opcodes that took too much time to execute relative to their weight usage).  Part of the motivation behind that trend is that filtering this or that structure doesn't actually prevent attacks since attackers will do whatever works, but part of it was also that additional standardness rules could be deployed as needed.  That's made harder by attackers pretending to be legitimate usage in enlistment attacks, which I think was probably expected in the past but perhaps under estimated-- what wasn't anticipated is that they could use any action in defense as a viable way to attack the defenders with lawsuits.  So in that sense you could say there may have been some oversight, but I don't know if the loss of "fix the spam with policy" as a tool is all that meaningful, given the broader point that the attack can just change shape.

I haven't even gone into the fact that standardness is a really weak protection since it doesn't apply to miners, who absolutely are known to mine non-standard txn for pay... the whole ethereum MEV dark forest with an endless supply of incentive incompatible smart contracts has also made dishonest conduct (in the sense of violating the unenforced protocol to maximize income) a norm for any part of that industry that has touched the ethereum ecosystem.

Enlistment can also be combated with communication and, in fact, communication is both necessary and sufficient since you can't deploy or preserve a stanardness rule against an attack without justifying it.  The tricky part is that if people make a big deal arguing against something they validate it as something important and give it free press so you have to be careful that you don't help it, but actually acting against with technical measures is probably a zillion times worse.

But here I don't know that a lot of communication is needed because I've seen very little evidence of significant enlistment, the enlistment mostly seems to be a cover.

Someone can argue that, but: (1) already we see miners sometimes manage to screw up the existing halvings and mine invalid blocks after it, so this would be even harder to get right, and (2) every time the reward decreases there is an incentive to reorg the chain to try to get the greater reward of the prior block instead of the lesser award of the next block.  The infrequent reductions bunch up that bad incentive into a short period that everyone is aware of rather than having the risk spread out.

More speculatively, a continually decreasing award seems like disincentivize participation favoring "Why bother starting when it rewards less than it did a day ago" over "the reward is still as good as its been for the last two years, I better start now before it drops again".

Today the small difference in what you suggest probably wouldn't be enough to cause instability, but early in Bitcoins history it probably would have been because there was essentially no fee income and the use of timelocks for anti-sniping hadn't been invented yet.

I don't think it's possible to do "strictly better": any other choice will be worse in some respect.  But equally I don't think the existing scheme is uniquely the best, since there are alternatives that are worse in some ways but better in others.

Every choice makes some tradeoff and there are many equally valid choices.  I think it's likely that Satoshi considered many valid options and picked the one he thought was simplest.

Indeed, Bitcointalk was long ago abandoned by the vast majority of people actually interested in doing development because it became a waste of their time and energy--  too few insightful discussions relative to ignorant ones and some of the ignorant posters are surprisingly abusive and prolific.

There are also too few translators-- people who understand the technical ins and outs and can explain and justify them though they're not directly involved, that can meat-shield the experts from people who are interested but technically clueless and save people with greater involvement or expertise from wasting their time on energy on people that don't (yet) know the difference between a Bitcoin and a bottle cap. ... though BCT probably has the second largest surviving population of these people of any of the online venues I've seen Bitcoin discussed, the stack exchange probably being the most.

These days I think there is relatively little development anymore that even makes sense to discuss outside of focused discussion around pull requests.  For example, I can't see a reason to have a bitcointalk thread over stuff like "streams: Drop confusing DataStream::Serialize method and << operator" or "refactor: rpc: Remove unnecessary uses of ParseNonRFCJSONValue() and rename it".  Mostly minutia that only matters to people maintaining the codebase, invisible to people who are only using the software.

The poor SNR and abuse isn't unique to Bitcointalk though it reached uselessness earlier than some other channels... I think probably the lack of discussion worthy activity is circularly related:  Interesting changes take collaboration, no one will collaborate when all the venues are toxic, without interesting changes there is nothing to discuss except toxic bullshit, wash rinse repeat.

*facepalm* I accidentally deleted ETFbitcoin's post above my reply, it's content is preserved in my quote (I'm not sure that it's all of it, unfortunately)... the quote/edit/delete buttons are right next to each other, and I don't use BCT much of late.  I'll send him a PM to repost it, and I'll fix the thread order.  

1 and 2 are correct, 3 is incorrect because it's talking about a different thing.

The post you've linked to is saying, effectively,  "The rules for witness type v0 further restrict the scriptpubkey to have exactly 20 or 32 bytes of payload, since that's the only sizes v0 can use.  With v1, instead, if the size isn't exactly 32 bytes (the only size that v1 can use) then the v1 rules aren't applied and those are treated the same as the other versions or v1 before the change: nothing is done, only the same validity rules apply as apply for all scriptpubkeys"  -- none of this has anything to do with data in the witnesses.

So for a scriptpubkey to get v1 treatment it must have v1 and exactly the right sized payload.  This leaves room e.g. to create a v1a that (for example) uses 33 bytes to add the sign back to the scriptpubkey or introduces 448 bit ECC without having to burn up an additional witness version number.

This consensus rule design doesn't improve people's ability to spam using large scriptpubkeys because the same large sizes are valid for non-segwit transactions and those couldn't be made consensus invalid without potentially destroying the bitcoins of someone who happened to have encumbered them with an nlocktime release that involves some large script.

Maybe the invalidity risk there is fringe enough that it could still be argued for, I think not, since the underlying attack that you'd be trying to stop doesn't really care *how* the data is encoded, closing off one will just cause them to use others-- but regardless, going around hobbling bitcoin's consensus rules to try to play wack a mole against some spam vector is a pretty *distinct* concern, and should be handled if at all separately and holistically.   Could you imagine if BIP 342 had an "oh yeah, and also all scriptpubkey's-- not just v1 but all unused witness types and non-segwit too are now limited to X bytes, hope you don't have any funds using long scripts that you can't move before BIP 342 gets activated!"? lol

I don't agree.

The exact same transactions were valid *before* (e.g. if taproot had never been proposed) and are also valid as witness versions 2 to 16, and the same congestion can be caused regardless of *any* limitation (just use more transactions or inputs).  I think people are being duped by a consensus cracking diversion intended to cause users to blame the congestion on "a bug" instead pretty the obvious flooding attack that is spending millions per day to congest the network-- flooding attacks were also being performed back in 2016.   There is a proven and robust way to inhibit flooding attacks, and as far as I know it's the only way to inhibit them: competition for space makes them eye wateringly expensive.  Unfortunately, it also makes ordinary transactions expensive (but far less so:  a normal transaction has to pay a high fee just once, while a flooder has to pay the fee of every transaction they block in each block they block it in) and inhibiting doesn't prevent them completely.  Sometimes attackers are willing to spend tens or hundreds of millions of dollars in a short lived attack--- though you have to wonder what they think they're going to get out of it.

I think it's a reasonable guess that since we know the congestion is almost entirely being performed by three Calvin Ayre funded companies that the goals are some mixture of congesting Bitcoin to reduce its utility and trick people into using his centralized and controlled fork of a fork of Bitcoin, BSV... and trying to get some engineers to push for controversial changes to filter their specific attack-- of course they instantly fanned the controversy as soon as Luke posted saying it should be blocked-- in order to attach lawsuits to even more technical experts and try to generate some substantiation for their existing multi-billion dollar backdoor demands.

Context: scammer Craig Wright pays people to spread that line because: (1) He has some narcissistic rivalry with everyone who understands technology better than him (which is  lot of people!), (2) he doesn't understand proof of work well enough to realize that a version with a trap-door is fundamentally unsuitable for almost every application people talk about using proof of work.  It's just pathetic.

Unfortunately, the whole thing about history being written by the victors only applies to stuff like warfare where the losers are literally killed.  Lots of people who don't know better end up picking up and repeating his narratives-- he stands to gain from spending to spread his bullshit and invests heavily in it.  Other people don't care to stop him.  Thanks for speaking up for the truth.

I think it's usually useless to debate motivations: either it's unambiguous, in which case there is no debate... or it's not and there will be no resolution.  Ultimately what matters is what people do, not what motivates them.  If something is explainable as confusion or benign greed, it's prudent to stick with that assumption until facts show otherwise both because it's more likely to be true but also because it has less collateral damage if you're wrong.

As far as the quote--  Your guess is as good as mine as to the intended tone, it's probably a mistake to assume much about it.  It can be extremely difficult to figure out the correct tone from text,  something I know all too well as someone who writes messages intended to sound playful but get received by many as a particularly forceful sermon.  

That said, It's easy to be popular with almost any identifiable clique:  Just yell the party lines louder than other people, hate on the right enemies, cheer on the right heros.  So much so that excessive popularity with an identifiable group can be a red-flag:  People who are genuine will usually have some unpopular opinions, they'll usually have better things to do with their time than sing from the hymn book all day long.   Bitcoin and the adjacent altcoin ecosystems have been full of bad actors using the popularity play book: Even early on many of the top rated OTC participants were scammers.  Plenty of loud twitter voices promoting Bitcoin turned out to only doing it to form a following to sell their scamcoin to... even Craig Wright totally suckered a big swath of large block bitcoiners[1] by saying what they wanted to hear. ([1] whom I disagreed with, but at least the general position was one a (confused) person could honestly adopt... not a con, but Wright managed to turn many people into con-co-conspirators by playing to their biases)

This isn't to say that disagreeable people are more trustworthy,  I think the compulsively disagreeable are even more likely to be bad actors.  There really just isn't a magic formula to figure out good motivations from bad.  But we don't have to-- unless you're shopping for a spouse you don't need to worry about judging people, just consider their actions and your responses.

I looked at the list discussion and see that other than luke people appear to be of the opinion that flooding attacks that drive up fees can't be completely prevented with known techniques-- sure users can block some particular transaction shape (as luke suggests) but the attacker will just make their flood look like something else.  I haven't given it that much thought but it matches my (admittedly rusty) impression.

We saw this back in 2016/2017 with sustained transaction flooding.  So I think it's not true to say that standardness rules prevented attacks like this, market forces for fees limit the attack but to the extent that people have become accustomed to consistently low fees as segwit adoption delivered excess capacity and now consider any elevation a disruption-- I don't think I've seen anyone propose anything that would prevent it more than competition for capacity does.  (Of course, there is always the BSV route: eliminate the capacity limits, let attacker push the chain up to many terabytes in size, drive off all nodes, do they can deploy stuff like "confiscation transactions" without anyone being able to do anything about it...)

Fortunately, this kind of attack is limited in its impact (causes the users choice of higher fees or waiting) and its execution is self limiting because it's extremely expensive (e.g. BRC-20 flood costing millions per day).

The attacks that standardness rules addressed were cases where some weird corner case used a disproportionate amount of resources such that you could exhaust the network without spending much on fees.  Those have mostly been addressed, the ones that remain are still protected against by standardness rules. (They ought to be actually fixed, since miners could still attack with them, but good luck there-- the appetite for making protocol improvements-- especially boring housekeeping ones-- given the toxic environment seems to be approximately zero)

That aside, *most* of the "they" you mention have long since quit working on Bitcoin, including myself (who I think might have been among the more outspoken in standing up against network abuse), and I think there is a snowballs chance in hell of any of them coming back now that it's clear that working on Bitcoin carries a serious risk of personal ruin fighting off billion dollar lawsuits from well funded attackers.  If you don't like it, perhaps count up the _20_ pages of this thread, the hundreds of comments on the subject and compare it to the relative jack shit the wider community has done to defend the developers against that other attack.  Every time it comes up there is inevitably someone "honebadger don't care-ing" it-- yet driving off people from contributing is a serious harm to the extent that sometimes engineering is needed to address other attacks.

If half the effort that has gone into the threads on BCT about this issue was put into dealing with Wright a couple years ago things would be in a doubly so (esp since >80% of BRC-20 traffic is from Ayre funded orgs-- it seems to be litterally another layer of the same attack!).

You're getting tricked by misinformation-- what I suspect is some intentional consensus cracking (especially since we know most if not all of the BRC-20 stuff is being funded by Ayre & related entities) though it might just be confusion.

This stuff doesn't have anything to do with taproot-- to prove this to yourself go start up node software from 2019 before the taproot bip was even proposed and observe that accepts this stuff just fine.

You could potentially attribute the attack to segwit in the sense that it increased the block size which made more room for junk but to the extent that your complaint is that fees have been driven up, the same attack would have worked prior to segwit.  It's also easy to see that people were embedding irrelevant data in Bitcoin long before segwit (fine example being the Bitcoin Whitepaper).

If you want to complain instead that the attack is bloating the blockchain on disk of archival nodes or that its increasing the data that must be transferred during IBD-- then it's fine to criticize segwit but otoh where the hell were you when there was extremely widespread demand for additional capacity? -- it's not like bloating up the chain is a surprising result: it's the reasonable and expected downside of increasing the capacity.

It's important when contemplating an attack to realize that the attackers have every reason to mislead about the nature of the attack and the enabling factors.

Another piece of measing narrative craft-- one I've seen rodarmor fall for, in fact describing his action as a kick in the teeth to bitcoin developers-- is the false claim that these ordinals translations are in any way charged lower fees by the network.  This isn't true.  The network doesn't set fees at all, they're established by the users competitively bidding for access to capacity.  Miners accept transactions in order of most fees per unit capacity down until the block is full.  Every transaction competes equally(*) and needs to pay based on the capacity it uses.

The deceptive discount claim dupes people for two reasons:  The first is because Bitcoin's block limit isn't measured in bytes, it's measured in weight.  But because the limit works on weight so do fee calculations.  If the limits was a limit on bytes (or the complaint was how much space archived nodes are using) but the fees miners demanded were irrationally calculated based on something else then it would be correct to say there was a discount, but there isn't.  The second is because segwit did in fact lower fees-- but it did so purely because it increased capacity resulting in a lower equilibrium fee rate. (Again, that's what people demanded.  Good job, you got what you wanted...)

If someone wants to say "because segwit, witness data like signature or witness-embeded garbage uses less capacity" -- then THAT would be true. Witness data using less capacity remains well justified: it should because it's prunable and doesn't have to be stored long term just to run a node at all.  Making this data use *more* capacity wouldn't diminish its effect on driving up transaction fees, it would *increase it*, because it would be using more capacity which could otherwise be used for other transactions.

To the extent that some misguided idiots want to store data in the blockchain the fact that it uses less capacity than it would without segwit only helps mitigate the harm.

To the extent that high fees are from an attack intending to drive up fees it's irrelevant in any case: no matter how it works the attacker has to pay in the fees of the next best transaction they displace in each block they displace it.

(*) ignoring things like CPFP which make some transactions more profitable then their fees imply due to having high-fee children.

Sorry, but in the interest of slowing the spread of misinformation this is just plainly false.  The idea of using a distributed anonymous cryptographic lottery to form a consensus is the revolutinary idea in Bitcoin and it had no historical precedent.  People were working on the problem since at least 2001 (search spent-twice) and not finding the answer-- even though they were well aware of the predecessor technologies:  The linked discussion included Hal Finney (eventual creator of RPOW), Adam Back (inventor of hashcash), and Peter Todd (eventual Bitcoin developer).

Sorry but that is also a fairly clear falsehood, one spread by inept and inexperienced developers to make themselves sound smarter.  Bitcoin was written in a modern style, almost entirely free of manual memory management.  Normally in industrial software you expect a defect rate of worse than 1 bug per thousand lines of code and bitcoin had a much higher proportion of tricky parts so I would expect a higher defect rate than typical.  Yet the original bitcoin software had an extremely low defect rate-- a few bugs in script mostly.  More than a few of the 'early' bugs found in 2011-2013 were introduced *later* after the initial release, the qualify of Bitcoin fell when public development began but then improved.  The defect rate in the original Bitcoin was significantly better than later developed altcoins which had the benefit of Bitcoin as an example and in some cases extremely experienced developers.  Comments by reviewers back in 2011 were mostly along the lines of "issues you expect to be there just aren't there".  The low defect rate is particularly surprising for a one-person project and has even been a reason some people have wondered if Satoshi didn't have more help than he made publicly known.

Some of these comments are because the original software lacked the modularity that would make sense for the later feature set, but those later features weren't imagined at the start so designing for them would have been an error and would have increased the defect rate.  It's easy to be critical in hindsight *after* you know the features that would later be developed.  But given the amount of *churn* in Bitcoin core, if choice of the correct abstractions and modules is a metric to judge experience we could say it supports an argument that Satoshi was more experience than the entire Core project is today (lol, but I don't think choice of abstractions is a very good metric).

It's possible that Satoshi was inexperienced but was a natural at it and worked very hard to get it right, but we absolutely can't say that there was poor software quality which implied inexperience.  I can't think of a single concrete "inexperienced developers do this" error that anyone has cited (other than the lament that it was not very modular).  Even the script bugs, they mostly arose through bad and surprising abstractions in library code-- not because of erroneous code that Satoshi wrote, maybe you could argue that failure to anticipate the library code being junk was a mark of inexperience but by that standard almost no one ever becomes experienced.


What more modern language would he have used?  The likely candidates that existed at the time have extremely poor performance (particularly memory usage overheads but also runtime), given that Bitcoin has many times been at the breaking point keeping up with the traffic and there are no alternative implementations with acceptable performance written in those more modern languages even today, I think that would have been unwise indeed.

Unisat ~= Calvin Ayre, https://nitter.it/B2029org/status/1655611301412982784

That's true, but brokenness never comes in an absolute form, it's always in some degree.  Better, more comprehensive terms would allow overcoming a greater degree of brokenness.

In any case, the MIT terms I think are generally pretty good. In hindsight I can see ways they could be improved, but even though they failed to get us a summary dismissal (which means they failed their primary purpose) very happy to have them over having nothing at all.

Right.  The vulnerability of concern there is that there is a risk some contributors could maliciously submit patent encumbered submissions without disclosing it then litigate against users.  They'd be countered on the basis of that their actions were misconduct ('cause they induced the infringement) and that the MIT license is an implied patent grant ('cause it gives you permission to USE etc, which you can't do without access to whatever patents there are),  but it would be easier to get a vexatious lawsuit dismissed if the contributors all had to agree to make their work available under an explicit patent grant (in addition to the MIT license).

The normal review process is inadequate because in the US patentees have a year after publication to file a patent and then there is some additional time for the patent application to be made public (and good luck finding it), so it's literally impossible for review alone to close the risk of that kind of attack. (Though I've previously advocated that consensus change proposals be substantially available for at least a year before activation to that it's at least theoretically possible to do a clearance search, if impractical).

Unfortunately even a parallel license with an explicit grant isn't sufficient, since a truly malicious party could make the infringing submissions through some anonymous sockpuppet account... but it at least might help in the case of a confused/misaligned employer or a situation where someone decides to go evil after the fact.

This thread might be of interest to some here: https://news.ycombinator.com/item?id=36119042

Creative commons specifically recommends against their licenses including CC0 for software.  One reason is that it lacks a disclaimer of liability.

The MIT expat license has what appears to be a strong disclaimer of liability.  Without it, anyone writing the software would be open to defending ruinously expensive lawsuits from users who didn't like how it worked. ... then again, Bitcoin has the MIT license and it failed to provide adequate protection.  ::shrugs::


Years back I'd tried suggesting the project require contributors to adopt apache 2.0 in parallel or a parallel patent grant, but by then much of the people around bitcoin had turned virulently toxic and the endurance of maintainers were already so thin that there didn't appear to be an appetite for it. 

::sigh::  "He who foresees calamities, suffers them twice..."