Bitcoin Forum
October 02, 2023, 01:55:03 PM *
News: Latest Bitcoin Core release: 25.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / [Full Disclosure] CVE-2012-2459 (block merkle calculation exploit) on: August 22, 2012, 02:29:49 AM
Since at least 80% of the Bitcoin network is now protected against this attack, I've been given permission to disclose it:

The Merkle hash implementation that Bitcoin uses to calculate the Merkle root in a block header is flawed in that one can easily construct multiple lists of hashes that map to the same Merkle root. For example, merkle_hash([a, b, c]) and merkle_hash([a, b, c, c]) yield the same result. This is because, at every iteration, the Merkle hash function pads its intermediate list of hashes with the last hash if the list is of odd length, in order to make it of even length.

And so, the Merkle root function can be effectively preimaged by changing the input so that one of the intermediate lists is of even length with the last two elements equal (where originally it was of odd length with a last element equal to the earlier mentioned two). As was later noted, this extends to any input length that is not a power of two: merkle_hash([a, b, c, d, e, f]) == merkle_hash([a, b, c, d, e, f, e, f]). Note that to maintain the same root hash, the only flexibility that exists is duplication of elements.

As a result, two blocks can easily be created that have the same block hash, though one can be valid and the other invalid, by duplicating one or more of the transactions in a way that maintains the Merkle root hash. Duplicating any transaction will make the block invalid, since the block double spends a certain past transaction output.

An unpatched Bitcoin installation can be permanently wedged at its current highest block using this and the fact that Bitcoin caches orphan blocks in a disk-backed database. To do so, the attacker must send it a valid block (that will eventually make it into the blockchain) made invalid by duplicating one of the transactions in a way that preserves the Merkle root. The attacker doesn't even need to mine their own block - instead, they can listen for a block, then mutate it in this way, and pass it on to their peers.

Once the victim receives this invalid block, they will cache it on disk, attempt to process it, and reject it as invalid. Re-requesting
the block will not be even attempted since Bitcoin believes that it already has the block, since it has one with the same hash. Bitcoin eventually displays the "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade." warning when the blockchain extends further beyond the received invalid block.

The problem was fixed by Gavin Andresen in Bitcoin commit be8651d [1] by rejecting blocks with duplicate transactions in CheckBlock, preventing them from being cached at all.

Forrest Voight

2  Bitcoin / Development & Technical Discussion / Proposal: New RPC call to get the transactions to be included in the next block on: August 24, 2011, 08:20:57 PM
A new command ("getmemorypool", possibly) that let a JSON-RPC client access bitcoin's transaction pool would be useful. It would help anybody that wants to mine, but compute their own generation transaction instead of letting bitcoind do it.

Initial revision:

EDIT: That revision adds a call "getmemorypool" that takes no arguments and returns a JSON Object with the following members:

* transactions: list of hex-encoded transaction hashes
* fees: integer amount of total fees for those transactions, in satoshis
* previous_block: hash of block that these transactions are valid for following
3  Bitcoin / Pools / p2pool - Mining power pledges on: July 29, 2011, 08:32:15 PM
In order to sidestep the chicken-and-egg problem of bootstrapping a mining pool, in this thread people can promise to put a certain amount of hashing power on the p2pool network when the total pledged is high enough.

P2Pool is a decentralized pool that works by creating a P2P network of miner nodes. These nodes work on a chain of shares similar to Bitcoin's blockchain. Each node works on a block that includes payouts to the previous shares' owners and the node itself. There is no central point of failure, making it DoS resistant.

Forum thread | P2Pool wiki page | GitHub project page

'High enough' should be around 30GH/s, but this is open to discussion. 30GH/s results in an average time-to-first-block of 3 days, with the 50% and 95% percentiles being 2 days and 9 days. Once the agreed upon amount is reached, I'll signal everyone to begin on this thread.

If you're already mining on p2pool, put your pledge in anyway so we can have an accurate total.

Sum so far: 25.68GH/s


I pledge the 410MH/s that I'm already mining with.
4  Bitcoin / Pools / [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 17, 2011, 11:14:22 AM
P2Pool release 17.0 - commit hash: 62fa7b020b82a92138d7652c26be2953b26fd4e5

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary:
Windows binary signature:
Source zipball:
Source tarball:


* SegWit compatibility
* Increased new transactions size limit per share to allow producing larger blocks
* Requires Bitcoin >= 0.13.1

SegWit (segregated witness) **has already activated** and for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded soon enough, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

Due to SegWit already activating upgraded users of P2Pool must not mine SegWit transactions as they are incompatible with older P2Pool versions. After v17 shares activate a new release will be made which removes this restriction.

So, please upgrade to 17.0 now and also tell everyone else to.

P2Pool is a decentralized pool that works by creating a P2P network of miner nodes. These nodes work on a chain of shares similar to Bitcoin's blockchain. Each node works on a block that includes payouts to the previous shares' owners and the node itself. There is no central point of failure, making it DoS resistant.

P2Pool homepage:
P2Pool stats page, made by twmz:
P2Pool subsidies - Several people are donating to all people using P2Pool in order to promote its decentralized nature -
Litecoin P2Pool status -

Things that are not P2Pool (and just people running P2Pool):


P2Pool wiki page | GitHub project page
New: Mailing list for urgent news (updates, bugs):

List of all blocks found:

Getting P2Pool

  • Run bitcoin with the RPC interface enabled - see the next section for instructions on how to do this
  • Download p2pool: (see links at top for binaries!)
    • git: git clone git://
  • Run p2pool:
    • Windows py2exe: run_p2pool.exe
    • Source: python
  • Run a miner daemon (see ) with long polling connecting to on port 9332 with any username and password
    • With all miners, using a high FPS target (30?) or a low intensity (7?) helps a lot with reducing stales.

HOWTO: Bitcoin server mode
You must be running the Bitcoin client, and it must have its RPC interface enabled.

Open the Bitcoin data folder. See

Make a new file named bitcoin.conf (not bitcoin.conf.txt! You might have to go into Control Panel > Appearance and Personalization > Folder Options > View and uncheck 'Hide extensions for known file types'). Paste this into it:


Dependencies for running FROM SOURCE:
  • Bitcoin 0.5.0 or higher
  • Python 2.5 or higher
  • python-argparse for Python 2.6 and lower
  • Twisted (Ubuntu package python-twisted)

Additional options of interest:
    -w PORT: Listen for workers on a port other than 9332.
    -a BITCOIN_ADDRESS: Mine to this address instead of requesting one from Bitcoin.

Last, forward port 9333 through your firewall to the host running p2pool! (Oh, and join #p2pool on freenode!)
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!