ARKdelegates.io
HomeDelegates

alessio

Address: ALessioRJeVFrDBD2tckrT3fTvsZzESocA

Rank

35

Contributes

Voters

82 (82 )

Vote weight

1,420,797Ѧ

Forging

Shares rewards

Payout

unknown

Payout min

0Ѧ

Payout max

0Ѧ

Payout interval

unknown

ProposalContributionsNews

Core-SV-022

Created on: July 2, 2019

Core-SV-022: Delegates could be forced to forge empty blocks and genuine transactions could be evicted from the pool: Unforgeable transactions could fill the transaction pool to prevent genuine transactions being forged as the forging process would retrieve transactions up to the maximum transactions per block size, filter away the invalid ones and return the result. This could possibly return zero valid transactions after filtering if the transaction pool contained more than the maximum number of transactions per block of unforgeable transactions with a higher fee than the genuine transactions. Additionally, sending a high volume of these invalid transactions could evict genuine transactions from the transaction pool at zero cost to an attacker.

Core-SV-021

Created on: June 28, 2019

Core-SV-021: Unverified transactions in bad blocks could purge genuine transactions from the pool: When a block was rejected for failing verification, any transactions from the sender(s) of any transactions in the block were purged from the transaction pool, even if they failed verification. This meant anybody could create a bad unverified block containing fake transactions to delete genuine transactions from that wallet from the transaction pool.

Core-SV-020

Created on: June 11, 2019

Core-SV-020: Race condition resulted in blocks containing already forged transactions: If a node received a high volume of transactions entering the transaction pool in a short time period, it would not filter out all the recently forged transactions from incoming blocks. This meant that when a delegate tried to forge, it may have included already forged transactions in its block, which would then be rejected by the network, causing the affected delegates to miss blocks until their pools were cleaned.

Core-SV-019

Created on: June 6, 2019

Core-SV-019: Block header manipulation in quorum calculations prevented nodes forging: Forging nodes could be tricked into thinking they were double forging, even when they were not. This activated the automatic protection which stopped the nodes from forging. As the delegates were not actually double forging in the first place, they did not produce any blocks. If all delegates were targeted, the chain completely stopped.

Core-SV-018

Created on: May 28, 2019

Core-SV-018: A forged second signature registration did not invalidate existing transactions from the same sender in the transaction pool: It was possible to stall the blockchain by manipulating second signature registrations. It involved broadcasting a transaction from a wallet without a second signature, then registering a second signature for that wallet which was forged prior to the initial transaction being forged.

Core-SV-017: Transactions signed with a second signature prior to the second signature registration being forged halt the blockchain

Created on: April 22, 2019

Core-SV-017: Transactions signed with a second signature prior to the second signature registration being forged halt the blockchain: A node that received a second signature registration, immediately followed by a transaction signed with that second signature prior to the second signature registration being forged in a block, would be unable to forge a new block as the second transaction was accepted by the node and added to its transaction pool but would not validate in a block since the second signature registration was not forged yet. As transactions are broadcasted to all nodes, this would stop the chain until the pools were cleared as nobody would be able to forge a block.

Core-SV-016: Receiving a block containing non-valid transactions causes peers to roll back

Created on: April 22, 2019

Core-SV-016: Receiving a block containing non-valid transactions causes peers to roll back: A received block containing a transaction that cannot be applied causes all peers to roll back. The accept block handler triggered a rollback if a block contained a transaction that cannot be applied, which was unnecessary when it was a case that the current block could not be applied due to the transactions within it.

Core-SV-015: Delayed block propagation causes the next delegate to miss its block

Created on: April 22, 2019

Core-SV-015: Delayed block propagation causes the next delegate to miss its block: If a delegate forged a block but was late broadcasting it, the next delegate in line would forge at the wrong height as it would not have received the previous block. By the time it attempted to broadcast the block, the previous delegate's delayed block would have been received by most (or all) of the network, meaning the newly forged block at the same height would be rejected and thus the delegate would miss its block.

Core-SV-014: Public API endpoint open to possible DDOS attack

Created on: March 19, 2019

Core-SV-014: Public API endpoint open to possible DDOS attack: Endpoint /api/v2/delegates/{delegate}/voters/balances did not paginate its results. This was a vector for DDoS as anyone could request the vote balances of every voter of a delegate in one API call. For delegates with large number of voters (>5000) this could overload the server even before the HTTP rate limiting kicked in.

Core-SV-013: Transactions near to the HTTP POST payload size limit can stop delegates forging and halt the chain

Created on: February 14, 2019

Core-SV-013: Transactions near to the HTTP POST payload size limit can stop delegates forging and halt the chain: The maximum HTTP POST payload is 1048576 bytes but there was no logic to ensure that blocks only contained transactions that would fit in a block below that size limit. It was possible for any network user to send deliberately oversized transactions that would approach (but not exceed) this limit. Although nodes would accept these larger transactions as valid, when it was time to forge them into a block, the additional block headers would make the block size larger than 1048576 bytes. This meant all nodes would reject the block with HTTP error 413 Request Entity Too Large, so the forging node would miss its block and the oversized transactions would remain in the transaction pool, meaning the node would be unable to forge until the oversized transactions expired (the default time being 6 hours).

Core-SV-012: Conflicting delegate registration transactions not detected by the transaction guard

Created on: February 11, 2019

Core-SV-012: Conflicting delegate registration transactions not detected by the transaction guard: A user could try registering the same delegate name using multiple wallets in a single block. It would result in a stalled network because no delegate would be able to forge a valid block as they would all try to forge blocks containing the conflicting transactions. If exploited maliciously, any bad actor could have stalled the network permanently by repeatedly sending conflicting transactions to ensure the transaction pools were never clean so the network could not recover.

Core-SV-011: Malicious delegate 0-ARK transaction spam

Created on: February 1, 2019

Core-SV-011: Malicious delegate 0-ARK transaction spam: The transaction schema to prevent zero-amount transfer transactions was never enforced by consensus, so zero-amount transfer transactions could be sent by a malicious delegate to spam the blockchain.

Core-SV-010: Malicious delegate can cause peers to fork and roll back simultaneously

Created on: February 1, 2019

Core-SV-010: Malicious delegate can cause peers to fork and roll back simultaneously: A malicious delegate could craft a block at the correct height but with a timestamp from a previous round that collided with a valid forging slot time for that delegate in the current round. This has the result that the block would be initially accepted, but, because the block was unchained due to the incorrect timestamp, it would cause the receiving node to immediately enter fork recovery mode and roll back the chain.

Core-SV-009: Fake peers can be added by using non-quad-dotted notation

Created on: February 1, 2019

Core-SV-009: Fake peers can be added by using non-quad-dotted notation: Peers using non-quad-dotted notation representation could be added to peer lists, which provides a denial of service vector as millions of IPv4 loopback addresses could be added to the peer list which will all resolve to the local node which would overwhelm the server.

Core-SV-008: Forged blocks by anyone can cause the chain to stop/or start recovering

Created on: January 25, 2019

Core-SV-008: Forged blocks by anyone can cause the chain to stop/or start recovering: Anyone can broadcast signed blocks, and when receiving a forged block from a wrong generator, the chain would fork. This also applied to inactive (unknown) generators. If a malicious actor kept broadcasting such blocks, the chain would effectively cease operating.

Core-SV-007: Forging multiple blocks in a slot and rewards hijacking

Created on: January 25, 2019

Core-SV-007: Forging multiple blocks in a slot and rewards hijacking: Any active delegate could forge multiple blocks within their allocated 8 second slot time, as long as the block IDs were different and were all sent to the same node with an incrementing block height, as each block was considered to be valid and accepted on the chain. This had the effect of generating block rewards for each of the multiple blocks that were forged in the slot, resulting in inflated rewards per round for any delegate that carried out this exploit.

Core-SV-005: Double forging a block

Created on: January 25, 2019

Core-SV-005: Double forging a block: A malicious forger could forge multiple distinct blocks and broadcast them to different peers causing instability in the network.

Core-SV-004: IP spoofing

Created on: January 25, 2019

Core-SV-004: IP spoofing: The whitelist could be bypassed by IP spoofing due to the way we determined the IP of a request. This could also be used to fill up the peer list with loopback IP addresses to cause a DoS attack and prevent block propagation.

Core-SV-002: Generating new Ark using multi signature transaction

Created on: January 25, 2019

Core-SV-002: Generating new Ark using multi signature transaction: In a multi-signature transaction, the transaction handler only verified the signatures and did not properly conduct balance checks. This made it possible to generate new ARK tokens on the network utilising a multi-signature transaction.

Core-SV-001: Invalid block received

Created on: January 25, 2019

Core-SV-001: Invalid block received: The lastDownloadedBlock variable was not reset when discarding invalid blocks. This caused network nodes to continually attempt to download new blocks from the wrong height, effectively halting the network. This issue would have allowed a malicious user to disrupt network nodes and the network itself.

Delegate Login | Github | v0.9.0