Pages:
Author

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

legendary
Activity: 1260
Merit: 1019
September 02, 2015, 04:29:20 AM
#14
Quoted. Just to prove for future use (forum allows to edit messages, so the date of message does not prove anything)

If only there were some kind of immutable public ledger I could store information on...
Bitcoin blockchain? OP_RETURN output?
member
Activity: 60
Merit: 10
September 02, 2015, 04:23:31 AM
#13
Quoted. Just to prove for future use (forum allows to edit messages, so the date of message does not prove anything)

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

EDIT: evidently needed the "Smiley"
legendary
Activity: 1260
Merit: 1019
September 02, 2015, 02:33:10 AM
#12
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):
Code:
d894bd6f1f8222ceb5101cc1d5d3f3eb326e04ce6b9567f74cca151bb2b7b927
member
Activity: 60
Merit: 10
September 01, 2015, 07:40:08 PM
#11
Here is another hash (this time XT/BIP101 related):

Code:
d894bd6f1f8222ceb5101cc1d5d3f3eb326e04ce6b9567f74cca151bb2b7b927

You can not create a blacklist before the attack start.

Code:
OP_
OP_
OP_NOTIF
  OP_15
  [OP_CHECKMULTISIG | OP_CHECKMULTISIGVERIFY]
OP_ENDIF

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.
legendary
Activity: 1260
Merit: 1019
September 01, 2015, 03:12:47 PM
#10
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.
You can not create a blacklist before the attack start.
Because I can create and fund thousands such addresses

Code:
OP_DUP
OP_NOTIF
  OP_15
  OP_CHECKMULTISIG
 
OP_ENDIF

is spendable by OP_1

Yes, it is possible to change the transaction priority algorithm
sr. member
Activity: 448
Merit: 251
September 01, 2015, 02:32:48 PM
#9
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.
legendary
Activity: 1100
Merit: 1032
August 31, 2015, 08:17:09 AM
#8
Yes. Miners can blacklist redeeming p2sh outputs with abnormal SIGOPS count.
Also they can mark these txs as low priority (need some coding)

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).

What do you think about the currency with blacklisted addresses?

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.

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

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 Smiley
legendary
Activity: 1260
Merit: 1019
August 31, 2015, 06:22:11 AM
#7
Hey...there's no connection between me an that alleged transaction.
Sorry.
So, there are at least 4 persons who has a knowledge how to attack blockchain  Grin
You, me, Peter Todd and the creator of that transaction  Smiley
member
Activity: 60
Merit: 10
August 31, 2015, 06:12:30 AM
#6
Quote
You put it into blockchain  Grin
This was releasing the attack vector for everyone  Smiley

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

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...
legendary
Activity: 1260
Merit: 1019
August 31, 2015, 06:04:11 AM
#5
 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).

You put it into blockchain  Grin
This was releasing the attack vector for everyone  Smiley
member
Activity: 60
Merit: 10
August 31, 2015, 05:49:53 AM
#4
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).
legendary
Activity: 1260
Merit: 1019
August 31, 2015, 03:23:19 AM
#3
Main "weakness" for this attack is that miners could easily just ignore those transactions, without involving any hard fork.
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?

So the practical spamming would be limited to relaying and the mempool, so no biggy.
OK, lets combine this attack with old good spam Smiley

During the last "stress-test" the majority of miners decided to include spam transactions to their blocks.
legendary
Activity: 1100
Merit: 1032
August 31, 2015, 03:17:44 AM
#2
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?  Grin

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.
legendary
Activity: 1260
Merit: 1019
August 31, 2015, 02:58:03 AM
#1
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
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;

So, MAX_BLOCK_SIGOPS is 20000

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

main.cpp
Code:
            if (fStrictPayToScriptHash)
            {
                // Add in sigops done by pay-to-script-hash inputs;
                // this is to prevent a "rogue miner" from creating
                // an incredibly-expensive-to-validate block.
                nSigOps += GetP2SHSigOpCount(tx, view);
                if (nSigOps > MAX_BLOCK_SIGOPS)
                    return state.DoS(100, error("ConnectBlock(): too many sigops"),
                                     REJECT_INVALID, "bad-blk-sigops");
            }

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:
Code:
OP_0 
OP_IF
  OP_15
  OP_CHECKMULTISIG
OP_ENDIF
OP_SMALLINTEGER
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?  Grin

Pages:
Jump to: