Bitcoin Forum
May 06, 2024, 01:54:46 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 6 7 »  All
  Print  
Author Topic: Cheap way to attack blockchain  (Read 28206 times)
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
August 31, 2015, 07:58:03 AM
Last edit: August 31, 2015, 08:12:51 AM by amaclin
 #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

1714960486
Hero Member
*
Offline Offline

Posts: 1714960486

View Profile Personal Message (Offline)

Ignore
1714960486
Reply with quote  #2

1714960486
Report to moderator
Bitcoin addresses contain a checksum, so it is very unlikely that mistyping an address will cause you to lose money.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
fairglu
Legendary
*
Offline Offline

Activity: 1100
Merit: 1030


View Profile WWW
August 31, 2015, 08: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.

amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
August 31, 2015, 08: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.
basil00
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
August 31, 2015, 10: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).
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
August 31, 2015, 11: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
basil00
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
August 31, 2015, 11:12:30 AM
Last edit: August 31, 2015, 11:29:34 AM by basil00
 #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...
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
August 31, 2015, 11: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
fairglu
Legendary
*
Offline Offline

Activity: 1100
Merit: 1030


View Profile WWW
August 31, 2015, 01:17:09 PM
 #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

tommorisonwebdesign
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
September 01, 2015, 07: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.

Signatures? How about learning a skill... I don't care either way. Everybody has to make a living somehow.
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
September 01, 2015, 08: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
  <push couple random bytes>
OP_ENDIF

is spendable by OP_1

Yes, it is possible to change the transaction priority algorithm
basil00
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
September 02, 2015, 12:40:08 AM
Last edit: September 02, 2015, 09:21:09 AM by basil00
 #11

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

Code:
d894bd6f1f8222ceb5101cc1d5d3f3eb326e04ce6b9567f74cca151bb2b7b927

You can not create a blacklist before the attack start.

Code:
OP_<smallInteger>
OP_<smallInteger>
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.
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
September 02, 2015, 07: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
basil00
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
September 02, 2015, 09:23:31 AM
Last edit: September 03, 2015, 02:52:19 AM by basil00
 #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"
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
September 02, 2015, 09: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?
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1093


View Profile
September 02, 2015, 09:39:58 AM
 #15

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

Have you heard of a project called "Bitcoin"?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
September 02, 2015, 10:15:03 AM
 #16

Have you heard of a project called "Bitcoin"?
  Grin Grin Grin
Today it is immutable. But nothing is permanent under the Moon
speaktome
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250



View Profile
September 06, 2015, 07:43:42 PM
 #17

Wanna hire me for this dirty job?   Grin


More like to somebody Gonna touch your door. Grin                    Is joke of course.



             ▄██████████▄
           ▄██████████████▄
          █████▀      ▀█████
         ████▀          ▀████
         ▀▀▀   ▄██████▄   ███▌
     ▄▄████   ▐████████▌  ████  ▄▄
   ▄████████   ▀██████▀   ███▌ ████▄
  █████▀▀▀▀▀      ▐█▌     ▀▀▀  ▀█████
 ████▀          ▄█████▄          ▀████
████   ▄█████▄▄█▀     ▀█▄▄█████▄   ███▌
███▌  ▐███████▌   ███   ▐███████▌  ▐██▌
████   ▀█████▀    ▀███   ▀█████▀   ███▌
 ████▄         ▄█▄ ▀███▄         ▄████
  ▀████▄▄▄▄▄▄▄███▀   ▀███▄▄▄▄▄▄▄████▀
    ▀▀████████▀▀       ▀▀████████▀▀
BitCloud  BTDX
A new type of decentralized currency
.
Most  Profitable  Masternode Coin
▬▬▬    • Wallet  • Details  • Exchanges  •Masternode    ▬▬▬
.
.
ANN  Blockexplorer  MN Calculator  ▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬    Twitter  Github  Slack

Sirius receive address:SQusssg3DRrKrEHW26c2skEDYCG7vrj11z
amaclin (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
September 07, 2015, 03:16:35 PM
 #18

More like to somebody Gonna touch your door. Grin
Is joke of course.
For what? I can tell you my home address.
I do not break country laws.
And there are no "laws" in bitcoin protocol. Only math and current consensus.
I can flood the network because I am able to do it. Just for fun.
(In fact, I try not to spend my time for non-profitable things)
defcon23
Legendary
*
Offline Offline

Activity: 1120
Merit: 1002


View Profile
September 07, 2015, 04:29:25 PM
 #19

Wanna hire me for this dirty job?   Grin


More like to somebody Gonna touch your door. Grin                    Is joke of course.



pweee..  man ...

trout
Sr. Member
****
Offline Offline

Activity: 333
Merit: 251


View Profile
September 12, 2015, 07:46:47 AM
 #20

to mitigate such an attack, how about introducing a fee policy (min relay fee etc.) that is based not only
on the size but also on the number of SIGOPS ?

that doesn't affect the  consensus, obviously.

I mean, if both the block size and the number of SIGOPS in it are a critical resource, then it's only natural to charge for using each of them.
Pages: [1] 2 3 4 5 6 7 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!