Topic: Cheap way to attack blockchain - page 7. (Read 28272 times)

Bitcoin blockchain? OP_RETURN output?

If only there were some kind of immutable public ledger I could store information on...

EDIT: evidently needed the ""

Quoted. Just to prove for future use (forum allows to edit messages, so the date of message does not prove anything)

Here is another hash (this time XT/BIP101 related):




There are a ~1000 6-byte variants.  For 7, 8, 9 byte, etc., there can be billions.  So a blacklist is not feasible.

Probably the correct way is to fix the sigop counting algorithm if there is a hardfork.

You can not create a blacklist before the attack start.
Because I can create and fund thousands such addresses


is spendable by OP_1

Yes, it is possible to change the transaction priority algorithm

Sounds like the best way to plug this loophole is to create the blacklist as suggested. Good to see developers catching this stuff before there is an attack on the whole network.

Blacklisting would be the "cheap fix", on a fairly optimized pool, you can expect there will be some kind of optimizer that tries to optimize the pool blocks by maximizing the tx fee while minimizing block size (to minimize orphans from propagation delays).
Which such block optimizations, your SIGOPS-heavy tx would naturally be pushed back as they would prevent more fee-paying tx to get in the block.

The "reference" core implementation (as described in https://en.bitcoin.it/wiki/Transaction_fees#Including_in_Blocks) would be vulnerable, but I do not expect any major bitcoin pool to run on that implementation (unless they do it out of charity).


You mean XT blacklist?

Services that provide taint info and services around it have already existed for years now, official blacklisting would just be acknowledging publicly what has been common knowledge less publicly. Heck, my explorers provide taint analysis information for 130+ cryptos, so it's really something you have to be aware of, and just "deal with it".

If you want better technological fungibility, DASH or XMR provide partial solutions, each with its own set of vulnerabilities and issues though, the perfect fungible crypto has not been invented yet IMHO.


Yes, and that leaves only two possible explanations in my mind: either the pool operators are not good at maths or it was pushing an agenda in the direction they liked. I do not think they are not good at maths, so let the conspiracy theories begin

Sorry.
So, there are at least 4 persons who has a knowledge how to attack blockchain 
You, me, Peter Todd and the creator of that transaction 

Hey...there's no connection between me an that alleged transaction .

Anyway, as Peter said, this is a known problem, meaning that I was not the first to figure it out.  If I figured it out then so will others.

I'm not sure what the fix is though.  That crappy sigop-counting code is consensus critical.  Probably we need a tightening of the IsStandard() rules...

You put it into blockchain 
This was releasing the attack vector for everyone 

Yes this is a known attack.  I independently discovered it a few weeks ago:

[Consider the script "OP_0 OP_IF OP_15 OP_CHECKMULTISIG OP_ENDIF OP_1", e.g.
see 3PxwzLuPZtgHuz2J9ocg6ejNcci5WbtS3h

This script is 6 bytes and "consumes" 15 sigops if I am not mistaken.  An
attacker can use this to fill the block sigop limit of 20000.  E.g.  See
6766e75d6166a0a14bd814921d0f903285e15779e648d7ec52a4f7c0868ec07d (225 sigops
in ~740 bytes).  An attacker spends just 0.04BTC ($10.70) to "fill" a block
with high-fee transactions. 

reddit.com/u/basil00

salt: 3md9smcjd7jkafh83mdlsjc9w,03m
]

Take the sha256 of everything between the square brackets [...] (including empty line at the end) and it will match this hash.  This is a version of the message I sent to Peter Todd to report the problem.  Peter informed me that it is a known problem.  I didn't release it publicly because it could be used for a very cheap and effective DoS attack (currently just $9USD to "fill" a block).

Yes. Miners can blacklist redeeming p2sh outputs with abnormal SIGOPS count.
Also they can mark these txs as low priority (need some coding)
What do you think about the currency with blacklisted addresses?

OK, lets combine this attack with old good spam

During the last "stress-test" the majority of miners decided to include spam transactions to their blocks.

Main "weakness" for this attack is that miners could easily just ignore those transactions, without involving any hard fork.

Only the pools that accept those transactions *and* that do not prioritize transactions in a block by total fee would be impacted, pools that build their blocks based on max fee they can rack in a block would automatically eliminate them, they may just need to take the SIGOPS limit into their block optimization code, but that's all.

In practice only the "faucet pools", those that accept zero-fee tx and do not prioritize tx would likely feel the attack.

So the practical spamming would be limited to relaying and the mempool, so no biggy.

Seems to me that I know new way to attack & flood bitcoin network.

The last attacks were based on filling the blocks with transactions.
This is because of limit of block size. (Consensus rule that the blocksize is below 1mb)

But there are another limits for block which can not be changed without hard fork.

There is a limit of SIGOPS in transactions included to a block.

consensus.h

So, MAX_BLOCK_SIGOPS is 20000

How does the client calculate the number of SIGOPS? Let us look to the sources.

main.cpp

Miner node includes transactions to a block while the nSigOps not exceeds 20000.
The block with nSigOps > 20000 will be invalid (consensus rule) and will be rejected by all other nodes.

Now let us look the transaction
https://blockchain.info/tx/6766e75d6166a0a14bd814921d0f903285e15779e648d7ec52a4f7c0868ec07d
and calculate the number of SIGOPS in it

All input scripts are redeeming from p2sh-outputs with the inner scripts build on the same template:
The number of SIGOPS in this small script is 15 (this is maximum value to pass IsStandard)
And the total number of SIGOPS in 6766e75d6166a0a14bd814921d0f903285e15779e648d7ec52a4f7c0868ec07d is 15 * 15 = 225

So, the maximum number of such transactions in one block is only 88 (because floor ( 20000 / 225 ) = 88)
And inserting 88 such transactions in one block leaves only 200 SIGOPS for regular transactions.
Which leaves a room only for ~100 transactions in block for other persons

The attack vector should be:
1) create and fund a big number of such p2sh-utxo
2) redeem them to OP_RETURN or to regular output

Each such transaction costs 0.00045 for dishonest attacker (can be even less)
88 transactions (attack one block) will cost only 0.0396 BTC
Daily attack 5.7024 BTC - not a big deal

Wanna hire me for this dirty job?