Next events will be on the 7th with the form of order hearing where you'll hear the injunctive relief we're seeking against Wright, but even with that aside this bullshit isn't over yet:  The lawsuit against exchanges for delisting BSV hasn't been dropped.

Wright has put up millions to cover his opponents costs in order to avoid orders to disclose the funding sources for his litigation.  The odd thing is that it's well known that Ayre is a funding source, -- so what are they so desperate to keep secret?  I wonder if there were parties funding Wright's attack on Bitcoin that would be surprising to learn about?

There are costs-- beyond the health impact to the network, pools charge a fee, and it is extremely easy for pools to steal from miners and for miners to withholding attack the pools.

wtf? why do you let people fucking lie to you like this.

They don't take up the "same space".  In order to validate blocks utxo data needs to be quickly accessible as the access speed bottlenecks validation speed, witness data doesn't need to be stored *at all*, since once you've validated it once you can forget it, so the long term cost of witness data is orders of magnitude lower.

Unfortunately the weight calculation can't disregard witness size completely because if its too disregarded it will make nodes bandwidth constrained, because witness and non-witness data are equivalent for the purpose relay at the tip.  Most nodes are far from bandwidth constrained and other known improvements at the time segwit was designed were expected to get nodes 2-4x bandwidth reduction (in terms of their ongoing p2p traffic).

In any case, the perspective you're adopting is a confused one-- I think a confused one specifically engineered by malicious parties attempting to engage in consensus cracking.

There is exactly one metric that matters when it comes to the ability to spam and the cost of spam: the capacity of the network relative to the demand.  Segwit did increase people's ability to add spam, but it did so purely by virtue of adding capacity.  Any other way of adding capacity would have the same effect.  Perhaps the particular spam *encoding* chosen might be different depending on how the capacity limit was constructed, but that's immaterial to anything you care about.   (and fortunately, the weighing scheme has caused the spammers here to encode their bullshit as witness data, which radically lowers the carrying cost of it for the network). 

This is a common post pattern people make to trick people into running malware.

Step 1. Have trouble getting things working (perhaps pretending).

Step 2. claim to have some magic attack that works and can recover private keys, explained with a bunch of opaque jargon.

Step 3. When people ask for copies of the tools, send them malware.   Usually the people at step 3 are coin thieves themselves, but not always.


Often these threads will use real terms so simple googling will "confirm" them, but they're misapplied.   A "twist attack" isn't an attack on secp256k1 but a related insecure curve.   You cannot engage in a twist attack except by getting the victim to produce an invalid pubkey or signature using faulty software.  Of course, if you could do that you could likely just have the backdoored code send you the key directly.

The only case  I'm aware of where it's perhaps more interesting is when you have a signing or key-generating device that you can potentially glitch with some kind of fault attack, getting it to temporarily produce a point on the faulty related curve rather than the real one.  Though this is why all such devices ought to verify keys and signatures after generating them, making it harder to ever get a corrupted point out of the device.

In any case, the OP's link is highly misleading.  In that thread I'm commenting on someone thinking that being able to run a limited number of operations in total counted as "a limit" and I point out that it's not a sufficient one.  But it was just a rando's question.  It's not difficult in any sense to implement a sensible limit (and in fact this was done in the elements test network and eventually copied into other bitcoin based blockchains like bcash).

OP, care to disclose your identity?  (or at least one you're better known by)

In order to be less identifiable as bitcoin traffic-- and iirc anything using the noise protocol also has an undifferentiated bitstream.

But that's not the purpose of the protocol, the purpose is to encrypt communications so that a passive monitor can't  simply watch where every transaction (/block) originates. 

It's just the case that since the protocol was changing it was convenient to switch to a form which would be more difficult to block (or at least would be when users move it off the default port. ).

Existing "privacy coins" change the security model pretty substantially--  a DLP break results in unbounded undetectable inflation.  They also tend to have scaling/scanning problems that in practice obliterate much of the privacy gains-- e.g. because huge numbers of users hand over scanning keys who might well just be selling them to your adversaries (whomever they are).

There is no free lunch, at least not yet-- though there is a lot of research ongoing.

Meanwhile there are ways to use bitcoin much more privately with little cost-- and yet few users avail themselves of them.  So technology isn't the limiting point or at least not the only limiting point.  Even better things have been imagined and could be developed, but a limiting factor there is just that no one will use them.  Or only people doing actually shitty stuff will:  Helping bad actors as an unavoidable side effect of helping everyone else is one thing-- it's an inherent consequences of development and invention--, but helping mostly the bad actors is something else entirely. -- and a privacy tool that is mostly used by bad actors isn't really much of a privacy tool anyways.


Look at zcash or whatever, use of the anonymity part is such an insubstantial part of the system that careful bitcoin use probably gets you a better anonymity set in spite of the huge theoretical gap in the potential privacy level.


Aside: Stronger privacy tools built out of non-privacy or weaker privacy functionality are inherently more censorship resistant and techniques that can also join users that don't care about privacy in their anonymity set will tend to have bigger anonymity sets.


As far as the tweet goes-- I doubt any bitcoin developer has ever heard from Snowden, I can imagine if they had they'd be quite exited.  Don't read too much into hyperbole.

Ah and aside: the latest Bitcoin Core major release supports a new p2p protocol which is encrypted, -- an important step forward against global passive observers... yet only about 9% of listening nodes are running it!

Use of the apparent difficult has been proposed many times before-- it and other schemes that result in a unique value for each block which is calcuable by the block finder immediately lead to a withholding attack:  If you know your block is unusually good, such that it is likely to win even if announced late, you are better off not announcing it.  The withholding profits are proporitional to your share of hash power (as thats how often your advantage gets you a second block) so it's also a centralization pressure.

Bitcoin's criteria has always been that each node adopt the first block it sees which meets the target, which creates an incentive to announce (one which breaks down if your share of the hashpower is over a large threshold, but if any party controls that much hashpower the system has other worse problems).

When your body gets a virus you get sick as your immune system fights off the infection.  Most of the symptoms you experience aren't from the virus-- they're from the immune response.

Bitcoin has a defense against flooding attacks.  Like your immune system, this defense is somewhat painful even to things which aren't the attacker.  But whatever the attacker is willing to spend, it'll eventually be exhausted and Bitcoin will be free to continue.

Compare to BSV, for example, which removed the defenses... where in a few days >100GBytes was added to their utxo set, their chain is now terabytes in spite of virtually no real use, and the fact that its impractical for anyone else to validate it let them slip in rules that allow the miner to steal any coin it wants.  And these harms remain forever, even when the attack stops.

Is Bitcoin's defense the most that can be done against flooding attacks?  Perhaps not.  Especially for ones that involve conscription (suckering other users into participating in the attack) it may be possible to convince the conscripts to stop.  Unfortuantely, conscription is usually fueled through things like the unbridled greed attached to seigniorage.  It's hard to convince people to not fuck over others when they think they can Make Money Fast.  Attempts to do so can backfire and just give validation and free press to the attack. (something some people have been quick to exploit, it's not that uncommon to find that the very first online mention of some new sketchy thing is anonymous complaints that the thing is being attacked or opposed. ::sigh:

There is no need to change the message and it's not desirable to do so.

Libsecp256k1 has context randomization available, as well as the nonce function aux randomness input. Either should be enough to mitigate this attack even if its vulnerable in the first place.

Making an application where an attacker can force you to make thousands of signatures while they time you is also not a great idea.

Fair enough, I hadn't been considering the ignorant enlisted-- e.g. people spamming out BRC-20 tokens because intentional attackers will buy them-- as attackers.  They don't intend to attack, they intend to "use" bitcoin to make money fast it just so happens that the actual attackers have managed to arrange things so that the "usage" is disruptive.

There are plenty of people who are irritated by the high fees created by this traffic who respond with suggestions to eliminate the resource limits, which are the only things holding back the attack and making it expensive-- and that's more where my warning applies.

And right you are that neither the attackers nor many of the people just trying to make a quick buck on the traffic give a damn if bitcoin is worth anything 5 years from now. But for the same reason, their concerns shouldn't weigh highly in everyone else's evaluation.

I can't decode the misunderstanding required to produce that answer. Do you think the attackers would accomplish something by getting themselves shut down for copyright infringement?

The attackers goal in that attack is make every node operator a copyright infringer and then they or someone else can shut any one of them down with an email and the rights holder has standing to drag anyone to court and bankrupt them with legal fees before they ever get to the novel leal question.  The attacker never needs to run a full node, it's better for the attack that they don't.

Related developers implemented this on BSV a couple years ago, in "CryptoFights". It serves no purpose except as a cover to add garbage to the blockchain, no code was ever even written to read the data back out that they wrote in... and why would anyone do that? Writing game state to a immutable public ledger serves absolutely no purpose itself, but for the damage you can do to other people's ability to validate the ledger.


.Because . Its . An . Attack.

Stuffing the blockchain full of unlawfully copied material is an attack, it's probably no accident that they picked the notoriously litigious nintendo as an initial target.

Doubling the UTXO set size with meaningless 'tokens' that have absolutely no purpose is an attack. (people talk about ordinals a lot but by far most of the congestion when I've looked is actually BRC-20)

If the usage were genuine they could save hundreds of millions of dollars in fees just doing it on their own blockchain, or almost any one of a thousand pre-existing ones.

The very same people doing this stuff are BSVers funded by Calvin Ayre.  This isn't speculation or a conspiracy theory, you can simply look them up. They carried out the same attacks on BSV, adding 165 GB to the utxo set in just five days (not the chain! the utxo set!), pushing off every other known non-calvin-controlled/funded node off the network.  At least in Bitcoin it mostly just drives fees up rather than forever destroying the network in days, because robustness to these kind of attacks was considered.  Many people are mistaking the protection *working* (fees go up making the attack astronomically expensive for the attacker) for the problem itself.

Most of you are absolutely fucking idiots. You deserve what you get.

Eventually you will figure it out as one by one your nodes are turned off by DMCA complaints, you get fucking bankrupted by vexatious copyright litigation and other bullshit resulting from attacks on the network that you were happy to pretend were actually good when you thought they could pump the price and you will look up and shout "save us!" and I'll whisper "No."

unless you are on relatively lower power hardware, this isn't the case because script validation is highly parallel and all the other processing ends up bottlenecking.

This has been tested in the past and torrent + validate was a massive slowdown.  Admittedly that was years ago, but if it's not true it must be because of limitations or defects in the node software (e.g. causing it to not achieve the potential download speed) as there is no reason using a torrent and separately validating should be faster.

This could possibly have some connection to my involuntary hobby-horse.

Recent leaked emails[1] show that Calvin Ayre-- the billionaire rube that has been funding Craig Wright's litigation-- believes that Wright actually controls early addresses in the blockchain, consistent with Wright's initial claims but contradicting Wright's more recent claims in court (that he "stomped the hard drives").  Calvin believes Wright can only win the lawsuit against Bitcoin devs by using these early keys and has been pressuring Wright to do so. I'd agree that at this point it would be his only path to even have a chance of winning, and even that would be far from certian given the extraordinary level of obvious forgeries.

On December 20th the UK courts increased the security Wright owes the Bitcoin devs for trial from £100k to £900k. The remaining amount not already paid was due today. (We won't know for a few days if the payment to the court cleared).  At the time of the transfer 26.91679286 was worth about £920k.

Up thread it's noted that the source of the funds has heavy BRC-20 activity and I've been told that Ayre has been significantly funding BRC-20 activity.

I wouldn't expect Wright to make the payment out of funds newly received from Ayre, but rather to make them out of float used to pay his legal representation going forward, and then get a top-up payment from Ayre.  Wouldn't it be funny if Ayre paid Satoshi's address as part of an effort to force Wright to use it?  It would be clever on his part:  If he believes Wright will lose unless he uses the address then funding him via an address he can't use won't make things worse and it might save Ayre money if Wright's inability to pay terminates the case early. It would be a genuinely good idea, given Ayre's beliefs. (a better idea would be to wake up and stop being ripped off, but that would have happened long ago if it were going to happen)

Another related explanation is that someone may have set this address as their primary address on a service, either as a joke or because they were LARPing as Satoshi-- and then they either accidentally withdrew to it or got kicked off the platform and automatically had their funds sent there.  Who do we know LARPs as Satoshi and may have needed to access another 26.9-ish Bitcoin today??  

History may not repeat but it does rhyme. During the large ATO investigation into Wright, Wright sent some amount of bitcoin equal to his tax-ID *to* some high value address he was (falsely) claiming to own-- so he could then point to his tax ID on the blockexplorer page as evidence that he owned the address.  The tax office didn't fall for it, but I could easily see some people falling for it. 26.9 BTC is a lot of money but relative to the amount Wright is spending on litigation it's not *that* substantial, it wouldn't be impossible for that manic to think he could get some benefit in court by throwing coins away at Satoshi's address.

All in all it's probably more likely that someone had the genesis address in their clipboard for some reason,  but I wouldn't find any of the above too shocking and they are fun to consider.


[1] Email page 1; Email page 2

Meh, Satoshi disabled all opcodes that allocated memory because there wasn't any control to prevent them from allocating too much. It was an urgent vulnerability. You could do dup mul dup mul dup mul dup mul dup mul... and run every node out of memory validating it. Like cat a multiply output is the sum of
the size of the inputs.

There was no fast way to make the validation engine safe because all the script numbers were openssl bignumber objects at the time, and there was no clear specification on how those suckers worked.  God knows what consensus and resource exhaustion bugs existed there.

The story today would be different, script numbers are now integers not some weird library object. A safe multiply would be trivial to add (and there is one I think from elements that has been copied into a bunch of forks of Bitcoin).

There are clear uses for arithmetic operations, particularly it lets you implement some alternative cryptographic schemes... like for example an anonymous accumulator output.

But there is less of a case for implementing them in the abstract since the 'generic' things that get implemented may be too inefficient or just not do exactly the right thing for the use to actually work.  So it's important to have clear use cases just to validate that the construct is actually useful.

I think things should be easier to justify with taproot, because if your application only needs to use the fancy opcodes in an exceptional case, the fact that they may be expensive to use isn't a problem.

Consider this scheme:  A cryptographic accumulator like Zerocoin lets parties put in coins and then take them out without any linkage between the transactions.  But it requires 3KB proofs making it costly to use.  A group of N people could come together and create an output which has a musig2 N-of-N threshold signature as the root,  and the expensive accumulator thing as a hidden branch.  So long as all N people are online they all just jointly sign to make changes to the accumulator, keeping all the accumulator proof stuff private and offline.  But if one of the N parties goes offline for whatever reason, no ones funds are frozen-- they can use the accumulator to kick out the unresponsive party at a one time cost and continue on.

Particularly if the N parties tend to pay each other often, this scheme is really efficient since it can encapsulate all the N*(N-1) potential payments between parties simultaneously in a transaction that uses the resources of a single party payment.

There are ways to do these schemes without a cryptographic accumulator, but once N is over a threshold size an accumulator is probably the cheapest way to implement it... even if it requires a pretty expensive script.  Of course it's more useful the cheaper that backup escape hatch is, so it's important that the right operations are implemented for it. The simple and stupid multiply would probably not result in a usefully efficient implementation.

I don't say this to advocate for any proposal (I don't even known if any exist right now) but to just point out that there are applications and not just trivial or dubious ones.

I wonder if Ledger is regretting their decision to support scamcoins yet? -- seams like it may ultimately cost them their business.

It's hard enough to handle bitcoin securely, but to handle alternatives whose designs have big security problems and then to support a thousand of them? It's a recipe for disaster on the basis of complexity alone.

It's not impossible, but I thought that through before commenting.

In this case I thought it better to blow it up immediately because it was significantly less credible than fakes used by Wright already and so I thought the odds of him attempting to use this one someplace meaningful (other than an effort to cause a quick BSV spike, which this might have been) was pretty low.