Bitcoin Forum
April 25, 2024, 06:13:18 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Fixed vulnerability explanation: Why the signature cache is a DoS protection.  (Read 2650 times)
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
January 14, 2013, 02:23:44 PM
 #1

I read a transcript of  #bitcoin-dev (http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/11/09) where jgarzik and, Sipa debated whether the signature cache was a performance optimization or a DoS protection and why.
The sig cache is both of them. But the sig cache was included before performance was a problem because of the DoS protection requirement.

The following attack against versions prior 0.6.3, e-mailed to Gavin on May-2012, explains it:

1. The attacker creates a transaction that pays 0.01 BTC to 100 different addresses. (The attacker must have 1 BTC). To avoid paying fees, the attacker can divide the transaction into slices, each one below 1 kilobyte.The attacker broadcasts the transactions and waits for confirmation.

2. Afterwards the attacker builds transactions grabbing 100 of his own prevouts and adding an additional prevout that he does not own.  This prevout is a coinbase that has not been matured (it does not need to have a valid signature, since the method exit point is before the script verification). To create many fake transactions, the order of the first 100 inputs is randomized.

3. The attacker sends these transactions to the victim. The transaction size would be around 18 Kbytes. The transaction would take around 0.36 seconds to arrive (with a 50 Kbytes/sec connection).

4. The victim's client app will go with the transaction straight through ConnectInputs() and successfully connect the first 100, and then fail to connect the last. The time required for this check in an average PC is approximately 100 * 4 msec = 400 msec  (an estimation). Then the attacker can hang the vitims app by sending these fake transactions at a rate of around 3 per second. The number of inputs used for the attack is arbitrary (can be as low as 10, giving 10! unique possible transactions).

Note that if the connection bandwidth is higher, then the attack is stronger. If the victim's CPU is slower, then also the attack also get stronger.

I proposed the solution of a signature cache to Gavin at that time. It turned out that Satoshi himself had thought about adding the sig cache, but I think it was mainly for performance reasons.

Best regards,
 Sergio.
1714025598
Hero Member
*
Offline Offline

Posts: 1714025598

View Profile Personal Message (Offline)

Ignore
1714025598
Reply with quote  #2

1714025598
Report to moderator
1714025598
Hero Member
*
Offline Offline

Posts: 1714025598

View Profile Personal Message (Offline)

Ignore
1714025598
Reply with quote  #2

1714025598
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714025598
Hero Member
*
Offline Offline

Posts: 1714025598

View Profile Personal Message (Offline)

Ignore
1714025598
Reply with quote  #2

1714025598
Report to moderator
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
January 14, 2013, 05:01:22 PM
 #2

Also, signature verification (that take a long time and can be repeatedly requested by an attacker), can be used as an oracle to distinguish between two or more different transaction processing results. Without the cache, for instance, attacks like this https://bitcointalk.org/index.php?topic=135856.0 can be executed faster, since the time it takes to process a transaction can be used to locate the exact prevout that fails, in a transaction with thousands of inputs. The cache tries to mitigate the timing side-channel.
Pages: [1]
  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!