gavinandresen

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

gavinandresen

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:

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

gavinandresen

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

gavinandresen

I share an office with Brett McDowell, who is the Executive Director of the FIDO Alliance, and who has lots of experience "with IETF, ISO, ITU-T, ANSI, OASIS, W3C, IEEE and the ETSI ICT Standards Board."

He's not a coder, he spends his time working on consensus, process, politics, etc-- all the stuff us coders tend to hate (but is necessary for mature real-world technologies).

I asked about his experience with standards-setting meetings-- my only experience is with the ISO standards process (which is horrible and bureaucratic and a path we do NOT want to go down)-- and our discussion made me even more pessimistic about the upcoming Montreal meeting. I'm hoping maybe we can have a little pre-meeting discussion that might make next week's meeting more productive for everybody.

A few things that came out of my discussion with Brett:

It would make sense if the first meeting was all about gathering requirements. But there needs to be somebody neutral (and trusted to be neutral) to do the gathering, and commit

gavinandresen

Background: Satoshi mostly implemented a 'headers only for initial block download' mode. See the fClient flag in the source, and the headersonly github branch.

The goal is to make newbie bitcoin users startup experience better-- it is painful to wait a day for the block-chain to download and verify.

The observation is that if you have an empty wallet and you aren't solo mining, you don't care about past transactions, you just need the best block chain. So bitcoin can just fetch block headers until it catches up with the current block, and then download and verify full blocks after that (once it shows the user a bitcoin receiving address, they might get transactions to it, so bitcoin has to fetch full blocks after the first time it starts up).

As I finish the implementation, I'll keep this gist up-to-date with issues or re-thinks.

---

gavinandresen

gavin$ src/bitcoinxt/src/bitcoin-cli -testnet getpeerinfo | grep subver
        "subver" : "/Satoshi:0.8.6/",
        "subver" : "/Satoshi:0.9.3/",
        "subver" : "/Satoshi:0.9.99/",
        "subver" : "/Bitcoin XT:0.11.0B/",
        "subver" : "/Bitcoin XT:0.11.0C/",
        "subver" : "/Bitcoin XT:0.11.0B/",
        "subver" : "/Bitcoin XT:0.11.0C/",
        "subver" : "/Bitcoin XT:0.11.0C/",
        "subver" : "/Bitcoin XT:0.11.0D/",

gavinandresen

TEST PLAN TITLE

Submit completed tests and debug.log files to: {Name <email>}

Version tested: {0.x.y release candidate N, or git commit}

Test environment: {Operating System or other relevant info}

gavinandresen

Transaction fee handling is quickly becoming an issue, due to several factors:

1. Bitcoin prices rising.
2. Transaction volume increasing, and competition for space in blocks beginning.
3. People with too much cash on their hands deciding to bloat the blockchain with data.

I propose the following band-aid, quick fix for the 0.8.2 release:

Modify the definition of CTransaction::IsStandard() as follows:

gavinandresen

Network/miner fee policy migration plan

Introduction

Changing the fees required for transactions to be relayed across the network and/or accepted by miners into their blocks requires care; policy mis-matches can result in users' transactions never confirming, either because they never reach a miner (they are not relayed) or because they are rejected by miners.

I have been working on simplifying the transaction fee rules for the 0.9 release; this document is intended to capture all of the details needed to make that transition as smoothly as possible.

The general idea is to make sure the transaction-generating code (the wallet code) is conservative, and generates transactions compatible with the previous version's rules. The relay and mining code is changed more aggressively, to anticipate future releases.