PseudoNode is better because it also covers any future non-blocksize related hardfork:



The only rational thing to do is to replace the entire Bitcoin network with PseudoNodes

This attack can be made more effective by exploiting this.  That is, instead of a vanilla OP_RETURN you use the script:


This counts as a extra 20 sigOps.  This bug is fixed in 0.12.0 (by making this script non-standard).

Fixing the broken sigOp counting method is indeed a hardfork.  It can be fixed when (if?) there is a block-size hardfork, e.g. this is one proposal.

This specific attack can also be mitigated by enforcing a bytes-per-sigop limit (policy change), as was merged into 0.12.0.  Any miner that does not adopt this policy will still be vulnerable.

Another attack...last 6 blocks (edit: and counting) have been hit.

Example: #385910 with 19125 fake sigOps.  The block is only 200KB despite a 5MB backlog (according to tradeblock).  It seems this attack is very effective.

Edit:
#385911 unaffected (enough high-fee legit txs)
#385912 = 18990 fake sigOps, 280KB.
#385913 = 18945 fake sigOps, 281KB.
#385914 = 17325 fake sigOps, 470KB.
...etc.

At least the attack is proven to work in practice.

Another attack, this time block #384831's sigOp limit was hit.

Is this you amaclin?  I thought this would be against your policy of not spending money on attacks?

This is a specific DoS attack vector that has nothing to do with buffer overflows.

The worse case scenario is that no transactions are confirmed for a while until centralized mining intervenes.

Looks like the attacker has successfully launched another attack.  This time using the address 3EgSUauJG5N27AUfQwiUfjAhHe6y9AKdVs corresponding to the script:


This time the attacker managed to successfully fill the 20,000 sigOp limit for block #382053, where 1245x15 = 18675 are fake sigOps arising from the attack transactions.  This meant that no more transactions (legitimate or otherwise) could be included in the block, leading to an underfull block of ~288KB (of which ~68KB are the attack txs).  Note that the network is currently running at capacity, with 1MB or 750KB blocks the norm.

The new attack was limited to a single block.  Also the attacker used a low fee rate of ~18sat/byte.  A higher fee rate would have made the attack for effective (but more expensive).

It appears that someone launched a limited form of this attack using the address 3G83ox5zw7D6eySoSMCervh9cbhMXdA5t9.  The address corresponds to the script:


The script is spent by push 0 in the sigScript.

The attacker only generated 960 such outputs, which corresponds to 14400 sigOps, which is not enough even to fill a block.  Furthermore the fee rate for the transactions was not very high (37sat/byte), meaning that most normal traffic would be unaffected anyway.  So overall this attack had no affect.  Maybe this was a test?

It was meant to be a "rule of thumb" for humans -- not a precise test.

The is an easy rule-of-thumb to spot high-S signatures.  For example, the following sig is high-S

3046022100aea3c7faf22df9ecf795ddb470d000bb2345679363fde6c24df4ab9c6922ff5d022100ae2ff77a2cd10794f166cbb7782316d6ceb74fc22c2188a22c52f6f1847401fa01

If the highlighted hex "022100" appears in the middle of the sig, then it is high-S.  Compare with the low-S equivalent:

3045022100aea3c7faf22df9ecf795ddb470d000bb2345679363fde6c24df4ab9c6922ff5d022051d00885d32ef86b0e99344887dce927ebf78d2483271799937f679b4bc23f4701

The low-S has "0220" (highlighted) or something else.

As I said in my post (which was overlooked?): coinwallet are not releasing more keys and are consolidating the remaining spam for themselves.  The current >1GB mempool backlog is directly related to this.

It seems Coinwallet have cancelled the 'giveaway' and have started consolidating the remaining dust presumably for themselves.  Example tx.  They have not released anymore keys AFAIK.

The entire tx chain (from the tx I linked to) has been invalidated.  This means that the sender needs to create new txs otherwise you'll never get paid.

This tx will not confirm.  It belongs to a tx chain that has already been invalidated by a malleated tx (original is here).

This attack is very good at exposing bad software.

I am not a "hodler" either; I am not financially or emotionally invested in Bitcoin.  I was just curious as to what the effect on the network would be, so was disappointed that it stopped.  But it has since restarted.

This attack is "free".  There is no profit but also no cost.  The attack is also not very difficult I think, so if you stop then someone can easily start again.

This is also the correct way to do it.


Perhaps to remind the community not to rely on chains of unconfirmed txs.

Btw, I wonder if it is possible to design scripts immune to this attack, e.g.


The wallet software needs to "mine" a 73byte sig (not very hard).
The malleated sig is always 1 byte bigger, so cannot be used.

I am not surprised.  You were my prime suspect.

This "attack" probably stops spam scripts that generate long chains of unconfirmed txs.  It might actually be a good thing to leave this running.

I think I get it -- it's because K is known.