Gavin Andresen gavinandresen

I need to be able to reliably measure how long it takes to receive a block, validate it, and be ready to relay it to peers.

I'm going to create a benchmarking infrastructure that I hope will give me a way of quickly benchmarking using real-world transaction data.

TODO

Patch bitcoind to create two CSV files containing information on transactions and blocks received. First is written if given -benchreceived=filename argument:

milliseconds,type,hash256

Preventing "surprise" 51% attacks

Disclaimer: these are half-baked thoughts. Until the #bitcoin-wizards crew has had a chance to think about this really hard I won't consider them fully baked.

The idea: can we take advantage of the fact that almost all nodes are well-connected to the p2p network almost all of the time to limit the ability of a 51% attacker to pull off a multi-confirmation double-spend?

Lets start with a well-connected node that has been seeing new blocks arrive approximately every ten minutes at difficulty D. Assume for now that the node can be confident that it is not being Sybil attacked and is on the actual, best blockchain.

Proposal: -alertnotify if there is a large drop in hashing power

Scenario: your node gets isolated from the network, or the network gets split into pieces. Instead of creating one block every ten minutes, the part of the network to which you are connected produces only one block every fifteen minutes.

Detecting and reporting this condition has been talked about for years, but the code has never been written. I propose implementing a new -alertnotify warning that is triggered if fewer than N blocks have been produced over the last T hours (N and T to be selected based on math I haven't worked out yet designed to give a very, very small false positive rate-- e.g. fewer than 12 blocks over the last 4 hours).

Proposed alert wording: "Warning: this node has received only N blocks over the last T hours, you might not be well-connected to the Bitcoin network. You might try restarting with the -addnode option to connect with a trusted, known peer."

Implementation: when receiving a new block with an up-to-date tim

2014-08-18 00:38:47 IBLT BLOCK DIFF: +8 12749 -35 12481 TOTAL: 25230 of 665400
2014-08-18 00:49:35 IBLT BLOCK DIFF: +4 2256 -8 2308 TOTAL: 4564 of 272682
2014-08-18 00:52:46 IBLT BLOCK DIFF: +6 5086 -10 4469 TOTAL: 9555 of 70362
2014-08-18 00:54:19 IBLT BLOCK DIFF: +26 9809 -15 9662 TOTAL: 19471 of 17359
2014-08-18 01:00:29 IBLT BLOCK DIFF: +4 18139 -37 16730 TOTAL: 34869 of 138737
2014-08-18 01:05:53 IBLT BLOCK DIFF: +23 22181 -44 22217 TOTAL: 44398 of 28558
2014-08-18 01:08:47 IBLT BLOCK DIFF: +79 65452 -35 11886 TOTAL: 77338 of 211764
2014-08-18 01:11:07 IBLT BLOCK DIFF: +22 8825 -16 8604 TOTAL: 17429 of 51392
2014-08-18 01:28:18 IBLT BLOCK DIFF: +10 9821 -28 9846 TOTAL: 19667 of 291628

O(1) Block Propagation

The problem

Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."

Now that we are finally starting to see the use of multi-signature and other more complicated transaction forms in applications I think it is time to open up the "IsStandard" transaction rules on the main Bitcoin network.

There are two main risks to doing this:

The risk that one of the seldom-used opcodes has a not-yet-discovered chain-forking bug. I believe that risk to be very low; we have never seen such a bug on the test network (where all transaction forms are allowed) and have never found a bug after writing extensive unit tests.
The risk of opening up a denial-of-service attack (either bloat the blockchain or use an excessive amount of CPU time) via a very expensive-to-store-or-verify transaction. This proposal does not entirely eliminate IsStandard checks to mitigate the potential for DoS attacks.

Proposal

Allow any Script containing 15 or fewer signature operations as a pay-to-script-hash (P2SH) Script to be relayed and mined by the reference implementation.

Task: starting with a bunch of .json files (read from stdin), generate a Google Charts javascript file on stdout.

Reward: CLAIMED!

Spec:

json-to-google-chart utility written in Python 2.7; will be released as public-domain, open source.

Input will be a series of JSON files, one after another, each of the form:

	I had a pull request to announce blocks (send an 'inv') as soon as the block header
	was validated, and not to ban a peer that sends a block with valid POW but
	turns out to have an invalid transaction.

	Here's a better (I think) proposal:

	New message: 'inv?' Sent as soon as a block's header is validated.
	It means: "I've heard about this block, but haven't validated it yet."

	SPV peers or old peers will ignore it (but we should protocol bump to

	#!/usr/bin/env python
	# Copyright (c) 2014 The Bitcoin Core developers
	# Distributed under the MIT software license, see the accompanying
	# file COPYING or http://www.opensource.org/licenses/mit-license.php.

	#
	# Test re-org scenarios with a mempool that contains transactions
	# that spend (directly or indirectly) coinbase transactions.
	#

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA512

	Gavin says: Support the Red Bridge River Park!
	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1

	iQIcBAEBCgAGBQJTRWxvAAoJECnZ7msfxzDBqN4P+wULLefioP6Pq50tsynOktrJ
	FEr67PoD0XpZyhdXUfX68Mn0EMad31RR3ti4i7xpa0NiH83VDWZJfGpn+4zynxkj
	FJUMVr3hgVfbyqwDfyn8i5aPJDIRWC/tErX+tfB0B8uln7W9oOYW/jQalfrpgYfb